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: Some issues with materials side report


>The heading is excessively compressed, and the numbers are jammed together.
>The heading, on my display, looks like
>
>Materialupply Prodapac

This is an interface issue. We have several tcltk interfaces, and also
different implementations of the Unix tcltk interface. People also have
different screen sizes etc. The code you submitted had a problem in that
the last column (capacities) ended up outside the unit list panel on some
interfaces.

The underlying problem is the font size. If you have an overlap problem in
the unit list panel, because your font is too big, you will most likely
have it in some other places as well. However, this is easily fixed. Just
go to the Preferences dialog and reduce your default font size so that the
columns do not overlap. The font in the unit list panel will now scale with
all the other fonts. I added this functionality when I checked in your
code, precisely to handle the above problem.

>For games with "infinite" capacity, the percentage reports as
>the digit zero, e.g. advances and coral sea.
>It was blank in the code I sent in.
>
>If a newish user sees 0 for capacity, (provided they
>worked out what "apac" meant, of course),
>it would have an alarming affect.
>So the 0 is misleading.

I disagree. The capacity is never infinite, it is always limited. So 0% is
the correct value to show here. Once these units accumulate enough
materials the "capacity" will change from 0% to 1%. Which will be correct
then.  And so forth.

I think there is a problem here, however, and that is that the word
"capacity" is somewhat misleading. It is not clear that this refers to
storage space, and not for example production capacaity. When I went over
your code, I briefly considered changing "100% capacity" to "0% room" (or
"0% free space"). This would make it crystal clear what these numbers
really mean.

>I think the main issue was the rejection retroactively of the use of
>9999 as an infinite capacity.
>At the time I suppose I could have challenged this, though I didnt,
>so I am raising this issue again. What exactly is the problem here?

This is a misunderstanding, perhaps because the docs are not crystal clear
on this point. 9999 was never ever used to denote "infinite" capacity
(which does not exist). It was just a convention used by Stan in some game
modules:"I know the capacity is always limited and never infinite. But
let's pick a large enough number, say 9999, so that it is unlikely that the
unit will ever run out of space". That's all 9999 ever meant.

Unfortunately, 9999 (or even TABHI) is not a large enough number in some
very real cases. Which is why I went through all the materials code and
made sure it always checks for numeric overflow.

Hans



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