Re: [Warzone-dev] WZ Profiled yet again
- Original Message - From: "Kamaze" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, March 30, 2007 6:40 PM Subject: Re: [Warzone-dev] WZ Profiled yet again Well, this is cutted down or? (the image) Otherwise it would be odd that all numbers += ~58% :) Yes, it's only showing the most evil functions. The comma-separated-values file has a complete listing of all functions. Troman - Kamaze Troman schrieb: I was playing around with AMD's CodeAnalyst and here's what I got when profiling debug build of WZ. I know this was already done before with some other application, but someone might be interested anyway. Although it would be more interesting to know what's eating up most of the CPU time in the release build. Troman ___ 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 mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Coding style
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, February 23, 2007 8:42 PM Subject: Re: [Warzone-dev] Coding style On 2/23/07, Giel van Schijndel <[EMAIL PROTECTED]> wrote: What I personally do *not* like about that coding style is the usage of tabs (because of variable tabsize) I think we should only maintain this tabsize in current files but definitely not use it in new ones (I'd vote for a 4 space indentation). Especially the printf example on the above link points out that this (tabs followed by space) identation isn't particulary nice (or easy for that matter, and ease of use/programming/writing seems the most important thing here to me). It is not my favourite, either, but I like consistency, and this style is rather consistently used throughout Warzone sources. So I would very much like it to remain that way, and I do not want new files to suddenly have a new style. I can manage to do the mental switch between styles when moving my attention between different projects, but to mentally switch styles when opening different files *in the same project* seems to ask a bit much, IMHO. I am a bit torn on the spaces after ( and before ), though. In the Warzone sources it is about half this way and half (no spaces). I have been adding spaces consistently in code I changed, though, and I'd hate for all that mind-numbing space-pressing to have been in vain ;-). - Per If we want to be consistent I suggest we drop the spaces before and after round braces. After looking at the code I haven't found many places in the code where this style is used. 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" Sent: Wednesday, February 14, 2007 11:59 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" 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" >> 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" >> >> 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? If I got that right data is assigned to variables successively, so figuring out the correct string shouldn't be a problem. First data entry gets assigned to the first variable, second data entry to the second variable and so on. I suppose saving strings can be done the way you suggested it. When saving a string first save its type as usually, then its length as UWORD for example and then dump the string itself. When loading the right string variable can be found with eventGetContextVal(), based on index of the loaded data and then that data can be safely copied to the .sval field of that script variable returned by eventGetContextVal(). I'm done with programming for today, if your hands are itching to take care of it go ahead, otherwise I can do it in the next days as I'm in a 'fix-it' mood lately anyway. 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" 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" 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" >> 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
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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" 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
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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] 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" 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" 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
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: Tuesday, February 13, 2007 8:45 PM Subject: Re: [Warzone-dev] Current problems On 2/13/07, Troman <[EMAIL PROTECTED]> wrote: - Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, February 11, 2007 11:33 PM Subject: Re: [Warzone-dev] Current problems >> Not sure I understood it. You said loading on mac worked before some >> revision. Have you endianized evntsave.c and scriptobj.c before that >> or >> did >> it work without endianization? Or are you referring to some changes >> that >> were made to evntsave.c and scriptobj.c in some revision? > > I never did any work on those files. Saving and loading used to work > (it works in 2.0.5). This is strange, I wonder how it could work without endianization, well anyway, I went through the saving and loading routines and endianized what I thought had to be endianized. I assumed you do endianization to make save files compatible with little-endian systems. I hope I didn't overlook anything. I guess the problem comes from something else. However, I have been going through your changes and noticed some of the particular weirdness ... whose idea was it to store psGroup->sRunData.forceLevel and .leadership as SDWORDs in the file but as UBYTEs in the game? Would there be any harm (other than of course breaking old savegames) in saving them just as UBYTEs? According to scriptLang.rtf both 'forceLevel' and 'leadership' are in %, we should be on the safe side storing them as UBYTEs. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, February 11, 2007 11:33 PM Subject: Re: [Warzone-dev] Current problems Not sure I understood it. You said loading on mac worked before some revision. Have you endianized evntsave.c and scriptobj.c before that or did it work without endianization? Or are you referring to some changes that were made to evntsave.c and scriptobj.c in some revision? I never did any work on those files. Saving and loading used to work (it works in 2.0.5). This is strange, I wonder how it could work without endianization, well anyway, I went through the saving and loading routines and endianized what I thought had to be endianized. I assumed you do endianization to make save files compatible with little-endian systems. I hope I didn't overlook anything. Troman mac_script_load_save.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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" 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: '' >> > 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: '' >> >> 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.
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" 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: '' > 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: '' 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] Patch: Fog of War / Mist
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, February 10, 2007 5:44 PM Subject: Re: [Warzone-dev] Patch: Fog of War / Mist On 2/10/07, The Watermelon <[EMAIL PROTECTED]> wrote: On 2/10/07, Gerard Krol <[EMAIL PROTECTED]> wrote: > Fog of War seems to be broken in that it renders a "foggy" sky instead > of a black background. Fixed that. hmm just curious,do you know why the sky texpages are unused/broken?seems it draws orange color filled 'fog' instead of the 'sky background' png stored in texpages folder... I don't think that was ever implemented. Right, it wasn't implemented. Anyone remember them being there in the original? - Per ___ 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] (repost) Patch: Removal of the AND and OR macro's
Applied in r731. Troman - Original Message - From: "Gerard Krol" <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, February 10, 2007 2:07 PM Subject: [Warzone-dev] (repost) Patch: Removal of the AND and OR macro's Hi, Noticed this one still has not been applied. Still interested? - Gerard ___ 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] scriptlang.rtf outdated
New scripting functionality will be documented and supported with the release
of the updated scripting engine (I'm not sure when it will be though). Until
then there are still things to be polished/removed/modified.
There might be functions that don't rely on any new functionality and can
already be safely added, but right now i'm short on time to go through them.
Troman
- Original Message -
From: The Watermelon
To: Development list
Sent: Monday, February 05, 2007 8:21 PM
Subject: [Warzone-dev] scriptlang.rtf outdated
I was adding some script functions to add the ability to enable/disable
design window and techshare in mp,then I suddenly noticed that some of the
script functions are undocumented in scriptlang.rtf.
the following lines in bold should be inserted to scriptlang.rtf between
'skFireLassat' and 'SCRIPT FUNCTION CONSTANTS',
as they are the 'new' script functions added by Troman and others after the
source release I think.
I dont have a tool to insert those lines to scriptlang.rtf without breaking
the hideous richtext tags,
so I decide to post them there,so that someone can do this for me...
VOID debugMenu
Show/Hide multiplayer debug menu.
VOID setDebugMenuEntry { STRING string, INT index }
Set debug menu output string,string:text string
index:index id of debug menu entry.
VOID scrSetTileHeight { INT tileX, INT tileY, INT newheight }
Modifies height of the tile with tileX,tileY coords specified to new height.
VOID processChatMsg { STRING string }
Process STRING string.
STRING getChatCmdDescription { INT index }
Returns a string representing a certain chat command,
based on the command index provided.
INT getNumArgsInCmd
Returns number of command arguments for a certain
chat command that could be extracted.
BOOL getChatCmdParam { INT commandIndex, INT paramIndex }
Returns a certain parameter of a certain chat command.
Returns FALSE if failed.
BOOL chatCmdIsPlayerAddressed { INT commandIndex, INT player }
Returns true if a certain command was addressed to a certain player.
--
___
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" Sent: Saturday, January 27, 2007 6:50 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" 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" >> 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: '' >> > 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. I added an additional check which should prevent wz from calling the CALL_NEWDROID script callback when droid wasn't successfully placed on map. Although i'm not sure if this is what is causing the problem, this is the only thing I can think of right now. If this won't fix it, i'll take a closer look at it at the end of the next week. Troman ___ 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 mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: Monday, January 29, 2007 6:27 AM Subject: Re: [Warzone-dev] Current problems 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)' It is probably related to https://gna.org/bugs/?7317 Regarding the color thing, I have found that some places in src/*.c use the byte.r, byte.g, byte.b, and byte.a entries instead of a row 0xaarrggbb number, so I can't do all the endianizing in the ivis code. However, I just came up with an idea that I will test out, which is using an #ifdef to change the order of the entries in the struct if you are on a big-endian machine. I'll report back how that works for me. ___ 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" 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" 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: '' > 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] Music playlists
- Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Saturday, January 27, 2007 6:35 PM Subject: tmp Troman schreef: - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Friday, January 26, 2007 10:44 PM Subject: tmp2 Dennis Schridde schreef: Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman: - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Thursday, January 25, 2007 5:57 PM Subject: temp Wel the functions on their own look quite good to me. Their prototypes however... Let's just say that I don't like the idea of passing pointers into the scripting engine. Why not? That's the way most of the scripting stuff works right now. Scripts currently work with a lot of pointers passed from WZ, although from the scriptor's point of view there's no difference between integers/bools or pointers to some internal wz structures. Not that it really matters to me. If we just work with integer ids, that would mean we have less different types to define for scripts (I don't really like the idea of flooding scripts with dozens of new types, unless really needed, but i'm not yet sure what would be optimal for us). The fact that that's the currently employed technique hardly makes it be good. Not just because of that, it simply works well, I had no issues with pointers whatsoever. And indeed from the scripter there is no difference between a regular integer or a pointer. Which makes it all the more dangerous to pass pointers into scripts. This could easily result in a segfault beyond our control. The way it is now you can't do anything to a pointer but only access it, bison would simply not compile script if you tried to manipulate a pointer, there are no operations that pointers support. You can't even set it to NULL using scripts, that makes pointers safe. What you can do is pass it to some internal function for it to mess it up and that's it. So that's not an issue. Ah so if I understand it correctly the scripts can only use pointers for API calls and only change their value through them? Yes, exactly. In that case it wouldn't be as dangerous as I thought it was. BTW why don't we just use forums for such discussions? This starts to look a bit awkward to me. Maybe we can ask Kamaze to set up some protected area for the developers and those participating in the mailinglist discussion? Personally i'd also be fine with a public forum, not sure if this would work well though. I think most of us are going well with a mailinglist and prefer it this way. At least to me it's much simpler to fire up my mail client and watch several threaded discussions. Forums have that flat, time-related style (lost the words... Allready getting late. I mean they only have one direction, you can't split of a discussion as easily) which makes the inconvenient IMO... Yep, I'm one of them, I really do prefer an email client above a forum. Well no forum then. It's just when replying you have to count those 'greater than' signs to find out who you are actually refering to and when you have more than 10 that looks messy not to mention that all text is cluttered. Hmm, well, I could advise the Thunderbird thingy again. It turns those '>'-signs into nice quote blocks for viewing purposes. Although I thought MS outlook did the same. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: 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: '' 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
- Original Message - From: "Ari Johnson" <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, January 27, 2007 4:09 AM Subject: Re: [Warzone-dev] Current problems 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)' Any clues on what that means? That could be related to r673. The CALL_NEWDROID is triggered when new unit comes out of factory. I will take a look at it when I will have a bit more time. I hope that doesn't get triggered too often during the game. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for removing the AND and OR macro's
- Original Message - From: "Gerard Krol" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, January 26, 2007 10:58 PM Subject: [Warzone-dev] Patch for removing the AND and OR macro's Hi all, The AND and OR macro's annoyed me, so I decided to remove them in flavor of the native && and ||. - Gerard My hands were always itching to do this. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Friday, January 26, 2007 10:44 PM
Subject: tmp2
Dennis Schridde schreef:
Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman:
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 5:57 PM
Subject: temp
Wel the functions on their own look quite good to me.
Their prototypes however... Let's just say that I don't like the idea
of
passing pointers into the scripting engine.
Why not? That's the way most of the scripting stuff works right now.
Scripts currently work with a lot of pointers passed from WZ, although
from
the scriptor's point of view there's no difference between
integers/bools
or pointers to some internal wz structures.
Not that it really matters to me. If we just work with integer ids, that
would mean we have less different types to define for scripts (I don't
really like the idea of flooding scripts with dozens of new types,
unless
really needed, but i'm not yet sure what would be optimal for us).
The fact that that's the currently employed technique hardly makes it be
good.
Not just because of that, it simply works well, I had no issues with
pointers whatsoever.
And indeed from the scripter there is no difference between a
regular integer or a pointer. Which makes it all the more dangerous to
pass pointers into scripts. This could easily result in a segfault
beyond our control.
The way it is now you can't do anything to a pointer but only access it,
bison would simply not compile script if you tried to manipulate a pointer,
there are no operations that pointers support. You can't even set it to NULL
using scripts, that makes pointers safe. What you can do is pass it to some
internal function for it to mess it up and that's it. So that's not an
issue.
In fact I think dynamic arrays (std::vector or std::list) are probably
the
best way to solve this. Then once your using C++ anyway you might as
well use a smartpointer to hold the `track' object which will fix the
problem I
mentioned above.
Such a small usage of C++ should be rather easy to contain/manage in a
single (e.g. `lib/sound/playlist.cpp') source file.
Well, C doesn't have std::vector, so I had no other idea...
What I just thought about was some selfmade dynamic array:
struct Playlist { meta-info; Track[]; }
malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
or realloc( ... );
Doesn't look nice, but would be an option...
While surely not as elegant as dynamic arrays we can as well just use
fixed
arrays if those are only used to hold pointers to playlists, to be
honest I
doubt anyone would want more than, say, 20 playlists at a time (i'm
being
rather generous).
Erm, I actually meant to contain the playlist itself (i.e. a list of
tracks in an order) in a dynamic array, so that dynamic array would _be_
the playlist.
Oh and 20 playlists? Yes you're being generous, I'd guess 5 would
already be enough. ;-)
WZSound_setPlaylist( "none" );
WZSound_playTrack( "event1.ogg" );
WZSound_setPlaylistMode( "shuffle", "fadein" );
WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
WZSound_setPlaylistMode( "none" );
Lets not use Cstrings (or any piece of rope for that matter; i.e.
strings)
to indicate play modes.
This was for the scripting engine. I don't think it supports bitflags,
does
it? So the first and possibly easiest option was concatenating strings.
Maybe we could also provide the C-defines (PLAYLIST_SHUFFLE,...) as
constants
to the scripting engine and add them on another...
Sure, best way to solve this is to provide constants predefined by wz,
works like a charm.
Sounds nice.
PS: geez am I the only one having trouble replying to attached
files?
Apparently: Yes...
Wouldn't have asked if it was apparent. I was refering to those '>'
markers actually. Don't see a way how to add them with outlook
express,
which forces me to make a small detour.
Outlook doesn't give you those '>' if you press reply on a mail which
has
an attached file???
Of course I can advise you to take and use Thunderbird instead ;-) .
It's more powerful than Outlook (e.g. in case of low level access, mem
footprint, etc).
Might as well do this someday, for now I think I'll give Outlook a try
and
see if it offers enough functionality (using Outlook Express right now).
BTW why don't we just use forums for such discussions? This starts to
look
a bit awkward to me. Maybe we can ask Kamaze to set up some protected
area
for the developers and those participating in the mailinglist
discussion?
Personally i'd also be
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 5:57 PM
Subject: temp
Am Donnerstag, 25. Januar 2007 15:46 schrieb Giel van Schijndel:
On Thu, 25 Jan 2007 07:31:25 +0100, Dennis Schridde <[EMAIL PROTECTED]>
wrote:
> Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
>> - Original Message -
>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>> To:
>> Sent: Thursday, January 25, 2007 12:26 AM
>> Subject: Re: [Warzone-dev] Music playlists
>>
>>> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
>>>> - Original Message -
>>>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>>>> To: "Development list"
>>>> Sent: Wednesday, January 24, 2007 8:43 PM
>>>> Subject: Re: [Warzone-dev] Music playlists
>>>>
>>>>> Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
>>>>>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
>>>>>>> I had some musings about the way this should work. Playlist
>>>>>>> script
>>>>>>> interface will be most used by scriptors I assume. I see two main
>>>>>>> occasions when such an interface might be used:
>>>>>>>
>>>>>>> 1) when it is time to interrupt any background music that might
>>>>>>> be
>>>>>>> played and kick in some moody piece to create atmosphere, like it
>>>>>>> is usually done in campaigns.
>>>>>>>
>>>>>>> 2) when someone wants to attach a custom playlist to his map, the
>>>>>>> way it is done with Unreal Tournament maps for example.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> As for the implementation, looks like wz uses 'tracks' to store
>>>>>>> songs. Track 2 corresponds to menu, track 1 to the in-game music.
>>>>>>
>>>>>> I do not think we should let that get in the way of a decent API.
>>>>>> We can change the way Warzone stores songs, if necessary.
>>>>
>>>> Since i'm not the one to program it it's fine with me. ;-)
>>>>
>>>>>>> When modder wants his custom playlist to be played when someone
>>>>>>> is using his map he either loads all songs manually to the user
>>>>>>> track using scripts, like
>>>>>>>
>>>>>>> playlistAddUserSong("mySong1.ogg");
>>>>>>> playlistAddUserSong("mySong2.ogg");
>>>>>>
>>>>>> Sounds good.
>>>>>>
>>>>>>> Since this is not the most convenient approach it might be a
>>>>>>> better idea to load playlist from an external playlist file,
>>>>>>> which will come with the mod
>>>>>>
>>>>>> Well, to me the in-script version above seems more convenient
>>>>>> than adding yet another file, since the number of songs will
>>>>>> probably never be high.
I agree, I think it's better to simply stick with creating the playlist
through scripted functions. Also since I believe the scripts support an
`#include' style directive, you don't have to clutter all your scripts
with
playlist-append calls.
>>>>>>> In case of a map with custom playlist it is simple, just call
>>>>>>> something like playlistPlayUserTrack(); from within the scripts
>>>>>>> (or again we can make wz start playing user track automatically
>>>>>>> if a map comes with a user playlist) for wz to switch from player
>>>>>>> playlist to the custom map playlist.
>>>>>>
>>>>>> I think starting the script-supplied playlist automatically seems
>>>>>> like the simpler and better way.
>>>>
>>>> What if the user doesn't want any music to be played at the
>>>> beginning?
>>>> It's probably better to let the modder decide this.
>>>
>>> I think what Per meant is that there should be an initPlaylist
>>> function
>>> in the scripts, which is called upon mission start. If the modder
>>> doesn't want that, he must not provide that function.
>>
>> I don't know how we jumped from playback to init
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To:
Sent: Thursday, January 25, 2007 12:26 AM
Subject: Re: [Warzone-dev] Music playlists
> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > - Original Message -
> > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > To: "Development list"
> > Sent: Wednesday, January 24, 2007 8:43 PM
> > Subject: Re: [Warzone-dev] Music playlists
> >
> > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > >> > I had some musings about the way this should work. Playlist script
> > >> > interface will be most used by scriptors I assume. I see two main
> > >> > occasions when such an interface might be used:
> > >> >
> > >> > 1) when it is time to interrupt any background music that might be
> > >> > played and kick in some moody piece to create atmosphere, like it is
> > >> > usually done in campaigns.
> > >> >
> > >> > 2) when someone wants to attach a custom playlist to his map, the way
> > >> > it is done with Unreal Tournament maps for example.
> > >>
> > >> Agreed.
> > >>
> > >> > As for the implementation, looks like wz uses 'tracks' to store songs.
> > >> > Track 2 corresponds to menu, track 1 to the in-game music.
> > >>
> > >> I do not think we should let that get in the way of a decent API. We
> > >> can change the way Warzone stores songs, if necessary.
> >
> > Since i'm not the one to program it it's fine with me. ;-)
> >
> > >> > When modder wants his custom playlist to be played when someone is
> > >> > using his map he either loads all songs manually to the user track
> > >> > using scripts, like
> > >> >
> > >> > playlistAddUserSong("mySong1.ogg");
> > >> > playlistAddUserSong("mySong2.ogg");
> > >>
> > >> Sounds good.
> > >>
> > >> > Since this is not the most convenient approach it might be a better
> > >> > idea to load playlist from an external playlist file, which will come
> > >> > with the mod
> > >>
> > >> Well, to me the in-script version above seems more convenient than
> > >> adding yet another file, since the number of songs will probably never
> > >> be high.
> > >>
> > >> > In case of a map with custom playlist it is simple, just call
> > >> > something like playlistPlayUserTrack(); from within the scripts (or
> > >> > again we can make wz start playing user track automatically if a map
> > >> > comes with a user playlist) for wz to switch from player playlist to
> > >> > the custom map playlist.
> > >>
> > >> I think starting the script-supplied playlist automatically seems like
> > >> the simpler and better way.
> >
> > What if the user doesn't want any music to be played at the beginning? It's
> > probably better to let the modder decide this.
> I think what Per meant is that there should be an initPlaylist function in
> the
> scripts, which is called upon mission start. If the modder doesn't want that,
> he must not provide that function.
I don't know how we jumped from playback to initialization. Anyway, for the
initialization of the playlist you just place the necessary code into the
script callback that gets called whenever a map is loaded.
>
> > >> > In cases when some music must kick in from time to time depending on
> > >> > some in-game conditions it is a bit more complicated.
> > >>
> > >> There are probably two different needs here:
> > >> 1) Scripter wants to play a short song to set the theme of some event,
> > >> then resume the playlist as normal. The new song should then not be in
> > >> the playlist afterwards.
> > >> 2) Scripter wants to change the whole theme of a level by playing a
> > >> new song or songs throughout the remaining time (or until it changes
> > >> again). So we need a way to reset the playlist; then the scripter can
> > >> add the new songs.
> > >>
> > >> So how about an API like this:
> > >> playlistReset() -- deletes existing playlist (eg to remove game
> > >> supplied playlist)
> > >> playlistAdd(son
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To: "Development list"
Sent: Wednesday, January 24, 2007 8:43 PM
Subject: Re: [Warzone-dev] Music playlists
>Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
>> > I had some musings about the way this should work. Playlist script
>> > interface will be most used by scriptors I assume. I see two main
>> > occasions when such an interface might be used:
>> >
>> > 1) when it is time to interrupt any background music that might be played
>> > and kick in some moody piece to create atmosphere, like it is usually
>> > done in campaigns.
>> >
>> > 2) when someone wants to attach a custom playlist to his map, the way it
>> > is done with Unreal Tournament maps for example.
>>
>> Agreed.
>>
>> > As for the implementation, looks like wz uses 'tracks' to store songs.
>> > Track 2 corresponds to menu, track 1 to the in-game music.
>>
>> I do not think we should let that get in the way of a decent API. We
>> can change the way Warzone stores songs, if necessary.
Since i'm not the one to program it it's fine with me. ;-)
>>
>> > When modder wants his custom playlist to be played when someone is using
>> > his map he either loads all songs manually to the user track using
>> > scripts, like
>> >
>> > playlistAddUserSong("mySong1.ogg");
>> > playlistAddUserSong("mySong2.ogg");
>>
>> Sounds good.
>>
>> > Since this is not the most convenient approach it might be a better idea
>> > to load playlist from an external playlist file, which will come with the
>> > mod
>>
>> Well, to me the in-script version above seems more convenient than
>> adding yet another file, since the number of songs will probably never
>> be high.
>>
>> > In case of a map with custom playlist it is simple, just call something
>> > like playlistPlayUserTrack(); from within the scripts (or again we can
>> > make wz start playing user track automatically if a map comes with a user
>> > playlist) for wz to switch from player playlist to the custom map
>> > playlist.
>>
>> I think starting the script-supplied playlist automatically seems like
>> the simpler and better way.
What if the user doesn't want any music to be played at the beginning? It's
probably better to let the modder decide this.
>> > In cases when some music must kick in from time to time depending on some
>> > in-game conditions it is a bit more complicated.
>>
>> There are probably two different needs here:
>> 1) Scripter wants to play a short song to set the theme of some event,
>> then resume the playlist as normal. The new song should then not be in
>> the playlist afterwards.
>> 2) Scripter wants to change the whole theme of a level by playing a
>> new song or songs throughout the remaining time (or until it changes
>> again). So we need a way to reset the playlist; then the scripter can
>> add the new songs.
>>
>> So how about an API like this:
>> playlistReset() -- deletes existing playlist (eg to remove game
>> supplied playlist)
>> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
>> supplied playlist)
>> playlistInterruptWith(song) -- play a song once, then resume playing
>> playlist (eg for event)
Makes sense to me.
>My proposal:
>
>Function to set a playlist.
>Function to immediately play one track.
>Function to stop playlist playback and one function to resume playback.
>Function to set playback-modes, like repeat_all, shuffle, fadein, fadeout,
>crossfade.
This all can surely be usefull to the end user/scriptor. Crossfades for
'insertations' especially in campaigns etc.
>
>Clearing the playlist is simply supplying an empty playlist.
>I don't think there is any need to dynamically attach a track to the playlist,
>am I correct? Why would one attach a song if he doesn't know when it will be
>played...
You never know what's going on inside of a modder's head, it doesn't take much
affort to provide this functionality, besides I don't see how else we would
want to re-fill the list (see below).
>Stoping and resuming the playlist may be interesting to create moments of
>total silence or when cutscenes are played.
>
>C-Functions:
>WZSound_setPlaylist( Song * song1, ... );
>WZSound_playTrack( Track interuptionTrack );
>WZSound_stopPlaylist();
>WZSound_resumePlay
Re: [Warzone-dev] WZ stats converter source
- Original Message - From: The Watermelon To: Development list Sent: Wednesday, January 24, 2007 9:05 AM Subject: [Warzone-dev] WZ stats converter source This is the source of the wz stats converter I sent devurandom a few days,havent worked on it for a while,because I was mainly working the '500KB' patch. This is unfinished,but I saw some advanced user on forum expressed their interests in modding wz,so I think this can help them a bit... Currently supports: weapons.txt,templates.txt,structures.txt,bodypropulsionimd.txt,assignweapon.txt,structureweapon.txt Mode:Old stats to New stats: convert old 'somename,somevalue1,somevalue2...' to '[somename] somevaluename1 = somevalue1; somevaluename2 = somevalue2; ...' Mode:New stats to Old stats:convert the new stats back to the primitive ones wz uses The read and write old/new stats functions are relative solid now,so I can add supports for other txt's relatively easy by adding a new function and copy the 'descriptive names' from wz stats load functions. It will only work with the txt in this zip archive for weapons and templates stats,because I added additional fields to them(ZNULLREARM and numMags). It's written in C and the 'main' function is ANSI C style like devurandom said,so it should work on both windows and linux as 'console' application.Though I only tested in windows cause my internet is borked,couldnt finish the linux installation with 45byte/sec dl speed... If you intend to distribute it already it would probably make sense to pre-compile it since not all modders can do it on their own. Troman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 500KB patch...
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Tuesday, January 23, 2007 4:03 PM Subject: Re: [Warzone-dev] 500KB patch... Am Montag, 22. Januar 2007 21:47 schrieb The Watermelon: > Couldnt separate them into smaller patches because the changes 'twisted' > alot...sorry for the huge patch. This is the final patch? Or another work-in-progress patch? (I won't have time to review it the next weeks... Sorry.) Won't have time for such a big patch either. Except for occasional fiddling around with AI scripts everything else is put on hold for the time being. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] wdgload utility
- Original Message - From: <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, January 20, 2007 9:08 PM Subject: Re: [Warzone-dev] wdgload utility On Sat, 20 Jan 2007 04:28:51 -0500 Troman <[EMAIL PROTECTED]> wrote: Are you refering to the gate mod we did with Elric back in the Pumpkin-2 times? If yes it won't work without source changes unfortunately. Gates would be very nice indeed and they do work well for human players, but it's difficult to make AI use it. Another difficulty is that as far as I remember Elric - author of the custom textures - prohibited using any of his work before leaving the team. Yes, I guess that is the same one. I didn't know Elric said that. There wasn't any readme file or anything in the gates.zip file. I just wanted to see if it could be done. :) I wonder if Elric still is that way? Anyone got a e-mail address for him we can ask? Don't have his email addy anymore, maybe someone else does. Anyway here's the source: http://user.supradigital.org/troman/mods/ it's a bit messy, but probably still better then the source extracted from wdg since it contains correct directory structure and correct filenames. Thanks! :D This will be a big help! BTW wrf files are not included into the final wdg file after compilation, they only contain instructions for wz and makewdg utility, so it's a bit difficult to reverse engineer wdg files. Troman From looking at the source as is now, it should be just a matter of telling the game to use these replacement wrf files instead of the original files. I do not see any code in the source files, so I wonder how they got them to open/close with no source code changes? Looks like I didn't put C Source into that archive when I created it, couldn't find it on my HD either, unfortunately. From what I can recall there were mainly three additions: 1) new structure to hold gate "function" (defined in functions.txt) 2) pretty annoying wall alignment code (when you put a horizontal gate next to the vertical wall section it shall become a corner wall etc) 3) the in-game gate functionality (right-click menu, opening, closing etc) I do not try original to see them work. I assume they work like other games gates? Yes, probably, maybe just more customizable. There were two gate behaviour modifiers accessible through the gates right-click menu: A 3-state-radio button with states: "Default state" (your own and ally units can pass; as soon as enemy unit approached gates it would close - power up the laser fence - not allowing anyone in or out), "Locked for all" and "Unlocked for all". And second one is an option to allow/disallow allies to cross the gates (in case you didn't want ai units to camp inside your base for example). On the downside there had to be two versions of the gate structure: a horizontal and a vertical one, which wasn't very optimal, but worked well for a MOD. That's basically it. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] wdgload utility
- Original Message - From: <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, January 20, 2007 2:33 AM Subject: Re: [Warzone-dev] wdgload utility On Fri, 19 Jan 2007 19:40:08 -0500 Christian Ohm <[EMAIL PROTECTED]> wrote: On Friday, 19 January 2007 at 14:19, [EMAIL PROTECTED] wrote: I got chance to play this wdgload utility Rodzilla sent, but I have question on conversions. I found a file called effects.wdg, and ran the wdgload on it, and it made a zip file with the information in it. There some files named strange like "bd486b8" they seem to be binary? I then happen to notice that is a pcx file??? Why strange names like that? Because WDGs don't contain the path/file names but identify files only through hashes. One of the reasons to get rid of them. Yes, you correct. I found info on berlios list, and Qamly talks about hashes, and what a mess they were. In zip is pie & pcx files now, so I need to convert to png then what about the pie? Do I convert those also, or something else needed to use? Convert the PCX to PNG, and adjust the name in the PIE file. Then how game know to use files? If I understand what you say, you talk about direct replacement for current files correct? What about some of these that use the hash for name? How to tell game to use that hash filename? Does it not need to be defines someplace? Also reading berlios, I think that this means that wrf files control what is loaded I think. But how he convert the wrf files to do this? Or was (is?) there a newer version of wdgload or something else that handles this? I sent e-mail to Qamly's address in logs, that address, it didn't bounce, so I think account is still alive. Maybe he can help? I am trying to do gates mod to work with wz as small test for mods. I think gates will be nice in wz! Are you refering to the gate mod we did with Elric back in the Pumpkin-2 times? If yes it won't work without source changes unfortunately. Gates would be very nice indeed and they do work well for human players, but it's difficult to make AI use it. Another difficulty is that as far as I remember Elric - author of the custom textures - prohibited using any of his work before leaving the team. Anyway here's the source: http://user.supradigital.org/troman/mods/ it's a bit messy, but probably still better then the source extracted from wdg since it contains correct directory structure and correct filenames. BTW wrf files are not included into the final wdg file after compilation, they only contain instructions for wz and makewdg utility, so it's a bit difficult to reverse engineer wdg files. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Development list"
Sent: Sunday, January 14, 2007 3:48 PM
Subject: Re: [Warzone-dev] Music playlists
On 1/12/07, Troman <[EMAIL PROTECTED]> wrote:
Per, do you want scripts to be able to create/manage playlists or just
start
some soundtrack with playBackgroundAudio()?
Now that you mention it, I think we would should have an interface to
some kind of playlist from scripts, not just playBackgroundAudio().
Not sure what exactly you have in mind, but as I see it all we need is
an
interface between scripts and some wz playlist functionality, and in
either
case that should be fairy easy to add the necessary script functions.
Could you have a go at it? If changes to the sound code is required, I
can do those, but I think pretty much everything that would be needed
is there already.
I might take a look at it in the next days.
Troman
I had some musings about the way this should work. Playlist script interface
will be most used by scriptors I assume. I see two main occasions when such
an interface might be used:
1) when it is time to interrupt any background music that might be played
and kick in some moody piece to create atmosphere, like it is usually done
in campaigns.
2) when someone wants to attach a custom playlist to his map, the way it is
done with Unreal Tournament maps for example.
As for the implementation, looks like wz uses 'tracks' to store songs. Track
2 corresponds to menu, track 1 to the in-game music. We can add a 'user
track', which will not be directly accessible by the player from inside the
game.
When modder wants his custom playlist to be played when someone is using his
map he either loads all songs manually to the user track using scripts, like
playlistAddUserSong("mySong1.ogg");
playlistAddUserSong("mySong2.ogg");
Since this is not the most convenient approach it might be a better idea to
load playlist from an external playlist file, which will come with the mod;
either using scripts, like:
playlistLoadUserTrack("myPlaylist.wpl");
or we can make wz recognize a pre-defined filename and load it
automatically.
In case of a map with custom playlist it is simple, just call something like
playlistPlayUserTrack(); from within the scripts (or again we can make wz
start playing user track automatically if a map comes with a user playlist)
for wz to switch from player playlist to the custom map playlist.
In cases when some music must kick in from time to time depending on some
in-game conditions it is a bit more complicated. If user manually adds songs
to the user playlist using script functions we might make this function
return some handle so that modder can refer to a particular song, since
different songs must be played on different occasions selectively, using
this handle or we can simply reuse the filename.
When some song must be played call playlistPlayUserSong(song_handle); or
playlistPlayUserSong("song_name.ogg");
In such cases it might not even be necessary to add songs to the playlist
before playing it, I guess it depends on whatever implementation we will
choose.
I'm not sure if we really need an additional 'user track', but it has
following advantages: songs defined by player and modder are present at the
same time and are kept in separate places. While playing player playlist
(sorry for the tongue twister) wz will not accidentally start playing a song
which might be reserved for a special occasion by the modder.
On startup wz can switch to the 'user track' to play songs defined by modder
while still leaving the player ability to switch back to his own playlist.
Comments?
Troman
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, January 14, 2007 2:51 PM Subject: Re: [Warzone-dev] Music playlists On 1/12/07, Troman <[EMAIL PROTECTED]> wrote: Per, do you want scripts to be able to create/manage playlists or just start some soundtrack with playBackgroundAudio()? Now that you mention it, I think we would should have an interface to some kind of playlist from scripts, not just playBackgroundAudio(). Not sure what exactly you have in mind, but as I see it all we need is an interface between scripts and some wz playlist functionality, and in either case that should be fairy easy to add the necessary script functions. Could you have a go at it? If changes to the sound code is required, I can do those, but I think pretty much everything that would be needed is there already. I might take a look at it in the next days. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Thursday, January 11, 2007 1:17 PM Subject: [Warzone-dev] Music playlists I think it would be a good idea to start adding some of the music that has been made, just to show that we care. So I had a look at the playlist code, and was a bit surprised at why it was made the way it is. Basically, the current playlist code was made after the code release, and just uses the text file data/music/music.wpl as a list. There is also a script command "playBackgroundAudio" which looks like it is supposed to control music from within scripts, and this seems to me a vastly superior solution. This way a scenario can change the music soundtrack from its scripts depending on where you are in the campaign, for example. However, this script command does not seem to be used anywhere, and ends up in a dummy function (lib/sound/openal_track.c:sound_PlayStream(...)). I think I would prefer fixing the script function, rather than keeping the playlist code. What is the opinion of everyone else? Troman, you are the script guru, any thoughts? - Per Sorry, wasn't online in the last few days. Per, do you want scripts to be able to create/manage playlists or just start some soundtrack with playBackgroundAudio()? Not sure what exactly you have in mind, but as I see it all we need is an interface between scripts and some wz playlist functionality, and in either case that should be fairy easy to add the necessary script functions. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: Increasing units 'caps'
Am Samstag, 6. Januar 2007 06:55 schrieb [EMAIL PROTECTED]: > On Fri, 05 Jan 2007 17:07:33 -0500 Joonas Saraj?rvi > > <[EMAIL PROTECTED]> wrote: > >The Watermelon kirjoitti: > >> You also have to remember that if you do increase it, and > > > >people > > > >> get up to that many units, the game may becomes a slideshow. > >> Depending on system of course. > >> > >> Do we have a minimum requirement for this game that we are > > > >sticking > > > >> to? > >> > >> I think the current bottleneck of overall performance is the > >> draw functions,not units ai/coords/info update functions,and > > > >there will > > > >> always be more rooms for optimizations for units 'update' > > > >functions even > > > >> if it becomes the major performance killer one day. > > > >Hello, this is my first posting here. I am posting this via gmane > >so I > >don't know if this really works. > > > >Anyways, could the unit limits be made configurable? At least in > >skirmirh games? > > Yes, I see your post, so it seems to work. :) > > Yes, it could be made like that, but the problem is the GUI. It > isn't easy to do anything with it really. Configuration via the config file should be rather easy. Not so easy for the users, but at least they have the possibility to change it, then. We have to make sure this works well in multiplayer. Limits for all players must be synced somehow. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Compilation issues with r599
There are some variables declared not at the beginning of the block in r599 (mem.c - memFree() ). This will break compilation with comilers that are not C99 conform, like MSVC. Troman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r596 -/trunk/data/mp/stats/weapons.txt
- Original Message - From: The Watermelon To: Development list Sent: Thursday, January 04, 2007 6:31 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r596 -/trunk/data/mp/stats/weapons.txt On IRC we were talking about multiple turrets for commanders. There were 2 ideas: 1. One offensive and one defensive turret. You can control the offensive one and the defensive one tries to defend the commander and therefore marks defensive targets. Some it has to be choosen which target a groupmember wants to choose. (Can I better defend my commander or should I rather use his offensive recommendation?) Maybe a target can additionally marked as "urgent", in cases where the commander droid is like to get destroyed by that unit soon. I think the groupmember's target acquisition is completely 'take over' by the commander,all groupmember will always try to choose commander's primary target 'psTarget[0]',and I dont think this can be easily changed... 2. One ground and one air turret. The attached AA units obey orders from the air turret, while the others obey those from the ground turret. This follows the usual rules for target selection. (Use droid-target if possible: Commander AA turret can't attack ground units, so it will choose a better target. This can then be also attacked by the attached AA units. Same applies for ground turret / ground units.) 2 is probably easier to implement, while 1 simulates a much higher inteligency of the commander. What do you think? --Dennis same problem as '1',imo the commander in wz is a squad leader rather than a commander(the human player is the commander),so some primitive artificial intelligence should be sufficient,e.g:attack/retreat like a wolf pack,and I always think commander will be alot useful if a commander can 'lead' tons of weak units like scavenger infantry. I'll fiddle with commander a bit after I finish the wzStats converter,'finite ammo',airfield and navy features... I don't think it is a good idea to combine different weapon types, like AA/Arty/Direct weapons on a single unit, unless we offer player a way to assign targets separately for each turret, which we currently can't (and which is probably not trivial unit-ai-wise). I'm sure when the multi-turret feature is released one of the first requests will be such a feature though. (A bit offtopic) If we are to implement such a feature I can think of a following implementation: we enumerate either droid turret slots or turret types: AA/Direct weapons/Indirect weapons/Service (ie repair turret/construction turret etc). If we enumerate turret slots, the player selects units then presses alt+ to select turret slot and then he chooses target for selected turrets. This way one could put direct weapons on turret slot 1 and AA weapons on slot 2. Pressing alt+2 would mark AA weapons of the selected units as selected turret. In case of weapon type enumeration, _all_ AA weapon slots would be selected ragardless of their slot index, if player presses alt+. That still doesn't eliminate conflicting situation between different weapons though. Maybe marking first weapon slot as default one (or the last slot that was given a new target) would solve it. Troman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r592 - in /trunk:lib/script/chat_parser.y lib/script/parse.hlib/script/script_lexer.l lib/script/script_parser.ysrc/scriptfuncs.c src/scriptfuncs.h src/scriptta
This one seems to create a problem, but I don't exactly know why: ../lib/script/script_lexer.l: In function ‘scriptSetInputBuffer’: ../lib/script/script_lexer.l:733: error: invalid lvalue in assignment The line it means is apparently: YY_CURRENT_BUFFER = yy_scan_bytes(pBuffer, size); YY_CURRENT_BUFFER is defined to: /* We provide macros for accessing buffer states in case in the * future we want to put the buffer states in a more general * "scanner state". * * Returns the top of the stack, or NULL. */ #define YY_CURRENT_BUFFER ( (yy_buffer_stack) \ ? (yy_buffer_stack)[(yy_buffer_stack_top)] \ : NULL) Should be fixed in r598. Looks like some inconsistancies between different FLEX implementations. GnuWin32 flex defines it as a pointer to a yy_buffer_state structure. Is there perhaps a function to handle those assignments via a Flex function? If I search for YY_CURRENT_BUFFER in the created lex.c file, I also find YY_CURRENT_BUFFER_LVALUE which is refrenced by several functions which seem to deal with creation of buffers. Also it seems as if Flex has a buffer of YY_BUF_SIZE by default and doesn't need to have the whole file in the buffer... (There seem to be some input streams used.) Flex can't use physfs for input. Maybe by rewriting some cryptic macros, which is probably not worth it. Just setting FLEX buffer size to YY_BUF_SIZE would result in a crash, since it is not FLEX that is taking care of the input in our case. Troman --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r592 - in /trunk: lib/script/chat_parser.y lib/script/parse.h lib/script/script_lexer.l lib/script/script_parser.y src/scriptfuncs.c src/scriptfuncs.h src/scripttab
- Original Message - From: "Roman" <[EMAIL PROTECTED]> To: Sent: Tuesday, January 02, 2007 9:12 PM Subject: [Warzone-commits] r592 - in /trunk: lib/script/chat_parser.y lib/script/parse.h >lib/script/script_lexer.l lib/script/script_parser.y src/scriptfuncs.c src/scriptfuncs.h src/scripttabs.c Author: troman Date: Tue Jan 2 21:12:14 2007 New Revision: 592 URL: http://svn.gna.org/viewcvs/warzone?rev=592&view=rev Log: -Implemented C-like #include preprocessor directive for the scripting engine, can be used up to depth of >MAX_SCR_INCLUDE_DEPTH. Unlike C counterpart main purpose is to reuse executable and non->executable code. Example: #include "multiplay/skirmish/my_include.slo" -Implemented C-like #define preprocessor directive. Nested macros allowed with up to depth of >MAX_SCR_MACRO_DEPTH. -Added a script function for a fast feature iteration (returns burning as well as non-burning oil resources) -Replaced some custom Pumpkin routines with default FLEX routines -Some cleanups Some additional scripting comfort. If that breaks any stuff on other compilers please let me know. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Tuesday, January 02, 2007 12:22 AM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c Am Montag, 1. Januar 2007 22:49 schrieb [EMAIL PROTECTED]: On Mon, 01 Jan 2007 13:10:14 -0500 Troman <[EMAIL PROTECTED]> wrote: >Devurandom, I think I tested this patch throughly enough with all >in all >more than a day dedicated to reviewing and testing. Whenever I >make mistakes >and we are not making something of nothing I'm ready to stand to >them, but I >hope you understand checking each weapon after each patch is >something none >of us can afford. > >If this bug was re-introduced this could be due to the conflicts >in >projectile.c which is still a bummer and I'm glad you fixed it, >but I don't >think this is a reason enough to groundlessly accuse anyone of >being >careless out of the blue because of that. I wonder, if we have the biggest map available, (250x250), and have all units possible on that map caged off (like build walls around them), would that make it easier to test all units? I think EditWorld can help in this? EditWorld plus scripts (or just scripts) could handle this. This would catch most errors I am guessing. We would just need a person with enough grey matter to make said map. I don't know if that would help much... You could test if the game crashes or similar, maybe you can even find out that a missile explodes right when it is launched, if you know that you need to look for it. (Which we didn't in this case.) I wondered myself if it is possible to setup some kind of unittest. But I currently can't imagine one I am sure would bring any benefit. There is just so much that could be wrong... _If_ we had the logic seperated from the graphics/sound/etc. we could run some probability tests to see if a missile hits 50% of the time on a target 100m away or similar. Eg. feed that system with some target balancing and see if the current engine and data match it. It is possible without further modifications, the only thing that is needed is a way to feed scripts with expected results for automated evaluation of the tests, if such evaluation is desired. That said I doubt any of the above would really pay off for us, to be honest. Troman But sadly we can't have the logic seperate atm. :( --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Monday, January 01, 2007 2:16 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c Am Sonntag, 31. Dezember 2006 23:10 schrieb Troman: >- Original Message - >From: "Dennis Schridde" <[EMAIL PROTECTED]> >To: >Sent: Sunday, December 31, 2006 8:54 PM >Subject: [Warzone-commits] r590 - /trunk/src/projectile.c > > >Author: devurandom >Date: Sun Dec 31 20:54:46 2006 >New Revision: 590 > >URL: http://svn.gna.org/viewcvs/warzone?rev=590&view=rev >Log: >Fix broken SCOURGEs yet again. Please check your patches before >commiting... >(SCOURGEs exploded immediately when launched.) Strange, scourges worked for me when I tested, Well they didn't work when I checked it out, because of this change: http://svn.gna.org/viewcvs/warzone/trunk/src/projectile.c?rev=587&view=diff&r1=587&r2=586&p1=trunk/src/projectile.c&p2=/trunk/src/projectile.c which I stripped from his patches, because it broke the scourges... Devurandom, I think I tested this patch throughly enough with all in all more than a day dedicated to reviewing and testing. Whenever I make mistakes and we are not making something of nothing I'm ready to stand to them, but I hope you understand checking each weapon after each patch is something none of us can afford. If this bug was re-introduced this could be due to the conflicts in projectile.c which is still a bummer and I'm glad you fixed it, but I don't think this is a reason enough to groundlessly accuse anyone of being careless out of the blue because of that. I even did some candidate screenshots with that revision we _might_ want to use, although some post processing might be required. http://user.supradigital.org/troman/screnshots/ BTW please also check the order of patches before commiting, I had to resolve quite some conflicts in the projectile.c before commiting patch from 27.12.2006. Was that to me? Did I commit some patch which wasn't applied fully? Or do you mean that I didn't commit the Multi-Target patch before commiting other patches? That was on purpose, because Watermelon told me that you were working with him on that patch, because you want to give orders to each of the turrets, while his patch only allowed to give orders to the droid as a whole. This looks like a work of a confusion-devil. I didn't even have a look at the patch by that time. I solely expressed my worries about weapon functions relying on bitfields as return value someday, which was probably the premice for the inclusion of the int->bool return value conversion in the patch and my only contribution to it (except for some modifications before commiting it). Troman --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Sunday, December 31, 2006 8:54 PM Subject: [Warzone-commits] r590 - /trunk/src/projectile.c Author: devurandom Date: Sun Dec 31 20:54:46 2006 New Revision: 590 URL: http://svn.gna.org/viewcvs/warzone?rev=590&view=rev Log: Fix broken SCOURGEs yet again. Please check your patches before commiting... (SCOURGEs exploded immediately when launched.) Strange, scourges worked for me when I tested, I even did some candidate screenshots with that revision we _might_ want to use, although some post processing might be required. http://user.supradigital.org/troman/screnshots/ BTW please also check the order of patches before commiting, I had to resolve quite some conflicts in the projectile.c before commiting patch from 27.12.2006. Modified: trunk/src/projectile.c ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Java applet for IRC
That thingy: http://java.freenode.net/index.php?channel=warzone seems to work nice. I assume ChatZilla would exclude users of other common browsers like IE users, wouldn't it? Anyway, giving an occasional forum visitor an easy access to the IRC (and thus an uncomplicated way to provide some feedback or get help) using the web browser sounds like a good idea. Troman - Original Message - From: Belhorma Bendebiche To: Development list Sent: Saturday, December 30, 2006 9:15 PM Subject: Re: [Warzone-dev] Java applet for IRC Java applets are horrible. A link to ChatZilla would be more appropriate IMO. On 12/29/06, Gerard Krol < [EMAIL PROTECTED]> wrote: Hi, How about putting a link to http://java.freenode.net/index.php?channel=warzone on the page http://www.wz2100.net/irc-chat.html, or even the applet itself like described at: http://java.freenode.net/howto.php ? Regards, Gerard ___ 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 mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch] MALLOC/FREE issues
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, December 30, 2006 5:38 PM Subject: Re: [Warzone-dev] [patch] MALLOC/FREE issues Sorry, I've been offline for a week. I thought my memory cleanup patch had been permanently lost in my harddisk crash a while ago. Good thing I have a habit of sending patches to the list frequently, even though they don't really work quite yet ;-) The problems I encountered were in the scripting engine, which I did not take time to understand, so if Troman wants to look into making it work there, I can see if I could update it again. Do you remember what exactly caused problems? Memory pools, properly done, have some very interesting properties, and I know they are put do some good use in the Apache webserver and in Subversion (both using the APR library). I doubt Warzone uses memory pools for anything very interesting. From what I could tell it was doing very rudimentary memory corruption checking, which is way better done with valgrind, and I do not think the memory pool system in Warzone is not cooperating well with valgrind. - Per ___ 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] MALLOC/FREE issues
Troman schreef: - Original Message - From: "Christian Ohm" <[EMAIL PROTECTED]> To: Sent: Thursday, December 28, 2006 4:52 PM Subject: Re: [Warzone-dev] MALLOC/FREE issues On Thursday, 28 December 2006 at 15:37, Troman wrote: The issue of MALLOC was already raised in some of the previous messages, and there seems to be something wrong with those MALLOC/FREE macros. I noticed a memory leak in the scripting engine, to find out what is actually causing it I set up a (script) loop with 10k iterations with nothing but a string assignment in the loop body. Due to the nature of this loop the interpreter was pushing string/non-string data to the stack interchangeably, hence allocation/deallocationg memory for strings. The memory usage went up by ~3mb after each 10k iterations. I couldn't stumble upon any flaws in the code, looks like MALLOC/FREE are causing this. Anyway, after replacng MALLOC/FREE with malloc/free the memory leak is gone. Apart from that I noticed WZ memory usage is increasing by about 35 mb each time a skirmish game is restarted, it wouldn't surprise me if it was due to MALLOC/FREE anomalies. Do we actually have to rely on those two, ar would it make sense to simply replace them with malloc/free? I remember someone (I think Per) was trying to rewrite some functionality that dealt with wz memory usage that turned out to be a non-trivial task, I hope it is not related to MALLOC/FREE. https://lists.berlios.de/pipermail/warzone-dev/2005-September/000538.html Is that what you meant? There were no actual problems mentioned. That's probably it. I only caught the late resounding of this discussion. A memory pool system has a few advantages: It's faster (ideally), it prevents memory fragmentation (the underlying OS might try to do that as well), and it can have some debugging functionality. Debugging could be done by external tools like valgrind (though valgrind is slw). Fragmentation is more a theoretical problem, and speed... well, malloc is probably faster than a bad memory pool system. I just had a quick look at wz memory management and if I got it right wz marks FREEd memory and can reuse it whenever MALLOC is called again, I don't quite understand why it consumed more and more memory, even though at the time of my test there was nothing else that could have requested it. We could replace MALLOC/FREE with a new (proven, so we need to find a working GPL implementation) memory pool system, but the only real advantage is built-in debugging, as long as we don't run lots of mallocs/frees per frame. So I guess just ripping out the current system (and leaving debugging to valgrind and other tools) and just using malloc/free is a good start. AFAIK valgrind is not available on windows, I don't know if there are any good free tools available for windows comparable to valgrind, if there are some though, then this shouldn't be an issue. @Troman, where you using a debug or release build when finding out about that huge memory usage? I'm not sure, as I was switching back and forth several times yesterday, but I think it was a debug build. Because the debug and release builds have two different implementations of MALLOC/FREE, the release one being rather small and manageable functions, the debug one being awfully large and are far from nicely written. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] MALLOC/FREE issues
- Original Message - From: "Christian Ohm" <[EMAIL PROTECTED]> To: Sent: Thursday, December 28, 2006 4:52 PM Subject: Re: [Warzone-dev] MALLOC/FREE issues On Thursday, 28 December 2006 at 15:37, Troman wrote: The issue of MALLOC was already raised in some of the previous messages, and there seems to be something wrong with those MALLOC/FREE macros. I noticed a memory leak in the scripting engine, to find out what is actually causing it I set up a (script) loop with 10k iterations with nothing but a string assignment in the loop body. Due to the nature of this loop the interpreter was pushing string/non-string data to the stack interchangeably, hence allocation/deallocationg memory for strings. The memory usage went up by ~3mb after each 10k iterations. I couldn't stumble upon any flaws in the code, looks like MALLOC/FREE are causing this. Anyway, after replacng MALLOC/FREE with malloc/free the memory leak is gone. Apart from that I noticed WZ memory usage is increasing by about 35 mb each time a skirmish game is restarted, it wouldn't surprise me if it was due to MALLOC/FREE anomalies. Do we actually have to rely on those two, ar would it make sense to simply replace them with malloc/free? I remember someone (I think Per) was trying to rewrite some functionality that dealt with wz memory usage that turned out to be a non-trivial task, I hope it is not related to MALLOC/FREE. https://lists.berlios.de/pipermail/warzone-dev/2005-September/000538.html Is that what you meant? There were no actual problems mentioned. That's probably it. I only caught the late resounding of this discussion. A memory pool system has a few advantages: It's faster (ideally), it prevents memory fragmentation (the underlying OS might try to do that as well), and it can have some debugging functionality. Debugging could be done by external tools like valgrind (though valgrind is slw). Fragmentation is more a theoretical problem, and speed... well, malloc is probably faster than a bad memory pool system. I just had a quick look at wz memory management and if I got it right wz marks FREEd memory and can reuse it whenever MALLOC is called again, I don't quite understand why it consumed more and more memory, even though at the time of my test there was nothing else that could have requested it. We could replace MALLOC/FREE with a new (proven, so we need to find a working GPL implementation) memory pool system, but the only real advantage is built-in debugging, as long as we don't run lots of mallocs/frees per frame. So I guess just ripping out the current system (and leaving debugging to valgrind and other tools) and just using malloc/free is a good start. AFAIK valgrind is not available on windows, I don't know if there are any good free tools available for windows comparable to valgrind, if there are some though, then this shouldn't be an issue. Troman -- You can move the world with an idea, but you have to think of it first. ___ 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] MALLOC/FREE issues
The issue of MALLOC was already raised in some of the previous messages, and there seems to be something wrong with those MALLOC/FREE macros. I noticed a memory leak in the scripting engine, to find out what is actually causing it I set up a (script) loop with 10k iterations with nothing but a string assignment in the loop body. Due to the nature of this loop the interpreter was pushing string/non-string data to the stack interchangeably, hence allocation/deallocationg memory for strings. The memory usage went up by ~3mb after each 10k iterations. I couldn't stumble upon any flaws in the code, looks like MALLOC/FREE are causing this. Anyway, after replacng MALLOC/FREE with malloc/free the memory leak is gone. Apart from that I noticed WZ memory usage is increasing by about 35 mb each time a skirmish game is restarted, it wouldn't surprise me if it was due to MALLOC/FREE anomalies. Do we actually have to rely on those two, ar would it make sense to simply replace them with malloc/free? I remember someone (I think Per) was trying to rewrite some functionality that dealt with wz memory usage that turned out to be a non-trivial task, I hope it is not related to MALLOC/FREE. Troman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r569 - in /trunk: src/keybind.c
- Original Message - From: "Giel van Schijndel" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 27, 2006 1:19 AM Subject: [Warzone-dev] Re: [Warzone-commits] r569 - in /trunk: src/keybind.c Roman schreef: Author: troman Date: Tue Dec 26 17:39:07 2006 New Revision: 569 URL: http://svn.gna.org/viewcvs/warzone?rev=569&view=rev Log: -new 'height-map' radar mode (CTRL+TAB to cycle through radar modes) -revamped radar modes management Scripting engine: -some interpreter speedups -new script function to modify map tile height from scripts -made numeric pad keys 0-9 accessible from scripts Modified: ... trunk/src/keybind.c ... This revision breaks compilability of keybind.c. It uses an postfix operator ++ on an enum while an enum's basetype (e.g. int) is undefined and therefore doesn't have such an operator. Attached a very simple patch to fix this one. -- Giel Actually unlike in C++ using postfix increment on enum is perfectly legal in C and it doesn't even go outside of the last value in this particular implementation, so there shouldn't be problems. But if that breaks any compiler we should of course get rid of that. ;-) Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r547 - in /trunk/src: action.caction.h ai.c ai.h combat.c droid.c droid.h keybind.ckeybind.h keymap.c multimenu.c multimenu.h order.c scriptai.cscriptfuncs.c st
Am Freitag, 22. Dezember 2006 16:13 schrieb Roman:
Author: troman
Date: Fri Dec 22 16:13:04 2006
New Revision: 547
URL: http://svn.gna.org/viewcvs/warzone?rev=547&view=rev
Log:
-replaced some numbers scattered across the code with defines
-when looking for a new target droids/structures will now take into
consideration targets of the friendly droids/structures nearby
-droids/structures are now constantly looking for the best target - will
no
longer lock on decoys/walls and other crappy targets forever -ALT+Space
now
opens a special debug window - set window text with setDebugMenuEntry()
-minor cleanups
Modified:
trunk/src/action.c
trunk/src/action.h
I hope stuff like NAYBOR_SKIP_FRAMES doesn't really use the _frames_ for
calculation? If yes I strongly recommend using ticks instead as the fps can
vary a lot...
Utimately it will rely on ticks. That is after I have figured out why it
didn't work for me as expected.
If ticks are used it should be named NAYBOR_SKIP_TICKS and similar, of
course.
trunk/src/ai.c
There are variables like "failure"... Shouldn't these be defines instead??
Could be a define as well, but since value of 'failure' is not used anywhere
outside of the function with the same meaning it doesn't make sense to me to
get overenthusiastic with flooding source with redundant global defines.
Using a self-explanatory variable name does the readability trick here.
trunk/src/ai.h
trunk/src/combat.c
trunk/src/droid.c
trunk/src/droid.h
trunk/src/keybind.c
trunk/src/keybind.h
trunk/src/keymap.c
kf_FinishResearch got removed... Why?
Because I think a single copy of kf_FinishResearch is absolutely sufficient.
;-)
trunk/src/multimenu.c
trunk/src/multimenu.h
trunk/src/order.c
trunk/src/scriptai.c
trunk/src/scriptfuncs.c
trunk/src/structure.c
--Dennis
Troman
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thoughts on future development
- Original Message - From: "Christian Ohm" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 13, 2006 1:50 AM Subject: [Warzone-dev] Thoughts on future development Hi everyone, Here are some random thoughts about the future development of Warzone. Things about the code that need changing imo: - The graphics engine, including the GUI As I said, I don't think it's useful to keep the current one. As far as I could see there are four open source engines that run on Windows, Linux and MacOS: OGRE, Irrlicht, Crystal Space and OpenSceneGraph. The first three are of the "everything and the kitchen sink" variant (with different renderers, file handling...) and include more than just the graphics engine. The fourth, OpenSceneGraph, is just that - an OpenGL scene graph library without much else (and thus my favorite). One problem with an external engine is availability. OGRE in Debian unstable is at version 1.0.6 (current is 1.2.4) and the last time I tried, wasn't straightforward to compile. Irrlicht is not in Debian, but was easy to compile. CrystalSpace in Debian is at 0.99, while 1.0rc is available, don't know about compilation. OpenSceneGraph is current. That's for Debian, I don't know which other distros include which version of those libs, but if we use an external lib, it has to be in lots of distros, and easily compileable for the rest, or we'll get no end of questions like "i cant compile teh 3d engine help plz or ur teh sukz". Or we include the engine (at least in releases), then we have to keep it current and integrate it into the build system. A new graphics engine needs the models in a compatible format which is dependent on the engine used, of course. There's a format called COLLADA which is intended as an interchange format to transfer data between 3D apps, and so should be supported by most newer 3D apps. This can be loaded directly by OpenSceneGraph (and I think OGRE as well), and is supported by Blender (so transferring the old models to a new format is no problem, once someone finds Rodzilla's Blender importer for PIEs or I finish mine). For faster loading the models could be converted to a binary format for releases (OpenSceneGraph has a converter for that, don't know about the others). The current gfx engine is surely outdated, but considering the nontrivial nature of this task and our limited manpower we really have to be sure we can pull this off, so we won't bargain one trouble for another getting stuck in a dead-end. In other words under current circumstances i'm a bit sceptical, but it shouldn't stop anyone who is sure of a positive outcome. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] liboil: interesting for performance improvements, but GCC only
- Original Message - From: <[EMAIL PROTECTED]> To: "Development list" Sent: Wednesday, December 06, 2006 12:11 AM Subject: Re: [Warzone-dev] liboil: interesting for performance improvements,but GCC only On Tue, 05 Dec 2006 17:23:29 -0500 Dennis Schridde <[EMAIL PROTECTED]> wrote: Just found this library on my system and investigated: http://liboil.freedesktop.org/wiki/ It implements several commonly used functions, mostly matrix computations and similar, in (GCC(!)) inline assemble and checks on startup which one is the fastest for the CPU it is currently running on, so that all calls to oil_* functions use the fastest implementation. Might be interesting, especially the matrix stuff, but sadly won't compile on MSVC... --Dennis AMD also has some matrix stuff that works on all platforms, but I don't think we need any of that, we will not really see any real speed improvements looking at the code. Anyway, about MSVC, I can't get the program to compile 'as is' with MSVC. Tons of errors, and I got the devpkg.7z & warzone-devpkg.7z & warzone-lexfiles.7z. Is there something missing? By "as is" I mean I just did a svn checkout, then un7ziped those above to the directory, then open the Warzone.sln file in VCEE, and you get to the point where I am now. Short list of errors, there are 100's of others. Error 410 error C2061: syntax error : identifier 'aText' level_lexer.l Error 411 error C2059: syntax error : ';' level_lexer.l Error 692 error C2061: syntax error : identifier 'STRING' resource_parser.y Error 694 error C2061: syntax error : identifier 'res_lval' resource_parser.h Error 731 error C2061: syntax error : identifier 'YYSTYPE' resource_parser.c So I figure I would ask whats up? If someone has the correct .sln file(s) then please post them to mailing list or stick on the ftp site or throw a link. As Watermelon pointed out, this is probably due to the outdated/missing lexer/grammar files. I have written a Flex/Bison compilation guide http://wz2100.net/wiki/user:flex_bison_win , it should cover all the necessary compilation steps for windows users. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Backporting fixes for 2.0.5?
Let's see if this finally gets through. - Original Message - From: "Christian Ohm" <[EMAIL PROTECTED]> To: Sent: Sunday, December 03, 2006 3:51 AM Subject: Re: [Warzone-dev] Backporting fixes for 2.0.5? On Saturday, 2 December 2006 at 19:11, Dennis Schridde wrote: Am Samstag, 2. Dezember 2006 18:51 schrieb Christian Ohm: > There have been quite a few patches fixing things, or adding small > features while touching only a few lines of code in the trunk (the > playlist fix, and the SDL_QUIT and gamma patches, for example). Any > plans to apply those to 2.0 as well? Go for it... ;) Actually it was not directly planed, but if someone wants to do it... I had a look at the SVN changelog. In most cases, I don't know if the fix applies to 2.0 as well or just a new feature. And there are quite a few patches where I can't find the supposed fix in the remaining changes, so the original author might want to have a look: r371: Fixed script compilation bugs r383: Remove an unnecessary and wrong cast applies r386: Disabled "Allied players send vision to each other automatically (only once)" for "Allow alliances" alliance mode r397: Correct openal buffer applies, but needs another change r405: Fixed difficulty slider applying settings to the wrong players r407: Fixed disabled AIs showing up in the game r411: fixed and enabled shared ally vision for TEAMPLAY and 'Locked Teams' modes fixed disabled players allying their team members r413: Fixed double messages in online games r415: Fixed AIs getting renamed when changing player number in MP games. Prevented NETbcast() from flooding the log in games with no network communication. orderDroidObj() scripting function will no longer cause ASSERT when DORDER_DROIDPERAIR is passed as parameter. r422: It is now possible to win in a team in 'Locked Alliances' mode, also in this mode a player doesn't lose until all of his team members were defeated Game now shows a text message when player has won/lost the game (just a temporary solution to bug #7317) Added extra heap debug, should be there at least until we fix bug #6530, as PTRVALID() doesn't seem to detect corrupted DROID pointers on win Increased number of iterations A* is allowed to do per frame, which will hopefully speed up pathfinding Fixed multiplayer menu slider bug (bug #6529) Fixed players not forwarding enemy units visibility to their allies in 'TEAMPLAY' and 'Locked Alliances' modes r424: Re-enabled some debug keys and disabled unused ones r427: Process SDL_QUIT applies r428, r430, r508: Add gamma controls combined patch may be attached r436: fixed implicit bool/int to string convertion for the scripting language minor scripting function fixes r440: Make lots of __inline, _inline, FUNCINLINE and whatnot static inline. See bug#7591 r448: Fixed double declaration of "FUNCTION" token for bison r451: resolution config value has been changed to width and height (easier to parse). I probably forgot to tell that I changed the --viewport cl option to --resolution, which should be more clear to non programmers needs parts of the previous one as well. I think we should use --resolution in 2.0 as well, so we do not need to document the different versions. r452: Report wrong tracknumbers to LOG_SOUND and don't crash in sound_Play*DTrack Correct --help text Make console backlog key configurable r459: HP/Reload bars overlaping only for multi-turret? r460: commander-related crash fix r472: sensorcrash.patch: fixes a crash when repairing a not damaged command center, corrects the mouse cursor r474: Fix for bug #7708: isHumanPlayer() now checks for player numbers outside the range if [0,MAX_PLAYERS) applies r492: License clarification about original data files add this or whatever we decide on r499: fixes disappearing oil derricks (bug #7740) r501: Fix typos in COMPILE and remove outdated COMPILE.html plus check other docs r502: Check for '\r' as well as '\n'. This should make playlists with DOS line endings work applies r511: Attempt to fix a script callback bug as described on IRC r515: Fixed target prediction finally Fixed a bug which prevents AA weapon area of effect damage from working properly Fixed crashes when firing at baba people,baba vehicle in singleplayer campaign r517: Fixed a potential crash with transport Fixed a crash/repair units disorder when linked to a commander None of my commits apply to 2.0. Most of what I have done will have to wait until 2.1 or later. If time will permit I will take a closer look at the bugfixes, although most of them seem to apply to the features to be released in 2.1. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r513 -/trunk/lib/widget/scrap.c
Am Sonntag, 3. Dezember 2006 01:50 schrieb Troman: Since when do my messages go through. (Sorry for spam.) LOL, I just passed your mail through, when you sent it again... You shouldn't have done that, those two I sent using wrong email address :-) But it's too late now I guess. Troman - Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, December 03, 2006 1:54 AM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r513 -/trunk/lib/widget/scrap.c ___ 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] Re: [Warzone-commits] r513 - /trunk/lib/widget/scrap.c
Since when do my messages go through. (Sorry for spam.) - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: Sent: Sunday, December 03, 2006 1:44 AM Subject: [Warzone-dev] Re: [Warzone-commits] r513 - /trunk/lib/widget/scrap.c Giel van Schijndel, this patch seems to be breaking MSVC compilation, I reverted it for now. Troman - Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Wednesday, November 29, 2006 6:57 PM Subject: [Warzone-commits] r513 - /trunk/lib/widget/scrap.c Author: devurandom Date: Wed Nov 29 18:57:58 2006 New Revision: 513 URL: http://svn.gna.org/viewcvs/warzone?rev=513&view=rev Log: Fix clipboard and compile on Windows. (Reported by Giel.) Modified: trunk/lib/widget/scrap.c ___ Warzone-commits mailing list Warzone-commits@gna.org https://mail.gna.org/listinfo/warzone-commits ___ 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] r513 - /trunk/lib/widget/scrap.c
Giel van Schijndel, this patch seems to be breaking MSVC compilation, I reverted it for now. Troman - Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Wednesday, November 29, 2006 6:57 PM Subject: [Warzone-commits] r513 - /trunk/lib/widget/scrap.c Author: devurandom Date: Wed Nov 29 18:57:58 2006 New Revision: 513 URL: http://svn.gna.org/viewcvs/warzone?rev=513&view=rev Log: Fix clipboard and compile on Windows. (Reported by Giel.) Modified: trunk/lib/widget/scrap.c ___ Warzone-commits mailing list Warzone-commits@gna.org https://mail.gna.org/listinfo/warzone-commits ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bug with mission briefings halfway fixed
I think this errors occurs when you give a stop order to more than 50 units. I have disabled the stop callback for now, it is currently unused, will think of an alternative implementation. R533 should fix it. Troman - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Saturday, December 02, 2006 9:03 AM Subject: [Warzone-dev] Bug with mission briefings halfway fixed Hey troman! this is Hikaru-orly - I've been trying to get to you on IRC, but we never seem to be on at the same time; I sleep during the day normally so this isn't helping obviously. That missions briefings bug is still there, but the behavior is massively improved, now when the problem happens it doesn't freeze the game, though I still have to quit the game completely to make it work right again. (I can't move the area I'm looking at around anymore after the bug triggers by putting my mouse at the edge of the screen, though I can with the arrow keys.) The game produces this on console when it happens: error: msgStackPush() - stack full error: msgStackPush: failed to push CALL_DORDER_STOP Please make a reply to at least this email address; I tried subscribing to warzone-dev but never got the verification mail, or anything else... So replying to the list is fine, but I won't see it. Tim McGrath ___ 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] Re: [Warzone-commits] r510 - in /trunk:data/mp/stats/weapons.txt data/stats/weapons.txt src/combat.csrc/order.c src/projectile.c src/stats.c src/statsdef.h
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Sunday, November 26, 2006 6:26 PM Subject: [Warzone-dev] Re: [Warzone-commits] r510 - in /trunk:data/mp/stats/weapons.txt data/stats/weapons.txt src/combat.csrc/order.c src/projectile.c src/stats.c src/statsdef.h Am Sonntag, 26. November 2006 17:30 schrieb Roman: Author: troman Date: Sun Nov 26 17:30:34 2006 New Revision: 510 URL: http://svn.gna.org/viewcvs/warzone?rev=510&view=rev Log: Patch by Watermelon: -adds penetrate flag to weapons.txt (relevant for multiplayer) -increases hit-box radius -adds some fixes to the hit-system Modified: trunk/data/mp/stats/weapons.txt trunk/data/stats/weapons.txt trunk/src/combat.c trunk/src/order.c trunk/src/projectile.c trunk/src/stats.c Ain't it possible to hand psStats->penetrate directly over to scanf? And: The other flags use a "compareYes" function. Why is this not used for penetrate? --Dennis Sorry I don't know about this, I hope Watermelon is reading this. As a long term goal we should consider converting txt files into a more user friendly format, this could also bring more people into modding. Since some lines consist of more than 20 entries of different types having tags or some other value descriptors will be helpfull (especially for files like structures.txt or weapons.txt). Naturally 'xml' comes to my mind. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r488 - in/trunk: lib/framework/ lib/script/ src/
Am Sonntag, 19. November 2006 18:06 schrieb Giel van Schijndel: Troman schreef: > Let me know if 'last_called_script_event' warnings are still there. > I'm not sure what's wrong with 'result' though, maybe i'm just blind > or linker is going berserk. > > Troman The `result' errors are still there. The main difference there that causes these linker errors seems to be the tight integration of `INTERP_VAL result' in these files: src/scriptai.c src/scriptcb.c src/scriptfuncs.c src/scriptobj.c Just look through this diff: http://svn.gna.org/viewcvs/warzone/trunk/src/scriptai.c?rev=488&view=diff&r 1=488&r2=487&p1=trunk/src/scriptai.c&p2=/trunk/src/scriptai.c You'll see that `result' is being used quite heavily to replace numerous variables, it seems however that the linker is trying to assign the exact same memory address to these instances of `result', which is in effect triggering the linker errors. (Or something like it, I believe I've stated before I'm far from an expert on fixing linker errors.) The "result" didn't look static. Which means that it becomes a global symbol, which then clashes with the other global "result" symbols in the other files... Beats me... No magic involved. Just mark that result static and the linker errors will go away. --Dennis PS: You may hit me if I'm wrong. ;) Sure, we'll remember that, but this time you escaped the punishment ;P ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r488 - in /trunk: lib/framework/ lib/script/ src/
Let me know if 'last_called_script_event' warnings are still there. I'm not sure what's wrong with 'result' though, maybe i'm just blind or linker is going berserk. Troman - Original Message - From: "Giel van Schijndel" <[EMAIL PROTECTED]> To: Sent: Friday, November 17, 2006 10:01 PM Subject: [Warzone-dev] Re: [Warzone-commits] r488 - in /trunk: lib/framework/ lib/script/ src/ Roman schreef: Author: troman Date: Thu Nov 16 15:30:29 2006 New Revision: 488 URL: http://svn.gna.org/viewcvs/warzone?rev=488&view=rev Log: Scripting engine overhaul - Part I -compiler and parts of interpreter now use union to store different data types -got rid of a great deal of pointer->integer casts -ASSERT() now outputs last event (or function) called by scripts -implemented float data type support for the scripting engine - basic functionality at the moment Modified: trunk/lib/framework/debug.h trunk/lib/script/event.c trunk/lib/script/event.h trunk/lib/script/interp.c trunk/lib/script/interp.h trunk/lib/script/parse.h trunk/lib/script/script.h trunk/lib/script/script_lexer.l trunk/lib/script/script_parser.y trunk/lib/script/stack.c trunk/lib/script/stack.h trunk/src/scriptai.c trunk/src/scriptcb.c trunk/src/scriptextern.c trunk/src/scriptfuncs.c trunk/src/scriptobj.c trunk/src/scriptvals. I don't want to be annoying or something, but since these changes I'm getting a lot of linker errors. I'm really not good at fixing linker errors (doesn't mean I can't do it, but I can't today, tomorrow and Sunday, so if anyone wants to fix it, this info might help). See attachments for linker errors. Just to inform you: I can compile and link r487 without a problem. -- Giel linker command: g++ -m32 -DVERSION=\"2.0.4\" -DYY_STATIC -I.. -I../.. -IC:\Warzone-DevPkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows -DWIN32 -o warzone2100.exe ai.o aiexperience.o astar.o action.o advvis.o atmos.o bridge.o buildpos.o cdspan.o cheat.o cluster.o cmddroid.o combat.o component.o console.o data.o design.o difficulty.o disp2d.o display.o droid.o e3demo.o edit2d.o edit3d.o effects.o environ.o fpath.o feature.o findpath.o formation.o frontend.o gateway.o gatewayroute.o gatewaysup.o geometry.o group.o hci.o init.o intdisplay.o intimage.o intorder.o intelmap.o keybind.o keymap.o level_lexer.o levels.o lighting.o loop.o map.o mapdisplay.o mapgrid.o mechanics.o message.o miscimd.o move.o multiint.o multimenu.o multiopt.o multisync.o multibot.o multistat.o objmem.o objects.o optimisepath.o order.o player.o powercrypt.o radar.o raycast.o research.o scores.o scriptai.o scriptcb.o scriptextern.o scriptfuncs.o scriptobj.o scripttabs.o scriptvals.o scriptvals_parser.o scriptvals_lexer.o selection.o stats.o text.o texture.o transporter.o visibility.o warcam.o wrappers.o ani.o arrow.o aud.o audio_id.o bucket3d.o clparse.o configuration.o csnap.o display3d.o drive.o function.o game.o ingameop.o keyedit.o loadsave.o main.o mission.o multigifts.o multijoin.o multilimit.o multiplay.o multistruct.o oprint.o power.o projectile.o seqdisp.o structure.o target.o warzoneconfig.o ../win32/warzone2100.o ../lib/libframework.a ../lib/libgamelib.a ../lib/libivis_common.a ../lib/libivis_opengl.a ../lib/libnetplay.a ../lib/libscript.a ../lib/libsequence.a ../lib/libsound.a ../lib/libwidget.a -LC:\Warzone-DevPkg/lib -lmingw32 -lglu32 -lopengl32 -lopenal32 -ljpeg6b -lpng13 -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net stderr: scriptai.o(.bss+0x0): In function `Z16scrGroupAddDroidv': C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/scriptai.c:35: multiple definition of `last_called_script_event' droid.o(.bss+0x0):C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/droid.c:134: first defined here scriptcb.o(.bss+0x0): In function `Z15scrCBDroidTakenv': C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/scriptcb.c:55: multiple definition of `last_called_script_event' droid.o(.bss+0x0):C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/droid.c:134: first defined here scriptcb.o(.bss+0x64): In function `Z15scrCBDroidTakenv': C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/scriptcb.c:75: multiple definition of `result' scriptai.o(.bss+0x64):C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/scriptai.c:44: first defined here scriptextern.o(.bss+0x0): In function `Z14scrExternResetv': C:/Documents and Settings/Giel van Schijndel/Mijn documenten/C++/warzone/src/scriptextern.c:48: multiple definition of `last_called_script_event' droid.o(.bss+0x0):
Re: [Warzone-dev] Re: [Warzone-commits] r488 - in /trunk: lib/framework/ lib/script/ src/
I don't want to be annoying or something, but since these changes I'm getting a lot of linker errors. I'm really not good at fixing linker errors (doesn't mean I can't do it, but I can't today, tomorrow and Sunday, so if anyone wants to fix it, this info might help). See attachments for linker errors. Just to inform you: I can compile and link r487 without a problem. -- Giel Wasn't a good idea to define "last_called_script_event" in debug.h. Thanks for pointing it out. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r489 - in /trunk: lib/framework/debug.c lib/script/codeprint.c lib/script/codeprint.h lib/script/interp.c lib/script/interp.h src/droid.c src/droiddef.h
- Original Message - From: "Roman" <[EMAIL PROTECTED]> To: Sent: Friday, November 17, 2006 12:25 PM Subject: [Warzone-commits] r489 - in /trunk: lib/framework/debug.c lib/script/codeprint.c >lib/script/codeprint.h lib/script/interp.c lib/script/interp.h src/droid.c src/droiddef.h Author: troman Date: Fri Nov 17 12:25:03 2006 New Revision: 489 URL: http://svn.gna.org/viewcvs/warzone?rev=489&view=rev Log: -fixed 'cpPrintProgram' -fixed some spelling mistakes -minor cleanups Modified: trunk/lib/framework/debug.c trunk/lib/script/codeprint.c trunk/lib/script/codeprint.h trunk/lib/script/interp.c trunk/lib/script/interp.h trunk/src/droid.c trunk/src/droiddef.h Hopefully I nailed all of them. Troman PS: my last email sent using the wrong email address awaits moderator approval, please disregard it, whoever is in charge of approving it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] r488 - in/trunk:lib/framework/ lib/script/ src/
- Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Development list" Sent: Thursday, November 16, 2006 9:13 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r488 - in/trunk:lib/framework/ lib/script/ src/ >Am Donnerstag, 16. November 2006 15:30 schrieb Roman: Author: troman Date: Thu Nov 16 15:30:29 2006 New Revision: 488 URL: http://svn.gna.org/viewcvs/warzone?rev=488&view=rev Log: Scripting engine overhaul - Part I -compiler and parts of interpreter now use union to store different data types -got rid of a great deal of pointer->integer casts -ASSERT() now outputs last event (or function) called by scripts -implemented float data type support for the scripting engine - basic functionality at the moment 1st: I get compilation errors: [67/209] * cc : ../lib/script/codeprint.c -> debug/lib/script/codeprint.o In file included from ../lib/script/codeprint.c:7: ../lib/framework/frame.h:99: warning: unused parameter ‘uword’ ../lib/framework/frame.h:110: warning: unused parameter ‘sword’ ../lib/framework/frame.h:121: warning: unused parameter ‘udword’ ../lib/framework/frame.h:135: warning: unused parameter ‘sdword’ ../lib/framework/frame.h:149: warning: unused parameter ‘fract’ ../lib/script/codeprint.c: In function ‘cpPrintProgram’: ../lib/script/codeprint.c:415: warning: assignment from incompatible pointer type ../lib/script/codeprint.c:425: error: invalid operands to binary - ../lib/script/codeprint.c:435: error: invalid operands to binary - ../lib/script/codeprint.c:457: warning: zero-length printf format string ../lib/script/codeprint.c:462: error: invalid operands to binary - ../lib/script/codeprint.c:469: warning: zero-length printf format string ../lib/script/codeprint.c:476: error: invalid operands to binary - ../lib/script/codeprint.c:483: warning: zero-length printf format string ../lib/script/codeprint.c:488: error: invalid operands to binary - ../lib/script/codeprint.c:538: error: invalid operands to binary - ../lib/script/codeprint.c:542: error: invalid operands to binary - ../lib/script/codeprint.c:546: error: invalid operands to binary - Compilation failed 2nd: Could you better spell out the namings? I know this is not your fault in this particular case, but I had no clue what .v.bval shall be (eg). Maybe .Value.Bool or similar would have been better... (Or .value._bool or whatever.) Generally I think we all should keep an eye on the namings of our stuff. It might me less to type, but it makes the code much harder to read if we only use s, v, a, b and other very descriptive namings. --Dennis 1st .Old artifacts conflicting with latest changes. There can be more of those (i'm not done yet) they are hard to detect, as MSVC doesn't report them. 2nd Ok, next time I'll see any of the Pumpkin guys i'll tell them to be more carefull when choosing names. ;-) But seriously I don't know what's the problem with bval, seems to be self-explanatory to me, when really unsure you can look at the declaration: BOOL bval; // VAL_BOOL I'll add a comment to the declaration of oval (Object value) or something. Troman BTW I will take care of this tomorrow, simply don't have time right now. If cpPrintProgram() is the only function that is causing problems you can comment it out for now without feeling any guilt, it's not relevant for any game functionality. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r488 - in /trunk:lib/framework/ lib/script/ src/
Am Donnerstag, 16. November 2006 15:30 schrieb Roman: Author: troman Date: Thu Nov 16 15:30:29 2006 New Revision: 488 URL: http://svn.gna.org/viewcvs/warzone?rev=488&view=rev Log: Scripting engine overhaul - Part I -compiler and parts of interpreter now use union to store different data types -got rid of a great deal of pointer->integer casts -ASSERT() now outputs last event (or function) called by scripts -implemented float data type support for the scripting engine - basic functionality at the moment 1st: I get compilation errors: [67/209] * cc : ../lib/script/codeprint.c -> debug/lib/script/codeprint.o In file included from ../lib/script/codeprint.c:7: ../lib/framework/frame.h:99: warning: unused parameter ‘uword’ ../lib/framework/frame.h:110: warning: unused parameter ‘sword’ ../lib/framework/frame.h:121: warning: unused parameter ‘udword’ ../lib/framework/frame.h:135: warning: unused parameter ‘sdword’ ../lib/framework/frame.h:149: warning: unused parameter ‘fract’ ../lib/script/codeprint.c: In function ‘cpPrintProgram’: ../lib/script/codeprint.c:415: warning: assignment from incompatible pointer type ../lib/script/codeprint.c:425: error: invalid operands to binary - ../lib/script/codeprint.c:435: error: invalid operands to binary - ../lib/script/codeprint.c:457: warning: zero-length printf format string ../lib/script/codeprint.c:462: error: invalid operands to binary - ../lib/script/codeprint.c:469: warning: zero-length printf format string ../lib/script/codeprint.c:476: error: invalid operands to binary - ../lib/script/codeprint.c:483: warning: zero-length printf format string ../lib/script/codeprint.c:488: error: invalid operands to binary - ../lib/script/codeprint.c:538: error: invalid operands to binary - ../lib/script/codeprint.c:542: error: invalid operands to binary - ../lib/script/codeprint.c:546: error: invalid operands to binary - Compilation failed 2nd: Could you better spell out the namings? I know this is not your fault in this particular case, but I had no clue what .v.bval shall be (eg). Maybe .Value.Bool or similar would have been better... (Or .value._bool or whatever.) Generally I think we all should keep an eye on the namings of our stuff. It might me less to type, but it makes the code much harder to read if we only use s, v, a, b and other very descriptive namings. --Dennis 1st .Old artifacts conflicting with latest changes. There can be more of those (i'm not done yet) they are hard to detect, as MSVC doesn't report them. 2nd Ok, next time I'll see any of the Pumpkin guys i'll tell them to be more carefull when choosing names. ;-) But seriously I don't know what's the problem with bval, seems to be self-explanatory to me, when really unsure you can look at the declaration: BOOL bval; // VAL_BOOL I'll add a comment to the declaration of oval (Object value) or something. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] BOOL used to store pointers?
It seems like setBackgroundFog is causing trouble. There was one call before it, but I didn't print the name of it. :( I can't see anything suspicious, but if anything, I'd say it's stackPopParams() that is causing problems. Maybe you can take a closer look at it. Most interesting place is *((SDWORD*)pData) = psVal->v.ival; which assigns psVal->v.ival to a bool pointer passed by scrSetBackgroundFog(). Maybe alignment problems? Troman - Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Tuesday, November 07, 2006 10:19 PM Subject: Re: [Warzone-dev] BOOL used to store pointers? ___ 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] BOOL used to store pointers?
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Tuesday, November 07, 2006 6:58 PM Subject: Re: [Warzone-dev] BOOL used to store pointers? Am Dienstag, 7. November 2006 18:06 schrieb Per Inge Mathisen: On 11/7/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: > The interesting thing is _why_ does it break with BOOL not being int? > Means: _Who_ is relying on BOOL, which logically could be 1bit, to >be > 32bit long? Why does this make WZ segfault? ... Could be due to loading a binary file in which bool is assumed to be of 32 bit width? Then the rest of the data will come out garbled. Would be sensible... Does the scripting engine use binary files somewhere? I thought they were compiled on every run... --Dennis No, binary files are not used, unless you load a savegame. I'm currently looking at it. Currently having some connection problems, hopefully will be able to access internet in the next days. I traced a path of an in-script boolean value, here's what we have: Whenever Bison encounters a boolean/integer value in the script it casts it to UDWORD and stores with PUT_DATA: #define PUT_DATA(ip, data) \ *ip = (UDWORD)(data); \ ip += 1 Later on this bool seems to be converted to SDWORD with: sVal.v.ival = (SDWORD)(*(ip+1)); in interpRunScript() before pushing values to the stack. ival is an SDWORD member of a union which is used to store different data types that occur in the script. Pumpkin uses standard approach for scripting languages here as union is a good way of storing different data types for scripts. I don't see how this could cause a crash, so the problem is probably somewhere else. Do we know where exactly the crash occurs? What script opcode causes it? And do we have any reasons to assume bool values store pointers somewhere? Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch by Watermelon: bug fixes
Forwarding another patch by Watermelon (looks like this patch includes previous one): Watermelon: 1.predictX,predictY offsets were swapped by mistake,they should be fixed now.2.Fixed a crash when ordering truck to 'repair' a full-health command center 3.Made proj_SendProjectile to accept another BOOLEAN value 'bPenetrate',when set to TRUE it will create a new projectile upon impact and the newly created projectile will try to reach the destination of the impact'ed projectile.(FLAME,ELECTRONIC,GAUSS weapons projectile can penetrate several enemy units) Troman bug fixes.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch by Watermelon: projectile patch
I'll just quote Watermelon: "1.Fixed a bug has something to do with AA weapon hitting ground unit(didnt check vector z for AA weapons)2.Tweaked the target prediction for AA weapon,they now use both zDiff and dist to calculate predicted x,y offsets,they should be better at hitting VOTLs now." Troman projectile patch.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch readmes from Watermelon
Acting as a 'medium' between Mailinglist and Watermelon, since he seems to have problems with email acoounts. Filenames are self-explainatory. Troman New hit/projectile Readme: Purposes: 1.Change the sure strike/sure miss projectile to 'real' ones 2.Added a 'collision' for projectiles 3.Target Prediction Changes: 1. Projectiles changes:(files affected:projectiles.c projectiles.h) 1.1 Added global projNaybor list array. 1.2 Added global #define(s) for projNaybor, 1/2 range of droid to reduce unnecessary naybor checks. 1.3 Added functions projGetNaybors function(merely a clone of droidGetNaybors from droid.c) to get a naybor list. 1.4 Changed proj_InFlightDirectFunc,proj_InFlightIndirectFunc to check all naybors for possible impact Extended projectile 'lifespan' for different types of weapons:(to ensure a projectile is not simply disappeared after it misses the intended target like old system) MGs 1.2x Cannon 1.5x Missile 1.5x 1.4.1 Added a hit radius bonus to all weapons except LAS_SAT to compensate the inability of hitting moving targets(or maybe the hit radius of units are too small) They are applied to TARGET_RADIUS check not WEAPON_RADIUS/SPLASH Mgs 2 = sqrt(2) times Cannon 3 = sqrt(3) times Missile 4 = 2 times AAGun 16 = 4 times 1.4.2 A missed projectile never deals damage in old hit system,now a projectile which missed its intended target can still deal damage to other objects that collide with it.(Artillery should be more powerful now) 1.4.3 Get rid of the 'sure strike' stuff in wz. Now theoretically your units can 'dodge' any non-homing projectiles with proper micro,unlike another 'mainstream' RTS games. 1.5 Changed establishTargetRadius function to droid type,body size based. Smaller units are a bit more hard to hit now while big units are easier to hit now DROID typebodysizehitRadius LIGHT DROID_WEAPONLIGHT TILES/8 = 16 MEDIUM DROID_WEAPONMEDIUM TILES/8 + body_size * 16 = 32 HEAVY DROID_WEAPONHEAVY TILES/8 + body_size * 16 = 48 S.HEAVY DROID_WEAPONS.HEAVY TILES/8 + body_size * 16 = 64 CYBORG DROID_CYBORGN/A TILES/8 = 16 2.Combat Game Mechanics changes(files affected:combat.c) 2.1: Changed missed random offset to accuracy based from distance based(more accurate when 'miss' with weapon with high acc) 2.2: Target Prediction Simple Target Prediction to increase the accuracy of 'hit' shots. predictX = cos([target move direction]) * [target velocity] * [actual distance] / [weapon velocity]; predictY = sin([target move direction]) * [target velocity] * [actual distance] / [weapon velocity];Multi-Turret Readme: Purpose: Add multiple turret support. Changes: 1 DROID,DROID_TEMPLATE struct changes(files affected:droid.c droiddef.h) 1.1 Changed TurretRotation,TurretPitch variable in those structures to array: TurretRotation[DROID_MAXWEAPS],TurretPitch[DROID_MAXWEAPS] respectively global #define DROID_MAXWEAPS changed from 1 to 3 2 Action related functions changes(files affected:action.c ai.c action.h) 2.1 Changed ActionAlignTurret to align all turrets instead of the one in asWeaps[0] 2.2 Changed ActionUpdateDroid to update all weapons info instead of the one in asWeaps[0] 2.1 Changed ActionInRange,ActionInMine,ActionVisibleTarget to int from BOOL now it returns a bitfield containing the weaponInRange info result 1 = no weapon in range/reserved 3 = (1 + (1 << (weaponslot + 1))) = first slot is available etc etc 3 Design interface changes(files affected:design.c) 3.1 Added 2 buttons for 2nd,3rd weapon(can add as many as DROID_MAXWEAPS but there was no room for the 4th 5th buttons etc) 3.2 Number of turrets is based on BODY size currently: 1 for SIZE_LIGHT 2 for SIZE_MEIDUM 3 for SIZE_HEAVY and SIZE_SUPERHEAVY 3.3 Changed validCheck a bit to accept multiple asWeaps and made it loop through all weapons to match the weapon nStat(id) 3.4 VTOL untouched because its attackRun will be screwed up if I add more weapons to them 4 Game load/save changes(files affected:game.c) 4.1 Added a game save version V99 to store/convert from old saves to new format because of TurretRotation/TurretPitch array change Old save should be compatible with this change,but you cannot use converted save games with old version of wz anymore. 5 Render/Display component changes(files affected:display.c component.c component.h) 5.1 Added the ability to set matrix/loop through all weapons to render them on a single droid in displayComponentObj. 5.2 Added the ability to use con
Re: [Warzone-dev] and the missing patch - nt
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, November 05, 2006 9:00 PM Subject: Re: [Warzone-dev] and the missing patch - nt Am Sonntag, 5. November 2006 19:25 schrieb Troman: n/t Are these patches allready applied? Yes, r460 and r461. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] and the missing patch - nt
n/t hit-system main.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] New hit-system with target prediction - patch by Watermelon
"New hit-system" with target prediction - patch by Watermelon, as discussed ín the forum: http://wz2100.net/forum/index.php?topic=141.0 Watermelon will provide readme's for his patches soon. Now it is probably time to lick the wounds. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets
- Original Message - From: "Linas Žvirblis" <[EMAIL PROTECTED]> To: Sent: Sunday, November 05, 2006 6:21 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis Schridde wrote: I guess the question was if it makes any sense for the player. Does he have any benefit from not building 3 turret droids... The biggest "benefit" of NOT having 3-turret (or even 2-turret) droids is that players would end up building single type units. Just put long range weapon, short range weapon, and repair turret on the same body, make 20 of them, and there you have it - an invincible army of droids that repair each other while blasting everything else. Repair towers can not be combined with weapons as I see. I think it should be impossible to combine arty (indirect weapon) with mgs and alike (direct weapons) as well. A solution I can imagine is introducing another extra heavy (and extra expensive, and extra slow) body that could mount, let us say, two turrets. This was also my suggestion, but I don't think we should make multiple-turret support something very special, it was just not finished in the game, hence I don't see a need to only allow multiple-turret support in the late game. This was discussed on forums already, my idea was to introduce new set of bodies (probably 3 - each one for eact tech level), which would be large enough to handle multiple weapons. T1 body - 1-2 weapons T2 body - 2-3 T3 - could be something huge, similar to stationary fortresses we have now, defitely not for mass-production. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, November 05, 2006 6:28 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets On 11/5/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >>Is there a > >> reason for the player not to add as many weapons as possible? > > You mean unrestricted number of weapon on a body or max weapon number > for > each body? I guess the question was if it makes any sense for the player. Does he have any benefit from not building 3 turret droids... Exactly. I take it the weight is increased? An idea could be longer reload times for multiple weapons. The point is that it should, IMHO, still make sense for players to build single-weapon big-body droids, if they want whatever advantage that gives instead of multiple weapons. It should definitely make sense to do so. One point is weight, yes (and speed as a result). Second one is power - each droid component requires power. I don't know if longer reload times really makes sense for multiple weapons though. We could increase weapon cost compared to the cost of other components if current weapon cost is too low to be a counterweight for the additional firepower. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Multi-Turret: Patch by Watermelon: commander crash fix
This one fixes commander-related crash. Troman commander fix.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, November 05, 2006 12:22 PM Subject: Re: [Warzone-dev] Re: [Warzone-commits] r453 - multiple turrets Am Sonntag, 5. November 2006 12:10 schrieb Per Inge Mathisen: On 11/4/06, Roman <[EMAIL PROTECTED]> wrote: > Patch by Watermelon: Droid Multi-Turret Support I had to try this one out, and it is quite funny. It makes building big droids much more interesting. However, there is no documentation of how this works. I had to cheat all techs to see it by trial and error. Does it require a specific tech? It looks like it is either one turret or three, and none with limit of two? I had that problem, too. I think it is enough if you reasearch a heavy body (Python?). HP bar disappears when all guns are firing. Some of the vehicles look a bit too funny, and the droid names are not quite right. I got some crashes, but they might be unrelated. Has this been discussed somewhere? What about game balance? This will probably take some time to tweak, we need to specify more limits for this, ie what turret classes can be mixed together (AA/direct/arty/commander/repair/sensor etc), what bodies can have more than 1 weapon - I think letting light bodies have more than 1 weapon doesn't really make sense (size issue) or at least limit secondary weapon to T1 weapons as most T2/T3 weapons would overlap in the game. Is there a reason for the player not to add as many weapons as possible? You mean unrestricted number of weapon on a body or max weapon number for each body? I think this is not a good idea in any case, as there's actually only one body - Dragon - that doesn't look funny with any weapon combination. Other ones are simply way too tiny. Won't this mean that rock-paper-scissors disappears for large vehicles, as they can attack anything really well? Yes game balance is very probably down the drain... :( We need to fix/limit this for 2.1... Especially the multiple different turrets caused me a headache, too. Discussion took place in the forums: http://wz2100.net/forum/index.php?topic=115.0 --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] More patches for warnings
- Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, November 03, 2006 10:16 PM Subject: Re: [Warzone-dev] More patches for warnings - Original Message - From: "Gerard Krol" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, November 03, 2006 12:21 PM Subject: Re: [Warzone-dev] More patches for warnings [...] The alternative is that I add casts to all MALLOC's that not yet have them, this would fix a lot of warnings too. - Gerard Maybe this is a better alternative to using NEW as an additional marco? Whether to get rid of MALLOC in favor or malloc or something else is another question, although judging from what Per said it will probably take a bit more effort to do this. Anyway, delaying the commit until we clarify this. Troman As a result of a small IRC discussion with Devurandom I guess we are putting this on hold for now. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Watermelon's Multi-Turret patch
Attached is Watermelon's multi-turret patch, since he is not using mailinglist, I think it is a good idea to post it here as well. Haven't looked it at yet. Troman multi-turret.rar Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] More patches for warnings
- Original Message - From: "Gerard Krol" <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, November 03, 2006 12:21 PM Subject: Re: [Warzone-dev] More patches for warnings [...] The alternative is that I add casts to all MALLOC's that not yet have them, this would fix a lot of warnings too. - Gerard Maybe this is a better alternative to using NEW as an additional marco? Whether to get rid of MALLOC in favor or malloc or something else is another question, although judging from what Per said it will probably take a bit more effort to do this. Anyway, delaying the commit until we clarify this. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] More patches for warnings
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Wednesday, November 01, 2006 11:50 PM Subject: Re: [Warzone-dev] More patches for warnings ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev Am Mittwoch, 1. November 2006 23:03 schrieb Gerard Krol: Hi, This evenings work ;) new.patch contains the addition of two macro's, and the use of them to replace MALLOC MALLOC itself is a macro around some custom wrapper around malloc... So perhaps we should also check if we (additionally to using this NEW wrapper) could drop that MALLOC malloc wrapper... (I don't really know what exact functionality MALLOC and FREE provide, besides that FREE checks for NULL pointers, what is useless as free() is defined by the C std to do nothing in that case.) --Dennis PS: Idea seems good, didn't look at the patch. It is a cleaner approach, but for me it is more intuitively to use MALLOC since already the name implies that malloc functionality will be used at some point. And these 2 new macros will not replace all occurances of MALLOC, so we are just introducing more macros for the same functionality. But anyway, I will be an impartial executor of a collective opinion. To make it painless for everyone if no objections will be raised until tomorrow evening I will just go on and apply the patch. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patches for removing some warnings
And if I understand the original intention correctly return((PICKTILE)TRUE); should probably be chnaged to: return HALF_FREE_TILE; If you think this is correct, it doesn't crash and HALF_FREE_TILE is of the same value as TRUE, then I see no problems. --Dennis Not the same value, but HALF_FREE_TILE should still be correct since they want to place two droids on the same tile and the tile under consideration is already occupied (oneDroid == true), it looks like some confusion among Pumpkin developers. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patches for removing some warnings
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Wednesday, November 01, 2006 1:00 PM Subject: Re: [Warzone-dev] Patches for removing some warnings Am Mittwoch, 1. November 2006 12:27 schrieb Gerard Krol: Hi all, Attached are 2 sets of changes to remove some warnings. Those in warnings_casts.patch cast variables back to what they were before the binary operations, for example: -sVal.type = (*InstrPointer) & OPCODE_DATAMASK; +sVal.type = (INTERP_TYPE)((*InstrPointer) & OPCODE_DATAMASK); I think this is quite harmless. warnings_changes.patch changes the types of some variables and adds calls to keyCodeToSDLKey in some assert statements. A quick look-through told me that this looks good. (Especially the explanation helped a lot! Makes a difference if one is just blindly trying to silence the compiler or if he has good reasons to cast in specific places.) Will look at it further and test it later, probably on the WE. --Dennis Devurandom, since these patches are compatible with TSVN, I can do it if that's ok with you. All patches seem to be ok, although i'm not sure if we really need keyCodeToSDLKey() or if just casting will suffice. I don't know if keyCodeToSDLKey() might do more in the future than just casting. And if I understand the original intention correctly return((PICKTILE)TRUE); should probably be chnaged to: return HALF_FREE_TILE; though. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Unit AI improvement
- Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: "Development list" Sent: Saturday, October 14, 2006 1:10 AM Subject: Re: [Warzone-dev] Unit AI improvement There's one flaw though: "first come, first serve" so to speak: if a tanks comes into the sensor range of a bunker buster unit it locks on it and won't target any bunkers if they will come into sensor range afterwards, but I think this is something we can live with. Does that mean, that, if I fly with a BB VTOL to the E base and the E has prepared tanks in front of his bunker lines, my BB VTOLs will attack the tanks? Perhaps this system can be improved in the long term. (I don't expect anyone to submit patches soon.) Yes, this is exactly the case. It is not a drawback from the newly commited changes, btw, this is how it always used to be. I have 2 possible solutions: 1) Recalculate all targets every n-th frame. - CPU-intensive and not very effective but would surely work. 2) Use the 'object seen' callback: everytime an enemy unit comes into radar range recalculate the best target (to save cpu time we can only compare the current and the new target against each other). - this is much more CPU-friendly. While it's not perfect it seems to be the best possible solution so far. 3) Introduce a distance/priority threshhold to prevent units from attacking low priority targets that are far away. If BB's max weapon range is 8, it will not attack targets with priority under 100 (will have to be tanks in this case) when this target is not closer than, say 7 tiles. This will let more enemy units come into weapon range thus maximizing the number of possible targets. -CPU friendly, but it will not be a cakewalk to find such a threshold, since the target selection routine does not really use 'absolute' values. Would lower weapon range, but since this is only for targets this unit is very uniffective against, I suppose this is not really vital. --Dennis ___ 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] Unit AI improvement
- Original Message - From: <[EMAIL PROTECTED]> To: "Development list" Sent: Friday, October 13, 2006 8:17 PM Subject: Re: [Warzone-dev] Unit AI improvement On Fri, 13 Oct 2006 06:56:01 -0400 Troman <[EMAIL PROTECTED]> wrote: I have just commited some improvements to the droid target selection routines (looks like we have some non-license issues on the mailinglist for a change today). The original idea was to prevent bunker buster droids from aiming tanks when there's a bunker near it (BB weapons have 5x bonus against bunkers, 4x against HPs), which was just a complete waste of units. This is especially relevant for AI as it doesn't use unit micro-management. I don't expect it to be flawless right away, but i'm satisfied with the result. In every tested situation unit AI seems to be more intellegent now when picking targets. Machineguns/lasers go after cyborgs, lancers/tank killers after tanks, bunker busters after bunkers and hardpoints. Damaged enemy units are targeted more willingly. I also made trucks/repair units/repair facilities preffered targets, since up till now you could simply put a repair unit behind your tank lines and repair your units while they are being attacked by AI, now it will be harder to pull off. Same with trucks repairing defenses. There's one flaw though: "first come, first serve" so to speak: if a tanks comes into the sensor range of a bunker buster unit it locks on it and won't target any bunkers if they will come into sensor range afterwards, but I think this is something we can live with. This modification affects both multiplayer and campaign modes, as I see it as improvement/tribute to faster CPUs, not as gameplay change. Comments/objections? Troman Sounds good to me. I wonder if it would be better to have this behavior on a 'hard' AI setting, and leave the original alone for 'easy' ? Or do as you suggested on IRC, and have a pick AI for the skirmish games? I noticed lots of people asking for cheat codes/how to enable, so I assume the original code/script is too tough for them, and this would be too much, pushing them over the edge, crying to their mom. ;) This is not something to worry about, I don't expect it to make AI unbeatable, already the fact that these changes apply to both AI and human-controlled units makes the effects neglectable. As I see it people are usually asking for cheat codes simply because they exist, to have some fun, less often due to unbalanced time constrains or due to bugs which prevent them to end a mission. When people will start asking to make AI easier this will be our triumph, but so far it seems we are far away from that. Do you have any documentation about how the AI scripting works? No, we don't have any documentations on the scripting engine, but there is "scriptlang.rtf" that documents scripting functions/callbacks etc, although it is a bit out of date. The original AI was made to be fast to run on a PS2, and since most everyone has at least a 1.5GHz CPU, we may be able to really improve the AI, but since their is hardly any docs for it, that may take some time. Is there (will there be?) a 'minimum' specs for this game? We know you need a video card that has openGL support, but what about texture memory and all that? I am guessing it all fits into 8 or16MB RAM (1 texture map per level?) ? There are terrain textures, unit/effects textures plus menu textures that are loaded at a time, but I'm really clueless whether they all fit into 16 mb ram. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ 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] Unit AI improvement
I have just commited some improvements to the droid target selection routines (looks like we have some non-license issues on the mailinglist for a change today). The original idea was to prevent bunker buster droids from aiming tanks when there's a bunker near it (BB weapons have 5x bonus against bunkers, 4x against HPs), which was just a complete waste of units. This is especially relevant for AI as it doesn't use unit micro-management. I don't expect it to be flawless right away, but i'm satisfied with the result. In every tested situation unit AI seems to be more intellegent now when picking targets. Machineguns/lasers go after cyborgs, lancers/tank killers after tanks, bunker busters after bunkers and hardpoints. Damaged enemy units are targeted more willingly. I also made trucks/repair units/repair facilities preffered targets, since up till now you could simply put a repair unit behind your tank lines and repair your units while they are being attacked by AI, now it will be harder to pull off. Same with trucks repairing defenses. There's one flaw though: "first come, first serve" so to speak: if a tanks comes into the sensor range of a bunker buster unit it locks on it and won't target any bunkers if they will come into sensor range afterwards, but I think this is something we can live with. This modification affects both multiplayer and campaign modes, as I see it as improvement/tribute to faster CPUs, not as gameplay change. Comments/objections? Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r422 - in /trunk:data/multiplay/skirmish/ lib/framework/ lib/script/ src/
Why did you change getPlayerColour to getPlayerColor, but left setPlayerColour? A bit inconsistent. Anyway, I'd prefer to keep the British English (to honour Pumpkin's legacy, so to speak). Pumpkin shall be honoured. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fix for r418
Devurandom, I think you forgot to commit updated MSVC project files. Troman - Original Message - From: "Dennis Schridde" <[EMAIL PROTECTED]> To: Sent: Sunday, October 08, 2006 1:53 AM Subject: Re: [Warzone-dev] Fix for r418 ___ 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
