Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

[Toffer90]

That would mean that the AI should be more complex to be able deal with the variation in game parameters. Optimizing the AI for one set of parameters is hard enough, optimizing it for multiple sets of parameters is even harder. Since programming and balancing the AI is probably the hardest part of the game, I think that going with your proposal would be a massive mistake.

I don't think the AI code care how fast units, buildings, and techs are gained at all, by that I mean that it isn't optimized for it in any way whatsoever currently, so it wouldn't matter if those parameters change. I might be wrong, perhaps there is AI code that creates strategies that depend on techs/units/buildings coming into play slowly enough or something like that. That a war strategy would fail if the army is created too fast or some such. Gamespeed also make such changes (does it for everyone, not only AI) and I don't see that as being a huge mistake or that it breaks the AI in any way, so why should it destabilize the AI when it is applied to AI and not human player?

 

[raxo2222]

I made excel calculator to show difference between this:
[Cumulative Tech Modifier] = ( iResearchPercent WorldInfo ) x ( iResearchPercent HandicapInfo )

and this:
[Cumulative Tech Modifier] = ( iResearchPercent WorldInfo ) + ( iResearchPercent HandicapInfo ) (effect of WorldInfo depends on HandicapInfo here)

It seems balance won't be hit hard by such change.
Cumulative Tech Modifier is only place where addition happens.
Only corner cases will get hit relatively hard.

Also reducing modifier X of A by Y% will be fully predictable - all settings using A will have reduced cost of X by Y% too.
For example reducing Prehistoric icostruct from 70 to 50 will mean multiplied building costs by 5/7 no matter what other setting you use as long as you are playing in Prehistoric era.

This is why I wanted property pseudobuildings, civics and traits act on base productivity like this.
Base*property pseudobuildings*civics*traits*(sum of other % modifiers)
Or at least like this:
Base*property pseudobuildings*(sum of other % modifiers)

 

[Toffer90]

True that starting era means next to nothing. I'll have to look at the difference between them and where they are applied exactly. It might just be that iResearchPercent should be doing AS iTechCostModifier is doing instead of what it is doing now, which is worthless and at that point the main thing is keeping naming conventions and the functioning behind them from one type of xml to the next the same.

Way back, I advocated the removal of iResearchPercent from era XML, so I wouldn't be against the tag reduction you suggest; but perhaps it is here prudent to stop and consider what we would need to balance a later than prehistoric start...

Would it be necessary to reduce research cost across the board if a player chose to start the game in modern time. Everything would certainly right away seem real stagnant at the start until you get enough cities up and running without the current iResearchPercent tag functionality... However it would later in the game make progress go real quick when you manage to catch up.

Perhaps it would be better if we implemented some kind of starting-boost leader trait that gets weaker and weaker and finally disappears after so-so many turns?

Do we even want to support a later than prehistoric start?

 

[Thunderbrd]

Way back, I advocated the removal of iResearchPercent from era XML, so I wouldn't be against the tag reduction you suggest; but perhaps it is here prudent to stop and consider what we would need to balance a later than prehistoric start...

Would it be necessary to reduce research cost across the board if a player chose to start the game in modern time. Everything would certainly right away seem real stagnant at the start until you get enough cities up and running without the current iResearchPercent tag functionality... However it would later in the game make progress go real quick when you manage to catch up.

Perhaps it would be better if we implemented some kind of starting-boost leader trait that gets weaker and weaker and finally disappears after so-so many turns?

Do we even want to support a later than prehistoric start?

Yes but the gamestart could include some merchants to help. I don't think it would be too stagnated at that point.

 

[Thunderbrd]

Haha, true that is a good point, but let's be realistic, that is the way it is done in almost every game ever designed, difficulty changing the envioronment/NPC/AI stats instead of the human player stats.
I remember a sort of disillusionment from my early childhood when I understood that this was the case in all strategy games, I actually though the AI was designed so that changing the difficulty was the same as changing the AI IQ (making it smarter or dumber), it is however very rare for game designers to write several different AI codes dedicated to the different difficulties.

That would mean that the AI should be more complex to be able deal with the variation in game parameters. Optimizing the AI for one set of parameters is hard enough, optimizing it for multiple sets of parameters is even harder. Since programming and balancing the AI is probably the hardest part of the game, I think that going with your proposal would be a massive mistake.

