I think not the actual values(properties and possibly commerce) cause overflows but possibly some calculations do. If the resulting values of the properties become to high in later eras they are probably just not balanced right. Commerce values are different because they can only reach MAX_INT/100 e.g. we already had some problems with Culture after MrAzure added those CultureLevels.
Even if we attempt to fix things by hedging against those x100 effects it still only buys us a few digits which in the extended vision of the game doesn't buy us nearly enough. However... this next comment may explain a lot about the gold problems:
World Bank adds a (hidden?) x% (I think it was 5%) interest per turn on gold in the bank. At one point interest gets higher than any spending and that snowballs until gold reaches 32bit integer and goes to 0.
Yeah that would cause big issues considering the national gold totals we tend to end up with right now. Perhaps it should simply be changed to a % modifier in all cities rather than this kind of compounding effect. That'd probably go a long ways towards helping.
If we don't extend the national value to a long long we'll be up against more problems down the line though. Until we do figure out how to drag at the late game gold values more.
Which leads to:
Gold imbalance was adressed in past few months and need serious look. I think when I end with EDU (its almost ended) Ill try to create serious raport about gold income and Ill try to find solution for this problem.
I've got the game acting as it should theoretically. What then becomes problematic is that this means we would really need to go through all buildings (or perhaps some national level modifiers and/or civics that may be presenting imbalances) and target some for adjustment so that we can recover some improved balance. These are the tougher ways to address these issues. But at least the problems shouldn't be in the code at this point. That gives us the correct platform to begin to work from to rebalance.
I may not be at my modding computer but I found two pieces of code missing from the pedia for routes. Unfortunately it is still not working. I get the following error.
Code:
Traceback (most recent call last):
File "CvScreensInterface", line 443, in pediaMain
File "SevoPediaMain", line 314, in pediaJump
File "SevoPediaMain", line 399, in showContents
File "SevoPediaMain", line 796, in placeRoutes
File "SevoPediaMain", line 1013, in placeItems
RuntimeError: unidentifiable C++ exception
ERR: Python function pediaMain failed, module CvScreensInterface
@Thunderbrd can you have a look at this. Last time the wigets were in the wrong order
and part of the problem this time was I was using the wrong one.
Soo... I'll take a look but you do realize python isn't my strong point.
We currently have constant sources that add or remove from the system total, decay that removes a percentage of the system total each turn and moves it towards 0 as total sum and diffusion which does nothing to the total sum (it just distributes it different). When no further sources and drains are added, it moves towards a state of flow balance.
If it is calculated well, that is (which it currently is not good enough but I will get to that later). A strict limit in the values can disturb that. Of course there is the possibility to have some weaker limits like a stronger decay on negative values.
The dynamic properties are solved once per turn, regardless if they changed or not.
Multiple threads are indeed used. Propagators and sources are split among the threads.
Order only matters in regards to percentage based manipulators like diffusion and decay. The order of the constant sources does not matter at all. It might well be that a cut after all property calculations once per turn works well. Depends on a try. But it definitely has to be considered where exactly to apply it.
All property manipulators compute their delta on all properties on all objects. This is then summed up on each object and afterwards all property manipulators get a chance to revise their delta. The result is then summed up again and actually applied.
So, even theoretically, is it possible to introduce hard limits to property values on particular game object types without causing problems? I can't honestly say I follow the math here very well at all but it would seem to me that we could make more useful systems if we could create xml defined limitations to how great or low the total property values can get on given objects.
After careful consideration I don't actually think that we have a case of integer overflow as the cause. It can happen as a result but the amount of sources needed for it to be the prime cause would be excessive (anything up to 5 million per turn added in a single city should still work and what would be the point of it with only up to around 1000 having a real effect).
My prime suspect is the diffusion propagator on trade routes. The problem is that trade routes are not symmetric and neither is the diffusion propagator. A single application of it only works in one direction. So we get a maze of one way diffusions with some cities being the target of a huge amount of trade routes.
If that city is then very low on crime while the other cities are not, the difference causes a moderate flow of crime from each of those cities which sums up to a number that rivals the difference in the first place. The revising step is not strong enough to counter that so the city ends up with high crime after a single turn. The net effect is that crime is now more concentrated than before and some strong trade cities will start to oscillate between high and low crime.
For now I'd suggest to remove the diffusion to trade cities until some counter measures are made. It did not make sense in the first place for properties like pollution anyway.
There's been some thoughts about this that were nagging me that you hit square on the head here. It was surprising to me that we could get an overflow like this on properties at all given that it's just so extreme a level and we have decay factors and... it just didn't seem like it should be possible so something had to be wrong in the processing if it were taking place. And I've seen numerous reports about wildly swinging values in some cities making the whole system seem completely messed up.
It was seeming like properties could somehow hit a point where they were like sloshing water in a glass back and forth and what you described explains it perfectly. That seemed to be the biggest issue there.
Unfortunately, you're not saying what I was hoping to see... that you had a solution for dampening this effect in mind. So for now we just turn trade diffusions off in the xml to address this then huh? Fair 'nuff I suppose. I hope we can come up with some way to get trade to affect things without it creating such an oscillation effect though.
EDIT: It sounds like with the trade effect we have generated 'Flubber'... every time it bounces out from the city it bounces back with greater strength. Ironically, the tougher you fight the property, the worse the effect, which means the harder our players have been trying to control their crime the more wild the values become because they have been able to push the swing harder and harder with all their efforts. Sheesh... no wonder our crime values were frustrating Joe and Vokarya so badly - the harder you fight it the more wildly out of control it would get (though would be doing GREAT every OTHER round... lol)
