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: 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


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