This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: update material display
- From: Hans Ronne <hronne at comhem dot se>
- To: Eric McDonald <mcdonald at phy dot cmich dot edu>
- Cc: xconq7 at sources dot redhat dot com
- Date: Mon, 13 Oct 2003 18:22:21 +0200
- Subject: Re: update material display
- References: <20031013114903.GB725@leonardo>
>> 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....
I know this is confusing. There are no infinite or unlimited capacities in
xconq. That being said, 9999 is used as a "very large" number in game
modules, a convention that Stan invented and that we are stuck with for
now. I agree with Jim that -1 might be a better choice to represent
infinity. However, -1 already has another use in GDL: that of causing one
table to be substituted for another one.
The kernel treats 9999 as any other number, i. e. as a real limit on the
capacity. There is one exception to this, and that is some code that I
added this summer, which causes the capacity not to be shown in unit
displays if it is 9999 (or 999 or 99). This was just because I thought
these bogus infinite numbers were cluttering the display with useless
information.
If we didn't use 9999, the limit would still be that of a short int, i.e.
32767. There is no way around that. So I guess -1 (or whatever) would have
to default to 32767, then.
>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.
I agree, and I intend to check it in together with the capacity display
code. This has been delayed only because I found a number of kernel bugs
that had to be fixed when I started to dig into the materials code.
Specifically, the upper limits on treasuries and unit supplies were not
always respected, thus leaving the door open for numeric overflows.
Hans