Team Projects Committed

It's been a while since I last committed anything to the SVN. I got a bit caught up on developing numerous projects in parallel and when a few of them proved to have some bugs upon completion, I had to take more time than I'd hoped dividing those projects up and testing them individually to figure out where the problems lie. Those issues have been sorted out so I'm now committing quite a few adjustments to the dll.

I'd also have committed each as they were completed except that I had some problems working with the new repository. meh... won't go into details there. Suffice it to say its all sorted out now.

Since the scope of this update is fairly large I figured I'd put a post together for it here.

• Bugfixes: There's a few various bugs I fixed along the way. I may not be recalling them all but they include a display error on Trait GP modifiers, a happiness display issue and other such small things.
  
  
• Reported Subcombats assigned to base unit info for DH to use to finish the SubCombat displays on the unit page of the pedia as per AIAndy's suggested implementation. @DH: let both of us know if you need further assistance in working with the vector on that.
  
  
• Team Project 1: If you're looking through the code I've marked most changes under a comment line //Team Project (x). I'll explain these each here. I'm going to assume y'all know how to refer to the schema to determine the correct syntax to implement the tags with but if anyone needs help with that, just let me know.
  
  Team Project (1) is for DH and CivPlayer8 (Vokarya had requested some of these too I think.) These new tags add Happiness/Unhappiness and Health/Unhealth by specialist and tech as well as giving buildings the ability to modify specialists yields in just the city where the building is built. The tags are as follows:
  
  • For Specialists:
    • TechHappinessTypes: Adds Happiness (+) or Unhappiness (+) to all cities from the specialist type with this tag when the designated tech type is known.
      
      
    • TechHealthTypes: Adds Health (+) or Unhealth (-) to all cities from the specialist type with this tag when the designated tech type is known.
    
    
  • For Buildings:
    • TechHappinessTypes: Indicates techs that cause this building to add the specified volume of Happiness (+) or Unhappiness (-) when known. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      
    • TechHealthTypes: Indicates techs that cause this building to add the specified volume of Health (+) or Unhealth (-) when known. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      
    • TechSpecialistHappiness: Indicates techs that, when this building is present, will, when known, cause ALL specialists to add the specified volume of Happiness (+) or Unhappiness (-). This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      
    • TechSpecialistHealth: Indicates techs that, when this building is present, will, when known, cause ALL specialists to add the specified volume of Health (+) or Unhealth (-). This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      
    • TechSpecialistHappinessType: Indicates techs that, when this building is present, will, when known, cause the SPECIFIED specialist type to add one Happiness. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      I warn that this is established as a boolean rather than a variable integer amount due to finding no appropriate examples of how to properly load such an integer. I realized it was really never a good idea to have just one building have a greater impact on all specialist of even a particular type than an adjustment of 1 anyhow so this was a sufficient solution. I just hope it doesn't cause undue confusion. Since no integer is entered (iModifier does not exist here), it has a fixed result to indicate the tech and the specialist - a +1 Happiness on that specialist from this building and knowledge of the tech. And thus you cannot use this tag to indicate UNhappiness for those specialists.
      
      
    • TechSpecialistHealthType: Indicates techs that, when this building is present, will, when known, cause the SPECIFIED specialist type to add one Health. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      This works as the previous tag, as a boolean rather than a variable integer amount. Since no integer is entered (iModifier does not exist here), it has a fixed result to indicate the tech and the specialist - a +1 Health on that specialist from this building and knowledge of the tech. And thus you cannot use this tag to indicate UNhealth for those specialists.
      
      
    • TechSpecialistUnhappinessType: Indicates techs that, when this building is present, will, when known, cause the SPECIFIED specialist type to add one Unhappiness. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      This works as the two above, as a boolean rather than a variable integer amount. Since no integer is entered (iModifier does not exist here), it has a fixed result to indicate the tech and the specialist - a +1 Unhappiness on that specialist from this building and knowledge of the tech. And thus you cannot use this tag to indicate Happiness for those specialists.
      
      
    • TechSpecialistUnhealthType: Indicates techs that, when this building is present, will, when known, cause the SPECIFIED specialist type to add one Unhealth. This is a local modifier which means that the building's effect only takes place in the city in which it is built.
      
      This works as the three above, as a boolean rather than a variable integer amount. Since no integer is entered (iModifier does not exist here), it has a fixed result to indicate the tech and the specialist - a +1 Unhealth on that specialist from this building and knowledge of the tech. And thus you cannot use this tag to indicate Health for those specialists.
      
      
    • LocalSpecialistYieldChanges: By indicating a specialist type, and a yield volume, you make all local specialists of the defined yield adjust their yields based on the presence of this building.
      
      We've had this on a national level since I have no idea when but the difference here is LOCAL - so it only affects the city in which the building is built. I'd have preferred to rename the tag we already have so that it states National but that could have a lot of unforeseen consequences now that its put in use in a number of places already so I broke some naming convention and simply indicated 'Local' for this tag, which should be the default anyhow.
    
    Let me know if this covers all the bases y'all were looking for. I may have added more than necessary but all the tech/specialist/happiness&health stuff compiles together and I figured if we ever wanted any listed here that weren't requested that it'd be easier to implement them now so that if they ever WERE requested it wouldn't take a huge effort to work through that complexity to weave in more.
  
  
