[patch] make city growth proportional to months, save partial growth

[neroden]

This makes city growth proportional to months, not ticks.  It also saves less-than-1-citizen city growth, starting with version 112.9.  You can of course change which version starts saving the value.

This solves a problem I was encountering in timeline games with paksets with large values for ticks_per_month.  City growth was proportional to ticks, not to months, so it was going very, very fast in terms of the number of years in the timeline, making it hard to play a long many-year game.

This slows it down to match the rate per month used in 88.x when the code was written.  It also saves "partial" city growth -- less than 1 citizen -- in the save file, because otherwise low growth rates may round down to zero and cause no growth.

You may wonder why I am storing the less-than-1-citizen city growth in a signed 64-bit variable rather than a 32-bit variable.  This is to make it easier to implement different city growth systems later, including:

   
• systems with very slow rates of growth, which need lots of precision in order have them come out to the correct numbers over long periods of time.  (I am planning to implement an exponential system, and it needs at *least* 25 bits of precision, probably more.)
• systems with negative growth (shrinking) -- this is why it is signed.  I think this would be a fun thing to implement.
• systems with large growth per city growth interval (perhaps with large city growth intervals)

Being able to do all of this with the same code led to the conclusion that I needed 64 bits.

The "new_town" variable is passed down through various levels of code, rather than being guessed based on population, in order to avoid certain false positives which can otherwise happen when the player is doing weird things with the public service tools.

In addition, when the public service tool is used to shrink cities, it shrinks to a minimum of 1, avoiding certain weird behavior.

I have plans for further city growth changes, such as the exponential model I mentioned, but this is the only part which will require savegame changes, and this fixes the main bug I was encountering.

This will change city growth rates in any pak which has bits_per_month != 18, but I believe it will change them in a desirable way.

[kierongreen]

Seems reasonable to me... Worth pointing out that this should have no real impact on pak64 since that uses bits_per_month of 18 (although maybe will be more accurate with storing partial city growth). Can't see any reason not to add to trunk but will wait to see whether anyone else wants to comment...

[prissi]

This will result in very slow city growth in real time. So this is a hardcore setting, while caual gamer want to see city growth in half an hour at least. Therefore, I personally would rather have configurable. But especially for network games slower growth seems quite desirable. In any case a more precise calculation seems a very good idea, as it woudl allow for lower factro altogether.

The name "unsupplied_city_growth" is probably just a relict from experimental. Why did you need to explicitely add the new_town parameter to  change_size()?

[kierongreen]

The name "unsupplied_city_growth" is probably just a relict from experimental.

As neroden is writing this for both experimental and standard it's actually in neither at the moment (confirmed checking at jamespetts experimental repository). Rather it's his translation (and replacement) for wachstum.

[neroden]

This will result in very slow city growth in real time.

It will have no effect on pak64.  On other paks, it will have the effect of making them independent of bits_per_month.

So this is a hardcore setting, while caual gamer want to see city growth in half an hour at least.

The gamer can always set the game to run at a higher speed, 2.0 or 4.0 or whatever.  :-)

Therefore, I personally would rather have configurable.

I hope to make the actual rate of city growth configurable, later.  This separates that question from the question of how often the city *checks* for growth.

But especially for network games slower growth seems quite desirable. In any case a more precise calculation seems a very good idea, as it woudl allow for lower factro altogether.

The name "unsupplied_city_growth" is probably just a relict from experimental. Why did you need to explicitely add the new_town parameter to  change_size()?

It is possible to end up with a town which is not a new town but has zero population (for instance, through manual building demolition), and likewise it has occasionally been possible in certain versions to end up with a town which is a new town but does not have zero population (in some pretty weird ways).  This gives *odd* results when it is passed through to the routines which check for building monuments etc. and has created hard-to-identify bugs in various branches in my past efforts.  It was much simpler and more reliable to just pass the flag down from the two (2) places where new towns are created.  Passing a boolean variable on the stack has very little overhead.

Regarding the speed of city growth, I thought that we should make the "check for city growth" tick count (city_growth_step) independent of the actual growth rate.  So we can check less often if it is too computationally intensive, or more often if it seems like all the growth happens in bursts -- without changing the actual *rate* of city growth. 

I have further plans to make the actual rate of city growth configurable.  This patch is simply a first step.  My next step was to replace the algorithm which decides how much a city should grow, but I figured that part would be controversial and might be different between standard and experimental.

[prissi]

How could you end up with a city with bev=0? The townhall is always level 1 at least, and demolition of the townhall will remove the city. Furthermore, the actual bev (not the displayed one) must not be reduced or else all attraction will appear multiple times in a town which shrinkes and grows.

But then I have to read your code more closely to see if you resolved this differently.

[neroden]

How could you end up with a city with bev=0?

It is not possible in my current code (note the change I made), but in the previous code it was possible with the "reduce size of city" tool which is present in some paks. 

It is simply cleaner and less error-prone to pass the new_town flag down.

The townhall is always level 1 at least, and demolition of the townhall will remove the city.

That's an option which we may want to change in future (to allow relocation of townhalls, etc.)

Furthermore, the actual bev (not the displayed one) must not be reduced or else all attraction will appear multiple times in a town which shrinkes and grows.

I plan to fix that bug later by changing the way attractions  (and factories) are triggered to prevent that.  That bug *is already present*.  However, I have to get this patch committed first, prissi.

---
Shrinking cities does not behave quite right now.  I am not quite sure how to make it work right and it will require some trial and error.  But I know that I need this patch to go in *first*.

[Ters]

That's an option which we may want to change in future (to allow relocation of townhalls, etc.)

Town hall relocation is something the game already supports and makes use of. There is just no tool for it (yet).

As for the patch itself, it can be that players want to have calendar time run more slowly, but everyting else (vehicles and city growth) should run at usual speed. Perhaps because they like to stay in an era longer. Isn't this what one can do by changing bits per month now, but that will stop working? (I guess finances will be somewhat out of balance by the slow passage of months, but not all players care about the money.)

[kierongreen]

(Optionally) slowing down city growth is definitely needed. I know it's one reason I give up on games after a while. simuconf option to scale city growth would be my suggestion (whether that uses same values as bits per month - default 18, 20 is 4 times slower, or whether it is just a multiplier I don't really mind).

[prissi]

Submitted, with only little changes.