When pax_level is very large, production level is large(about 9999), and city size is also large, pax&mail demand can overflow.
pax_level_overflow.png
If the value overflows, pax or mail are not generated (because the value is treated as "not larger than 0").
do_not_generate_pax_if_overflow.png
Since such a big number are not really practical, I will cap the demand at 932,067 (2^23-1)/9. However, I fail to create these numbers in a test game. So please test the latest revision.
my test factory pax_level is 65535 and city population is about 99999.
I will check with latest version later.
Thank you! I check the fix of overflow!
But I have some questions:
The default production_pre_month value in factory_edit_t is already scaled with month length.
Why is pax_demand of factory also scaled with month length in fabrik_t::update_scaled_pax_demand() again?
And why the limit range of the production value in factory_edit_t is not dependent on the month length?
The limit is due to the 32 bit arithmetic before scaling. Honestly, asking for 1 million workers/customer per month is not a factory ...
The production is per fixed time interval. If a month is longer, then there are more of those intervals => nothing needs to be scaled. So some values have to scaled (like how many passengers per month to display) while the things per production intervall do not need scaling.
But of course, errors are always possible, that code had become quite complex with all the just_in_time stuff.
OK, I understand.
In factory_edit_frame_t, they use this value as prod_per_month, but when call build_factory, they call inverse_scale_width_with_month_length(), so this value treated as prod_per_unit-time.