The International Simutrans Forum


Author Topic: 64bit revenue bug - probably savefile corruption  (Read 3508 times)

0 Members and 1 Guest are viewing this topic.

Offline paco_m

  • *
  • Posts: 170
64bit revenue bug - probably savefile corruption
« on: March 13, 2011, 11:31:45 AM »
Original Bug report was "Milliardengewinne mit 64bit Simutrans" in german forums

as jamespetts is intersted in this I'll continue here ;)

110.0.1 64bit Linux R4356
and 32bit Version to compare

PAK-Set (+addons):
pak.german_pm - Märzspiel

operating system:
Linux 64 bit (openSUSE 11.3 and 11.4)

Wrong revenue calculation in 64 bit version

Verhalten (Absturz, Einfrieren, ...):
The problem occured first in our network game but can be reproduced in local games.
The bug was found (online and offline) in simutrans versions R4346 and R4356 (other versions not tested so far).

Network game save with several issues of this kind (all horse coach lines and at least one steam boat line), look at the city Leuterhausen and let the game advance until 20 of june to reproduce the following results:

june 20th using 32bit version - correct calculation

click to enlarge image

june 20th using 64bit version

click to enlarge image

Dwachs suggested to change some const long variables to const sint64, however this was not succesful.

Further investigations:

I now made some further experiments copying the R4356 binary (64bit) into the simutrans tree from the 102.2.x stable and there it worked fine.
In the simutrans 110 directory the same binary is affected by the mentioned problem when creating a new game there.
Loading the savegame created in the 102.2.x tree it works even fine in the 110 directory.

As far as I know the savegame version is defined somewhere in and appearently the new (simutrans 110) savegames are corrupted in the 64bit simutrans version.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4869
  • Languages: EN, DE, AT
Re: 64bit revenue bug - probably savefile corruption
« Reply #1 on: March 23, 2011, 06:59:05 AM »
should be fixed in r4375.