Quantitative Resources

[EviltheMonkey]

There is a possible implication of QR that I've been mulling arround in my head for a while and I'd like to know what other people think of it.

Luxury good are defined in real life largely based on their scarcity as opposed to any inherent material value. As such it would make sense to tie the bonuses of some resources to their quantity, for example in small quantities almost any food stuff could be considered a luxury and would therefore provide but if too much becomes available it losses its luxury status and becomes just another staple crop. It shouldn't be too hard to introduce a negative happiness bonus to cancel out the as the novelty wares off (ie when more of the resource is available).

What I am thinking is more complicated (and maybe undo-able), is linking a resources in-game status to its quantity (for the purposes of adding additional bonuses from markets etc.)

Thoughts anyone?

 

[Gaius Octavius]

It is a very interesting idea about luxury units, and kind of makes sense. Rarity = greater value. I'd have to think about how to implement it.

I have started to consider porting this to the SDK instead of Python, since it's liable to increase the overall speed. A few questions:

In CvCity.cpp, there are instances such as "case ORDER_TRAIN:", "case ORDER_CONSTRUCT:", and "case ORDER_CREATE:". Are these the functions which control the assignment of a unit/building to the city queue? What I am thinking is that these will be the best way to reset the stockpiles. (Of course, when you remove something from the queue, the resources have to be added back, and I do not know if these are appropriate for that.)

Also, if someone could tell me how to utilize the pickle script to store stockpile arrays in a saved game, that would be very helpful. Ever since the wiki went down there is no good reference of all the Python and SDK commands.

 

[Ambreville]

Anything new on this topic??

 

[Dom Pedro II]

I have started to consider porting this to the SDK instead of Python, since it's liable to increase the overall speed.

Very much so... If you can, do this.

In CvCity.cpp, there are instances such as "case ORDER_TRAIN:", "case ORDER_CONSTRUCT:", and "case ORDER_CREATE:". Are these the functions which control the assignment of a unit/building to the city queue? What I am thinking is that these will be the best way to reset the stockpiles. (Of course, when you remove something from the queue, the resources have to be added back, and I do not know if these are appropriate for that.)

The switch/case is used like a series of if/then statements.

So instead of saying:

if (eOrder == ORDER_TRAIN)
{
      "do stuff";
}
else if (eOrder == ORDER_CONSTRUCT)
{
     "do other stuff";
}

You have this:

switch(eOrder)
{
case ORDER_TRAIN:
"do stuff";
break;
case ORDER_CONSTRUCT:
"do other stuff";
break;
}

Doesn't really save a lot of time with two things, but if you have 5+, it can be really handy.

And basically that refers to what you're telling the city to do. I'm not sure if this has anything to do with the queue, but I know it's used elsewhere for other things.

You would use the above function if you wanted the program to do different things depending on the order type you give it.

 

[Gaius Octavius]

Okay, so basically where do I control what happens when a unit/building gets assigned to or taken off the queue?

My original intention in Python was to have the game check to see if there were enough resources each time it populated the list of things you can build, which is accomplished through CannotTrain. Trouble is, in order to do that you have to keep track of how many resources have been earmarked for construction already, in conjunction with your "true" stockpile. That means doing lots of recalculating each time the city queue pops up... for 100 units looped through 7 resources, it's not a good recipie for speed.

