From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32169 invoked by alias); 12 Aug 2004 17:24:04 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 32158 invoked from network); 12 Aug 2004 17:24:02 -0000 Received: from unknown (HELO av13-1-sn4.m-sp.skanova.net) (81.228.10.104) by sourceware.org with SMTP; 12 Aug 2004 17:24:02 -0000 Received: by av13-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 4F9FD37E47; Thu, 12 Aug 2004 19:24:02 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av13-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 4224A37E42; Thu, 12 Aug 2004 19:24:02 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp4-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id EBFD337E46; Thu, 12 Aug 2004 19:23:57 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: <200408121539.i7CFdMW10498@panix5.panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Aug 2004 17:35:00 -0000 To: Eric McDonald From: Hans Ronne Subject: Re: time.g weirdness Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00889.txt.bz2 >On Thu, 12 Aug 2004, Jim Kingdon wrote: > >> > /* Don't print out storage space if it is set to arbitrarily large >> > (9999, 999 or 99) as in many games. */ >> >> Well, that's more problematic, in that it doesn't check storage >> against consumption, production, etc. > >I agree. This is one of the pieces of code I had in mind when I >suggested that relative infinity would be useful beyond just the >help system. > >> It does seem like an argument for some more real form of infinity >> (maybe just TABHI). > >I agree. I also agree that a real infinite instead of the bogus ones (99 etc) would be nice, so if any of you want to give it a try, I'm all for it. There was one other consideration with the above code, though, and that was to save space and reduce the clutter in the unit info box (and Mac unit closeup popup). This is what they would look like in most games before the change: Food: 4 / 9999 Minerals: 6 / 9999 Fuel: 2 / 9999 Ideas: 12 / 9999 Typically, the right half of this line would be truncated in the closeups (which are smaller than the unit info boxes). Now it says instead: Food: 4 Minerals: 6 Fuel: 2 Ideas: 12 which is much neater. Now, if the game designer sets capacity to a bogus infinite, it usually means that he doesn't expect the ceiling to be hit in a real game. If 99 is too low, he would use 999 or 9999 instead. This, in turn, means that the player has no interest in knowing about the capacity. All he needs to know is that there is no ceiling that he has to worry about. Which is why I suppressed the printing of bogus infinites. The weak point here is of course that the game designer may deviate from this rule, by intention or mistake. Having a relative infinite that defaults to TABHI, and which is suppressed in most outputs, is therefore a superior solution. Hans