getting this again after last 2 updates:
[52932.734] info type 'ATTACHABLE_CHIMNEYSMOKE' not found, Current XML file is: modules\Natural_Wonders\Reef_Shark_CIV4SpawnInfos.xml
[53000.047] info type 'ATTACHABLE_CHIMNEYSMOKE' not found, Current XML file is: modules\Natural_Wonders\Reef_Shark_CIV4SpawnInfos.xml
[53194.969] info type 'ATTACHABLE_CHIMNEYSMOKE' not found, Current XML file is: modules\Natural_Wonders\Reef_Shark_CIV4SpawnInfos.xml
[53749.859] info type 'ATTACHABLE_CHIMNEYSMOKE' not found, Current XML file is: modules\Natural_Wonders\Reef_Shark_CIV4SpawnInfos.xml
[53986.688] info type 'ATTACHABLE_CHIMNEYSMOKE' not found, Current XML file is: modules\Natural_Wonders\Reef_Shark_CIV4SpawnInfos.xml
I'm getting this too and don't know how we ever corrected it in the first place. I'm looking into it again.
When I try to Update the SVN I get a "checksum" Error in Red. I have done the recommended Clean up that the SVN asked. But it says now that the pristine files are now corrupt. So I have to re- d/l the whole svn files.
That CAN happen for unknown reasons, whenever updating to earlier revisions and then updating later - basically jumping around. There's likely some small bugs in Tortoise on that matter.
As to the PM's and not getting them, I closed the conversation on my end. You will need to start a new PM. Or not.
rev 9767. Just need to know why you were reducing the progression on iTechCostModifier. I'm not thinking its suspicious - just wondering what prompted you to make that change. It ultimately caused the later stages of the game to go way out of balance in the production to technology progress ratio, which ended up leading to the complaints that it was getting harder and harder to keep up with units and buildings as the techs began to fly by. I was thinking you might have made this change to help the tech progression rates match better to the dates, in which case it was a reasonable adjustment but since the production factors didn't scale along with it, we ended up out of a frying pan and into a fire. When I later adjusted the construction scaling 2 months later, it was more apparent why that had become necessary when seeing the slashing that was done to tech costs as the eras progressed.
I'm not trying to audit your work, so much as was trying to understand the balance factors and the course of the changes they've made and the reasons for some of them. Once the calculations were corrected, it seems like we're running fairly well. I have no problem admitting my own mistakes there.
I do have a question about the removal of the BBAI iTechCost Modifier though. What exactly was done? Was the Modifier just removed from the file it was in? Was the Modifier set to 0 before it's removal? Was the BBAI code for that Modifier changed? How it was done will have a big impact.
As stated previously:
I stopped the use of the era tag iTechCostModifier and changed the previously unused era tag, iResearchPercent, to work like the construction and build percent tags and to operate off the current era rather than the starting era,
The global variable that influences research was also moved and renamed slightly (so that it would be in the same globalmodifiers.xml file right next to the train and construction globals.) But ultimately, the numbers are all the same as they were before I messed with the research calculation in this last pre-v38 preparation push.
The amount that was in iTechCostModifier was converted over to the iResearchPercent tag, which operates on a base of 100 rather than the old one which operated on a base of 0. The iResearchPercent tag was at 100 across the board and had thus not had any effect on the calculation so just adding the iTechCostModifier amount into that tag was enough once I had changed iResearchPercent to stop operating on the starting era and start operating on the current era instead. Thus the formula doesn't change as I remove the tag. The iTechCostModifier tag is now defunct - it's still there in a sense but it doesn't apply its value to the formula.
BBAI code is not an isolated thing - it blends into the rest of the tapestry of the coding - a tag is just a tag. I can research any problems you may think might exist from such a change that could be processed outside of the tech cost calculation, which to my knowledge is the only place that tag influences. I suppose I didn't look through python files but I'm not thinking there would be anywhere else it would have an effect - it's a pretty simple adjuster.
If you get no
for selling a building then what good is this new option? Help please?
If there's any coding to make there be no gold for selling buildings based on that option then it's working the opposite to the way it should. The idea is that with this option you get gold for disbanding units, so along the same lines, it should also mean you don't normally get gold for disbanding buildings BUT with this option, you still do.
@Toffer90 I thought that we had set things up so that buildings do give SOME gold when disbanded so perhaps we do have a switch somewhere in that formula based on the option that is working opposite to how it should? I dunno... On that side I didn't apply the option to building selling off at all. Just unit disbanding.
New subject, cost of Upgrading a unit. I meant to post these screen shots earlier to explain the reason for dropping it to 50% when the new formula and tag changes were introduced.
Below is a screenie of the upgrade of a slinger to an archer on a Snail, Immortal game, when the changes were 1st made. The upgrade cost was 830 Gold. This is ine of the reasons I said there was a problem. While the cost of building a new Archer was 360 gold.
The next screenshot is the current cost at 100% Upgrade cost, 208Gold for a slinger to archer, again for an archer that costs 360 hammers.
You can see why I did the change. 830 gold was cut down to 417 gold, before all the "fixes". It was untenable to upgrade during that time. Now at 100% it is 208, after multiple fixes.
I understood that personally. I also said, before you did this change:
What the value of gold is in relation to the value of production is not only very circumstantial but it's also much to do with how easy or difficult it is to generate and keep a healthy gold income and reserve. For so long it's been so difficult for us to challenge a player with gold so gold was worth a LOT LESS than production. BUT if the balance is making gold more difficult to maintain then perhaps we can consider lowering unit upgrade costs further than a 1:1 (100%) ratio. Tends to be best if we can keep them the same and just adjust the production costs on units a bit if it seems to expensive. If its too expensive for gold, perhaps its too expensive for production as well? We should consider that angle a bit before jumping into a less than 100 value for UNIT_UPGRADE_COST_PER_PRODUCTION imo. Not ruling it out.
I guess I probably got overly complicated in saying what I meant, which was:
Since we have an error in the production cost calculation at the moment, leave the upgrade cost ratio to production at 100 until that gets sorted out and then we can revisit considerations on changing it from 100, which should at that time depend on how hard it is to maintain a positive gold budget. You may not have realized I assumed you understood that I understood that something was still off in production calculations. Why else were we going through the formula as a team to try and figure out what was incorrect? So I took your change to mean you felt basically units should barely cost anything to upgrade and that they were too expensive even before all this.
To help you understand her position on this, Whisperr was very strongly against this as well and was upset you ignored what I said and felt as if she needed to show not only that we still have a problem with gold income balance, regardless of WHY or WHO is to blame isn't really the point, but that reducing unit upgrade costs is only making that problem worse since unit upgrading is really the main purpose for a player to amass gold anyhow if you don't play with tech trading.
i believe this mini-dump is from trying to build the "inquisitor", i clicked on it and poof CTD . . .
I'll take a look at it immediately.
@Thunderbrd
A python function would have to made in the dll so that python can ask how much difficulty is affecting the building hammer cost.
A CvHandicapInfo.getConstructionPercentage() function.
OK. I'll include it in the next commit today.
No, I can't remember where to do it, I think it is on an improvement but I am not sure.
