----- Original Message -----
From: "Ari Johnson" <[EMAIL PROTECTED]>
To: "Development list" <warzone-dev@gna.org>
Sent: Sunday, February 11, 2007 8:17 PM
Subject: Re: [Warzone-dev] Current problems
> On 2/11/07, Troman <[EMAIL PROTECTED]> wrote:
>>
>>
>> Back to this loading topic. I wasn't reading all mailinglist messages
>> lately, but from reading old messages looks like this is still not
>> resolved.
>>
>> > Anyhow, I fixed the crash in saving the game. Loading the game
>> > resulted in a different crash, which I also fixed, but then there
>> > was
>> > another one:
>> >
>> > 7. The following error occurs when loading a saved game, at least in
>> > campaign mode:
>> > error: eventSetContextVar: Variable type mismatch (1/0)
>> > error: Assert in Warzone: event.c:779 : eventSetContextVar
>> > (FALSE), last script event: '<none>'
>> > event.c:779: failed assertion `(0)'
>>
>> I'm really clueless why this happens.
>> I wouldn't deal with the loading/saving code, if it worked fine for
>> you
>> at
>> some point, since AFAIK loading/saving code wasn't changed after the
>> 64bit-patch (r495). Do you know if loading worked after this patch?
>> There
>> were also modifications to the savegame format, maybe something wasn't
>> endianized? Another thind you can do is to try to find the commit that
>> broke
>> savegame loading on mac.
>>
>> > I'm attaching a savegame. Chances are good that there are endian
>> > issues so it won't load for others, but if you can give me some
>> > hints
>> > about where it crashes trying to load this, it might help fix it on
>> > my
>> > end, too. Thanks!
>>
>> Can't load it, that's what I get as debug output:
>>
>> never: levLoadData: loading script system state
>> error: resGetDataFromHash: Unknown ID:
>> error: Assert in Warzone:
>> c:\wz\source\lib\framework\frameresource.c:544 :
>> resGetDataFromHash (FALSE), last script event: '<none>'
>>
>> call stack:
>>
>> > Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c,
>> > unsigned
>> > int
>> HashedID=1065441038) Line 544 + 0x5b bytes C
>> Warzone.exe!eventLoadContextHashed(int version=50331648,
>> char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370
>> +
>> 0xe
>> bytes C
>> Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int
>> fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C
>> Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669
>> +
>> 0x11 bytes C
>> Warzone.exe!levLoadData(char * pName=0x00d63000, char *
>> pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C
>> Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int
>> filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C
>> Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int
>> filesize=4572) Line 3283 + 0x14 bytes C
>> Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 +
>> 0xd
>> bytes C
>> Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line
>> 562 +
>> 0xa bytes C
>> Warzone.exe!_main() + 0xd1 bytes C
>>
>> I have attached savegame from campaign 1, mission 1 in case you still
>> need
>> it.
>
> That savegame definitely crashes on the Mac. I'm pretty sure it's the
> endian issue. The problem seems to stem from the script state being
> saved without any endianizing. To my knowledge, saving and loading
> games worked fine until that change occurred, which I think was
> post-r495. A test of r495 just now actually crashes when attempting
> to save the game, with the crash coming from code that is commented
> out in the latest source. However, this is entirely separate from the
> crashes I get now.
>
> What we need to do is go through the evntsave.c and scriptobj.c code
> to endianize all the things that get saved out to the file. I don't
> know the file formats so I can't go through them accurately myself.
Unfortunately I'm not familiar with saving/loading routines or save game
formats myself, I don't remember anyone really worked with it before.
I think starting to blindly fix the code isn't a good idea. The best
approach seems to be to track down the revision that introduced that bug,
otherwise it looks pretty hopeless, since non-mac users can't even
recreate
the bug.
If it will turn out to be r496 and loading worked fine on mac before r496
(and hence I assume that it was properly endianized) and saving/loading
routines were only modified in r496 dealing with scriptobj.c and other
parts
of the saving/loading routines that were not modified doesn't make much
sense imho. All that has to be checked are the modifications to the
saving/loading routines or save game format made after loading stopped
working on mac.
