This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: time.g weirdness
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Jim Kingdon <kingdon at panix dot com>
- Cc: xconq7 at sources dot redhat dot com
- Date: Wed, 11 Aug 2004 12:34:45 -0400 (EDT)
- Subject: Re: time.g weirdness
On Wed, 11 Aug 2004, Jim Kingdon wrote:
> It also might be nice if the online help said something a bit more
> than just:
>
> Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into
> river.
> Needs MP to traverse terrain: -1 by default, 2 across river.
>
> although I'm not really sure how to express this best. I guess the
> "99 by default" could be turned into "cannot enter other terrain" (if
> the help code can figure out that 99 is never possible). Something
> similar for the "-1 by default".
I have been strongly considering the idea of introducing the
concept of relative infinities. So, if a game designer says that
he/she is going to use 9999 to represent an impossible action,
then he/she could write:
(set relative-infinity 9999)
as a global, and then help system would do special interpretation
with it. I am still not sure if this is the best way to proceed.
As far as certain defaults that mean impossible (0 or -1), they
could also be handled as such on a case-by-case basis. This is
something I definitely plan to do.
(The relative infinity stuff could come in handy in the actual
Xconq action logic as well, since then we would no longer be
divining the intent of the designer wrt a number, but would have
his/her explicitly stated intention that the number should be
treated as indicating an impossiblility, unlimited capacity,
etc... of some sort.)
I also intend to make it possible to list off several related
values in the same listing, such as with the adjacent terrain
changing stuff that I added a while back ago.
So, yes, I do plan to do more with the online help system (the
changes which will also be automatically reflected in the help
file output), and I have been thinking about these very issues.
But, I have been doing so much coding at work lately that I
haven't felt like writing any code for Xconq. Hence my
image-related work.
> kind of mouseover (I could threaten to make it a tooltip for Xconq
> Office) when you are on a unit which has a border slide possible.
This isn't such a bad idea. (I notice that the IMFApp Office
thread has thus far failed to lure Stan out onto the list again.
He must be on vacation, only reading the monthly list digests, or
something....)
> Of course, all this is predicated on making border slides work from
> the user interface in the first place.
Right. It is true that Peter had some border slide logic in his
code. However, it was deeply rooted into one of the functions
which I had to surgically remove, and I didn't see any easy way of
saving that part of the logic. The other thing is, _I have no idea
whether it actually worked. It seemed reasonable, but, given all
the other brokenness that came with his code, I don't think we
should assume that it actually worked, unless someone has proof
that it did.
Eric