News:

Want to praise Simutrans?
Your feedback is important for us ;D.

If the value of factory's pax or mail demand overflows, no pax generated

Started by poppo, April 06, 2026, 07:17:20 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

poppo

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

prissi

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.

poppo

my test factory pax_level is 65535 and city population is about 99999.
I will check with latest version later.

poppo

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?

prissi

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.

poppo

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.