[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

2007-01-04 Thread Dennis Schridde
Am Dienstag, 2. Januar 2007 21:12 schrieb Roman:
 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

 Modified:
 trunk/lib/script/chat_parser.y
 trunk/lib/script/parse.h
 trunk/lib/script/script_lexer.l
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)


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.)

--Dennis


pgp6eOyjADOMr.pgp
Description: PGP signature
___
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.h lib/script/script_lexer.l lib/script/script_parser.y src/scriptfuncs.c src/scriptfuncs.h src/scrip

2007-01-04 Thread Dennis Schridde
Am Donnerstag, 4. Januar 2007 13:41 schrieb Dennis Schridde:
 Am Dienstag, 2. Januar 2007 21:12 schrieb Roman:
  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
 
  Modified:
  trunk/lib/script/chat_parser.y
  trunk/lib/script/parse.h
  trunk/lib/script/script_lexer.l

 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)

 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.)
This fix does NOT work:

Index: lib/script/script_lexer.l
===
--- lib/script/script_lexer.l   (revision 594)
+++ lib/script/script_lexer.l   (working copy)
@@ -729,7 +729,8 @@
scr__flush_buffer( YY_CURRENT_BUFFER );

//yy_scan_string(pBuffer);
-   YY_CURRENT_BUFFER = yy_scan_bytes(pBuffer, size);
+   if (yy_buffer_stack != NULL)
+   YY_CURRENT_BUFFER_LVALUE = yy_scan_bytes(pBuffer, size);
 }

 void scriptGetErrorData(int *pLine, char **ppText)


Without the if, it segfaults, with the if it gets into an infinite loop.

--Dennis


pgpqdbz6DUtgA.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


[Warzone-dev] Re: [Warzone-commits] r596 - /trunk/data/mp/stats/weapons.txt

2007-01-04 Thread Dennis Schridde
Am Donnerstag, 4. Januar 2007 15:42 schrieb Dennis Schridde:
 Author: devurandom
 Date: Thu Jan  4 15:42:40 2007
 New Revision: 596

 URL: http://svn.gna.org/viewcvs/warzone?rev=596view=rev
 Log:
 Multiplayer Command Turrets can now attack/mark air targets. This makes it
 sensible to attach AA weapons to commanders for defensive purposes.
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.

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


pgpeKbV3ogWGt.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] multiple commander targetting

2007-01-04 Thread Giel van Schijndel
The Watermelon schreef:
 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...
So if I understand, currently groupmembers of a commander simply `copy'
the commander's primary target?

If it would be possible to simply copy an entire array with
commander-assigned targets (e.g. ground  air) would it then be possible
to select the best suitable target from that array?
Optionally it might then probably be nice to have a bool for every of
those targets which tells whether that target is currently firing at the
commander.

-- 
Giel



signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] Re: [Warzone-commits] 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

2007-01-04 Thread Troman

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


Re: [Warzone-dev] multiple commander targetting

2007-01-04 Thread The Watermelon


Yes, but it will still be limited to only a few (lets say three at max?)
targets, which is already an advantage. Then secondly: having two target
types (i.e. ground/air) really shouldn't be a problem in firefocussing
since an AA gun simply can't fire at ground targets (except for stuff
like assault gun etc.).

--
Giel


iirc the commanders just choose the 'bestTarget' for its laser designator(1
damage per projectile...),so basically the targets chosen by the commander
automatically is not suitable for most group members,and you cannot assign
more than one targets with commander manually.
___
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

2007-01-04 Thread The Watermelon


  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.

Manual-assign targets will be too complex for players,with 1 target you

just select your unit first then left-click on the enemy unit/building and
your 'manual-target-assignment' is done,while with multiple weapons you have
to do this number of DROID_MAXWEAPS times,not to mention some weird keycombo
that is needed to pressed while doing that...


(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+number 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+AA_WEAPON_TYPE_INDEX.

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


yep we need a main/default weapon_slot to control the movement of the
droid(currently using '0').

The weapon combo a droid is a bit messy for current wz,the idea of
multi-weapon/multi-target is to improve the combat capacity vs multiple
different types of targets of a droid with zero/little human player
'intervention'.In 'stock' wz it seems there is only 1 'type' of target(all
units are 'droids' and certain weapons are not exceptionally good vs certain
units/armor or completely useless vs certain units/armor,e.g:mg's just
'counter' everything in game),so this is not very useful imo.

I am not sure if combinating 'utility' turret and 'combat' turret is a good
idea or not,since the 'utility' turret will have always to be '0' due to the
droid type checks(DROID_CONTRUCT,DROID_REPAIR,DROID_WEAPON etc)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev