Re: [Warzone-dev] Coding style
- Original Message - From: Per Inge Mathisen [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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 warzone-dev@gna.org Sent: Wednesday, February 14, 2007 4:37 AM Subject: Re: [Warzone-dev] Current problems I didn't make this particular change. I did, however, get savegame saving and loading to work on the Mac again. I will try the non-Mac savegame in a bit. Here is a list of my notes as I went through (line numbers may be a little off since I have made changes): evntsave.c:378 Why is numContext signed? evntsave.c:398 Why is savedNumVars signed? evntsave.c:361 Why is numVars signed? evntsave.c:361 Why is numVars double-word while savedNumVars is single-word? evntsave.c:417 Why do we use a SDWORD to loop a SWORD? evntsave.c:455 Should ival be SDWORD or is UDWORD enough? evntsave.c:497 UDWORD variable stored as UWORD scriptobj.c:1127Why do we store a UBYTE as an SDWORD? No clue. More importantly, I came across something that would be a showstopper if it were being saved by the game. In evntsave.c the SCRIPT_VARFUNC and SCRIPT_FUNC types (indicated by VAL_OBJ_GETSET and VAL_FUNC_EXTERN) are pointers, and those pointers are being saved directly into the savegame file on disk. This is very very bad. We need to come up with a better way to save these. I'm not sure what to do with SCRIPT_VARFUNC. Maybe we should just hardcode it in the interpreter, since there's only one SCRIPT_VARFUNC function anyway, at least I can't think of an elegant solution. Another odd one is the way VAL_STRING gets stored. Two conflicting assumptions are at play. Basically, the string's char* value is set to the position in the file, as if the string were stored verbatim in the file, but then the position pointer is updated by sizeof(char*), as if there had been a char* pointer in the file. I think that an appropriate solution would involve storing the size of the string as a UWORD or UDWORD and then the string's characters after that. Sounds good to me. There is already a TODO about strings in eventSaveContext, which I am changing to a more complete FIXME. I am committing my changes, with the FIXMEs described above. Please comment on the list of items I mentioned if you have any thoughts on them. Thanks to Troman for helping out with most of the endianization. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 5:49 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 4:37 AM Subject: Re: [Warzone-dev] Current problems I didn't make this particular change. I did, however, get savegame saving and loading to work on the Mac again. I will try the non-Mac savegame in a bit. Here is a list of my notes as I went through (line numbers may be a little off since I have made changes): evntsave.c:378 Why is numContext signed? evntsave.c:398 Why is savedNumVars signed? evntsave.c:361 Why is numVars signed? evntsave.c:361 Why is numVars double-word while savedNumVars is single-word? evntsave.c:417 Why do we use a SDWORD to loop a SWORD? evntsave.c:455 Should ival be SDWORD or is UDWORD enough? evntsave.c:497 UDWORD variable stored as UWORD scriptobj.c:1127Why do we store a UBYTE as an SDWORD? No clue. More importantly, I came across something that would be a showstopper if it were being saved by the game. In evntsave.c the SCRIPT_VARFUNC and SCRIPT_FUNC types (indicated by VAL_OBJ_GETSET and VAL_FUNC_EXTERN) are pointers, and those pointers are being saved directly into the savegame file on disk. This is very very bad. We need to come up with a better way to save these. I'm not sure what to do with SCRIPT_VARFUNC. Maybe we should just hardcode it in the interpreter, since there's only one SCRIPT_VARFUNC function anyway, at least I can't think of an elegant solution. One thing we can do is have a table and store an integer that indexes into it. Another odd one is the way VAL_STRING gets stored. Two conflicting assumptions are at play. Basically, the string's char* value is set to the position in the file, as if the string were stored verbatim in the file, but then the position pointer is updated by sizeof(char*), as if there had been a char* pointer in the file. I think that an appropriate solution would involve storing the size of the string as a UWORD or UDWORD and then the string's characters after that. Sounds good to me. The question is how the strings are stored - do we malloc up space for them when we read in the file? When save games are loaded? I think loaded strings should be just copied into the space allocated for string variables (union's .sval pointer). I can look into this sometime if nobody else knows. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r749 - in /trunk:lib/script/interp.c lib/script/interp.h src/scriptfuncs.csrc/scriptfuncs.h src/scriptobj.c src/scripttabs.c
Am Mittwoch, 14. Februar 2007 schrieb Christian Ohm: On Wednesday, 14 February 2007 at 18:29, Roman wrote: - removed some ASSERSs doubling debug() error output ASSERT quits (in debug mode) and debug LOG_ERROR doesn't. Was that intentional? Yes, Troman explained it to me in IRC: The code uses gotos to jump to the callstack part, where it will assert. If it would assert before, it would never output the callstack. --Dennis Looks like Devurandom was faster than me. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 10:18 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: The question is how the strings are stored - do we malloc up space for them when we read in the file? When save games are loaded? I think loaded strings should be just copied into the space allocated for string variables (union's .sval pointer). That won't work, if I am reading you correctly. The .sval pointer is just that: a pointer. You need to point it to some memory to store the actual contents of the string. The way to solve this is to find out where .sval pointers come from in the normal running of the game. Are they malloc()ed and later free()d, are they stored in a central store with garbage collection for the scripting engine, or are they stored in static buffers somewhere? Once we know this, we can go forward with fixing how they are stored in evntsave.c. What I wanted to say is that at that point .sval already points to a valid memory address, so it should be safe to copy the string. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 10:43 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 10:18 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: The question is how the strings are stored - do we malloc up space for them when we read in the file? When save games are loaded? I think loaded strings should be just copied into the space allocated for string variables (union's .sval pointer). That won't work, if I am reading you correctly. The .sval pointer is just that: a pointer. You need to point it to some memory to store the actual contents of the string. The way to solve this is to find out where .sval pointers come from in the normal running of the game. Are they malloc()ed and later free()d, are they stored in a central store with garbage collection for the scripting engine, or are they stored in static buffers somewhere? Once we know this, we can go forward with fixing how they are stored in evntsave.c. What I wanted to say is that at that point .sval already points to a valid memory address, so it should be safe to copy the string. I don't believe that it is. If you read eventLoadContextHashed, up through line 485, where does sval get initialized? In eventNewContext(), line 415. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 11:20 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 10:43 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, February 14, 2007 10:18 PM Subject: Re: [Warzone-dev] Current problems On 2/14/07, Troman [EMAIL PROTECTED] wrote: The question is how the strings are stored - do we malloc up space for them when we read in the file? When save games are loaded? I think loaded strings should be just copied into the space allocated for string variables (union's .sval pointer). That won't work, if I am reading you correctly. The .sval pointer is just that: a pointer. You need to point it to some memory to store the actual contents of the string. The way to solve this is to find out where .sval pointers come from in the normal running of the game. Are they malloc()ed and later free()d, are they stored in a central store with garbage collection for the scripting engine, or are they stored in static buffers somewhere? Once we know this, we can go forward with fixing how they are stored in evntsave.c. What I wanted to say is that at that point .sval already points to a valid memory address, so it should be safe to copy the string. I don't believe that it is. If you read eventLoadContextHashed, up through line 485, where does sval get initialized? In eventNewContext(), line 415. Except that it's the data variable which is set, whereas eventNewContext is only called with reference to psCode, release, and psCCont. Maybe I am missing how those relate. You probably are. ;-) eventNewContext() gets a pointer to some code, it initializes variables of that script to their default values, allocates space for strings etc. It then returns some script context - 'psCCont' (whatever it is). After some value has been read from the save game, it gets assigned to a temporary 'data' var. Then eventSetContextVar() gets called. Based on value of 'i' it iterates through psCCont's variables to find a variable that corresponds to the data that was just read from the save file and then assignes this data to the corresponding variable to restore its state. At least that's what I could understand reading that code. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 11:33 PM Subject: Re: [Warzone-dev] Current problems Not sure I understood it. You said loading on mac worked before some revision. Have you endianized evntsave.c and scriptobj.c before that or did it work without endianization? Or are you referring to some changes that were made to evntsave.c and scriptobj.c in some revision? I never did any work on those files. Saving and loading used to work (it works in 2.0.5). This is strange, I wonder how it could work without endianization, well anyway, I went through the saving and loading routines and endianized what I thought had to be endianized. I assumed you do endianization to make save files compatible with little-endian systems. I hope I didn't overlook anything. Troman mac_script_load_save.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Tuesday, February 13, 2007 8:45 PM Subject: Re: [Warzone-dev] Current problems On 2/13/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 11:33 PM Subject: Re: [Warzone-dev] Current problems Not sure I understood it. You said loading on mac worked before some revision. Have you endianized evntsave.c and scriptobj.c before that or did it work without endianization? Or are you referring to some changes that were made to evntsave.c and scriptobj.c in some revision? I never did any work on those files. Saving and loading used to work (it works in 2.0.5). This is strange, I wonder how it could work without endianization, well anyway, I went through the saving and loading routines and endianized what I thought had to be endianized. I assumed you do endianization to make save files compatible with little-endian systems. I hope I didn't overlook anything. I guess the problem comes from something else. However, I have been going through your changes and noticed some of the particular weirdness ... whose idea was it to store psGroup-sRunData.forceLevel and .leadership as SDWORDs in the file but as UBYTEs in the game? Would there be any harm (other than of course breaking old savegames) in saving them just as UBYTEs? According to scriptLang.rtf both 'forceLevel' and 'leadership' are in %, we should be on the safe side storing them as UBYTEs. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. Troman As for the scrCBNewUnit() problem, did r690 fix it? I haven't had it occur since then, so it appears that that problem is fixed. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 10:12 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. That's the problem. When I endianized the data loading and saving processes early on in my involvement with the project, I had the struct definitions to go from to determine what parts needed to be endianized
Re: [Warzone-dev] (repost) Patch: Removal of the AND and OR macro's
Applied in r731. Troman - Original Message - From: Gerard Krol [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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 warzone-dev@gna.org Sent: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 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 warzone-dev@gna.org Sent: Saturday, January 27, 2007 6:37 PM Subject: Re: [Warzone-dev] Current problems On 1/27/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Saturday, January 27, 2007 4:27 AM Subject: Re: [Warzone-dev] Current problems On 1/26/07, Christian Ohm [EMAIL PROTECTED] wrote: On Friday, 26 January 2007 at 22:09, Ari Johnson wrote: 1. I think that the minimap's display area indicator is supposed to be a yellow outline with a lighter yellow interior. This is what gets drawn when I zoom all the way in, although it's drawn in kind of the wrong shape, as if it were just zoomed in until you went cross-eyed at it. 2. When you zoom to regular levels, out enough to see more than a couple units at a time, it is drawn in the right shape but does not have a filled-in light yellow appearance, just the outline. Actually it isn't yellow. There's a grey trapezoid indicating the field of view. If you zoom in, the parallels are shortened, they overlap, and the overlapping area is overlayed with a lighter gray, like the selection box should be since r603. Since both are yellow in your case, the two problems might be connected somehow. That helps to know. Thanks! Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' No clue about this one, do you know when this problem started? I see you fixed something related to loading/saving in r682, was it this problem that you fixed? No - this came up after I made that fix. I haven't traced back where the two variables it is comparing come from. I'm sure that following them back to their sources will reveal why they aren't matching as expected. As to your response to #6, it seems to be kind of random but somehow relates to what units I have selected at the time, I think. The problem is that when it happened this last time I was watching my factory production and none of them was done producing a unit when it crashed. Otherwise I would say right away that it must be due to unit production scripts. I'm sure it is related to unit production somehow. Maybe it was AI that produced a unit. Let me know what you find, if anything. I will. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 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 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
Re: [Warzone-dev] Patch for removing the AND and OR macro's
- Original Message - From: Gerard Krol [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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: 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: warzone-dev@gna.org 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 warzone-dev@gna.org 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 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. I think we should just allow the creation of multiple playlists, and then have some function to select the current active one (like bindPlaylist below). Then when you select a playlist to be active it should simply start playing automatically. If you would want nothing to play then just select playlist NULL or something similar, meaning no playlist is active. When everything starts you must have the state playing=no/stoped=yes, because you don't even have a playlist to play from. Your idea would imply that bindPlaylist doesn't only bind the playlist, but also implicitly advises the soundengine to play it. Doesn't sound too nice to me. 1st that function does several things instead of only one and 2nd the modder might not want to start it immediately for whatever reason. Ditto. I don't know why we would want to force playback, let the modder decide. Eg. in GL the texture you bind is also not immediately painted on the screen. Or if AL uses a similar way, I don't think every sound-source you bind is immediately played. (But I have _no_ idea of AL, I must admit.) So my advice would be to let bindPlaylist bind the playlist and let startPlaylist/resumePlaylist handle the beginning playback. (Maybe we should have start/stop and pause/resume functions, where start/stop start from the beginning or stop entirely and pause/resume only ... pause and resume. Would save us from weird double namings (start and resume being the same thing) and would also add some functionality for no fees.) In cases when some music
Re: [Warzone-dev] Music playlists
- Original Message - From: Dennis Schridde [EMAIL PROTECTED] To: warzone-dev@gna.org 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 warzone-dev@gna.org 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(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. Didn't say that it doesn't to me. Just the naming is not my favourite... playlistReset - clearPlaylist playlistInteruptWith - playTrack That was my idea... Maybe not ideal, either. 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. Those effects (not shuffle, but .*fade.*) would also affect playTrack(). If the modder wants something different, he can switch modes before and after his custom track. (Reacting to events.) 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
Re: [Warzone-dev] 500KB patch...
- Original Message - From: Dennis Schridde [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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 warzone-dev@gna.org 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] Music playlists
- Original Message - From: Per Inge Mathisen [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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 warzone-dev@gna.org 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] 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: warzone-commits@gna.org 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=592view=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 warzone-dev@gna.org 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
[Warzone-dev] Re: [Warzone-commits] r590 - /trunk/src/projectile.c
- Original Message - From: Dennis Schridde [EMAIL PROTECTED] To: warzone-commits@gna.org 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=590view=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] [patch] MALLOC/FREE issues
- Original Message - From: Per Inge Mathisen [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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] 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
[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] MALLOC/FREE issues
- Original Message - From: Christian Ohm [EMAIL PROTECTED] To: warzone-dev@gna.org 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
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=547view=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] Backporting fixes for 2.0.5?
Let's see if this finally gets through. - Original Message - From: Christian Ohm [EMAIL PROTECTED] To: warzone-dev@gna.org 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
[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: warzone-commits@gna.org 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=513view=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] 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: warzone-dev@gna.org 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=510view=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
[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: Per Inge Mathisen [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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
Re: [Warzone-dev] More patches for warnings
- Original Message - From: Gerard Krol [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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] Unit AI improvement
- Original Message - From: Dennis Schridde [EMAIL PROTECTED] To: Development list warzone-dev@gna.org 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] 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
