Re: [Warzone-dev] Odds ends
On Tuesday, 6 February 2007 at 11:58, Dennis Schridde wrote:
Am Dienstag, 6. Februar 2007 schrieb Christian Ohm:
Hello everyone,
Here are a few comments and things I've noticed recently:
- In the trunk the selection box is filled with a transparent overlay,
which is 1 pixel too narrow and too low. The first attached patch
fixes that, but the actual error might be hidden somewhere deeper.
What about this?
- The radar view indicator fix and possibly the fixed selection box
patch could both be applied to 2.0.
Yes, that would be nice.
I see the radar fix was applied, the other wasn't. Any specific reason
for that?
- When using the Windows installer for 2.0.5 as a regular user, when
selecting a write-protected directory the installer just aborts
instead of offering to select another directory.
I can have a look whether there is any example on the NSIS pages, showing how
to do this. But currently I think this is more a fault of NSIS and is thus
out of reach.
Ah well, if it's possible, ok, if not, well, it's just Windows... :P
- The german description of Grim's graphics update in the installer was
somewhat strange.
Written by me. ;) What's strange with it?
(BTW: I just recognized that the english version should have the same
strange description, but I mixed up TEXT and DESC, what might be the reason
it is not shown.)
LangString TEXT_SecGrimMod ${LANG_ENGLISH} Grim's art update. Replaces
campaign 1 textures with more detailed ones. Also includes some other texture
and model updates. License: NON GPL: Copyright by Grim. Use is only permited
for Warzone 2100 GPL.
LangString DESC_SecGrimMod ${LANG_ENGLISH} Grim's art update
LangString TEXT_SecGrimMod ${LANG_GERMAN} Grims Grafik Update
LangString DESC_SecGrimMod ${LANG_GERMAN} Grims Grafik Update. Ersetzt
Kampagne 1 Texturen mit Detailieren. Enth�t auch einige andere Textur und
Model updates. Lizenz: Nicht GPL: Copyright by Grim. Verwendung nur fr
Warzone 2100 GPL gestattet.
Besserer Vorschlag: Grim's Grafik-Update. Enthält detailliertere
Textures für Kampagne 1 sowie einige andere Textur- und Model-Updates.
Copyright [Jahr?] by Grim [richtiger Name?], Verwendung nur für Warzone
2100 GPL gestattet. Das Lizenz: Nicht GPL würde ich weglassen (oder
zumindest mit Bindestrich schreiben), und vielleicht noch Jahr und
richtigen Namen hinzufügen (beim englischen Text dann auch). Ist das
Update eigentlich irgendwo runterladbar oder nur im Windows-Installer
versteckt?
___
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 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:1127Why 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. 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. 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
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:1127Why 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? 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
Re: [Warzone-dev] Current problems
- 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:1127Why 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
[Warzone-dev] Re: [Warzone-commits] r747 - in /branches/2.0: configure.ac makerules/configure.mk
On Wednesday, 14 February 2007 at 17:52, Dennis Schridde wrote: Backport r746 Small request: Could you (and everyone else) please add a short description of what the backported revision actually contains? Half the log of 2.0 consists of Backport of rXXX, which isn't very helpful. -- BOFH excuse #300: Digital Manipulator exceeding velocity parameters ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r747 - in /branches/2.0: configure.ac makerules/configure.mk
Am Mittwoch, 14. Februar 2007 schrieb Christian Ohm: On Wednesday, 14 February 2007 at 17:52, Dennis Schridde wrote: Backport r746 Small request: Could you (and everyone else) please add a short description of what the backported revision actually contains? Half the log of 2.0 consists of Backport of rXXX, which isn't very helpful. You could look into the comment for revision 746... But ok, I will add a short comment next time. pgpA96hJeuvfm.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Please apply this patch
I know I only posted it only 4 days ago, but I really sleep better when
I know my patches have been applied. Could someone apply this patch? I
even polished it a little bit more.
This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a
construction droid. Then hover your mouse over another system, like
sensor or command.
Regards,
Gerard
Index: src/design.c
===
--- src/design.c (revision 747)
+++ src/design.c (working copy)
@@ -3612,13 +3612,43 @@
static void intSetTemplatePowerShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- //SDWORDAvail, Used, Total;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+BRAIN_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+SENSOR_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+ECM_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+REPAIR_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
+CONSTRUCT_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
+PROPULSION_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
+WEAPON_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+ switch (type)
+ {
+ case COMP_BODY:
+ bodyStats = (BODY_STATS*)psStats;
+ break;
+ case COMP_PROPULSION:
+ propulsionStats = (PROPULSION_STATS*)psStats;
+ break;
+ case COMP_ECM:
+ ECMStats = (ECM_STATS*)psStats;
+ break;
+ case COMP_SENSOR:
+ sensorStats = (SENSOR_STATS*)psStats;
+ break;
+ case COMP_CONSTRUCT:
+ constructStats = (CONSTRUCT_STATS*)psStats;
+ break;
+ case COMP_REPAIRUNIT:
+ repairStats = (REPAIR_STATS*)psStats;
+ break;
+ case COMP_WEAPON:
+ weaponStats = (WEAPON_STATS*)psStats;
+ break;
+ //default:
+ //don't want to draw for unknown comp
+ }
+
type = statType(psStats-ref);
/*if type = BODY or PROPULSION can do a straight comparison but if the new stat is
a 'system' stat then need to find out which 'system' is currently in place so the
@@ -3648,43 +3678,56 @@
}
else
{
-type = COMP_UNKNOWN;
+ // compare it with the current weapon
+type = COMP_WEAPON;
}
}
switch (type)
{
case COMP_BODY:
- compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
+ bodyStats = (BODY_STATS*)psStats;
break;
case COMP_PROPULSION:
- compTempl.asParts[COMP_PROPULSION] = (PROPULSION_STATS *)psStats -
-asPropulsionStats;
+ propulsionStats = (PROPULSION_STATS*)psStats;
break;
case COMP_ECM:
- compTempl.asParts[COMP_ECM] = (ECM_STATS *)psStats - asECMStats;
+ ECMStats = (ECM_STATS*)psStats;
break;
case COMP_SENSOR:
- compTempl.asParts[COMP_SENSOR] = (SENSOR_STATS *)psStats -
-asSensorStats;
+ sensorStats = (SENSOR_STATS*)psStats;
break;
case COMP_CONSTRUCT:
- compTempl.asParts[COMP_CONSTRUCT] = (CONSTRUCT_STATS *)psStats -
-asConstructStats;
+ constructStats = (CONSTRUCT_STATS*)psStats;
break;
case COMP_REPAIRUNIT:
- compTempl.asParts[COMP_REPAIRUNIT] = (REPAIR_STATS *)psStats -
-asRepairStats;
+ repairStats = (REPAIR_STATS*)psStats;
break;
case COMP_WEAPON:
- compTempl.asWeaps[0] = (WEAPON_STATS *)psStats - asWeaponStats;
+ weaponStats = (WEAPON_STATS*)psStats;
break;
//default:
//don't want to draw for unknown comp
}
+ // this code is from calcTemplatePower
+ UDWORD power, i;
- widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
-calcTemplatePower(compTempl));
+ //get the component power
+ power = bodyStats-buildPower + brainStats-buildPower + sensorStats-buildPower + ECMStats-buildPower + repairStats-buildPower + constructStats-buildPower;
+
+ /* propulsion power points are a percentage of the bodys' power points */
+ power += (propulsionStats-buildPower *
+ bodyStats-buildPower) / 100;
+
+ //add weapon power
+// FIXME: Only takes first weapon into account
+power += weaponStats-buildPower;
+ for(i=1; isCurrDesign.numWeaps; i++)
+ {
+ power += (asWeaponStats + sCurrDesign.asWeaps[i])-buildPower;
+ }
+ widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
+power);
}
else
{
@@ -3705,12 +3748,18 @@
static void intSetTemplateBodyShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats +
Re: [Warzone-dev] Please apply this patch
Am Mittwoch, 14. Februar 2007 schrieb Gerard Krol: I know I only posted it only 4 days ago, but I really sleep better when I know my patches have been applied. Could someone apply this patch? I even polished it a little bit more. I think there were no objections? I'll commit it when I am back from my journey to Windows... --Dennis pgpK8c8b2TNnL.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Please apply this patch
Gerard Krol schreef: I know I only posted it only 4 days ago, but I really sleep better when I know my patches have been applied. Could someone apply this patch? I even polished it a little bit more. This patch prevents a segfault when designing a droid on amd64. Reproduce: on amd64, go to the droid design screen and design a construction droid. Then hover your mouse over another system, like sensor or command. Regards, Gerard Applied in r750. Hope you did sleep well enough those 4 days? Anyway I'm hoping you'll sleep better now again ;-) . -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r749 - in /trunk: lib/script/interp.c lib/script/interp.h src/scriptfuncs.c src/scriptfuncs.h src/scriptobj.c src/scripttabs.c
Am Mittwoch, 14. Februar 2007 schrieb Christian Ohm: On Wednesday, 14 February 2007 at 18:29, Roman wrote: - removed some ASSERSs doubling debug() error output ASSERT quits (in debug mode) and debug LOG_ERROR doesn't. Was that intentional? Yes, Troman explained it to me in IRC: The code uses gotos to jump to the callstack part, where it will assert. If it would assert before, it would never output the callstack. --Dennis pgpxQMgZWYN9S.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
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. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r749 - in /trunk:lib/script/interp.c lib/script/interp.h src/scriptfuncs.csrc/scriptfuncs.h src/scriptobj.c src/scripttabs.c
Am Mittwoch, 14. Februar 2007 schrieb Christian Ohm: On Wednesday, 14 February 2007 at 18:29, Roman wrote: - removed some ASSERSs doubling debug() error output ASSERT quits (in debug mode) and debug LOG_ERROR doesn't. Was that intentional? Yes, Troman explained it to me in IRC: The code uses gotos to jump to the callstack part, where it will assert. If it would assert before, it would never output the callstack. --Dennis Looks like Devurandom was faster than me. Troman ___ 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 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. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
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? ___ 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 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. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
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. ___ 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 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. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
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 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