I don't think the AI code care how fast units, buildings, and techs are gained at all, by that I mean that it isn't optimized for it in any way whatsoever currently, so it wouldn't matter if those parameters change. I might be wrong, perhaps there is AI code that creates strategies that depend on techs/units/buildings coming into play slowly enough or something like that. That a war strategy would fail if the army is created too fast or some such. Gamespeed also make such changes (does it for everyone, not only AI) and I don't see that as being a huge mistake or that it breaks the AI in any way, so why should it destabilize the AI when it is applied to AI and not human player?

It does make it harder for us to understand what the AI is experiencing in play though. There ARE some adjustments to strategy that the AI will take when certain things take more turns or less turns to build, but this isn't really the concern so much as being able to make assumptions based on what you can expect the AI is experiencing.

I've gotta side with the removal of the use of the AI adjustment tags. It does seem redundant now and we'll have what I think is a better way to go there. That said, I admit valid arguments exist on both sides.

 

[Thunderbrd]

I'm running out of time to do further work on this for today and tomorrow is a wash. I'll pick it back up on thursday. I've made changes here but I'm having a hard time with the established values and possibly with the calculations. I have to run a debug to see how the numbers get to where they are where I'm seeing them.

Does anyone know what good turn count expectations for some first round selections would be on Normal speed, Noble difficulty, Standard map size? What, on that setting, is a good expected amount of turn to research the first technology on the same settings?

 

[raxo2222]

