This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GDL Notice: New Tables and Variables pertaining to ACP and Capture


Wow!

Documentation, release notes, software upgrades...

Be careful, or the Union of Professional Programmer's will be after you,
for
Violating union rules ;)

Great stuff!

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Eric McDonald
Sent: Monday, June 14, 2004 9:54 PM
To: xconq7@sources.redhat.com
Subject: GDL Notice: New Tables and Variables pertaining to ACP and
Capture


Hello fellow Xconq game designers,

  I just added a small truckload of new functionality to GDL and thought
you should know about it. I suppose now I really should get back to
fixing bugs (including new ones that I probably created with these
enhancements).

  Where to start? Hmmm..., let's talk about ACP modifiers first.
  New tables: 'night-adds-acp', 'night-multiplies-acp',
'occupant-adds-acp', and 'occupant-multiplies-acp'.
  Tables that are no longer around: 'acp-night-effect' and
'acp-occupant-effect'. Don't worry, __I replaced these old tables with
their new "*-multiplies-acp" counterparts in the various games in the
library.
  The documentation describes all of these new tables in a fair amount
of detail. I will be updating the doc Web pages at the Xconq site
shortly.
  Also, the new version of Wreckreation demonstrates the usage of
'night-adds-acp' and 'night-multiplies-acp'. Play the Undead side, and
watch how much ACP a Nightwing has during the night as opposed to during
the day. For that matter, notice that the zombies are a bit sluggish
during the day, and that the various human units aren't too active at
night. Better yet, actually try to move a Nightwing during the day. :-)
(Hint: If it actually moves or causes a crash, then you have found a
bug.)

  Now let's talk about the capture-related stuff.
  I finally got fed up enough with the model-0 combat/capture situation
and provided true capture-resistance tables. These are independent of
any combat protection. They are: 'occupant-allows-capture-by',
'occupant-allows-capture-of', 'stack-neighbor-allows-capture-by',
'stack-neighbor-allows-capture-of', 'any-neighbor-allows-capture-by',
and 'any-neighbor-allows-capture-of'.
  Again, these are fairly well-documented. But, as a summary, the
"occupant-*" tables pertain to how an occupant helps/hinders its
transport regarding capture. The "stack-neighbor-*" tables pertain to
how units in the same cell (excluding occs) help/hinder one another. The
"any-neighbor-*" tables are like "stack-neighbor-*" but include occs as
benefactors. The "*-by" tables refer to how the helper/hinderer affects
the capture based on the type of the unit _attempting capture_. The
"*-of" tables refer to how the helper/hinderer affects the capture based
on the type of the unit _resisting capture_. In all cases, 0% is good
(meaning capture is entirely prevented), 100% is normal (attempted
capture is not interfered with), and >100% is bad for the unit which is
the victim of the capture attempt.
  Wreckreation demonstrates the use of 'occupant-allows-capture-of'.

  But, that's not all. By default (for legacy support), the combat
protection tables ('protection', 'stack-protection',
'cellwide-protection-for', and 'cellwide-protection-against') are still
considered as capture chance modifiers. This is because the new global
variable, 'protection-resists-capture' is true by default. To make the
Xconq capture code _not_ use the combat protection tables when
calculating capture chances, then:
  (set protection-resists-capture false)
like Wreckreation does. Note that the new "*-allows-capture-*" tables
are always considered, no matter what this global var is set to; there
default of 100% will not (should not) affect existing games in any way.

  And, finally, per my wish and Matthew Skala's verbalized suggestion,
Xconq nows has 'changed-type-if-captured'. If an unit is successfully
captured, it will change type to whatever unit type you specify for the
given captor-prisoner lookup. By default, no type change occurs upon
successful capture (the table default is 'non-unit'). Wreckreation
demonstrates the usage of this table as well.

  Hoping this wasn't all too much,
  Enjoy,
    Eric



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]