I've run some tests on Lexad's request to no longer count production modifers on gold from production overflow. The change itself is the addition of the two green lines below in CvCity:opOrder(). You may note that this is from the part where training units is handled; similar additions would be made for building and project construction within the same function. The logic used is essentially the same as that used in CvCity::changeOverflowProduction() to undo the modifiers on hammer overflow. Code: [COLOR="Green"] iLostProduction *= 100; iLostProduction /= std::max(1, getBaseYieldRateModifier(YIELD_PRODUCTION, getProductionModifier(eTrainUnit)));[/COLOR] int iProductionGold = ((iLostProduction * GC.getDefineINT("MAXED_UNIT_GOLD_PERCENT")) / 100); Here is my test situation: A city with base production of 50 hammers, 50 overflow hammers, and various modifers building a 28-hammer unit (Explorer on a Normal speed game). The change keeps the overflow gold much less than if the city had built wealth which should remove most of the exploitability but you still get something for your lost hammers. Note that chopping can still gain extra money. In the same scenario with 3 Math-fueled forest chops (90 total hammers) the results are: This change always results in a 1:1 hammer-to-gold conversion from the chops (all the tests got 90 gold more than the previous scenario) so while you can still get extra money over what wealth would have gotten you, it's not a particularly efficient use of a forest chop and again should limit exploitability. I'm liking this change. Thoughts?