• Team Project 2: A while back, SO asked me for some tags to get merged in from theLadiesOgre's mod project and I had figured there were some among them that would not be necessary in C2C. I stand corrected.
  So these are completed now. I'll still gladly list the ones I just merged in to complete this project here:
  
  For Promotions:
  • iSurvivorChance: Gives a chance for the unit to survive a battle where it would otherwise have died.
    
    
  • iVictoryAdjacentHeal: Gives units with this ability a chance for units adjacent to them to gain the benefit of a round of healing after they win a battle.
    
    
  • iVictoryStackHeal: Gives units with this ability a chance for units in the stack to gain the benefit of a round of healing after they win a battle.
    
    
  • isOneUp: Gives an extra 'life' that can be lost by the unit.
  
  I'm going to ask anyone who wishes to know more about these to refer to theLadiesOgre's documentation on them as I did not spend much time greatly evaluating what his coding would accomplish exactly... just enough to look for things about the coding that would need to be converted for C2C use.
  
  
• Team Project 3: Capture Mechanics tags
  I suggested to do these for DH so he could weave the tag applications into the python that controls the mechanism. I did not convert the capturing code into the dll so these tags, reported by the dll to python from CyUnit:
  
  int captureProbabilityTotal(); which gets the total probability of the unit's capture ability as compiled from all sources onto the specific unit.
  
  and
  
  int captureResistanceTotal(); which gets the total resistance capability of the unit.
  
  Once plugged into the python, this will put XML in full control of determining the odds of capture.
  
  There's a number of tags that can be used to tally into those above reported numbers on units:
  • On Promotions:
    • CaptureProbabilityModifierChange: gives the promotion the ability to enhance or reduce the unit's ability to capture other units.
      
      
    • CaptureResistanceModifierChange: gives the promotion the ability to enhance or reduce the unit's ability to resist being captured when defeated.
    
    
  • On Units:
    • CaptureProbabilityModifier: gives the unit a base enhancement or reduction to the unit's ability to capture other units.
      
      
    • CaptureResistanceModifier: gives the unit a base enhancement or reduction to the unit's ability to resist being captured when defeated.
    
    
  • On Civics:
    • NationalCaptureProbabilityModifier: gives all units an enhancement or reduction to their ability to capture other units.
      
      
    • NationalCaptureResistanceModifier: gives all units an enhancement or reduction to their ability to resist being captured when defeated.
    
    
  • On Buildings:
    • NationalCaptureProbabilityModifier: if building has been built anywhere, this tag gives all units an enhancement or reduction to their ability to capture other units. This effect does stack so be careful with this.
      
      
    • NationalCaptureResistanceModifier: if building has been built anywhere, this tag gives all units an enhancement or reduction to their ability to resist being captured when defeated. This effect does stack so be careful with this.
      
      
    • LocalCaptureProbabilityModifier: if built, this building will enhance or reduce the ability to capture other units for units that are IN this city.
      
      
    • LocalCaptureProbabilityModifier: if built, this building will enhance or reduce the ability to resist being captured when defeated for units that are IN this city.
    
    
  • On Traits:
    • NationalCaptureProbabilityModifier: Units operating under the control of a leader with this trait have an enhanced or reduced ability to capture other units.
      
      
    • NationalCaptureResistanceModifier: Units operating under the control of a leader with this trait have an enhanced or reduced ability to resist capture when defeated.
    
    
  
  
  I realize there's probably some noteworthy oversights here as I'm not sure how these tag effects should work into the capture of civilians. @DH: Let me know if you need anything else tallied and reported (perhaps a total capture resistance for the city itself for its citizens?).
  
  
