Improvement Ideas and Discussion

Improvement Changes:

\Assets\Modules\NaturalWonders\NaturalWonder_CIV4ImprovementInfos.xml:
This file can now be deleted. (Nature Preserve and Marine Preserve has been merged into CIV4ImprovementInfos.xml)

\Assets\XML\Art\CIV4ArtDefines_Feature.xml:
Added Art Defines for City and Arcology Ruins

\Assets\XML\Art\CIV4ArtDefines_Improvement.xml:
Adjusted scaling of a few improvements
Added Art Defines for Mesoamerican Temple, Stone Circle, Pyramids, Asian Temple, abd Ziggarut

\Assets\XML\Civilizations\CIV4TraitInfos.xml
Added Build modifiers for Hamlet, Village, Town and suburb improvements to the Financial trait.
Removed obsolete Scavenging Camp 2 references, added Build modifiers for Hunting Preserve to Nomad Trait.

\Assets\XML\Terrain\CIV4BonusInfos.xml:
Removed 1 commerce yield from Guina Pig Bonus (balance vs hunting camp line improvements)
Turquoise can now appear on Peaks
Removed Lunar terrain as valid locations for Geode and Turquoise (these form w/ water action)

\Assets\XML\Terrain\CIV4FeatureInfos.xml
Rainwater Basin now provides 1 commerce and 10 defence.
Added City Ruins and Arcology Ruins as a Feature. (these should be non-appearing, and will have to be created via python)

\Assets\XML\Text\Terraforming_CIV4GameText.xml:
Removed obsolete Terraform Barren text key.

\Assets\XML\Text\Balanced_CIV4GameText.xml:
\Assets\XML\Text\RoM_GameText_Objects.xml:
\Assets\XML\Text\CIV4GameText_Objects_BTS.xml:
\Assets\XML\Text\Prehistoric_CIV4GameText.xml:
\Assets\XML\Text\CIV4GameTextInfos_Objects.xml:
\Assets\XML\Text\RoM_GameTextInfos_Misc.xml:
\Assets\XML\Text\STONE_AGE_Civilopedia_BTS.xml:
\Assets\XML\Text\STONE_AGE_GameText_Objects_BTS.xml:
\Assets\XML\Text\RoM_GameText_Civilopedia.xml:
Fixed various translations and typos.
Moved all TXT_KEY_IMPROVEMENT, TXT_KEY_BUILD, and TXT_KEY_IMPROVEMENT_PEDIA strings into C2C_Terrain_Addons_CIV4GameText.xml.
Deleted some redundant/unused text keys.

\Assets\XML\Text\Plant_Forest_CIV4GameText.xml
\Assets\XML\Text\Make_Jungle_CIV4GameText.xml:
\Assets\XML\Text\newPlantImprovements_CIV4GameText.xml:
\Assets\XML\Text\GoodyIsland_CIV4GameText.xml:
These files can now be deleted. (all have been merged into C2C_Terrain_Addons_CIV4GameText.xml)

\Assets\Modules\Modifieda4\:
This directory and all its files can now be deleted. The BasicForest and Solar Panel improvements and related data has
now been integrated into the main files.

\Assets\XML\Text\C2C_Terrain_Addons_CIV4GameText.xml:
Fixed various typos and translations
Moved several TXT_KEY_IMPROVEMENT, TXT_KEY_BUILD, and TXT_KEY_IMPROVEMENT_PEDIA strings into this file.
Renamed several improvements.
Fixed several broken or missing pedia links.
Added Text, Build and Pedia keys for several new improvements.

\Assets\XML\Text\zObsolete_CIV4GameText.xml:
Added text keys to newly obsolete improvements.
Removed some build text keys to obsolete build actions.

\Assets\XML\Units\Civ4BuildInfos.xml:
Added Build infos for all new improvements mentioned on chart.
Altered the Featurestruct info for several improvements.
This was done to standardize the time, tech pre-req, and production gain values of removed features,
to include many recent features which were absent (Ancient Forest, Burnt Forest, Bamboo, etc.), and
include new features (City Ruins & Arcology Ruins) for removal from some improvements.

