@DH: Sorry ... may have not worded it very well since I was rushing to post that.
@Joe: Possible theories:
1) Are you playing Size Matters? I would assume not but IF you are then there COULD be some causes coming from that - not directly related to level or number of promos but specific promo types.
2) Could it be a difference between upgrading a master hunter unit vs a normal hunter unit?
This doesn't strike me as likely due to your level of familiarity.
3) I don't offhand know of any promotions that could do this for an early hunter BUT could the ones that are cheaper to upgrade be getting a promotion (perhaps free from a city?) that is making it cheaper to upgrade them? There is a promo tag that can do this but again I don't off hand know of any promos early hunters like that can get that do use this tag.
4) Oh... wait. lol! Looking at the code directly for upgrade costs I find something VERY interesting... ROFLMAO!
Code:
//ls612: Upgrade price is now dependent on the level of a unit
if (iPrice != 0)
{
iPrice *= std::max(100, (100 + (5 * ((getLevel()) - 4))));
iPrice /= 100;
}
'nuff said. That does explain what you were experiencing and why none of us knew anything about it.
As to whether its a good or bad idea I think is debatable. How ironic is it that at this point I find myself thinking ls612 had a good idea here? lol. If you want that to be an option I'd be happy to make an adjustment there. Actually... I don't care even if you demand its removal as long as nobody else cares... I'd do that for you. But I do kinda see the point in this. I mean, it makes some sense to me that more experienced units take longer to train and thus cost a little more to.
Also, to assuage a concern you've been voicing...
Analysis of the code that determines the cost of the upgrade has revealed 2 interesting global defines that can easily be adjusted to adapt if things really get too far out of whack with increased production costs for units:
Code:
<Define>
<DefineName>BASE_UNIT_UPGRADE_COST</DefineName>
<iDefineIntVal>20</iDefineIntVal>
</Define>
And
Code:
<Define>
<DefineName>UNIT_UPGRADE_COST_PER_PRODUCTION</DefineName>
<iDefineIntVal>200</iDefineIntVal>
</Define>
The basic math for this is:
The base price is 20. (BASE_UNIT_UPGRADE_COST)
The modifier for the price is 'the production cost of the unit it will be after upgrade' minus 'the production cost of the unit it is now'. That modifier is then multiplied by the UNIT_UPGRADE_COST_PER_PRODUCTION then divided by 100.
The modifier at this point is 200% of the difference in production costs between unit A and unit B.
The Modifier is then added into the base price. For AI's its then modified further by difficulty level settings, making it cheaper for them if the handicap for the main player is higher. (I THINK it must be player 0 that sets the 'game's' difficulty setting but it could be the highest of all human players... would need to follow how that gets setup to be sure.)
Basically this gives you the full formula and the tags to adjust it. IMO, this begins to explain why gold costs for upgrades are so dramatically impacted by their production costs. Maybe 150% rather than 200% would be a better modifier? If you take your cities and build gold you can get between 30% and 100% of the city's production converted to gold every round.
Thus many cities can combine to swell the treasury for a massive upgrade event but only one city is usually qualified to train the new replacement units if you want them to be of any quality. And often newly trained units will have more XP than earlier trained one. Given all considerations, one should probably only upgrade units that have seen some serious action while just retraining ones that haven't unless that gets in the way of other more important production goals, which it often does for the city to train new units. Therefore, upgrading with gold is probably a good idea for the majority of cases - but yeah, expensive and getting moreso with more reasonable production costs. If it's too severe, we can back down on that modifier value a bit to address the issue.
Then again, in discussion of goals... it would be nice, imo, if a treasury was rarely capable of just immediately adapting to upgrading all units at all times. Having to make the choice whether to slow down on your research a bit to collect more gold for upgrading has been an enjoyable 'interesting decision' point since Vanilla. This slowdown can be achieved either from taking the slider down or from taking completed cities sitting around building research and converting them to building gold. Either way, it forces some decision making, which is not a bad thing for game design is it? As for the AI, they tend to get such a discount on unit upgrades if you're playing a tougher difficulty level that they usually adapt pretty well due to the reduced cost.
Interesting analysis... back when playing vanilla I often wondered how the AI could upgrade so many of its units as soon as they get a tech that allows the upgrade. Here in C2C it's been sometimes they can right away and sometimes they can't.
Besides... if you're not using gold for keeping a few negative events at bay and for upgrading troops, what are you using gold for? Isn't unit upgrading usually the primary use for gold being in the treasury at all?