• Team Project 4: Also dubbed the WorkRateMod. This is pretty much just an audit and ensuing edit of some of ls612's work on worker tags so that the unit types can have these special workrate adjustments without having to give them free promos to do it. @ls612: Search //Team Project (4) or //WorkRateMod - either one will work so you can thoroughly review the adjustments made there... keep in mind that I've gone out of the way to make it compatible with the tags you made and those should eventually be migrated to the new tags and then extracted from use in both xml and code so that we only have the one implementation eating up memory. The two extra tags I did here provide clear examples of how they would have best been implemented originally.
  
  For the team's sake and the sake of anyone trying to update a changelog, the tags introduced here are:
  • For Promotions
    • TerrainWorkRateModifierChangeTypes - adapted from TerrainWorkPercent
    • FeatureWorkRateModifierChangeTypes - adapted from FeatureWorkPercent
    • BuildWorkRateModifierChangeTypes
    • iHillsWorkModifierChange - adapted from iHillsWorkPercent
    • iPeaksWorkModifierChange
    
    
  • For Units
    • TerrainWorkRateModifierTypes
    • FeatureWorkRateModifierTypes
    • BuildWorkRateModifierTypes
    • iHillsWorkModifier
    • iPeaksWorkModifier
  @ls612: I'm sure you've got some questions for me but for the sake of brevity I'll not try to address them in this initial post but rather in response to them as asked. So ask away
  
  
• Team Project 5: Religious Disabling of buildings.
  Some players after this update are going to be gasping in terror at their gold amounts, sudden unhappiness and unhealth, and reduced research. This is not a bug but rather a project in development that's going to take immediate response from the Traits and Civics guys to give these poor players some access to respite.
  
  What's happening here is that buildings that are designated as being of a religion (by either a specified religion as a prereq or with the use of the Religion tag on that building) that is NOT your state religion, basically stop working.
  
  This is setup so that most tags on buildings go unfunctional but others remain in effect. I've got a compiled list (which COULD have infrequent inconsistencies with display and may be somewhat incomplete but should be pretty much on target.) But to display that here is probably going to push the character count on this post too far so I'll post it later.
  
  This effect selectively disables TAG implementations on these Religiously Disabled buildings rather than considering the building completely disabled. This sets us up so that we can clone some tags and create either alternative effects while under religious disabling, and/or clone tags that DO work when under religious disabling as well as when not, tags that look identical in every way (except in xml) to the ones they clone but while the usual tag gets disabled, the clone does not.
  
  Thus, if under religious disabling you want almost all religious buildings to lose any health offering benefits but for a select group of special buildings among them you want those health benefits to merely reduce under religious disabling, that can be done with a cloned tag that creates an alternative effect. And if you want those health benefits to stay entirely on these buildings while health benefits are disabled on others during religious disabling, we would utilize the second cloning method.
  
  @DH, You'll have to do 3 things for me here:
  1) Look through the list of tags that are disabled and those that are not as I've set it up for now and let me know if you want any to sweepingly remain enabled or to be disabled that are currently in what you feel would be the wrong group.
  
  2) Determine what tags you'd want to have an adjusted effect under a religious disabling.
  
  3) Determine what tags you'd want to have cloned so that some religious buildings can use them when religiously disabled while others, as a rule, do not.
  
  @Civics and Traits designer(s)
  Religious Disabling is a status in the nation where the worship of religions that are alternatives to the State Religion is shunned, frowned upon and deterred but not outright illegal. The buildings are there and are allowed to stand but very few worshipers are staffing them and willing to take the heat for having religious views contrary to the state.
  
  That's the middle ground. Then we have the Enabled view of a Free Religious outlook that while may be declaring a religion politically, welcomes the worship of all religions. And on the other side of the pendulum is outright Banning. In the Enabled status, all religious buildings, regardless of state religion, are completely functional. In the Banned status, all religious buildings not of the state building (or all religious buildings period if not on State Religion) are completely disabled outright just as any other building can be in civ.
  
  We allow the player to toggle this decision through traits and civics and the tags to do so, as booleans, give the player ONE reason to be towards one direction or another. The middle ground is Religious Disabling and that is also the default. The following boolean tags can be used to state that with this trait or civic active a reason for weighting towards one end or the other exists:
  
  On both Civics and Traits:
  • bAllReligionsActive: Weights towards all religious buildings being activated (VERY powerful for civs that have collected a lot of religions, particularly a lot of holy cities and their shrines!)
    
    
  • bBansNonStateReligions: Weights towards all non-state religious buildings being disabled outright. If DH and I can strike a good balance on how functional religious buildings are when Religiously Disabled, this can have a pretty powerful effect. At the moment, the majority of religious buildings are so crippled by religious disabling alone that this isn't MUCH of a step towards it (though disabled buildings cannot be built.) But it still counts as a cause that can counter a source of AllReligionsActive.
  
  Yes, I expect a lot of questions to be asked here. Fire away.
  
  