Made all gatherer build that kill the gatherer go obsolete at Sedentary lifestyle if they did no go obsolete prior to that tech.
This change was made in conjunction with allowing Gatherers to make use of the non-kill builds enabled at Sedentary lifestyle.
The effect of this change should allow gathers to still build things, but not die after Sedentary Lifestyle, while your waiting
for enough gold to upgrade them.

Added build actions for existing improvements:
Factory, Manufacturing Complex, Hamlet, Village & Town

Merged all BUILD_BURN_(feature) actions into a single BUILD_BURN_VEGETATION action.
Merged all BUILD_REMOVE_(tree-feature) actions into a single BUILD_REMOVE_VEGETATION action.

Added a BUILD_REMOVE_ROCK_FORM action, removes all rocks form features, requires explosives.

Made BUILD_SCRUB_FALLOUT_RAPIDLY require a higher tech as it was previously Ecology, the same as the regular BUILD_SCRUB_FALLOUT.

\Assets\XML\Units\CIV4UnitInfos.xml:
\Assets\Modules\Alt_Timelines\Steampunk\Units\Worker\SteampunkWorker_CIV4UnitInfos.xml:
\Assets\Modules\Custom_Religions\Voodoo\Voodoo_CIV4UnitInfos.xml:
\Assets\Modules\DancingHoskuld\Captives\Captives_CIV4UnitInfos.xml:
\Assets\Modules\DancingHoskuld\Captives\Captives1_Build_CIV4GameText.xml:
\Assets\Modules\DancingHoskuld\Captives\Captives_CIV4BuildInfos.xml:
\Assets\Modules\ls612\CultureUnits\CultureUnits_CIV4UnitInfos.xml:
\Assets\Modules\ls612\NormalUnits\EarlyUnits\EarlyUnits_CIV4UnitInfos.xml:
\Assets\Modules\Units\Unique\California\California_CIV4UnitInfos.xml:
Added support for new build actions & improvements.

\Assets\Modules\ls612\Traits\ls612_CIV4TraitInfos.xml:
Deleted obsolete reference to Scavenging Camp 2.
Added build modifiers for Hunting Preserve improvement to Nomad...
...It seems I've written this twice, why is the Nomad trait duplicated?

\Assets\Modules\Natural_Wonders\NaturalWonder_CIV4GameText.xml:
Moved all TXT_KEY_IMPROVEMENT, TXT_KEY_BUILD, and TXT_KEY_IMPROVEMENT_PEDIA strings into C2C_Terrain_Addons_CIV4GameText.xml.

\Assets\Modules\Natural_Wonders\NaturalWonder_CIV4ImprovementInfos.xml:
This file can now be deleted, the Nature Preserve has been moved into CIV4ImprovementInfos.xml.

\Assets\XML\Terrain\CIV4ImprovementInfos.xml:

Changes too numerous to detail individually, see the tables posted on pages 7 & 8.

NOTE: I have not added worker support for the Mesoamerican Temple, Asian Temple, Pyramids, Stone Circle, and Ziggurat improvement.
I think these require more discussion before being fully implemented.

You may want to make a code Archive before adding all these changes in.

I am still in the process of testing these, but I'll be busy the next couple of weeks, so I wanted to go ahead and get this posted now
for other people to test as well.

I've update the two tables in this thread to what should be the most recent edits as per the attached files.

Any insights and suggestions would be helpful.

excess health in a city should add a bouns to great people and disease rate or something similar along with excess happiness<>

I updated the attachment file in the previous post in case anyone grabbed it already.