So now what I plan to do (since I'm aiming for the SDK) is to have the game automatically deduct the resources from your stockpile when you assign something, and have it put them back if you take it off the queue. To do that, I need to find out where the assignment function is controlled in SDK. Plus, it has to be the one that controls both the AI and the human player's queues - I assume there's a separate routine that governs the interface/display for the human (partly in Python) and that's not what I need here.

 

[Dom Pedro II]

Okay, so basically where do I control what happens when a unit/building gets assigned to or taken off the queue?

No clue. But give me a couple hours and I can probably get an answer for you (don't have my SDK files with me).

My original intention in Python was to have the game check to see if there were enough resources each time it populated the list of things you can build, which is accomplished through CannotTrain. Trouble is, in order to do that you have to keep track of how many resources have been earmarked for construction already, in conjunction with your "true" stockpile. That means doing lots of recalculating each time the city queue pops up... for 100 units looped through 7 resources, it's not a good recipie for speed.

It has to run through that to determine if you can or cannot build a unit now anyway, so it should have a teeny, tiny difference in speed (faster than a human being could perceive). At least if you do it through the SDK. I mean, if you just store the stockpile quantity, it shouldn't be much more code or calculation time than returning a boolean value of whether it has or does not have the resource in question.

So now what I plan to do (since I'm aiming for the SDK) is to have the game automatically deduct the resources from your stockpile when you assign something, and have it put them back if you take it off the queue. To do that, I need to find out where the assignment function is controlled in SDK. Plus, it has to be the one that controls both the AI and the human player's queues - I assume there's a separate routine that governs the interface/display for the human (partly in Python) and that's not what I need here.

Well, my recommendation with taking and putting back resources is to only put back a portion of the resources if you take the item off the queue and take the same portion of the resources if you put it back since removing it from the queue doesn't actually get rid of the invested production.

Just something to keep in mind.

 

[Dom Pedro II]

To answer the first question: It looks like it has to do with the popOrder and pushOrder functions. Check there. Unfortunately, I'm a bit too swamped to really go more in-depth than that basic analysis.

 

[Gaius Octavius]

It has to run through that to determine if you can or cannot build a unit now anyway, so it should have a teeny, tiny difference in speed (faster than a human being could perceive). At least if you do it through the SDK. I mean, if you just store the stockpile quantity, it shouldn't be much more code or calculation time than returning a boolean value of whether it has or does not have the resource in question.

In the SDK, yes, which is why I wanted to do it that way. Basically, in Python and using CannotTrain, the only way to do it would be to check how many of every unitclass you are making and then output the "new" stockpile for each resource. Then, if there is enough to start a new unit, return false.

The trouble is that this is called for every unit, so you are literally looking at every unit repeatedly - once to see how many a player is building, and then again to see if you have enough resources to build it. A hundred units would be 100 x 100 calls... And you can't simply check once at the start of the turn, because it has to be adjusted for each assignment you make during the turn.

Jeckel suggested I use a better recursive system but that proved tricky enough that I decided to go with the direct deduction in the SDK, if I can find it.

Well, my recommendation with taking and putting back resources is to only put back a portion of the resources if you take the item off the queue and take the same portion of the resources if you put it back since removing it from the queue doesn't actually get rid of the invested production.

Just something to keep in mind.

We shall see.

To answer the first question: It looks like it has to do with the popOrder and pushOrder functions. Check there. Unfortunately, I'm a bit too swamped to really go more in-depth than that basic analysis.

Hmm... I'm just wondering, since by the name popOrder and pushOrder, it sounds like that relates to the UI, so will it affect the AI?

 

[Dom Pedro II]

Hmm... I'm just wondering, since by the name popOrder and pushOrder, it sounds like that relates to the UI, so will it affect the AI?

No, it's not related to the UI. The popOrder function is called, for example, from the clearOrderQueue() function which basically removes all of the production items from the building queue. But it doesn't just clear the whole queue though... it seems to be used to clear out each order node. So I would assume then, that if you tinker with that function, you can get it to also add any resources back into the resource stockpile.

 

[Gaius Octavius]

Here is an update on what I plan to do over the next few weeks.

Because of the many similarities between Duke176's oil counter and generalized quantified resources, I have decided to start work there. This will help all those modders who want realistic oil supplies (say, for WWII scenarios, which is my own area of interest) to utilize it as a separate entity if they don't want the full Q.R. system.

Oil Movement Counter Reqs
Provide X amount of oil per turn
Store the supplies in a player's stockpile
Check that stockpile upon moving a mechanized unit and deduct from it when appropriate
Prevent movement if the stockpile runs low

Quantified Resources Reqs
Provide specific amounts of each resource per turn
Store those in several stockpiles
Check these stockpiles when creating new units/buildings and deduct/return resources when new ones are added/canceled in the queue
Prevent construction if there are insufficient resources


This is likely going to take a long time to flesh out, but the tutorial that Duke176 wrote is a good start. I am confident in my own ability to handle the SDK, but the only thing that concerns me is that I don't have a debugger. That will make things much more interesting once we enter the testing round.

There are two other prereqs for this to work well: I will have to modify the interface (which I have already done) and I will have to expose the variables to Python in order to use them correctly. (I'd also like to be able to change the stockpiles in Python with events, but that can wait.) Maybe this sounds rather trivial, but since this is my first real foray into the world of C++, I'll have to check that tutorial I saw lying around somewhere about exposing functions to Python to make it work.

In short, it looks as though things are progressing, if ever so slowly.

 

[keldath]

Gaius Octavius,
hey,
i hope to see this lomg awaited modpack come to be.

 

[Gaius Octavius]

Gaius Octavius,
hey,
i hope to see this lomg awaited modpack come to be.

Yeah, me too. It'd be quite a coup if we can pull it off. Even the oil resource alone would add an entirely new dimension to the game.

Unfortunately, I have not yet had time to do much, although I did look through Duke176's oil code. There's a lot there that isn't in the tutorial, and I think I can actually simplify some of it to make things more streamlined.

 

[Jerrymander]

Hey, I remember throwing this around last summer. Good to see progress.

 

[Gaius Octavius]

Pseudo-update on the progress: I haven't been able to get any work done on this, partly due to the pace of innovation on the forums as of late. However, Grey Fox's fuel modcomp looks to be precisely what I need, and I'll probably end up using it as a base due to its coding similarity.

On another note, somebody volunteered to help me out in C++ with debugging, but I have since forgotten who it was and lost his name. If you are still interested, rest assured the project is not dead. Perhaps I can get this rolling soon!

 

[Mylon]

Pseudo-update on the progress: I haven't been able to get any work done on this, partly due to the pace of innovation on the forums as of late. However, Grey Fox's fuel modcomp looks to be precisely what I need, and I'll probably end up using it as a base due to its coding similarity.

On another note, somebody volunteered to help me out in C++ with debugging, but I have since forgotten who it was and lost his name. If you are still interested, rest assured the project is not dead. Perhaps I can get this rolling soon!

If you want, I can give you some code I wrote for my Frontier Awaits project. I had originally planned to make resources a discrete (and localized) resource so I added in some bits to do it. I had down the ability to generate a resource with a building and have it accumulate in towns (as well as making sure negative resource values were not affected by multipliers), but hadn't put any code into how to spend it and such.

Right now I'm working off of clean code to incorporate the combat model, as I had decided the finite resources _might_ not be the way to go for my particular project.

If you're interested, I can post it, though.

 

[jefmart1]

What about limiting the number of buildings by the number of a resource you control? For example, if you have 3 sources of Cotton, you could build a Weaver in 3 cities?

 

[Gaius Octavius]

Mylon: Sure, I don't see any harm in posting it. Might prove useful.

jefmart1: What happens when you no longer have 3 sources of cotton? You can't automatically just lose the building, since production chains would be upset by it, especially when you have two different buildings requiring the same resource.

 

[Gaius Octavius]

Latest update for those still following this project.

I have managed to quantify Grey Fox's fuel modcomp, so that now your ability to create a unit (soon to include buildings and projects as well) is based directly on your stockpile and only indirectly on your access to oil. If you have a connected resource but a rather limited stockpile of oil, it will limit your production capability until you build up reserves; if you have no connected oil sources but huge reserves, you'll still be able to make tanks, planes, and battleships.

Basically, I overrode the CanTrain function in C++ so that the game now checks your stockpiles before it decides whether you can train a unit. Grey Fox had already done this, but his modcomp had a major drawback in that if you lost access to oil, you would lose the ability to train the armies that needed it, even if you had 10,000 drums lying around. That now is no longer an issue. I also added a second tag in XML to set individual movement costs, so that a battleship could use 3 oil/turn and a smaller destroyer might use only 1 oil/turn. This is not really necessary since you could simply adjust their overall ranges to achieve the same effect, but I threw it in anyway.

The next step will be to generalize this to all strategic resources. I think I can do this easily enough, though it will take time (as always). Just getting this far has been a major step, since we've now got all the necessary ingredients for a truly quantified resources system. The only thing that I lack is the ability to train the AI to respond to it in any detail, but that will have to wait anyway.

 

[MikeJep]

awsome cant wait

 

[faichele]

Hello!

Good to see there's work progressing on this idea.
Do/would you still require help with coding?