Re: time.g weirdness

[Eric McDonald <mcdonald@phy.cmich.edu>]

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