Wow a patch -- that's a (partially) nice surprise!
And quite a lot of the UP fixes are implemented.
The one change I am most curious about is this:
~~~~~~~~~~~~
I tried really hard, but I just cannot see the intended logic in this piece of code.
The new variable
iMaxOverflowForGold is calculated as the maximum of the current build cost (
iProductionNeeded) and the number of
base hammers of the city (from tiles, specialists, buildings) multiplied by its
generic (=non build-specific) modifiers. In the early game with the typical low base hammers and few generic modifiers (forge, bureau) iMaxOverflowForGold will be equal to iProductionNeeded.
Chops and whips have absolutely no effect on it!
The capping of
iOverflow at the maximum of iProductionNeeded and the base hammers multiplied by ALL modifiers remained unchanged and will also typically result in iOverflow = iProductionNeeded in the early game, especially at slower speeds.
Thus iProductionGold = max(0, iProductionNeeded - iProductionNeeded) = 0.
You will gain a little overflow gold if the city has a lot of base hammers (e.g. > 17 base
for pro-stone-wall @normal speed) and then the amount of gold will be
higher the
more build-specific modifiers are active
.
The exact gold overflow = base hammers * build-specific modifiers, excess chops and whips turn into thin air. IMHO this goes against everything the change note of the patch stands for.
Solver offered his help, maybe he can shed some light on this (and perhaps tell us why the UP-code wasn't good enough)?