• Team Projects 6-8: I'm out of time for further discussion on these subjects and probably nearly out of space in this initial post so I'll return in a bit to explain these but I'll just say for now that they are all additional tags for Traits. I may just go ahead and describe all those tags in the traits thread.

Ok, that's what I have time for at the moment. I'll return to offer more information and answers to questions.

Team Project 5: Religious Disabling of buildings.

Click to expand...

I hope this does not destroy religion play the way it is now. If it does.......it will be a sad sad day for me.

Worried and very concerned.

JosEPh

Should deepen rather than destroy. The ability to religion hoard is not being taken away, just offered through more careful trait and civic selection.

I don't hoard, I want a tight race with competent AI competition. Always have, always will. Once I have 2-4 religions I'm done with that phase.

But I don't use the Traits Options either. And Civics are............meh......unfortunate and necessary evil.

We shall see, I hope for good things, but I think my days and ways might be numbered.

JosEPh

Even using more than one religion is still hoarding them to some extent.

And the Traits Options should only provide a little more play on that where traits are concerned. It will be important for a trait in the main traits definitions to be invested with the ability to maintain all religious buildings as active as well as to have one (probably a negative) that does the opposite.

As promised, here's the list of building abilities that do and do not continue to function while a building is Religiously Disabled:
There may be some that were overlooked here as I later found some alternative means some tags were being tallied and was not being ultra diligent in making sure to note which were or were not disabled during a religious disabling.

Also: my apologies that this list is not done in xml but rather in dll code tagging. When the list was defined it was done by looking through a list in the coding rather than in the schema. I'll try to get an xml tag list for this done up eventually.

@ALL: Please be looking for display discrepancies between what's stated by this list and what is displayed on the help popups on religiously disabled buildings. I have not done an extremely careful audit here yet - something I'll do once I've got that xml tag list completed.


@dll Coders: Question... the one known oversight in this process is that the list of yields/commerces/happy/unhappy/health/unhealth and perhaps a few more by icon, that shows up next to a building in the building list in a city screen does not apparently filter those displays by the religious disabling. This is purely a display discrepancy and the hoverover help shows things accurately to the best of my knowledge. But I'm a bit concerned for those players who only refer to the shortlist of effects on buildings.

When I looked into how to go about filtering this list, I came to presume that these displays are pulled from 'void CvGameTextMgr::setBuildingActualEffects(CvWStringBuffer &szBuffer, CvWString& szStart, BuildingTypes eBuilding, CvCity* pCity, bool bNewLine)' The complexity of how those tally up was fairly overwhelming and I know there's some bugs in there already. It would take some patience to make sure its fully filtered by this semi-disabling so before setting to further work on that end I wanted to make sure that this is where it would need to be done. Or am I wrong and that short list is derived from python?

Also: there's some religious selection AI that interacts with this feature that I could not get to work properly without a crash. A note was left where I commented out what I'd done there in "int CvPlayerAI::AI_religionValue(ReligionTypes eReligion) const" asking for another pair of eyes to take a look and see if they can spot whatever I may have done wrong there. That segment is intended to improve the AI's religious selection mechanisms and involve consideration of the Religious Disabling feature.

Thunderbrd said:

New Traits tags as of most recent update:
As Mentioned in the other thread:

• iNationalCaptureProbabilityModifier
• iNationalCaptureResistanceModifier

May want to refer to DH on appropriate values to come from the traits direction as these are elements that will tally from a lot of differing sources.

Here's the rest of them:

