What did just happen?!

[migr8r]

Something I don't understand just happened.

I'm playing the Earth 18 map as England on Monarch, Marathon speed. I had a city (York) where I was building the mids, for fail, and was about to finish researching Pottery. Since I wanted a granary in York I planned on putting a warrior in the build queue in front of the mids, whip it with 1 turn left and next turn, which would be the turn I'd finish Pottery, put a granary in front of the mids and let it catch the overflowing hammers, there would 85 of them. So I set it up as planned, but it is not what happened.

Instead only 30 hammers flowed over and 55 gold was added to my treasury!? I reloaded to make sure I wasn't seeing things. So what happend here? Is this a bug or is this a hint of some law of CIV-Physics I'm unaware of?

Could somebody please explain this to me?

 

[strijder20]

Well, warriors are 30 hammers. You can only overflow so many hammers as your previous build project cost.

 

[VoiceOfUnreason]

Instead only 30 hammers flowed over and 55 gold was added to my treasury!? I reloaded to make sure I wasn't seeing things. So what happend here? Is this a bug or is this a hint of some law of CIV-Physics I'm unaware of?

Could somebody please explain this to me?

Civ Physics.

The game has some conflicting goals. To eliminate some tedious micromanagement, the game supports overflow. But if you allow overflow to accumulate indefinitely, humans will start building every wonder in one turn - essentially, the human player can invest hammers in the Pyramids before discovering Masonry, then one shot it.

So they implemented an overflow cap, which strijder20 correctly points out is dependent on the build.

Unintended consequences(?): whipping warriors/scouts is a bad idea, since you can't avoid the overflow cap. When whipping multiple builds on the same turn, the order that you queue the builds after whipping can also run into the overflow cap.

 

[migr8r]

Ah, ok! Didn't know about the law of overflow cap. Thx for the explanation. But I didn't actually lose those hammers, right? I got some gold. Can this be seen as a form of wealth building? Or would that just be horribly inefficient?

 

[lymond]

Isn't OF gold from a pre 3.19 patch version of BTS? Are you on the right patch, OP, or are you playing Vanilla or Warlords? OF gold pre-dates me, but my understand is that it was an exploit that was fixed.

 

[migr8r]

Isn't OF gold from a pre 3.19 patch version of BTS? Are you on the right patch, OP, or are you playing Vanilla or Warlords? OF gold pre-dates me, but my understand is that it was an exploit that was fixed.

I don't know. I guess not. I haven't played for a while and i never let things update automaticly so yeah, probably. I'll update.

 

[coanda]

I believe you still get overflow gold post 3.19, but you get what it would be without any multipliers. Someone who pays more attention to overflow gold can probably confirm or correct me.

 

[r_rolo1]

Isn't OF gold from a pre 3.19 patch version of BTS? Are you on the right patch, OP, or are you playing Vanilla or Warlords? OF gold pre-dates me, but my understand is that it was an exploit that was fixed.

Ok ...

a) OF gold is still alive in 3.19
b) As such , it does not predate you
c) It could definitely exploited pre 3.19
d) It was wrongly overnerfed and as such is basically useless in 3.19. I would not call that fixed In fact IMHO it is even worse than it was ...

As someone that knows better than me said ...

(From CvCity.cpp)

iProductionNeeded = getProductionNeeded(eTrainUnit);

// max overflow is the value of the item produced (to eliminate prebuild exploits)
iOverflow = getUnitProduction(eTrainUnit) - iProductionNeeded;
int iMaxOverflow = std::max(iProductionNeeded, getCurrentProductionDifference(false, false));
int iMaxOverflowForGold = std::max(iProductionNeeded, getProductionDifference(getProductionNeeded(), getProduction(), 0, isFoodProduction(), false));
[b]iOverflow = std::min(iMaxOverflow, iOverflow);[/b]
if (iOverflow > 0)
{
    changeOverflowProduction(iOverflow, getProductionModifier(eTrainUnit));
}
setUnitProduction(eTrainUnit, 0);

int iProductionGold = std::max(0, [b]iOverflow - iMaxOverflowForGold[/b]) * GC.getDefineINT("MAXED_UNIT_GOLD_PERCENT") / 100;

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)?

And firaxis awnser :

It is definitely a bug, although the effect on game play is minor. Sorry about that.