Re: [Warzone-dev] Current problems
On 2/14/07, The Watermelon <[EMAIL PROTECTED]> wrote: > evntsave.c:455 Should ival be SDWORD or is UDWORD enough? 455:no it's not enough,the ival(integer) can be negative or return a negative number in script functions It's stored as a UDWORD at present, is why I asked. It looks like a few of the things here could use some thought and cleaning up. Regardless, today definitely represents major progress for the big-endian world. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 2/13/07, Ari Johnson <[EMAIL PROTECTED]> wrote: 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:1127Why do we store a UBYTE as an SDWORD? 378,398,361: unsure 417:probably 32bit SDWORD increment operation is faster than a 16bit one 455:no it's not enough,the ival(integer) can be negative or return a negative number in script functions 497,1127: no idea ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
Okay, this is a strange one. With the savegame that Troman sent, things work fine as long as I don't have a debug build. However, when I configure with --enable-debug, it crashes right after the tank explodes (which is less than a second after the savegame loads up). The crash is at line 264 of mapgrid.c. Everything looks normal but I don't understand what that code is doing so I don't know what "normal" is. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 2/13/07, Troman <[EMAIL PROTECTED]> wrote: - Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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" >> 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:1127Why 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
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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" 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. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 2/13/07, Troman <[EMAIL PROTECTED]> wrote: - Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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. Troman mac_script_load_save.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