• EraAdvanceFreeSpecialistType: Specify a specialist type. Every time the owner of the denoted trait advances an era, he gains a free specialist of that type in every city.
  
  
• GoldenAgeonBirthofGreatPeopleType: Specify a type of GP. Every time the owner of the denoted trait has a Great Person birthed of that type, they go into a golden age.
  
  
• iGlobalPopulationgrowthratepercentage: A percentage adjustment (poorly named but done to make it like its clone from Civics) to the growth rate of the population in all the trait owner's cities.
  
  
• iCityStartCulture: A fixed amount of culture given to all founded cities when founded by the owner of the trait.
  
  
• iGlobalAirUnitCapacity: A flat adjustment to the number of air units that can be held in all the cities of the trait owner.
  
  
• iCapitalXPModifier: A % adjustment to the amount of XP given to all units trained in the capital of the owner.
  
  
• iHolyCityofStateReligionXPModifier: A % adjustment to the amount of XP given to all units trained in the Holy City (if possessed) of the trait owner's state religion.
  
  
• iHolyCityofNonStateReligionXPModifier: A % adjustment to the amount of XP given to all units trained in the holy cities of non-state religions that are owned by the trait owner.
  
  
• iBonusPopulationinNewCities: Additional population that starts in cities founded by the trait owner.
  
  
• iMissileRange: Missile units of the Trait owner have an adjustment to their operation ranges as denoted from this tag.
  
  
• iFlightOperationRange: Non-Missile Air units owned by the Trait Owner have an adjustment to their operation ranges as denoted from this tag.
  
  
• iNavalCargoSpace: Naval ships with carrying capacities owned by the Trait owner have an adjustment to their allowed Cargo Space as denoted from this tag.
  
  
• iMissileCargoSpace: Units that carry missiles that are owned by the owner of this Trait have more or less cargo space for those missiles as denoted from this tag.
  
  
• iStateReligionSpreadProbabilityModifier: Units owned by the Trait owner that are attempting to spread their state religion have this much a penalty or bonus to the % chance to successfully enact this mission in a city.
  
  
• iNonStateReligionSpreadProbabilityModifier: Units owned by the Trait owner that are attempting to spread a Non-State religion have this much a penalty or bonus to the % chance to successfully enact this mission in a city.
  
  
• bCitiesStartwithStateReligion: This tag enables the Trait owner to automatically gain the state religion wherever he/she founds a new city.
  
  
• bDraftsonCityCapture: When the armies of the Trait owner conquer a city, the city immediately and freely drafts as many units as it can from its population to support the conquerer as its citizens are immediately put to military service.
  
  
• bFreeSpecialistperWorldWonder: The cities of the Trait owner gain a free specialist for every world wonder that city has built.
  
  
• bFreeSpecialistperNationalWonder: The cities of the Trait owner gain a free specialist for every national wonder that city has built.
  
  
• bFreeSpecialistperTeamProject: The cities of the Trait owner gain a free specialist for every Team Project that city has built.
  
  
• bExtraGoody: Goody Huts and Islands revealed by the Trait Owner will grant an additional goody result (thus two results rather than one.)
  
  
• GoldenAgeYieldChanges: Lists the changes to the base rates on yields in all cities of the trait owner when a Golden Age is underway.
  
  
• GoldenAgeCommerceChanges: Lists the changes to the base commerce outputs in all cities of the trait owner when a Golden Age is underway.
  
  
• UnitCombatFreeExperiences: Additional (or less) experience given to units of the specified Combat Class by the owner of the Trait.
  
  
• UnitCombatProductionModifier: % modifier to the amount of production being produced by the trait owner's cities when training units of the designated combat class.

Any questions? Any more ideas for tags?

I'd like to pause to thank playtyping for the inspiration for the vast majority of these tags. Most of them come from evaluating his python driven Trendy Traits. Thanks playtyping!

Click to expand...

As posted in the Traits thread. These are projects 6 - 8.

@Thunderbrd

Wow. Just wow!

Pn opne of mine, is that " isOneUp: Gives an extra 'life' that can be lost by the unit."
i thought it was supposed to be "bOneUp??

EDIT: Yeppers, i looked and in the schema it is listed as bOneUp, thx.

Yeah. Sorry I was trying to get that thing written in a bit of a hurry and didn't approach the tags from the xml side as much as a pish-posh mish-mash of xml and code side usage that was derived from my handwritten notes meant to keep me straight on what was part of what project when I divided things up.

Do refer to the schema to make sure tag usage is correct.

Very impressive work. As there is so much new here, I guess that realizing the implications it allows as well as providing ideas for even further adjustments and modifiers will need some time.

some comments though

EraAdvanceFreeSpecialistType

Being able to receive a (selectable) free specialist for adopting a certain trait (or advancing to a certain era with a already established trait) is like what you have in civ5 right now, once you build Hagia Sophia or complete a certain social policy branch ("liberty" in vanilla civ5 I think)

GoldenAgeonBirthofGreatPeopleType

