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
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] 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
Re: [Warzone-dev] Current problems
- 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. Troman mac_script_load_save.patch Description: Binary data ___ 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 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? ___ 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: 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. 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 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: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
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/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. As for the scrCBNewUnit() problem, did r690 fix it? I haven't had it occur since then, so it appears that that problem is fixed. ___ 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: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. Troman As for the scrCBNewUnit() problem, did r690 fix it? I haven't had it occur since then, so it appears that that problem is fixed. ___ 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
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 10:12 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. That's the problem. When I endianized the data loading and saving processes early on in my involvement with the project, I had the struct definitions to go from to determine what parts needed to be endianized
Re: [Warzone-dev] Current problems
On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 10:12 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. That's the problem. When I endianized the data loading and saving processes
Re: [Warzone-dev] Current problems
On 2/6/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 6. Februar 2007 schrieb Ari Johnson: On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Does anyone have a savegame I can test on? Also, I think that one of the problems is going to come from lib/script/evntsave.c not doing any endianizing when it saves or loads files. Can someone who understands what's going on in that file help me out in fixing that? It doesn't seem to be as consistently structured as the other save/load code that I endianized a few months ago, so it's hard to tell exactly which things are being saved to the file and what data type each one is. Thanks. http://wz2100.net/forum/index.php?topic=308.0 This thread contains several savegames from the end of CAM_1 and CAM_2. You can use those to test branches/2.0. (They won't work with trunk, because it can't load them. Unexpected end of file. I think someone broke the load-old-savegame-version code.) BTW: You fixed several bugs for Mac lately. Could you port them to branches/2.0? Otherwise I have to (and will) do that. I backported the two changes that I made that were problems in 2.0. However, there is still that Audio error after init bug that someone else committed the fix to. That needs to be backported as well, and then I think 2.0 is Mac-clean as far as I can tell. (Saved game saving and loading worked the last time I checked, and is only broken in trunk as far as I am aware.) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 2/8/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Donnerstag, 8. Februar 2007 schrieb Ari Johnson: On 2/6/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 6. Februar 2007 schrieb Ari Johnson: On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Does anyone have a savegame I can test on? Also, I think that one of the problems is going to come from lib/script/evntsave.c not doing any endianizing when it saves or loads files. Can someone who understands what's going on in that file help me out in fixing that? It doesn't seem to be as consistently structured as the other save/load code that I endianized a few months ago, so it's hard to tell exactly which things are being saved to the file and what data type each one is. Thanks. http://wz2100.net/forum/index.php?topic=308.0 This thread contains several savegames from the end of CAM_1 and CAM_2. You can use those to test branches/2.0. (They won't work with trunk, because it can't load them. Unexpected end of file. I think someone broke the load-old-savegame-version code.) BTW: You fixed several bugs for Mac lately. Could you port them to branches/2.0? Otherwise I have to (and will) do that. I backported the two changes that I made that were problems in 2.0. However, there is still that Audio error after init bug that someone else committed the fix to. That needs to be backported as well, and then I think 2.0 is Mac-clean as far as I can tell. (Saved game saving and loading worked the last time I checked, and is only broken in trunk as far as I am aware.) You mean r660 by Giel? That's the one. Committed. Thanks. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
Dennis Schridde schreef: Am Donnerstag, 8. Februar 2007 schrieb Ari Johnson: On 2/6/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 6. Februar 2007 schrieb Ari Johnson: On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Does anyone have a savegame I can test on? Also, I think that one of the problems is going to come from lib/script/evntsave.c not doing any endianizing when it saves or loads files. Can someone who understands what's going on in that file help me out in fixing that? It doesn't seem to be as consistently structured as the other save/load code that I endianized a few months ago, so it's hard to tell exactly which things are being saved to the file and what data type each one is. Thanks. http://wz2100.net/forum/index.php?topic=308.0 This thread contains several savegames from the end of CAM_1 and CAM_2. You can use those to test branches/2.0. (They won't work with trunk, because it can't load them. Unexpected end of file. I think someone broke the load-old-savegame-version code.) BTW: You fixed several bugs for Mac lately. Could you port them to branches/2.0? Otherwise I have to (and will) do that. I backported the two changes that I made that were problems in 2.0. However, there is still that Audio error after init bug that someone else committed the fix to. That needs to be backported as well, and then I think 2.0 is Mac-clean as far as I can tell. (Saved game saving and loading worked the last time I checked, and is only broken in trunk as far as I am aware.) You mean r660 by Giel? If it is directly after initialization it is very likely to be that piece of code. Because it checks for errors there before there could be any (but OpenAL's error value isn't zero-initialized so chances are that you'll get an error value anyhow from alGetError anyway). It isn't Mac-specific btw, probably just library implementation specific (on my laptop with nVidea OpenAL implementation I never got this error, on my PC with Creative's implementation I did have it). Anyhow as I was writing this email and just attempting to commit this change to the 2.0 branch I found Ari already did so. -- 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] Current problems
On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Does anyone have a savegame I can test on? Also, I think that one of the problems is going to come from lib/script/evntsave.c not doing any endianizing when it saves or loads files. Can someone who understands what's going on in that file help me out in fixing that? It doesn't seem to be as consistently structured as the other save/load code that I endianized a few months ago, so it's hard to tell exactly which things are being saved to the file and what data type each one is. Thanks. Ari ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On Mon, 29 Jan 2007 08:40:28 -0500, Ari Johnson [EMAIL PROTECTED] wrote: I was wrong - this no longer comes up. However, I saved the game a few times and once this one came up: error: Returned savegame/test.gam Not sure what that means. From _runLoadSave(), if when returning TRUE strlen(sRequestResult) != 0 then a valid game slot was selected otherwise cancel was selected. In hci.c at line 1771, the code checks strlen(sRequestResult) and prints a debug message with LOG_ERROR. This should probably be LOG_NEVER or something similar, since it's not an error. Note that one reason the output I got before may have gone away is that I accidentally reconfigured without --debug. I'll report back as I run into things, but this is definitely getting much cleaner as we go. How about using config.status? It should be generated by configure and retains your configure flags/parameters. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/29/07, Giel van Schijndel [EMAIL PROTECTED] wrote: On Mon, 29 Jan 2007 08:40:28 -0500, Ari Johnson [EMAIL PROTECTED] wrote: I was wrong - this no longer comes up. However, I saved the game a few times and once this one came up: error: Returned savegame/test.gam Not sure what that means. From _runLoadSave(), if when returning TRUE strlen(sRequestResult) != 0 then a valid game slot was selected otherwise cancel was selected. In hci.c at line 1771, the code checks strlen(sRequestResult) and prints a debug message with LOG_ERROR. This should probably be LOG_NEVER or something similar, since it's not an error. Note that one reason the output I got before may have gone away is that I accidentally reconfigured without --debug. I'll report back as I run into things, but this is definitely getting much cleaner as we go. How about using config.status? It should be generated by configure and retains your configure flags/parameters. I occasionally do a fresh checkout / configure / compile to make sure there's nothing missing from that process. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/28/07, Christian Ohm [EMAIL PROTECTED] wrote: On Saturday, 27 January 2007 at 11:21, Ari Johnson wrote: Thanks. I can see that there are some other colors I need to work on. What I am having a hard time with is where exactly to do the color twiddling. Should I do it in the ivis code or in the warzone code? I am thinking the ivis code is the best place to do it, because that's where most of the other twiddling (such as bit-shifting things into color slots) seems to occur. If anyone has a preference, let me know. Otherwise I'll be doing it in the ivis code (unless that turns out to be impossible to fix everything). I'd say do it in the lowest level possible, so that's ivis. The only problem with that is that some of the Warzone code seems to use the byte-level parts of the color code and other parts of it use the 32-bit 0xaarrggbb format. I will try to find all the spots that cause trouble. More to come on that. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: Just a general recap... Of all the things that I've said were bugs in this thread, these are the only items that still seem to be problems for me: 4. This output comes up just in the first couple of stages of playing the campaign: warning:loadFile2: optional file sequenceaudio/BrfCom.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1ascv.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1b_P.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1b.txt could not be opened: No such file or directory I was wrong - this no longer comes up. However, I saved the game a few times and once this one came up: error: Returned savegame/test.gam Not sure what that means. 6. Crash while playing the game. It semes to be related to what units I have selected but I don't know what triggers it. Here is the output: error: scrCBNewUnit: no unit has been set error: Assert in Warzone: scriptcb.c:121 : scrCBNewDroid (FALSE), last script event: '11 (CALL_NEWDROID)' scriptcb.c:121: failed assertion `(0)' 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' 8. If I lose in skirmish mode, I get the following crash: rror: widgSetButtonState: Couldn't find button/click form from ID error: Assert in Warzone: widget.c:1243 : widgSetButtonState (FALSE), last script event: 'checkEndConditions' widget.c:1243: failed assertion `(0)' ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/27/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 27. Januar 2007 schrieb Ari Johnson: One thing that would help immensely right now would be to see the following screenshots taken on a PC (for my comparison and progress): 1. The part of the UI where you set up a new multiplayer game 2. In-game with the zoom all the way in 3. In-game with the zoom all the way out #2 and #3 depend on the minimap being visible on your screenshot, of course. Thanks to anyone who can help me out here! Thanks. I can see that there are some other colors I need to work on. What I am having a hard time with is where exactly to do the color twiddling. Should I do it in the ivis code or in the warzone code? I am thinking the ivis code is the best place to do it, because that's where most of the other twiddling (such as bit-shifting things into color slots) seems to occur. If anyone has a preference, let me know. Otherwise I'll be doing it in the ivis code (unless that turns out to be impossible to fix everything). I also see that the minimap view window is kind of messed up on Windows, too. I have found some math tweaks that make it look a lot nicer. I will submit those as a patch here rather than committing to subversion. See the attachment. Ari minimap-viewport-fix.patch Description: Binary data ___ 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: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/27/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? No - this came up after I made that fix. I haven't traced back where the two variables it is comparing come from. I'm sure that following them back to their sources will reveal why they aren't matching as expected. As to your response to #6, it seems to be kind of random but somehow relates to what units I have selected at the time, I think. The problem is that when it happened this last time I was watching my factory production and none of them was done producing a unit when it crashed. Otherwise I would say right away that it must be due to unit production scripts. Let me know what you find, if anything. ___ 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: Saturday, January 27, 2007 6:37 PM Subject: Re: [Warzone-dev] Current problems On 1/27/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? No - this came up after I made that fix. I haven't traced back where the two variables it is comparing come from. I'm sure that following them back to their sources will reveal why they aren't matching as expected. As to your response to #6, it seems to be kind of random but somehow relates to what units I have selected at the time, I think. The problem is that when it happened this last time I was watching my factory production and none of them was done producing a unit when it crashed. Otherwise I would say right away that it must be due to unit production scripts. I'm sure it is related to unit production somehow. Maybe it was AI that produced a unit. Let me know what you find, if anything. I will. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/27/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Saturday, January 27, 2007 6:37 PM Subject: Re: [Warzone-dev] Current problems On 1/27/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? No - this came up after I made that fix. I haven't traced back where the two variables it is comparing come from. I'm sure that following them back to their sources will reveal why they aren't matching as expected. As to your response to #6, it seems to be kind of random but somehow relates to what units I have selected at the time, I think. The problem is that when it happened this last time I was watching my factory production and none of them was done producing a unit when it crashed. Otherwise I would say right away that it must be due to unit production scripts. I'm sure it is related to unit production somehow. Maybe it was AI that produced a unit. I am sure I can get it to crash again. Let me know if there is any information from the GDB output that would help you. Let me know what you find, if anything. I will. ___ 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
Re: [Warzone-dev] Current problems
On Friday, 26 January 2007 at 19:20, Ari Johnson wrote: I don't have time to check the bug lists, but I'm just running these by everyone in case they are Mac-only problems. This is from the latest subversion: 1. When you drag a rectangle to select multiple units, it comes up as solid yellow with the unit brackets showing through but not the terrain or units themselves. Basically, anything 3D becomes solid yellow. Screenshots are attached. Look at r603 for that. 2. The minimap view indicator (the yellow trapezoid) seems to scale incorrectly, and goes inside out at some points. Screenshots are attached to show the two extremes of zooming out and then in. That was always the case for as long as I remember (for the GPL version), I guess it's the increased zoom ranges. -- A nasty looking dwarf throws a knife at you. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
Am Samstag, 27. Januar 2007 schrieb Ari Johnson: I don't have time to check the bug lists, but I'm just running these by everyone in case they are Mac-only problems. This is from the latest subversion: 1. When you drag a rectangle to select multiple units, it comes up as solid yellow with the unit brackets showing through but not the terrain or units themselves. Basically, anything 3D becomes solid yellow. Screenshots are attached. Really odd. Very probably related to r603, like Christian said. Works fine here... Dunno why it may be a problem for MacOS... 2. The minimap view indicator (the yellow trapezoid) seems to scale incorrectly, and goes inside out at some points. Screenshots are attached to show the two extremes of zooming out and then in. Either I am just too stupid, my imaging program doesn't work correctly or you attached the wrong portion of your screenshots... I simply can't see the minimap at all. 3. Keys with Left Control shifting are off. For instance, Ctrl-left-arrow speeds up the simulation, Ctrl-minus sets it to 1.0 speed, and Ctrl-equal-sign slows it down a step. Ctrl-Z, which used to be select all similar units is now jump to next factory. I don't know what might be causing this. Probably the keymap was changed. Did you try to delete the old one? 4. The output at the end of this message comes up just in the first couple of stages of playing the campaign. Just had a quick look. Those files really don't exists. Probably someone changed a portion of the code to make them appear, while they were hidden behind some unused code earlier. It shouldn't be a problem, since they are not required, as the output says. Maybe someone can have a look in the 1.10 Warzone to see what was in them before they got lost... (Or maybe they were even in the SVN earlier, but got deleted in an accident? Should be fixed then.) 5. It crashes if you try to save the game at any point. It appears to come from endian_uword(psSaveDroid-turretPitch[i]) online 6417 of game.c. I haven't had chance to look into this one yet but it looks like i has a value of 46657 so I'm thinking what happens is numWeaps gets endianized and then the loop from 0 up to numWeaps goes way too far. The way to fix this is to move the endianization of numWeaps to after the loop, I think. That's all I have for now. There are some other issues that I had but they didn't come up in my test run tonight. I will test run it later this weekend to find the others, probably. (If I don't save the game, it will run longer so I can crash it doing something else.) Let me know if anyone has any ideas for #1-#4. Of those, all of them are relatively new other than the minimap thing. Ari Output from game: warning:loadFile2: optional file sequenceaudio/BrfCom.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1ascv.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1b_P.txt could not be opened: No such file or directory warning:loadFile2: optional file sequenceaudio/cam1/cam1b.txt could not be opened: No such file or directory pgpUUDZbvw1Lp.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 Friday, 26 January 2007 at 22:47, Ari Johnson wrote: Here we go. Please look at these screenshots and tell me if any colors are off. I changed pie_DrawRect to endianize the color value before splitting it into individual bytes. That seems to have been much of my problem, including the fact that red meant healthy and green meant almost dead for my units' health indicators. I'm in particular not sure about the color indicators of the construction progress - white on blue? Anyhow, let me know if anything is off here. I don't have a PC to make comparisons on. Thanks. The build progress should be yellow on black, selection box outline blue, field of view indicator on the radar grey. The rest looks ok. -- Sight is a faculty; seeing is an art. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/26/07, Ari Johnson [EMAIL PROTECTED] wrote: I don't have time to check the bug lists, but I'm just running these by everyone in case they are Mac-only problems. This is from the latest subversion: 1. When you drag a rectangle to select multiple units, it comes up as solid yellow with the unit brackets showing through but not the terrain or units themselves. Basically, anything 3D becomes solid yellow. Screenshots are attached. 2. The minimap view indicator (the yellow trapezoid) seems to scale incorrectly, and goes inside out at some points. Screenshots are attached to show the two extremes of zooming out and then in. 3. Keys with Left Control shifting are off. For instance, Ctrl-left-arrow speeds up the simulation, Ctrl-minus sets it to 1.0 speed, and Ctrl-equal-sign slows it down a step. Ctrl-Z, which used to be select all similar units is now jump to next factory. I don't know what might be causing this. 4. The output at the end of this message comes up just in the first couple of stages of playing the campaign. 5. It crashes if you try to save the game at any point. It appears to come from endian_uword(psSaveDroid-turretPitch[i]) online 6417 of game.c. I haven't had chance to look into this one yet but it looks like i has a value of 46657 so I'm thinking what happens is numWeaps gets endianized and then the loop from 0 up to numWeaps goes way too far. The way to fix this is to move the endianization of numWeaps to after the loop, I think. That's all I have for now. There are some other issues that I had but they didn't come up in my test run tonight. I will test run it later this weekend to find the others, probably. (If I don't save the game, it will run longer so I can crash it doing something else.) Let me know if anyone has any ideas for #1-#4. Of those, all of them are relatively new other than the minimap thing. Ari 5.I added multiple info for turrent pitch and rotation to the gamesave/load,though I never had that crash when saving/loading svn save games,so I guess it's a platform depend problem... A bit offset:just want to comment on current radar minimap,I think the radar minimap is not very modern,drawing tons of 'moving lines' on radar is weird,esp with multiple fast moving units like vtols being tracked on radar... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/26/07, The Watermelon [EMAIL PROTECTED] wrote: On 1/26/07, Ari Johnson [EMAIL PROTECTED] wrote: I don't have time to check the bug lists, but I'm just running these by everyone in case they are Mac-only problems. This is from the latest subversion: 1. When you drag a rectangle to select multiple units, it comes up as solid yellow with the unit brackets showing through but not the terrain or units themselves. Basically, anything 3D becomes solid yellow. Screenshots are attached. 2. The minimap view indicator (the yellow trapezoid) seems to scale incorrectly, and goes inside out at some points. Screenshots are attached to show the two extremes of zooming out and then in. 3. Keys with Left Control shifting are off. For instance, Ctrl-left-arrow speeds up the simulation, Ctrl-minus sets it to 1.0 speed, and Ctrl-equal-sign slows it down a step. Ctrl-Z, which used to be select all similar units is now jump to next factory. I don't know what might be causing this. 4. The output at the end of this message comes up just in the first couple of stages of playing the campaign. 5. It crashes if you try to save the game at any point. It appears to come from endian_uword(psSaveDroid-turretPitch[i]) online 6417 of game.c. I haven't had chance to look into this one yet but it looks like i has a value of 46657 so I'm thinking what happens is numWeaps gets endianized and then the loop from 0 up to numWeaps goes way too far. The way to fix this is to move the endianization of numWeaps to after the loop, I think. That's all I have for now. There are some other issues that I had but they didn't come up in my test run tonight. I will test run it later this weekend to find the others, probably. (If I don't save the game, it will run longer so I can crash it doing something else.) Let me know if anyone has any ideas for #1-#4. Of those, all of them are relatively new other than the minimap thing. Ari 5.I added multiple info for turrent pitch and rotation to the gamesave/load,though I never had that crash when saving/loading svn save games,so I guess it's a platform depend problem... A bit offset:just want to comment on current radar minimap,I think the radar minimap is not very modern,drawing tons of 'moving lines' on radar is weird,esp with multiple fast moving units like vtols being tracked on radar... sorry,I was tired 'offset' should be 'off-topic' =) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems compiling
Am Dienstag, 7. November 2006 22:30 schrieb Dennis Schridde: Am Dienstag, 7. November 2006 21:08 schrieb Ari Johnson: On 11/7/06, Christian Ohm [EMAIL PROTECTED] wrote: On Tuesday, 7 November 2006 at 13:05, Ari Johnson wrote: With a fresh subversion checkout, you cannot compile Warzone because there is no win32/Makefile.in file in the repository. There are also currently crash bugs on MacOS that I am going to try to find time to track down, but hopefully someone knows what is going on with the win32 missing Makefile.in. Makefile.in should not be in the repository, it is created from Makefile.am by running ./autogen.sh. Revision 464 added some mingw stuff to the build system, the culprit being the added win32 in SUBDIRS in the main Makefile.am, which should probably enclosed in an if MINGW32. (If it serves any purpose. Looking at the diff for r464 it doesn't. What's win32/warzone2100.o for and how is it generated?) Another problem was #include malloc.h in src/gateway.c. I think that somewhere along the way we lost the configure.ac bits to find malloc.c and attach an appropriate -I to CFLAGS. (My system has malloc.h, but it is not in /usr/include but rather a subdirectory of that one.) I removed that looong ago, I think. :( I'll check if there is an autoX way to find the correct -I flag... The inclusion of malloc.h doesn't seem to be needed. Removed in r471. configure.ac still refers to win32/Makefile, but there is no win32/Makefile.am in the repository. The only files in win32 that I get with a fresh checkout are Warzone.sln, Warzone.vcproj, warzone2100.ico, and warzone2100.rc. Did I forgot to commit the file? :( Now fixed. pgpfEGr8iD9Wx.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
