Problems loading save games

Topic: Problems loading save games (Read 5803 times) previous topic - next topic

Problems loading save games

July 15, 2009, 11:22:59 am

Using git commit 965b19da7d89c8fc51a6ee7dc4529b1499b3edda on a linux/debian/squeeze/pak128 (modified so that the call to mmsystem.h in winsys_c.cc is removed - by instruction from Knightly) I am unable to load any save games, even such just created by Experimental. The error I am getting is

Code: [Select]

FATAL ERROR: planquadrat_t::rdwr()
Error while loading game: Unknown ground type '-1'
Aborting program execution ...

which is reminiscent (though not identical) to the error I receive when trying to open an Experimental save with Standard. I get this error when I try to open a save game saved with Standard as well, ie no matter if I saved with Experimental or Standard, I am unable to open it in Experimental.

Opening save games with Standard works as usual, ie games saved within Standard works fine, but those saved with Experimental crashes the game with

Code: [Select]

FATAL ERROR: planquadrat_t::rdwr()
Error while loading game: Unknown ground type '0'
Aborting program execution ...

which is the expected (though not so nice) behaviour.

Save game from Experimental that wont open with Experimental

Re: Problems loading save games

Reply #1 – July 15, 2009, 12:18:30 pm

Sanna,

thank you very much for the report :-) I will look into that when I have a chance and reply further when I have made further progress.

Is this just with the latest commit, incidentally, or do you also get the problem with 4.6?

Re: Problems loading save games

Reply #2 – July 15, 2009, 01:08:51 pm

It does not happen with 4.6, with the exception that 4.6 cannot read the save file created by 5.0. In fact the quickest way to provoke the problem is for me to try to start pakBritain with 5.0 since the demo game read at start up is also affected, though pak128 and pak64 starts flawlessly. pakBritain also starts flawlessly with 4.6 or Standard.

Re: Problems loading save games

Reply #3 – July 15, 2009, 08:46:28 pm

Hmm, I've tried it in my local version, and your saved game works fine. This is all very odd. Can you try it again when I release 5.1?

Re: Problems loading save games

Reply #4 – July 15, 2009, 10:00:43 pm

Quote from: jamespetts – on July 15, 2009, 08:46:28 pm

Hmm, I've tried it in my local version, and your saved game works fine. This is all very odd. Can you try it again when I release 5.1?

Of course... just as soon as you release it *smile*

Re: Problems loading save games

Reply #5 – July 26, 2009, 01:24:10 pm

Sanna,

do you still have this problem with the latest version?

Re: Problems loading save games

Reply #6 – July 30, 2009, 08:20:45 am

Yes, I am afraid that I still see the same behaviour with (self-compiled) Experimental 6.1.

While looking at the issue, I did notice something that might be of interest for the problem at hand. It has always bothered me that the error dialog states that the problem is with Unknown ground type '-1', when it seems to be generated by the following snippet from simplan.cc:252-266:

Code: [Select]

		do {
			grund_t::typ gtyp = (grund_t::typ)file->rd_obj_id();

			switch(gtyp) {
				case -1: gr = NULL; break;
				case grund_t::boden:	    gr = new boden_t(welt, file, pos);                 break;
				case grund_t::w****er:	    gr = new w****er_t(welt, file, pos);                break;
				case grund_t::fundament:	    gr = new fundament_t(welt, file, pos);	       break;
				case grund_t::tunnelboden:	    gr = new tunnelboden_t(welt, file, pos);       break;
				case grund_t::brueckenboden:    gr = new brueckenboden_t(welt, file, pos);     break;
				case grund_t::monorailboden:	    gr = new monorailboden_t(welt, file, pos); break;
				default:
					gr = 0; // Hajo: keep compiler happy, fatal() never returns
					dbg->fatal("planquadrat_t::rdwr()","Error while loading game: Unknown ground type '%d'",gtyp);
			}

which AFAICT tries to deal with ground type being specifically -1. Now looking at the output of a clean make, simplan.cc is accompanied by the following warning:

Code: [Select]

simplan.cc:256: warning: case label value is less than minimum value for type

Line 256 is exactly the line dealing with case -1. So it seems that my compiler (gcc 4.3.3) does not think that -1 is a valid value for gtyp...

However, the exact same make warning is issued with simutrans-standard - where the quoted snippet of code reads exactly the same, but where I do not experience the same problems with loading maps. So if the problem is indeed that -1 is an invalid value, then I can only surmise that simutrans-standard does never call the code with the value -1, in which case I do not understand why the first case-statement is there at all....

However, I think my next step must be to set up totally independent environments for simutrans-standard and simutrans-experimental, so that I can ascertain that the problem is not due interference between the two.

Before saving edit: Just did a fast check with fresh make from simutrans-standard, and now it seems I am having problems there as well... but still with the "mixed" standard/exp environment... I am afraid I will not have time to set up the clean environments (it is the configuration files I am primarily worried about) just now... So I will have to return to you when I have.

A nightly download (r2605) works however (gcc 4.1.6) - so it leans towards being compiler dependant. I have not had time to get the precompiled experimental with its brand new configuration files into place, so can not check if that would work as well, but since it seems to work for most others, my guess would be that the compiler is "to blame" here as well.

Re: Problems loading save games

Reply #7 – July 30, 2009, 08:31:00 am

Just above your code snippet, simutrans writes the id -1 to indicate the end of the array, so indeed to -1 case is necessary. I have no idea how to fix this without breaking existing savegames.

Re: Problems loading save games

Reply #8 – July 30, 2009, 10:29:00 am

I submitted a fix, making the integer deliberate signed. Maybe the enum is default unsigned 16bit and thus -1 will be never reach, since case may work on 32 bit signed (int). ANyway, try the next revision.

Re: Problems loading save games

Reply #9 – July 30, 2009, 11:24:42 am

Quote from: prissi – on July 30, 2009, 10:29:00 am

I submitted a fix, making the integer deliberate signed. Maybe the enum is default unsigned 16bit and thus -1 will be never reach, since case may work on 32 bit signed (int). ANyway, try the next revision.

Your fix solves the problem for me, with a fresh svn pull made clean, I can save and load save games again. Thank you! *smile* Furthermore, testing your fix on experimental also solves the problem there - so once experimental syncs simplan.cc with standard again, experimental will work again.

BTW, while looking at the issue, I noticed that while most (fundament.h, tunnelboden.h etc.) of the various flavours of get_typ() returns an enum, but that those in w****er.h:34 and boden.h:34 does not. Is this deliberate or an oversight?