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 11:20 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 10:43 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 10:18 PM
>> >> Subject: Re: [Warzone-dev] Current problems
>> >>
>> >>
>> >> > On 2/14/07, Troman <[EMAIL PROTECTED]> wrote:
>> >> >> > 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).
>> >> >
>> >> > That won't work, if I am reading you correctly.  The .sval pointer
>> >> > is
>> >> > just that: a pointer.  You need to point it to some memory to store
>> >> > the actual contents of the string.  The way to solve this is to find
>> >> > out where .sval pointers come from in the normal running of the
>> >> > game.
>> >> > Are they malloc()ed and later free()d, are they stored in a central
>> >> > store with garbage collection for the scripting engine, or are they
>> >> > stored in static buffers somewhere?  Once we know this, we can go
>> >> > forward with fixing how they are stored in evntsave.c.
>> >>
>> >> What I wanted to say is that at that point .sval already points to a
>> >> valid
>> >> memory address, so it should be safe to copy the string.
>> >
>> > I don't believe that it is.  If you read eventLoadContextHashed, up
>> > through line 485, where does sval get initialized?
>>
>> In eventNewContext(), line 415.
>
> Except that it's the "data" variable which is set, whereas
> eventNewContext is only called with reference to psCode, release, and
> psCCont.  Maybe I am missing how those relate.

You probably are. ;-)
eventNewContext() gets a pointer to some code, it initializes variables of
that script to their default values, allocates space for strings etc. It
then returns some script context - 'psCCont' (whatever it is).

After some value has been read from the save game, it gets assigned to a
temporary 'data' var. Then eventSetContextVar() gets called. Based on value
of 'i' it iterates through psCCont's variables to find a variable that
corresponds to the data that was just read from the save file and then
assignes this data to the corresponding variable to restore its state.

At least that's what I could understand reading that code.

If I understand what you are saying, then we still have to find the
correct string somehow.  This actually makes things harder, since we
can't just read in a string of characters from the file and pointer to
them in data.v.sval.  How do you propose we fix it?

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to