Make Lua city_size_change signal consistent wrt (City).size
When the "city_size_change" Lua signal was originally added in gna bug #24115, cazfi wrote:
Looking at the code, this is still true, but it doesn't look like it has to be; on a quick look, all the signal sites now look to me like they could easily be rearranged to go one way or the other (this code has been rearranged a bit since it first went in).
Note that city_size() is practically undefined at the time of the signal execution (the change might be already applied, or not)
- city_reduce_size: signal before change
- city_change_size: signal before change
- city_populate: signal after change
- do_city_migration (1): signal before change
- do_city_migration (2): signal after change
- city_add_unit: signal before change
I think we should probably standardise on signal before change (avoiding awkwardness when the change is to size 0).
If it's harder than it looks, we should instead add the above comment to the Lua reference manual (which I was about to do when I disappeared down this rabbit hole).
We should probably get this stable before 2.6.0.
#4 Updated by Jacob Nevins about 1 month ago
(...and FTAOD I think that's correct; emitting city_size_change in this situation would be needlessly confusing. NB city_size_change is not emitted even if the unit builds a city of size>1, even though that's implemented internally as create-then-grow; a script that cared would have to hardcode behaviour or infer that this had happened from the city-builder's unit_lost signal.)
Jacob Nevins wrote:
I don't think so (only "city_built").
Yes, for some time I simply mapped radius_city_built() to radius_city_growth( 1 ), just because size 2 wasn't reliable wrt "add to city" size changes. Later I replaced it by some "last biggest city size seen per player", because all I want is ONE tutorial message for biggest city size 2, 5, 8, ..., 17 per player.
Likewise I let radius_city_destroyed() call radius_partisans( city, loser, destroyer, 1, 1 ) if the loser wasn't the destroyer.
JFTR, because it's not obvious for me, and I wasn't aware of Gna! 24115: If I get a new city_size_change( city, change, reason ) I can emulate an old and now fixed city_growth() by calling an existing radius_city_growth( city.size + change ) for any change > 0. Please holler if that's wrong, I want the same script.lua working for 2.4+2.5+2.6 (and later 3.0), but of course with all deprecations honored.