Getting golden ages for like every born great prophet, ... etc? Could lead to exploitation so using this may need nerfing. Maybe only the first of one type might trigger a golden age, not every born GP of that same branch.

Strategic implications for people using this trait: You need to birth lots of different GP to have many golden ages, could imagine a "prominent" traitline for that...

Thunderbrd said:

Yeah. Sorry I was trying to get that thing written in a bit of a hurry and didn't approach the tags from the xml side as much as a pish-posh mish-mash of xml and code side usage that was derived from my handwritten notes meant to keep me straight on what was part of what project when I divided things up.

Do refer to the schema to make sure tag usage is correct.

Click to expand...

Thx, i will hopefully get my Star Sign Module done now.

strategyonly said:

Sorry just looked and i am still missing this one (see attached)

Click to expand...

Recall that this was not merged in because I'd already generated the same effect for the combat mod. My version was/is iStrengthChange. Does exactly the same thing though.

Is the AI fully aware of all budding tags, promotion effects, and the impact on religious buildings etc.?

DRJ said:

Very impressive work. As there is so much new here, I guess that realizing the implications it allows as well as providing ideas for even further adjustments and modifiers will need some time.

some comments though

EraAdvanceFreeSpecialistType

Being able to receive a (selectable) free specialist for adopting a certain trait (or advancing to a certain era with a already established trait) is like what you have in civ5 right now, once you build Hagia Sophia or complete a certain social policy branch ("liberty" in vanilla civ5 I think)

GoldenAgeonBirthofGreatPeopleType

Getting golden ages for like every born great prophet, ... etc? Could lead to exploitation so using this may need nerfing. Maybe only the first of one type might trigger a golden age, not every born GP of that same branch.

Strategic implications for people using this trait: You need to birth lots of different GP to have many golden ages, could imagine a "prominent" traitline for that...

Click to expand...

Admittedly, many such tags are mostly made for the truly advanced selections at the tops of the tiers.

I've also got a concept of designing a 'minor golden age' that is something like a quarter length GA. I may convert that tag to utilizing THAT golden age rather than a full length one because, yes, it could get a bit too much, even if the trait were earned in a very late era.

Koshling said:

Is the AI fully aware of all budding tags, promotion effects, and the impact on religious buildings etc.?

Click to expand...

I've cludged my way through some things there but there's a number of tags that still need further ai development. There's some questions I'll be asking of you on some of that - I'll be needing to learn some sections of the code that I don't really understand yet to really make this work I think. And I did try to give it a good go at the bAllReligionsActive civics tag for the religious disabling but I have a feeling its not really up to snuff. Before I do more there I wanted to see what you thought of what I've attempted on that.

And I'm still a bit unsure as to the value of some of the tags so I've held off on doing ai for those.

Building tag AI is something I totally don't know the first thing about so those tags need developing on the AI level, and the specialist tags are the same way.

Step 1, get this stuff in there so the xml can start getting worked in. Step 2, consult with you on how to implement AI.

i hope the Religious Disabling will be a Gameoption as monasteries are usually the lift i need to get ahead again in Tech

I am torn. On the one hand I want to commend you for all the work that you have done there.

On the other hand, I am unhappy about the way this has been done. Lots of hard coded small/small solutions without consulting us first and then pushed in one huge commit which is bad for testing.

Like why did you go through the effort to introduce partial disabling of a building and then make it for one specific case only (religious disabling).

I would prefer if you made a thread first about larger stuff you want to implement so we can talk about how to do it and the final result will be better for it. Then use separate working copies and probably also feature branches when you work on multiple projects at the same time so you can commit them in small steps.

With C2C becoming somehow slowly exponentialiy bigger in the sense of the level of advancing strategic layers complexity the more or less coordinated inclusion of the sheer amounts of emerging, possibly groundbreaking (in the sense of enhanced gameplay) code enableing that will be, again, more or less design-political decisions -

at least at some down point the line there could be the situation that a long search for compromise or finetuning could either be constructive in the sense of stability or destructive in the sense of missing out on extraordinary innovational esprit, which, sadly, often tends to be short-living.
(thesis: 'the Stones weren't as good anymore when the Beatles were gone')

I respect Thunderbrds work very much and I can see AIAndys point here as well.

My personal hope is that quick, possibly controversial progress is not made impossible and that furthermore the best thing to start writing code is by freely following the flow of your uninhibited associations. The resulting code nevertheless would have to be discussed or be part of a "use developing modifiers" game option (which btw I would gladly playtest as I do with all new stuff^^)