I was going to quote a bunch of stuff here and reply with a 'case' but I do understand the frustrations.
I'm pretty certain my math is accurate now. Toffer is also making every point I was going to make and you'd really have to read the math examples closely to understand it. The examples we've given don't add up to the dramatic 'problems' that the original system presented. But the difference in correcting the math certainly does. I get that at the moment, the end result does not appear to be a debug, nor is it an improvement.
And it does make a bit of an incidental bonfire out of the finely measured adaptations that have had things dialed in to near perfection.
But here's the messed up thing... it was dialed in to near perfection on a mechanism where, without a complete understanding of the order in which modifiers were being added, you could never calculate out what you were going to get with the numbers you were using. The change this introduces is to make it possible for you to actually hand calculate the end results of tech costs based on the variables you are working with.
I know that may not seem like much of an advantage when you've had everything perfect and it gets shattered by a change in the machinery. But we're constantly changing things here in various measures on the surface so just how long is our current perfection going to be maintained?
We're about to have a new cost assignment chart for techs and yes, almost all techs are going to have to get a new reassignment of base tech costs anyhow. Mind you, I wasn't planning a dramatic change to the base, just making sure the progression now matched the changes to era shifts on the x grid and the new length of the x grid and so on. And I also get that this doesn't help the immediate now to resolve things either.
I have seen, in game, some comparisons between old and new tech costs and yeah, it's pretty dramatic.
So we have a quandry. And again, let's be clear, this has very little to do directly with the new options. I'll address what was brought up about that in a moment.
To resolve,
I can revert the method:
Pros: We'll still be currently fairly dialed in as to what our end result tech costs should be by all optional factors.
Cons: It's going to make rebalancing after changes start to corrupt that fine tuned balance a real pain. You won't be able to directly calculate the end result without a much more intensive set of calculations based on deep knowledge of the hierarchy of modifiers as established in the code. I CAN deliver that knowledge to the Modder's Documentation so you don't have to be a coder to sort it out. BUT do you want to have to make 10 calculation steps to come to a final conclusion as to what the tech costs should be for various options?
I can leave it as is:
Pros: When you apply a modifier, it applies directly to the base amount the same no matter what the source of the modifier may be. A Gamespeed modifier will apply exactly the same to a base value as a Handicap (game difficulty) modifier. This if you have a base cost of 100 and you apply a 30% modifier (as 130 in the xml) to the Gamespeed and a 50% modifier (as 150 in the xml) to the Handicap, you will get a total of a 180% modifier. This is very easy to then see the final results WILL be a total of 180 research cost for that tech. The current way would require knowing which modifier applies first to find out the end result. We have something like 8 modifier sources... trying to keep the order of those in mind to come up with the end total would be hell. So just how much control do we really have under the old method?
Cons: It will completely bork all game balance we've achieved so far in the rate of tech achievement and require a complete re-evaluation of the modifiers from all sources of modification. To get us back to the balances we were at up to now, some modifiers will seem to be requiring incredibly dramatic numbers. I totally respect the perspective that this adjustment is not helpful if you've become very comfortable working with the numbers the way they were.
I personally lean towards the second because it's the technically 'right' way to go about it. But I also understand the massive frustration (and admission that the current game structure is totally screwed up until a complete rework of a LOT of stuff) that presents. It's too bad it was all setup incorrectly to begin with is all I can say.
As for:
Another side note: With Tech D Off and T-brds new WFL Option ON the WFL acts just like TD Except you don't have to meet any other Civs to get it's benefits! Especially at game start.
It will have a major impact when you fall behind the AI in population right away, sure. So on harder handicaps, it's quite possible you'll get a pretty immediately visible benefit from it. If you're the one leading in population and city counts, however, you'll not get any benefit from it. It does not offer any nation a penalty because penalties are perceived as 'unfun'. So it's all positive and only for nations falling behind the leader in population and/or city count. This is very different to the technical function and purpose of TD but not so much in perception of the system when you are benefiting from it.
However, I recognize the manner in which TD and WFL can have an impact on date matching. For that reason, we might want to add an additional cost modifier for all techs if TD and/or WFL is on if we want to help those systems to compensate to match the dates a little better. If we make them all a little more expensive, that can help to balance out the fact that across the globe, most nations are getting some form of benefit from these handicap systems.
Of course, Tech Trading has a far more dramatic impact on trying to match tech dating as well, so that would also qualify as another massive headache that makes it very difficult for eras after trading is introduced to be balanced against.
I have just been running the XMLValidator program by Koshing over some of the C2C folders, I was trying to find a strangeness in one of my files. I found a whole heap of problems, mostly due to the schema not being pointed to correctly and I will post the fixes for all of them to the SVN shortly. However there were 2 which weren't in mods I have worked on and I am not sure what needs to be fixed.
Code:
eValidating files in the current directory and all subdirectories
F:\Games\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Caveman2Cosmos\Assets\Modules\My_Mods\Neanderthal_Units\Neanderthal_Units_CIV4UnitInfos.xml:2260,6: The 'x-schema:Neanderthal_Units_CIV4UnitSchema.xml:NotUnitAI' element is not declared.
-----------------------------------
F:\Games\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Caveman2Cosmos\Assets\Modules\My_Mods\New_Cultures\XML\Heroes_CIV4UnitInfos.xml:34867,5: The 'x-schema:New_Cultures_CIV4UnitSchema.xml:iBaseFoodChange' element is not declared.
Someone else needs to look at these as fix them, probably after I get the other fixes up there as I did fix some of the Neanderthal_Units files.
All that needs to happen is to update these schemas. This, I think anyone can do right? The schemas in the core are what all schemas should look like... it's just that they get outdated and then checks like this show that there could be real bugs due to letting them get out of date. I'll try to update these ones if someone else hasn't gotten to them by this evening.