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 10:12 PM
Subject: Re: [Warzone-dev] Current problems
> 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.
Not sure I understood it. You said loading on mac worked before some
revision. Have you endianized evntsave.c and scriptobj.c before that or did
it work without endianization? Or are you referring to some changes that
were made to evntsave.c and scriptobj.c in some revision?
I never did any work on those files. Saving and loading used to work
(it works in 2.0.5). Saving and loading do not work now. I don't
know exactly which revision they stopped working in. I don't believe
that evntsave.c was even used back when saving and loading worked
(that is, I don't think that 2.0.5 saves a savegame.es file). I am
not sure about the history of those files, but they are at fault for
this crash.
> 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.
I'm not familiar with the format and I have no idea if this will help you,
anyway, I took a look at the loading routine and did a rough description of
the loading process:
Loaded script data ('pBuffer', looks like it just holds states for each
variable of a single script at the moment when save game was created) is
passed to eventLoadContext(), then it iterates through all states, checking
the type of the variable these states belonged to.
1) If it's a simple type ("if (type < VAL_USERTYPESTART)", eg float, string,
integer etc) the content is directly assigned to the approriate union field
of a temporary INTERP_VAL variable - 'data'. Then it calles
eventSetContextVar(), which first gets a pointer to the corresponding script
variable (the script itself is probably loaded beforehand) with
eventGetContextVal(). Then eventSetContextVar() checks if the type of this
script variable matches the type of the saved variable state ("if
(psVal->type != data->type)"). And that seems to be exactly the place where
it fails on mac. If that check succeeds however, loaded variable state is
assigned to the variable with "memcpy(psVal, data, sizeof(INTERP_VAL));" .
2) If it's a pointer to some kind of internal structure (like a droid,
structure, research etc) it gets the function that is capable of the
initialization of this partucular data type (loadFunc = asScrTypeTab[type -
VAL_USERTYPESTART].loadFunc;). There seem to be only one function:
scrValDefLoad(). For example if it's a droid variable that gets passed wz
looks for the correct droid id, once found it assignes this droid to the
void pointer of the passed INTERP_VAL variable (psVal->v.oval).
The problem is that the code is a bit more intertwined than that.
There are a lot of unstated assumptions that make it impossible to
just endianize each relevant variable.
Saving is probably analogous to loading.
Troman
>
> _______________________________________________
> Warzone-dev mailing list
> Warzone-dev@gna.org
> https://mail.gna.org/listinfo/warzone-dev
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
