On 2/11/07, Troman <[EMAIL PROTECTED]> wrote:
----- 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.
That's the problem. When I endianized the data loading and saving processes early on in my involvement with the project, I had the struct definitions to go from to determine what parts needed to be endianized and what type each one was. With evntsave.c and scriptobj.c, there don't seem to be any similar structs to work from. If someone is familiar with the file format used by evntsave.c and scriptobj.c, I would appreciate any chance I can get to talk to them about how the format works so that we can get that code endian-clean. _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
