And yet another bug!

Grille · 18-12-2003, 19:45

Catt suggested on CFC that commerce assigned to tax is always calculated lastly -or: what's left over, goes to tax. IMO the suggestion is quite reasonable, makes at least also sense for Kingreno's pic:

Newcastle has 2 uncorrupted commerce units:
70% go to science -> rounded down to 1 as shown in the pic
20% go to entertainment -> rounded down to 0 as shown in the pic, but that 1 left over commerce unit would not be wasted due to rounding, it goes to tax, i.e. 1 gold.

Not too logical, but apparently the game calculates this way. So the shown tax percentage (e.g 10%) doesn't mean anything (also, there is no tax slider). It's not really a bug, but some weird annoying stuff - and 'interstage' rounding before commerce multipliers do their job can often produce strange results as well.

Imagine a market (+50%) in that city, you *should* then get even 2 tax gold out of the "10%" rating. That looks weird in comparison to science, because science gets 70% from slider settings and ends up with only 1 beaker.

Well, it's a micro-managing hell... the optimal commerce output would be reached if you'd always meet the 'round up' condition; the really wasted commerce is not only determined by capital distance (etc...), but also by slider settings. I wonder how courthouses, policestations and policemen kick in...

As for the editor corruption slider: I *suspect* that there are two corruption/waste calculations made, if the the slider does not stay on 100%. Both calculations are possibly rounded indepently and then summed up. I guess one calc is for the 100%-default waste/corr portion (slider was patch-added IIRC) and the other portion gets either added (slider above 100) or substracted (below 100). With this assumption, it is at least very easy to explain the 'more shields from working tiles - less production capacity' situation in Rise of Rome.

Obviously, Firaxis loves rounding and is afraid of non-integer numbers

- sparing memory (for non-integer variables) may have been a reason(?).

18-12-2003, 19:45	#11
Grille Join Date: May 2003 Location: in a swamp. Posts: 901	Catt suggested on CFC that commerce assigned to tax is always calculated lastly -or: what's left over, goes to tax. IMO the suggestion is quite reasonable, makes at least also sense for Kingreno's pic: Newcastle has 2 uncorrupted commerce units: 70% go to science -> rounded down to 1 as shown in the pic 20% go to entertainment -> rounded down to 0 as shown in the pic, but that 1 left over commerce unit would not be wasted due to rounding, it goes to tax, i.e. 1 gold. Not too logical, but apparently the game calculates this way. So the shown tax percentage (e.g 10%) doesn't mean anything (also, there is no tax slider). It's not really a bug, but some weird annoying stuff - and 'interstage' rounding before commerce multipliers do their job can often produce strange results as well. Imagine a market (+50%) in that city, you should then get even 2 tax gold out of the "10%" rating. That looks weird in comparison to science, because science gets 70% from slider settings and ends up with only 1 beaker. Well, it's a micro-managing hell... the optimal commerce output would be reached if you'd always meet the 'round up' condition; the really wasted commerce is not only determined by capital distance (etc...), but also by slider settings. I wonder how courthouses, policestations and policemen kick in... As for the editor corruption slider: I suspect that there are two corruption/waste calculations made, if the the slider does not stay on 100%. Both calculations are possibly rounded indepently and then summed up. I guess one calc is for the 100%-default waste/corr portion (slider was patch-added IIRC) and the other portion gets either added (slider above 100) or substracted (below 100). With this assumption, it is at least very easy to explain the 'more shields from working tiles - less production capacity' situation in Rise of Rome. Obviously, Firaxis loves rounding and is afraid of non-integer numbers - sparing memory (for non-integer variables) may have been a reason(?).