Re: [Xconq-developers] Problem setting up advances in a new game

[<ms...@an...>]

On Sun, 2 Oct 2005, Lincoln Peters wrote:
> I am trying to do some things with ZOC that I don't think have ever been done
> before (e.g. you can approach an enemy neodymium unit, but once you move to
> within 3 cells, you can't move away), so I wouldn't be surprised to discover
> a few ZOC-related Xconq bugs on the way.  But for now, it's too soon to be
> filing any bug reports pertaining to my use of ZOC in this module.

I've made some changes to the ZOC code recently, and there remain some
behaviours that could be called bugs, but have at least been documented in
current CVS.  I found these while implementing a similar type of ZOC in
SRE:  you can move into, and within, a black hole's gravity well but you
can't leave.

With the current CVS version of Xconq, it should work (and does for me) if
you set zoc-range appropriately, mp-to-enter-zoc and mp-to-traverse-zoc to
0, and mp-to-leave-zoc to a large number, like 999.  Also be warned that
the order of indices may be counter-intuitive; for zoc-range the unit
exerting the ZOC goes first, but for the other tables the unit that's
moving goes first and the unit exerting the ZOC goes second.  My GDL code
looks like this:

   (table zoc-range add (black-hole u* 2))
   (table mp-to-enter-zoc add (u* black-hole 0))
   (table mp-to-traverse-zoc add (u* black-hole 0))
   (table mp-to-leave-zoc add (u* black-hole 999))

It is a known bug (already in the tracker) that the online help, when it
reports these table values, gets the indices backwards for some of them.
The design manual (in current CVS) describes them correctly.  For a long
time it was documented that you could use -1 for "not possible" instead of
999, and at some point in the future that will be fixed, but at present,
it doesn't work and is documented as not working.
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/