I discovered that attempting to use bValid = 0 for a feature on the ImprovementInfos does not cause that improvement to not be buildable on that particular feature. (For example, disallowing Cottages from being built on Tarpits, etc.) Instead, I had to add that feature to the FeatureStruct of the bulild, require its removal, and set the Prereq tech to very high (Analyze Strings). This effectively allows me to deny the ability to built specific improvements on specific features.

meatball20 said:

excess health in a city should add a bouns to great people and disease rate or something similar along with excess happiness<>

Click to expand...

This thread is for ideas and discussion about Terrain improvements (Mines, Cottages, Quarries, etc) not general improvement ideas. I'd repost your idea in the general ideas and discussions thread.

0100010 said:

I updated the attachment file in the previous post in case anyone grabbed it already.

I discovered that attempting to use bValid = 0 for a feature on the ImprovementInfos does not cause that improvement to not be buildable on that particular feature. (For example, disallowing Cottages from being built on Tarpits, etc.) Instead, I had to add that feature to the FeatureStruct of the bulild, require its removal, and set the Prereq tech to very high (Analyze Strings). This effectively allows me to deny the ability to built specific improvements on specific features.

Click to expand...

There's a placeholder tech that would be better to use for that I think. I'd have to look into it to tell you what it is but it's used on a number of promos.

Thunderbrd said:

There's a placeholder tech that would be better to use for that I think. I'd have to look into it to tell you what it is but it's used on a number of promos.

Click to expand...

Analyze Strings is the old Future Tech it is the correct place as you can never get all of them.

Why was the name of this tech changed? Future Tech means something in all civ versions? It is the tech at the end of the tree which you can research multiple times but can never satisfy as a requirement as there is always one more.

0100010 said:

\Assets\XML\Civilizations\CIV4TraitInfos.xml
Added Build modifiers for Hamlet, Village, Town and suburb improvements to the Financial trait.

Click to expand...

0100010 said:

Added build actions for existing improvements:
Factory, Manufacturing Complex, Hamlet, Village & Town

Click to expand...

There should not be build functions for Hamlet, Village and Town as these can only be built by working the plot via the city. Did we decide that the upgrade was not going to happen this way and workers could build these improvements. It will make the proposed changes to the Great merchant and Great Statesman next to useless. Social Reform I upgrades all cottages to hamlets. Social Reform II upgrades all cottages and hamlets to towns etc. Also build times are always way quicker than upgrade times.

0100010 said:

Made all gatherer build that kill the gatherer go obsolete at Sedentary lifestyle if they did no go obsolete prior to that tech.
This change was made in conjunction with allowing Gatherers to make use of the non-kill builds enabled at Sedentary lifestyle.
The effect of this change should allow gathers to still build things, but not die after Sedentary Lifestyle, while your waiting
for enough gold to upgrade them.

Click to expand...

Will this mean that the 47 turns just spent by the gatherer in building a stone tools workshop on the forested will be wasted and that they will have to start from scratch building the new type of stone tool workshop or did you merge the two types together and just have the one improvement with two build types or was it always one improvement with two build types (I forget)

0100010 said:

Added build modifiers for Hunting Preserve improvement to Nomad...
...It seems I've written this twice, why is the Nomad trait duplicated?

Click to expand...

It may be that there is a mod that changes the Nomad trait. Perhaps based on a game option. This means that you probably could have just gotten round modding the one in core. Doing both will be safe.

Dancing Hoskuld said:

Analyze Strings is the old Future Tech it is the correct place as you can never get all of them.

Why was the name of this tech changed? Future Tech means something in all civ versions? It is the tech at the end of the tree which you can research multiple times but can never satisfy as a requirement as there is always one more.

Click to expand...

Don't know I didnt change the names of any techs. But its tag is TECH_FUTURE (or whatever it was)

There should not be build functions for Hamlet, Village and Town as these can only be built by working the plot via the city. Did we decide that the upgrade was not going to happen this way and workers could build these improvements. It will make the proposed changes to the Great merchant and Great Statesman next to useless. Social Reform I upgrades all cottages to hamlets. Social Reform II upgrades all cottages and hamlets to towns etc. Also build times are always way quicker than upgrade times.

