Re: update material display

[Peter Garrone <pgarrone at acay dot com dot au>]

On Fri, Oct 10, 2003 at 11:20:36PM +0200, Hans Ronne wrote:
> >Hi Hans, I am getting every email twice so posting directly to the list.
> 
> That's a feature, not a bug, at least on this list :-). We usually reply
> directly to somebody and cc the list, if appropriate. So you should always
> get two messages if somebody is replying directly to you and everything
> works as expected.
> 
> >Just on the 999 stuff, I have a small advance game with 3 cities, and
> >its giving me a total capacity on Food and Ores of 29997, even though I
> >am doing a check on the treasury as you say. Looking at advances.g,
> >cash and ideas are in the treasury, but food and ores are not, so
> >I will keep testing for 99 etc, unless you can suggest something better,
> 
> 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).
> 
> In the specific example you mention, the total storage space for food or
> ores is 3 * 9999 = 29997. So the code is reporting the correct result.
> OTOH, if you assume that 9999 is the same as unlimited storage (which it is
> not) you will get the wrong result.
> 
> Hans
> 
But is it not a game convention that a unit with a storage capacity
of 9999 has infinite capacity for that material?

My understanding is that there is no "proper" way of representing
infinite capacity, so people have been using these odd numbers.

If a designer uses 9999 instead of 10000, for max capacity, when
they meant a finite rather than infinite capacity, then they
deserve it if their game breaks.

I would agree that testing for 99 and 999 as well as 9999 is a bit tacky.
Possibly any instances of this in existing games could be addressed
with grep/edit.
 Peter