If production cost is going to be set like this:

    iProductionNeeded = GC.getBuildingInfo(eBuilding).getProductionCost();

    iProductionNeeded *= GC.getDefineINT("BUILDING_PRODUCTION_PERCENT")
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getHandicapInfo(getHandicapType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getEraInfo(getCurrentEra()).getConstructPercent();
    iProductionNeeded /= 100;

Final cost = Defined iCost*(BUILDING_PRODUCTION_PERCENT/100)*(Game Speed Modifier/100)*(Handicap Modifier/100)*(Era Modifier/100)
Assuming Game Speed and Era modifiers at 100.
Nightmare - 225
Noble - 100

Setting BUILDING_PRODUCTION_PERCENT to 50 will yield following numbers:
Nightmare - 113
Noble - 50

If we wanted to have Nightmare costs elevated by 50%
Nightmare - 150
Noble - 67
This means BUILDING_PRODUCTION_PERCENT set to 67%
----------------------------------------------------------------------------------------------------
Just keep in mind, that <iBeelineStingsTechCostModifier> and <iTechCostModifier> in EraInfo have base set on 0.
Below 0 - cheaper - above 0 - more expensive in their case.
There are two constants: one in TechDiffusion Global Defines with ground level of 0.
<DefineName>TECH_COST_MODIFIER</DefineName>
<iDefineIntVal>0</iDefineIntVal>
Negative - all techs heaper, positive - all techs more expensive.

Other is in GlobalDefines.
<DefineName>TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER</DefineName>
<iDefineIntVal>100</iDefineIntVal>
It seem like its neutral value basically doing nothing.


Tech cost calculation would look like this (changed that so it reflect production cost equation):
Final Cost = Defined iCost*[( TECH_COST_MODIFIER+100)/100]*(TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER/100)*(Game Speed Modifier /100)*(Handicap Modifier/100)*[(TechCostModifier Era+100)/100]*(Research Era Modifier/100)*[(Beeline Stings+100)/100]*(Map Size Modifier/100)
Blue are constants or unused, Green is optional and modifies past era costs, Red is active part.

In your code can add 100 to TECH_COST_Modifier, TechCostModifier in era info and beeline stings variables before using them in equation, so equation itself is cleaner.
There would be 8 pairs of "Multiply by modifier" and "Divide by 100"

For comparison here is production cost equation.
Final cost = Defined iCost*(BUILDING_PRODUCTION_PERCENT/100)*(Game Speed Modifier/100)*(Handicap Modifier/100)*(Era Modifier/100)

Adding Size modifier to Handicap modifier was like adding apples to oranges.
Same with adding BUILDING_PRODUCTION_MODIFIER to Handicap and Era modifiers.
It was like adding width to length and for production costs to height too.

End of story: Techs are coming too fast relatively to buildings BECAUSE BUILDING/UNIT COST IS TOO HIGH!
-----------------------------------------------------------------------
Better to have bit too low building/units costs than too high.
On too low side you can build all buildings and more units than you need or even set some cities to produce gold/research/espionage/culture from production.
This means seeded up research, and you can unlock more buildings/units faster.
There is more gold for units and espionage is boosted up too.

Too high building costs will cause some buildings to be plain useless, and your resource/property control infrastructure may suffer due to obsoletions.

I'll list some consequences.
As for resource infrastructure obsoletions:
Lets say it has chain of Hut, Workshop, Factory, and Megafactory (pepper additions for late Modern era and beyond)
Huts shouldn't get obsolete before you unlock Factories.
Workshops shouldn't get obsolete before you unlock Megafactories.
Factories get obsoleted by various techs somewhere later. Hopefully not too soon

As for property management obsoletions:
nth generation of buildings/units shouldn't get obsoleted before (n+3)th generation gets unlocked.
This is to protect hardcore beeliners, and those who play with upscaled costs on higher difficulties.
It is related to resource infrastructure, as suddenly producer may get obsoleted and you are out of resource for this unit or that building.

 

[JosEPh_II]

End of story: Techs are coming too fast relatively to buildings BECAUSE BUILDING/UNIT COST IS TOO HIGH!

Thank you Raxo. You can express it while I can not.

Lets say it has chain of Hut, Workshop, Factory, and Megafactory (pepper additions for late Modern era and beyond)
Huts shouldn't get obsolete before you unlock Factories.
Workshops shouldn't get obsolete before you unlock Megafactories.

Exactly.

And here is another sore subject, all the LE units do not need a ForceObsolete tag. They all but the last in line have ReplacementBuildings. Remove the Obsolete tags and the progression does not create a loophole were a player will only build the lowest level unit for ever. It might if the Building/unit cost stay too high. But even that is not what is showing up in game play.

Finally Upgrade costs at 50% of production cost is "reasonable" at all diff levels. And if the Building/Unit costs don't come down are an absolute must.

 

[raxo2222]

And here is another sore subject, all the LE units do not need a ForceObsolete tag. They all but the last in line have ReplacementBuildings. Remove the Obsolete tags and the progression does not create a loophole were a player will only build the lowest level unit for ever. It might if the Building/unit cost stay too high. But even that is not what is showing up in game play.

Yeah, LE (and other property control) units especially later ones have impressive demand tree, same with buildings.
This means small cities will spend long time getting such units, unless you send 20 or so units along with settler.

My settlers were accompanied by 3 workers, 5 - 10 Crime Control units, 5 - 10 Disease Control units and 5 - 10 Education Control, units somewhere in Classical/Medieval/Renaissance on my space playtrough (there wouldn't be much difference if AI existed in that case) - most likely I would pick some 10 or so military units too.
Alternatively I could be alone on continent separated by ocean.
All my property control units were most modern ones.

Without ForceObsolete your small city on island in middle of ocean would pretty quickly be capable of building lowest tier property control units, if you don't bring them with settler, workers and military.
You can see here, that producing stack of 20 - 40 units for new city may be hard task if unit production cost is too high.

By the way even if said loophole was abused by more creative players (like those, who would go for state druidism//shamanism and build buildings, that block unhealth from all buildings even from property pseudobuildings, yep this one exists), but it was changed on SVN 9885:

Added tags in PromotionInfos MinEraType and MaxEraType which enforce that the promotions cannot be taken by units trained in eras earlier than the minimum era or beyond maximum era.

For example unit X got unlocked in Prehistoric era.
It can't take promotion Y, that got unlocked in Medieval units, even though it could take earlier promotions on Y promotion line.

ForceObsolete wouln't be that disruptive, if it was much easier to keep eye on your resource/property infrastructure, that is faster production and GUI showing your missing resources (unlocked, but not produced/imported) and missing buildings for property infrastructure
Even with that small distant cities would be in trouble unless you bring a lot of units for example 5 Crime, 5 Disease and 5 Education control units.
On other hand if you can't make 10 - 30 unit stack for variety of reasons ForceObsolete is annoyance.
But that tag most likely is obsolete, as units can be restricted to certain promotions by era (or something like that)

 

[Thunderbrd]

If I go back to all modifiers being multiplicative to each other than the same should be done for research. We'll just have to do that and then see where we're at then.

Tests show that any attempt to revert the tech costs back to the previous multiplicative method upsets the calculations too much to pull off any semblence of the balance we have. What I'm going to do is revert all the attempts to address the problem with difficulty not scaling building and unit costs. I'll just drop them by about 20% overall and I'll just leave it from there in the mess its in. That's the only fast way to get us back to where everyone was happy.

 

[Thunderbrd]

all the LE units do not need a ForceObsolete tag.

None are using one at this time.

 

[Thunderbrd]

Thank you Raxo. You can express it while I can not.

If you felt that overall they were too high, why did you not reduce the overall global modifier for them? This was your domain to work with. I guess its easier to ***** about someone else's work than it is to do what you can to dial it in to an accurate balance when that's your job in the first place. Much more useful to start getting leverage at getting someone else to look bad.

 

[raxo2222]

Tests show that any attempt to revert the tech costs back to the previous multiplicative method upsets the calculations too much to pull off any semblence of the balance we have. What I'm going to do is revert all the attempts to address the problem with difficulty not scaling building and unit costs. I'll just drop them by about 20% overall and I'll just leave it from there in the mess its in. That's the only fast way to get us back to where everyone was happy.

Was it something like this?
Final Cost = Defined iCost*[( TECH_COST_MODIFIER+100)/100]*(TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER/100)*(Game Speed Modifier /100)*(Handicap Modifier/100)*[(TechCostModifier Era+100)/100]*(Research Era Modifier/100)*[(Beeline Stings+100)/100]*(Map Size Modifier/100)

This one is for production, where modifiers act as should act.

    iProductionNeeded = GC.getBuildingInfo(eBuilding).getProductionCost();

    iProductionNeeded *= GC.getDefineINT("BUILDING_PRODUCTION_PERCENT")
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getHandicapInfo(getHandicapType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getEraInfo(getCurrentEra()).getConstructPercent();
    iProductionNeeded /= 100;

It would look like that but with 8 pairs:

Beeline Stings += 100
TechCostModifier Era += 100
TECH_COST_MODIFIER += 100

    TechCost = Defined iCost

    TechCost *= TECH_COST_MODIFIER - tech diffusion constant
    TechCost /= 100;

    TechCost *= TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER - global defines constant
    TechCost /= 100;

    TechCost *= Game Speed Modifier
    TechCost /= 100;

    TechCost *= Handicap Modifier
    TechCost /= 100;

    TechCost *= TechCostModifier Era
    TechCost /= 100;

    TechCost *= Research Era Modifier - unused - set to 100 for all eras
    TechCost /= 100;

    TechCost *= Beeline Stings - activated with game option and affects past techs only
    TechCost /= 100;

    TechCost *= Map Size Modifier
    TechCost /= 100;

There is not much difference from it:
[Tech Cost] = ( iCost TechInfo ) x ( TECH_COST_MODIFIER ) x ( iTechCostModifier EraInfo, depends on what era the tech is in ) x [( iResearchPercent WorldInfo ) + ( iResearchPercent EraInfo ) + ( iResearchPercent HandicapInfo ) + ( iBeelineStingsTechCostModifier EraInfo )] x ( iResearchPercent GamespeedInfo ) x ( TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER )

Without Beeline stings option and since EraInfo is set to 100% everywhere we have something like that:
[Tech Cost] = ( iCost TechInfo ) x ( TECH_COST_MODIFIER ) x ( iTechCostModifier EraInfo, depends on what era the tech is in ) x [( iResearchPercent WorldInfo ) + ( iResearchPercent HandicapInfo ) ] x ( iResearchPercent GamespeedInfo ) x ( TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER )

Maybe you failed to adjust iBeelineStingsTechCostModifier EraInfo, TechCostModifier Erainfo and TECH_COST_MODIFIER by 100?
In my XML calculator few post earlier research costs didn't strayed too far except in extremes like Duel/Nightmare, Duel/Settler, Gigantic/Nightmare and Gigantic/Settler.

Spoiler :

Basically this component: [( iResearchPercent WorldInfo ) + ( iResearchPercent EraInfo ) + ( iResearchPercent HandicapInfo ) + ( iBeelineStingsTechCostModifier EraInfo )]
[( iResearchPercent WorldInfo) x ( iResearchPercent EraInfo ) x ( iResearchPercent HandicapInfo )x ( iBeelineStingsTechCostModifier EraInfo )]

If you felt that overall they were too high, why did you not reduce the overall global modifier for them? This was your domain to work with. I guess its easier to ***** about someone else's work than it is to do what you can to dial it in to an accurate balance when that's your job in the first place. Much more useful to start getting leverage at getting someone else to look bad.

Reducing global modifier doesn't work in way you except - reducing it to 0 reduces building costs to 50%, if and only if two other modifiers are at 100.
It would reduce costs by different percentage, if Handicap and Era components would be different, as you used essentially their sum reduced by 300 (and multiplied by -1 if modifier became negative) for further processing - essentially you are using handicapGLOBAL_PRODUCTIONEra modifier.

Similarly for Techs you aren't using three modifiers independently - Instead of it you are using worlderabeeline modifier in further processing, and this is different animal.

 

[Toffer90]

Oh dear. I'm not playing it right now, but I had started a game ON 9873. I had later updated my local version to 9890 mid-game...

Joseph can you explain a bit what will "break"? I have only noticed that Enforcers are missing their model, which isn't a big deal for me.

He's talking about unit and building cost being "different", and especially on difficulties other than Noble.
It is "different" enough to be something that must be addressed before v38 is released.

 

[Thunderbrd]

Was it something like this?
Final Cost = Defined iCost*[( TECH_COST_MODIFIER+100)/100]*(TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER/100)*(Game Speed Modifier /100)*(Handicap Modifier/100)*[(TechCostModifier Era+100)/100]*(Research Era Modifier/100)*[(Beeline Stings+100)/100]*(Map Size Modifier/100)

This one is for production, where modifiers act as should act.

    iProductionNeeded = GC.getBuildingInfo(eBuilding).getProductionCost();

    iProductionNeeded *= GC.getDefineINT("BUILDING_PRODUCTION_PERCENT")
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getHandicapInfo(getHandicapType()).getConstructPercent();
    iProductionNeeded /= 100;

    iProductionNeeded *= GC.getEraInfo(getCurrentEra()).getConstructPercent();
    iProductionNeeded /= 100;

It would look like that but with 8 pairs:

Beeline Stings += 100
TechCostModifier Era += 100
TECH_COST_MODIFIER += 100

    TechCost = Defined iCost

    TechCost *= TECH_COST_MODIFIER - tech diffusion constant
    TechCost /= 100;

    TechCost *= TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER - global defines constant
    TechCost /= 100;

    TechCost *= Game Speed Modifier
    TechCost /= 100;

    TechCost *= Handicap Modifier
    TechCost /= 100;

    TechCost *= TechCostModifier Era
    TechCost /= 100;

    TechCost *= Research Era Modifier - unused - set to 100 for all eras
    TechCost /= 100;

    TechCost *= Beeline Stings - activated with game option and affects past techs only
    TechCost /= 100;

    TechCost *= Map Size Modifier
    TechCost /= 100;

There is not much difference from it:
[Tech Cost] = ( iCost TechInfo ) x ( TECH_COST_MODIFIER ) x ( iTechCostModifier EraInfo, depends on what era the tech is in ) x [( iResearchPercent WorldInfo ) + ( iResearchPercent EraInfo ) + ( iResearchPercent HandicapInfo ) + ( iBeelineStingsTechCostModifier EraInfo )] x ( iResearchPercent GamespeedInfo ) x ( TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER )

Without Beeline stings option and since EraInfo is set to 100% everywhere we have something like that:
[Tech Cost] = ( iCost TechInfo ) x ( TECH_COST_MODIFIER ) x ( iTechCostModifier EraInfo, depends on what era the tech is in ) x [( iResearchPercent WorldInfo ) + ( iResearchPercent HandicapInfo ) ] x ( iResearchPercent GamespeedInfo ) x ( TECH_COST_EXTRA_TEAM_MEMBER_MODIFIER )

Maybe you failed to adjust iBeelineStingsTechCostModifier EraInfo, TechCostModifier Erainfo and TECH_COST_MODIFIER by 100?
In my XML calculator few post earlier research costs didn't strayed too far except in extremes like Duel/Nightmare, Duel/Settler, Gigantic/Nightmare and Gigantic/Settler.

Basically this component: [( iResearchPercent WorldInfo ) + ( iResearchPercent EraInfo ) + ( iResearchPercent HandicapInfo ) + ( iBeelineStingsTechCostModifier EraInfo )]
[( iResearchPercent WorldInfo) x ( iResearchPercent EraInfo ) x ( iResearchPercent HandicapInfo )x ( iBeelineStingsTechCostModifier EraInfo )]



Reducing global modifier doesn't work in way you except - reducing it to 0 reduces building costs to 50%, if and only if two other modifiers are at 100.
It would reduce costs by different percentage, if Handicap and Era components would be different, as you used essentially their sum reduced by 300 (and multiplied by -1 if modifier became negative) for further processing - essentially you are using handicapGLOBAL_PRODUCTIONEra modifier.

Similarly for Techs you aren't using three modifiers independently - Instead of it you are using worlderabeeline modifier in further processing, and this is different animal.

You realise that at this time I'm going back to fully multiplicative modifiers right? Its how it was before being tampered with.

 

[Singularity125]

He's talking about unit and building cost being "different", and especially on difficulties other than Noble.
It is "different" enough to be something that must be addressed before v38 is released.

Oh ok, gotcha. Sorry I posted in the wrong thread.
Perhaps I will wait to pick it back up until v38. I kind of wanted to use a scenario map with space terrain anyway.

 

[raxo2222]

You realise that at this time I'm going back to fully multiplicative modifiers right? Its how it was before being tampered with.

Oh I misread your post and thought you are just reverting changes for production modifiers, that happened this week.

What I said was for showing example of fully multiplicative modifiers for techs and production.

Now I'm unsure what you are going to do at the end:
Reverting all changes to production costs from this week including removal of handicap production modifiers, or reverting much earlier change to tech costs, where Map Size, Era and some other modifiers are added to each other.

 

[Thunderbrd]

Oh I misread your post and thought you are just reverting changes for production modifiers, that happened this week.

What I said was for showing example of fully multiplicative modifiers for techs and production.

Now I'm unsure what you are going to do at the end:
Reverting all changes to production costs from this week including removal of handicap production modifiers, or reverting much earlier change to tech costs, where Map Size, Era and some other modifiers are added to each other.

Reverting all. Then reducing global 20%.

As I tried to explain earlier, if I go back and correct the production and training modifiers to work in a completely multiplicative procession, then I should probably do that for the tech cost modifiers. Problem is, if I do that then I throw everything out of whack and the effort and time that has gone into making the game balanced to the calendar at all will have been a complete waste. Correcting it will take months, not days and the release would be greatly delayed. In fact, it appears adjusting anything will upset that balance at this time.

So my attempt to add a set of game difficulty modifiers to production and training is hopelessly incapable of working to provide a quick fix to the complaints of those on easier settings because it will then create complaints from those on harder settings.

This means that, although we are getting a pretty good result from the numbers we've set, with the technology costs being influenced by game difficulty but the production costs NOT being influenced by game difficulty, we have a very tough situation to uproot and refigure to get back to the balance we're at AND achieve a fair similarity between various game difficulty settings in the ratio between technology costs and construction costs.

AKA, we're geared and balanced for harder setting players in v38 and that's that and there IS no quick fix. Once I revert what I've done at least. I may leave the new tags partially in place, just not applied to the formulas so there's no chance of corrupting the tenuous sense of perfection we had at this point. There were some general complaints about 'things being too expensive overall' and the way to address that is to adjust the global, which will have a totally multiplicative effect once the formula has been reverted.

We'll try address the underlying problem later when we are not looking at the precipice of a release.

 

[raxo2222]

Flattening tech cost modifiers for maps smaller than Standard and difficulties easier than Noble should help achieve balance in that zone.

Here is my excel voodoo showing how Map Size and Handicap affect each other.
There is also tech cost calculation (Base Tech Cost, Cumulative Tech Cost and Tech Cost are cut in picture)
Research Era Info here is effectively unused, and Beeline modifier affects cost of past techs depending on handicap and map size modifiers.

Spoiler :

This can be tested after release.
What speed/handicap settings you were testing, Thunder?

 

[Toffer90]

Flattening tech cost modifiers for maps smaller than Standard and difficulties easier than Noble should help achieve balance in that zone.

The map size research modifier is planned to be removed completely, this was discussed and concluded somewhere on the forum 3-5 days ago.
The iResearchpercent in era infos is also planned to be removed and the iTechCostModifier in era infos will most likely be renamed to iResearchPercent for consistency.
Difficulty xml is planned to be keept the way it was a month ago afaik (no iTrain & iContruct modifiers) for v38 release.
After the release the iTrain and Iconstruct will be reimplemented and since they add to the difficulties it is only reasonable to reduce the incrment steps of iResarchPercent and have iTrain and iConstruct be the same as the iResarchPercent.

You are incredibly curious about mod developments, that's why I'm briefing you now with the info I believe is correct atm (plans change and I'm not always privy to know about them before they do). So that you can calm a bit down.... or not.