Click to expand...

I was not aware of said plans for the great merchants and statesmen. (great Statesmen don't exist yet though it seems, except in name) With these changes, they can both upgrade and have a direct build.
I'm not opposed to turning off these builds for generic workers, though I would keep the build definitions for them. Perhaps they can one day be assigned to a special worker. There is much more I want to do with these types of improvements, but that will involve building changes for City vicinity checking. That's something for phase II of all this stuff.

Will this mean that the 47 turns just spent by the gatherer in building a stone tools workshop on the forested will be wasted and that they will have to start from scratch building the new type of stone tool workshop or did you merge the two types together and just have the one improvement with two build types or was it always one improvement with two build types (I forget)

Click to expand...

It was always one improvement with two build types, though this could use some more testing to see what happens during this transition. I believe they'll keep working, if began before obtaining the obsoleting tech, but those than began before obtaining the tech will still probably be killed at the end.

It may be that there is a mod that changes the Nomad trait. Perhaps based on a game option. This means that you probably could have just gotten round modding the one in core. Doing both will be safe.

Click to expand...

I'll let someene else do that. I just didn't notice it was the same until writing up the list of changes.

There's a replacement trait set that uses the Focused Traits gameoption.

Gha! I was 75% through doing these changes when I realised I was doing it to a back up version of v32!

NOTE: I have not added worker support for the Mesoamerican Temple, Asian Temple, Pyramids, Stone Circle, and Ziggurat improvement.
I think these require more discussion before being fully implemented.

Click to expand...

One possible way to do these is via additional religious workers, Nahgualism worker for Mesoamerican Temple, Mesopotamism worker for Ziggurat, Druidic worker for Stone circle, Kemetism worker for Pyramids, etc.

Any other ideas?

Well I think Improvements can have a resource prereq (at least roads have), so you could use certain cultures as requirement for those.

Faustmouse said:

Well I think Improvements can have a resource prereq (at least roads have), so you could use certain cultures as requirement for those.

Click to expand...

That was also mentioned in prior discussion.

I've thought of a possible way to prevent regular mines from being able to be placed on mountains, even if a validating bonus is present.

If it is possible to specify peaks as a valid location for specific features, then we would need an invisible 'mountain' feature, that shows up on top of mountains 100% of the time during map generation. For non-mountain mine & quarry improvements we set this feature up as requiring removal with the future_tech prereq making it impossible to remove. For the mountain mine improvements we just ignore the feature and leave it be.

Dancing Hoskuld said:

Gha! I was 75% through doing these changes when I realised I was doing it to a back up version of v32!

Click to expand...

I HATE it when that sort of thing happens! I don't keep around old versions like that but I DO have a multi-player set and a core file set and last night I did something very similar. Programmed an adjustment into one side and another into the other side and they both needed to have been on the one side so it lent itself to just a LITTLE confusion!

@0100010:
Sounds like a simple tag set: bOnPeak and bNotOnPeak would be able to fix your issue in a much cleaner way. I presume that both should be added to Builds AND Improvements right? Or do you think it would be sufficient (you know the current tag list for these better than I do) to only include these on Build Infos?

The most efficient would be better set of flagging variables at the ImprovementInfo level rather than the build level for that kind of allow/disallow stuff. however that requires a broader interpretation of most validity flags from a binary evaluation of true "allow" and false ("default value/not set") to a trinary evaluation of true "allow", false "disallow" and a 3rd default value of "not set". I would not call the present form of the validity flag evaluations for improvements simple or straightforward.

There are some problems with events now that you have changed the improvements. For example the tar pit one.

I have not yet had my coffee yet, but I will fix them when I have.

edit It is not the event infos but the Traits file in the Civilizations folder. It has two instances of BUILD_HUNTING_CAMP but BUILD_HUNTING_CAMP is not defined. I am seeing this in the compressed file you posted also.

Odd. I didn't have any xml complaints. I added BUILD_HUNTING_PRESERVE to the Nomad Traits. Is this what it is supposed to be referring to? (just under BUILD_CAMP)

Ah, on the file in your compressed file they are the BUILD_HUNTING_CAMP not BUILD_HUNTING_PRESERVE

Dancing Hoskuld said:

Ah, on the file in your compressed file they are the BUILD_HUNTING_CAMP not BUILD_HUNTING_PRESERVE

Click to expand...

I must have fixed that afterward and forgot to reinclude the correct version into the archive.

0100010 said:

The most efficient would be better set of flagging variables at the ImprovementInfo level rather than the build level for that kind of allow/disallow stuff. however that requires a broader interpretation of most validity flags from a binary evaluation of true "allow" and false ("default value/not set") to a trinary evaluation of true "allow", false "disallow" and a 3rd default value of "not set". I would not call the present form of the validity flag evaluations for improvements simple or straightforward.

Click to expand...

I'm not sure about how the current form of the validity flag evaluations go there (is this an AIAndy Expression System boolean in use?) but the reason I'd use bOnPeak and bNotOnPeak as two separate tags is to give you exactly what you're talking about with a trinary evaluation. The first would be that the improvement would HAVE to go on a peak while the second would mean the improvement CAN'T go on a peak. If both are false then it would mean it CAN go on a peak as well as elsewhere.

Peaks and hills are unique and must be referred to as such... they aren't just 'features' on the feature list. (Ironically I think they exist on the feature list but they aren't implemented that way here. They represent their own unique layer of the plot, isPeak or isHill. That might be causing some confusion here in the first place.) This is so that we can have a feature on a plot in addition to a Peak or Hill.

