This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: update material display
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Peter Garrone <pgarrone at acay dot com dot au>
- Cc: Hans Ronne <hronne at comhem dot se>, <xconq7 at sources dot redhat dot com>
- Date: Mon, 13 Oct 2003 11:18:45 -0400 (EDT)
- Subject: Re: update material display
Hello Peter,
On Mon, 13 Oct 2003, Peter Garrone wrote:
> > I think you misunderstood me. The point I was trying to make was not that a
> > side treasury check should replace the 999 test for any given material, but
> > rather 1) that we need to check the treasury for those materials that have
> > one, and 2) that testing for 999 etc (whether the material has a treasury
> > or not) is pointless since these figures mean nothing special to the
> > kernel. The only limit that the kernel knows about is um_storage_x, which
> > is always less then TABHI (32767 ). So the storage space is always limited,
> > and the capacity is always defined unless there is a side treasury for the
> > material (and it will be defined in those cases as well when I check in the
> > revised treasury code).
> >
> But is it not a game convention that a unit with a storage capacity
> of 9999 has infinite capacity for that material?
I can't think of any way that a game designer can prevent a unit
from acquiring an amount of material equal to its storage capacity
(aside from expending the material faster than it is accumulated
or by not producing the material at all). I am not sure that there
really is such thing as an infinite capacity. But maybe I am
missing something....
Perhaps a better example of how 9[9+] are used as a sort of
"infinity" is movement, such as mp-to-enter-terrain. Since the
game designer can limit the amount of accumulated movement points
(MP), an amount higher than any unit's max MP can be set and be
regarded as an infinity.
> My understanding is that there is no "proper" way of representing
> infinite capacity, so people have been using these odd numbers.
I would agree with Jim, as he has suggested several times now,
that -1 might be a good convention for Xconq to adopt for this.
Of course, it might be prudent to wait on the necessary kernel
changes until after the 7.5 release. And there is an upper limit
on "infinite" capacities, namely the maximum value that the
underlying numeric type can represent.
But please take all of this as constructive criticism. I am a fan
of your number formatting routine and hope that it gets included
in the kernel.
Regards,
Eric