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


> The algorithm in the patch I posted
>checks if the capacity for a material is 99, 999 etc
>using (storage+1)%10==0
>and if so decides it is infinite and so displays nothing. In
>my game of advances, it comes out blank. Only the "capacity"
>heading is there, which should be OK I hope.

Yes. There are two problems, however. First, there are no infinite
capacities: um_storage_x is strictly limited by TABHI (32767 ). I know it
says in the docs that 99, 999 etc. are used to denote unlimited capacities,
but this is meant in figurative way, i. e. many game modules use them as
arbitrarily large (but still finite) numbers.

The second problem is with side treasuries (a common unit-independent
storage place for certain materials). They are really unlimited, which is a
problem right now, since they are vulnerable to numeric overflow. So
materials with treasuries do have "infinite" capacities.

A possible fix for your code is therefore to skip the 99, 999 stuff and
instead set the infinite flag for materials that have a treasury. I have
already tested such a patch, and it works fine with all games. It draw my
attention to two other problems, however. First, the above mentioned
numeric overflow. Second, the fact that functions that modify unit->supply
do not always check um_storage_x. I have therefore started to fix these
bugs as well. I will check in both your capacity patch and the necessary
bug fixes later.

> In my game of bellum, besides being incorrect, the numbers
>totally overwrote each other. In the patch I implemented a number
>formatting function so that numbers greater then 9999 come out
>as nn.nK, n.nnM, n.nnG so that this can never occur. Do you
>think this is satisfactory?

I think this is fine. It gets rather crowded with images, names and 3
columns. BTW, I noted that you had a much larger spacing in your tcltk
patch, which puts the last column offscreen for me. Are you using a very
large font?

> Should these functions to find total supply, production,
>and capacity be part of the kernel rather than the interface,
>so if other interfaces wanted the information it is not duplicated.
>Possibly they could be moved there.

Yes, that makes sense. I'll look for a suitable location. The number
formatting function could also be useful in other places.

Hans



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