On 2/13/07, Troman <[EMAIL PROTECTED]> wrote:
----- Original Message ----- From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" <warzone-dev@gna.org> Sent: Tuesday, February 13, 2007 8:45 PM Subject: Re: [Warzone-dev] Current problems > On 2/13/07, Troman <[EMAIL PROTECTED]> wrote: >> >> ----- Original Message ----- >> From: "Ari Johnson" <[EMAIL PROTECTED]> >> To: "Development list" <warzone-dev@gna.org> >> Sent: Sunday, February 11, 2007 11:33 PM >> Subject: Re: [Warzone-dev] Current problems >> >> >> 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). >> >> This is strange, I wonder how it could work without endianization, well >> anyway, I went through the saving and loading routines and endianized >> what I >> thought had to be endianized. I assumed you do endianization to make save >> files compatible with little-endian systems. I hope I didn't overlook >> anything. > > I guess the problem comes from something else. However, I have been > going through your changes and noticed some of the particular > weirdness ... whose idea was it to store psGroup->sRunData.forceLevel > and .leadership as SDWORDs in the file but as UBYTEs in the game? > Would there be any harm (other than of course breaking old savegames) > in saving them just as UBYTEs? According to scriptLang.rtf both 'forceLevel' and 'leadership' are in %, we should be on the safe side storing them as UBYTEs.
I didn't make this particular change. I did, however, get savegame saving and loading to work on the Mac again. I will try the non-Mac savegame in a bit. Here is a list of my notes as I went through (line numbers may be a little off since I have made changes): evntsave.c:378 Why is numContext signed? evntsave.c:398 Why is savedNumVars signed? evntsave.c:361 Why is numVars signed? evntsave.c:361 Why is numVars double-word while savedNumVars is single-word? evntsave.c:417 Why do we use a SDWORD to loop a SWORD? evntsave.c:455 Should ival be SDWORD or is UDWORD enough? evntsave.c:497 UDWORD variable stored as UWORD scriptobj.c:1127 Why do we store a UBYTE as an SDWORD? More importantly, I came across something that would be a showstopper if it were being saved by the game. In evntsave.c the SCRIPT_VARFUNC and SCRIPT_FUNC types (indicated by VAL_OBJ_GETSET and VAL_FUNC_EXTERN) are pointers, and those pointers are being saved directly into the savegame file on disk. This is very very bad. We need to come up with a better way to save these. Another odd one is the way VAL_STRING gets stored. Two conflicting assumptions are at play. Basically, the string's char* value is set to the position in the file, as if the string were stored verbatim in the file, but then the position pointer is updated by sizeof(char*), as if there had been a char* pointer in the file. I think that an appropriate solution would involve storing the size of the string as a UWORD or UDWORD and then the string's characters after that. There is already a TODO about strings in eventSaveContext, which I am changing to a more complete FIXME. I am committing my changes, with the FIXMEs described above. Please comment on the list of items I mentioned if you have any thoughts on them. Thanks to Troman for helping out with most of the endianization. _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