Anyhow, you answered my question sufficiently, on the Improvement is where you'd want this. Unfortunately I'm still on a 'new tag freeze' at the moment so I may not be able to do this right away.

Thunderbrd said:

I'm not sure about how the current form of the validity flag evaluations go there (is this an AIAndy Expression System boolean in use?) but the reason I'd use bOnPeak and bNotOnPeak as two separate tags is to give you exactly what you're talking about with a trinary evaluation. The first would be that the improvement would HAVE to go on a peak while the second would mean the improvement CAN'T go on a peak. If both are false then it would mean it CAN go on a peak as well as elsewhere.

Peaks and hills are unique and must be referred to as such... they aren't just 'features' on the feature list. (Ironically I think they exist on the feature list but they aren't implemented that way here. They represent their own unique layer of the plot, isPeak or isHill. That might be causing some confusion here in the first place.) This is so that we can have a feature on a plot in addition to a Peak or Hill.

Anyhow, you answered my question sufficiently, on the Improvement is where you'd want this. Unfortunately I'm still on a 'new tag freeze' at the moment so I may not be able to do this right away.

Click to expand...

Nothing of AIAndy's stuff in use, it still uses all the default tags.

The current (default) validity tags are not simple in that without understanding their precedence order the new tags you are proposed may not work as advertised.

For example in ImprovementInfos, HillsMakesValid, and FreshwaterMakesValid (and a few other tags) override all other conditions. So even if you only included a narrow set of terrains or features marked as valid, the improvement would still be buildable on terrains you did not specify if it was sitting on a hill or on a tile marked as having access to fresh water. (Like how farms can be build on Tundras if and only if they have freshwater, even though Tundras are not listed in its set of valid terrains.) Thus depending on where you put your Peak, NotOnPeak checks, it might just ignore your NotOnPeak flag if it already passed FreshwaterMakesValid, and so on. I dont know what the actual code looks like that evaluates all those things, so I dont know what order it does stuff in. All I am saying is it may not be a straighforward as you are hoping.

IF you want a finer level of control of what improvements are allowed where, we may need to use the more robust bonusInfo valid placement checking, which allows a per terrain, per feature and per terrain+feature combo checks.