----- Original Message -----
From: "Ari Johnson" <[EMAIL PROTECTED]>
To: "Development list" <warzone-dev@gna.org>
Sent: Wednesday, February 14, 2007 5:49 PM
Subject: Re: [Warzone-dev] Current problems
On 2/14/07, Troman <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: "Ari Johnson" <[EMAIL PROTECTED]>
To: "Development list" <warzone-dev@gna.org>
Sent: Wednesday, February 14, 2007 4:37 AM
Subject: Re: [Warzone-dev] Current problems
> 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?
No clue.
>
> 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.
I'm not sure what to do with SCRIPT_VARFUNC. Maybe we should just
hardcode
it in the interpreter, since there's only one SCRIPT_VARFUNC function
anyway, at least I can't think of an elegant solution.
One thing we can do is have a table and store an integer that indexes into
it.
> 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.
Sounds good to me.
The question is how the strings are stored - do we malloc up space for
them when we read in the file?
When save games are loaded? I think loaded strings should be just copied
into the space allocated for string variables (union's .sval pointer).
I can look into this sometime if
nobody else knows.
_______________________________________________
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
