News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Maintenance overflow

Started by Antarctica, July 18, 2017, 05:52:47 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Antarctica

My monthly maintenance has just become negative. Somewhere around 86 Million credits a month it silently overflows to -86 million.

86 million is so uncommon a number. Somewhere around 1.25 * 2^26. Now I wonder: what data type are you using there?






Ters

Well, first of all, it is not 86 million that is the relevant number in your finances, but 8.6 billions. That is still twice the value where you could expect overflow.

prissi

Another point I never expected people to ever reach. Same surpricse when in 2004 (and then without any real means to accelerate the game) a Japanese player complained in crashes in 2236, which was the overflow of the game time at that time. (That must have been close to eight months real time!)

But back to your troubles: Is the mainenance really negative, or is this only a conversion problem? (Is there sudden positive influx of money at the end of the month and not reduction as expected?)

Because the maitenacne should be a sint64, in 1/100 of credits, which gives a limit of 92,233,720,368,547,758 or 92 quadrillions. I rather suspect some of the conversion routines into float (which is used to actually display such big numbers) ran into trouble.

To run into the negative maintenance barrier, you need 2^31 objects, with the maximum maintenance cost  of 2^32-1. Since this is unlikely, maybe there is some trouble with the savegame? But I most likely suspecct the display routine.

Ters

I can't see anything wrong with the display routines, but it might be a compiler bug, or even a random runtime bug. An attempt to put the algorithm into a small test program worked fine for 8600000000 centicredits.

Antarctica

#4
I think you should check the routines adding up maintenance cost, not the display routines, because

- the displayed Maintenance is shown as a positive value,
- the displayed Operational profit at the start of the month is shown as a positive value,
- the displayed Net Wealth makes a jump up (not down) at the start of the month.

Version is rr8249, by the way.



Does it help you if I mention that when it overflowed, I was building tunnels, or is the maintenance calculation function always the same for all objects?

QuoteSame surpricse when in 2004 (and then without any real means to accelerate the game) a Japanese player complained in crashes in 2236
I thought that in 0.80, HaJo already added the possibility to increase simulation time in steps of 0.06? I remember reporting to him a bug that caused lags if you reduced the game speed to 0.13 and increased it to 1 again. Let me see if I find that version on my disk... just to see that we've come such a long way in these nearly 20 years.

An_dz

Couldn't it be an overflow in another number that compose the maintenance number? Like some sint16 of a line with many vehicles.

I think we would need the savegame to debug.

Quote from: Antarctica on July 19, 2017, 03:29:29 PM
Does it help you if I mention that when it overflowed, I was building tunnels, or is the maintenance calculation function always the same for all objects?
It does, but then Ters might be right, a random runtime bug.

Antarctica

#6
I am not sure I want to provide the savegame. If I decided to, where should I upload it?

Does Google Drive suffice?

Quote from: An_dz on July 19, 2017, 03:38:57 PM
Couldn't it be an overflow in another number that compose the maintenance number? Like some sint16 of a line with many vehicles.
Only stations and tracks contribute to the Maintenance total, convois only to Operation Costs. The overflow occurred while the game was paused and I was in underground mode, building new tunnels.

Ters

The strange thing is that the absolute value stays at about eighty millions. Most situations that I can think of that changes the sign would also change the value significantly, unless the value was very near 27, 28, 215, 216, 231, 232, 263 or 264.

Going from about 85899345.92 to about -85899345.92 can happen if four (or eight?) different events each overflow a 32-bit value which are then added into the 64-bit sum one by one.

Dwachs

#8
maintenance is sint32 in finance.h ...

Edit: this savegames takes ages to load, in particularly the stations...
Parsley, sage, rosemary, and maggikraut.

TurfIt

and sint32 per transport type, so if only rail maintenance overflows, road maintenance would still be correct, and the summation shown in the finance screen would be at a non 2^x wrap around point...

Ters

It can also be scale_with_month_length that is messing things up, perhaps?

Dwachs

Parsley, sage, rosemary, and maggikraut.

Antarctica

Quote from: Dwachs on July 19, 2017, 06:35:43 PM
Edit: this savegames takes ages to load, in particularly the stations...
For that very reason, I stopped rebooting my computer every night.

Ters

Quote from: Dwachs on July 19, 2017, 07:10:21 PM
no, this is fully sint64

I was thinking that it masked the actual overflow value. That the raw value in the finance member variable actually is near one of the power-of-twos I listed, but is then turned into this 86 million figure.

Dwachs

Please recheck with r8269 (use nightly). This should fix the overflow issue. It should also speedup the loading process for this savegame.
Parsley, sage, rosemary, and maggikraut.

An_dz

Ok, this makes sense, money is saved with cents so with sint32 it can only hold -21 474 836,48, four times this and it's -85 899 345,92 or ~86 millions.

Antarctica

Yes, rr8269 fixes the overflow issue. Thank you!

prissi

Still strange, since this game uses only trains. So it have already should overflow at 2^31/100 ... Maybe some month length arithmetic doing their thing in between.

Anyway, solved.