Installation Question

[Thalassicus]

Maybe it will help if I detail how the game figures maintenance?

400 40 Rifleman

Maintenance
= 0.018*Cost + 0.18 * MAX(Combat, RangedCombat) - 1
= 0.018 * 400 + 0.18 * 40 - 1
= 13

This happens in the database before we start a game, so the actual gameplay effect of the code I wrote does not depend on gamespeed. However! The game core might adjust the results of this code later. I did temporarily change the visual display on tooltips, in the mistaken belief marathon multiplied gold costs by 3. The earlier posts indicated inflation might be a factor, so I set the inflation to 0% in Gem v1.12.1.

 

[mystikx21]

I've been playing with that formula to see how it would calculate based on game speed.

That's how I arrived at the conclusion I did that game speed must be raising upkeep cost.

Inflation I have set to zero and a Rifle is still costing me actually 28 upkeep on marathon speed even though it displays as though it is 13 Game speed also is an explanation for why it's not as noticeable earlier on as units do not have as much cost variance when they are cheap on standard game speed. 28 is precisely what it would be using that formula adjusted for game speed.

I haven't tested yet with disbanding workers to see if that costs more later on (about to). It has before inflation was removed, up to 5-6 late. They'd be the easiest to test as they should just cost 2 since they're the only set unit cost for upkeep.

If they fail the test, then we would need to figure out some other way to remove inflation it sounds like.

 

[mystikx21]

Workers were still costing 4-5 gold later as well. Possibly inflation wasn't nixed correctly

I'll try with the newer version and see if that helps (I was testing the inflation fix already in the last version).

Other findings: When I ran my entire military through a projected cost assessment for "marathon level" upkeep, it still came up about 160 short of what it was costing me in GPT, even after charging myself 4-5 gold for workers. That was a lot closer than the standard calculation, but still wrong. So there's probably some other source for unit costs rising involved here. Probably inflation somewhere still?

I also think buildings were slightly affected. Building upkeep was off by 2-4 per city. Buildings cost less to maintain than units, so inflation would take a lot longer to notice. It's possible however that this was from playing as Carthage and the "free" harbors were not actually "free". Inland cities appeared unaffected. More testing with another civ in progress.

Some reports for how unit upkeep works in later game standard settings would be useful here to compare. I will try a couple games at that setting as well and see if it's more a marathon-epic game speed issue or if it's a general inflation issue that we can fix some other way.

 

[mystikx21]

Thal, adjusting the modifier (below) to a higher value removes the inflationary effect on unit upkeep (or reduces it to more modest level). I don't think the other values actually do anything.

<Update>
			<Where Name="UNIT_MAINTENANCE_GAME_MULTIPLIER" />
			<Set Value="0" />
			<!-- 8 -->
		</Update>
		<Update>
			<Where Name="UNIT_MAINTENANCE_GAME_EXPONENT_DIVISOR" />
			<Set Value="100" />
			<!-- 7 -->
		</Update>

Doing that reduced the unit upkeep totals to a much closer margin to the displayed value. Probably setting it to zero would remove it entirely, but that's the variable that needs attacked. It's more noticeable on slower game speeds simply because there are more turns, creating a higher "power" function in the inflation calculation, and potentially doubling or tripling upkeep by the end game. It doesn't appear to impact anything other than unit upkeep.

If the new variables in game speeds were intended to reduce the inflation disparity, they either don't play well with the mod or they didn't work (as you thought).

 

[Thalassicus]

Ohhhh!

I assumed multiplying by zero equals zero! Of course Firaxis didn't do it this way.

Thanks for finding this. I would have never thought to look there. Now that we have access to the game core, we can look directly at the maintenance algorithm.

// Game progress factor ranges from 0.0 to 1.0 based on how far into the game we are
double fGameProgressFactor = double(GC.getGame().getElapsedGameTurns()) / GC.getGame().getDefaultEstimateEndTurn();

// Multiplicative increase - helps scale costs as game goes on - the HIGHER this number the more is paid
double fMultiplyFactor    = 1.0 + (fGameProgressFactor * GC.getUNIT_MAINTENANCE_GAME_MULTIPLIER());

// Exponential increase - this one really punishes those with a HUGE military - the LOWER this number the more is paid
double fExponentialFactor = 1.0 + (fGameProgressFactor / GC.getUNIT_MAINTENANCE_GAME_EXPONENT_DIVISOR());

double dFinalCost = pow(fMultiplyFactor * iSupport, fExponentialFactor);

It turns out they labelled the variables badly. They called the first variable a "multiplier" (0 * n = 0) when it is actually a modifier of the multiplier (1+0 * n = 1).

Hmm... this makes it more complex to nullify vanilla maintenance costs. I'll have to think about the function.


============

Edit: I looked over the broader function and don't see a way to completely eliminate the GameProgressFactor, but we can essentially zero it out by setting the exponent divisor to a huge value. I'll go with 30,000.

Since the game was previously balanced with this unknown cost included, we'll need to increase unit maintenance to compensate for its disappearance. What's an average nationwide unit maintenance expense by the Modern Era for leaders with a big army?

1 + 1/7 = 1.142857

Expected| Actual
100|193
200|426
300|678
400|941
500|1215
600|1496
700|1785
800|2079
900|2378
1000|2683

I think a decent starting point to compensate for this is doubling lategame maintenance across the board, for both units and buildings. It will bring the expected maintenance up close to the actual values once that exponent is gone.

The unusual maintenance was seen on marathon speeds, but map size is the main factor, since large maps have more units and more maintenance. It just happens to be that most marathon games play on large-huge maps (correlation vs causality). This is also why militaristic AIs get crippled by their armies, from this unknown exponential factor.


===============

Edit: Thinking about this some more, this is probably why some players reported excessive lategame gold, if they were peaceful and built few units.

On a side note... we are sooooo off topic!

 

[mystikx21]

We are. But it's a really important question. It's likely why players would complain about unit upkeep and gold.

If the inflation modifier is basically gone, I would be fine upping unit upkeep by some factor (not 2x as that cripples map size and large AIs, more like 1.25/1.2 for units. Units are also already expensive. 19 for infantry, 13 for artillery and rifles vs maybe 6 for a school? Guns are expensive but 3-6x butter?). Buildings could be increased by 2x and I wouldn't really care except for tier 1. Should increase more along the tree. Stadiums cost same as colosseums right now. Science buildings scaled reasonably well. I could see bumping them only 1.5.

I routinely can have ~80 units in the industrial-modern era, not counting free garrisons or workers. Figuring on 12 per in industrial and 18 per modern (about 50 of that is likely ships or planes or MGs which are all cheaper while the rest is artillery and infantry and tanks). Something like that. I also think we could balance this by reducing gold somewhere too rather than replicating the inflation by increasing base costs throughout (another option is to increase rush buy modifiers).

 

[Zaldron]

It turns out they labelled the variables badly. They called the first variable a "multiplier" (0 * n = 0) when it is actually a modifier of the multiplier (1+0 * n = 1).

Hmm... this makes it more complex to nullify vanilla maintenance costs. I'll have to think about the function.

In order for dFinalCost to not scale with time all we need is for fExponentialFactor to be close to 1. We can get close by making the GC.getUNIT_MAINTENANCE_GAME_EXPONENT_DIVISOR()); value large, say 1048576 (2 ^ 20).