A Modder's Guide to the Advanced Disease Structure of the Combat Mod

[Thunderbrd]

Part One: Affliction Promotion Dynamics


Introductory Discourse:
As I've mentioned in the second Introduction to the Combat Mod, the Advanced Disease system the Combat Mod offers us will be an ingame option once I've established a Combat Mod Bug Options page.

In the meantime, since we're already beginning to design diseases, I feel the team should have a full explanation of what we're able to do here and we should have a serious discussion on what changes or adjustments you might like to make to the structure of this system before we get much further into those endeavors.

So its time to get into detail on this system and the tags involved.

The Origin of this System:
I figured I should take a moment to explain the design philosophy so you might understand how this came about since I've been hearing the call of 'not necessary' echoing about the halls regarding this segment of the Combat Mod.

As we all know by now, AIAndy's original intention for diseases utilizing the generic properties system was to have each disease be its own independent property. By doing so, we'd have been able to create some rather intricate mechanisms to control its spread.

However, we've gravitated towards a generic Disease Property to control the majority of factors involved in emerging diseases. I don't think this was a bad idea though because otherwise there's a disharmony with other Generic Properties such as Crime, Flammability, Air and Water Pollutions, that have a very wide angle on a variety of effects. There are many crimes all controlled and guided by the crime property for example. So it is quite natural to take the same approach with diseases.

But the problem with this is that it undermines a lot of the functionality built into the Generic Properties system that could've allowed us to define each disease's emerge, spread, resistance, and recovery mechanics to a highly refined detail. I'm ever impressed, however, with our modders and how amazingly well they think things through to come up with innovative solutions to make things work even with less than perfect options at hand. So I'm not downing any decisions made along any lines here.

However, on the flip side, I personally did not feel that an absolute emergence and recovery levels embodied by the iMinimum and iMaximum settings did not leave enough room for the degree of chance that I feel real world disease operates on. Yes, that could've been addressed with a simple adjustment in the mechanism of the generic property system. And I still think we might want to do so for crime so that its not such a static absolute appear/disappear condition.

So why did I feel the need to take things a number of steps further and branch off of a generic system into a specific structure designed only for disease interactions?

Because it naturally evolved from one step to the next.

I was working on poisoning. Inspired by FFH2, I wanted to allow us to define a unit or allow a promotion on a unit to have the ability to INFLICT a poison (an ANTI-promotion I later termed Affliction) on its enemy when it attacked. Generally, if the attacked unit survived then it usually meant the attacker would've died but in tandem with Withdrawal and Early Withdrawal I began to see that we could develop our Criminal types to strike and retreat, leaving their victim poisoned in their wake, a strategy any MMORPG player is rather familiar with (DOTamage over Time).

So following the theory presented in FFH2 while allowing us to define numerous various Poisons, I generated two tags to give a unit the ability to inflict a poison on an injured foe.

Poisoning Tags
These are:
AfflictOnAttackTypes (on units. Simply list the promotions the unit will pass to an injured enemy within the tag lines <AfflictOnAttackType>. No need for a boolean value to support those definitions thanks to Koshling and AIAndy guiding me to a better vector mechanism design.)

and
AfflictOnAttackChangeTypes (Goes on a promotion to empower a unit to Afflict the listed Affliction Promotion(s) when it attacks another unit and injures it.)

There was no need to create a tag on promos that would remove an ability to afflict a given promotion onto an enemy since the promos that would bring the ability would get overridden or obsoleted as better presented itself.


Diseases As Promotions
Once this was done, I immediately realized that the tags I'd designed to flesh out these negative promos (Afflictions) would be just as useful for diseases as well.

Another feature in FFH2 that I much enjoyed was that 'diseased' units would pass their disease onto the units they fought, the disease promotion itself adding the afflicting ability to spread itself to another unit on combat.

But I didn't feel that our design philosophy in C2C really supported a single generic poison promotion, nor did it support a single generic disease promotion. We were wanting to design diseases from a perspective of research and knowledge on how those diseases operate in the real world.

So it wasn't a sufficient answer to say that if a unit with a disease managed to harm another unit it would automatically pass that disease to the other (as poisoning worked.) Instead, the disease should have a CHANCE to pass. And since all diseases work differently and each would have a varying chance of such transmission, it was necessary to define a tag for the chance of a disease passing from one unit to another in combat.

This tag became:
iCommunicability, a tag for a disease Affliction to define its % chance of passing from one unit to another.

Therefore, to some extent a disease is differentiated from a poison, despite both being considered Afflictions, by whether or not the Affliction has an iCommunicability value. If a unit with an Affliction that has an iCommunicability rating above 0 damages another unit, the iCommunicability becomes the base chance for that same Affliction promotion to be inflicted upon the damaged unit.

However, a disease CAN have no Communicability, in which case its been transferred to the victim most likely as a result of being attacked by a unit with an AfflictOnAttack ability designating that Affliction to be afflicted automatically upon injury, like a poison. OR it has been handed to the victim unit by the Generic Disease property mechanism where the unit's generic disease level has exceeded the iMinimum threshold established and the unit qualified to receive the disease according to all the filters setup there.

Sometimes it is appropriate for a disease to include an AfflictOnAttackChange tag to represent it passing from one form to another. For example: Rabies. Rabies would be a Disease Affliction promotion that only non-Human Mammals can possess (feel free to get more specific in defining this beyond this basic example.) It can pass between animals from one to another via proximity (more on proximity below.) But the definition of the Affliction Promotion that represents animal based Rabies would include an AfflictOnAttackChange of something like PROMOTION_HUMAN_RABIES which means if such a diseased animal attacks and injures a human unit, the disease passes to the human unit as a poison would - now the human unit has its own form of Rabies. And perhaps that form of disease has no iCommunicability, indicating it will not pass beyond that unit via combat, proximity or any other means as it would also NOT include any AfflictOnAttackChange designations.

Note: how such animals would initially contract such a disease is still going to involve further programming at the moment...


Proximity
It is also possible for a unit to contract a disease by proximity to other units, including neutral, hidden enemy units, and friendly units alike that exist on the same plot. Every turn, each unit in proximity to another unit with an affliction that bears a Communicability value, checks to see if it has contracted that disease much the same as if it had entered combat with such a diseased unit.

There are two tags that can deny these forms of contraction in a given disease too. Obviously, some diseases should be able to pass between units in proximity while not being able to pass during combat and others able to pass between units in battle while not being able to pass as a result of proximity. So the following tags allow us to establish these limitations:
bNoSpreadonBattle
bNoSpreadUnitProximity

I believe these are fairly self explanatory.


Resistance and Recovery
Then I realized that it could be a neat ability to allow our units to develop a general hardiness and resistance to diseases and that tag could directly counter the chance to pick up a disease whenever it needed to make such a check.

This tag became:
iFortitude (on units as a base ability definition) and
iFortitudeChange (on promos for the intention of developing a promotion line or two that would help a unit develop its Fortitude value and thus resistance to disease.)

Then I realized that the general hardiness of Fortitude could be useful in helping a unit overcome any given Affliction, be it Disease or Poison and would make Fortitude more desirable despite the fact that it would add little to the unit in terms of combat value.

So when designing recovery on Afflictions, I established that every turn, a unit should check to see if it had recovered from the Affliction. But the ability for a unit to overcome an affliction should not be based on the affliction's Communicability for a few reasons. Poison didn't have a Communicability definition and the ability for one to overcome a disease really had little to do with how easily they could catch it.

So I needed a new tag for all affliction definitions:

iOvercomeProbability (to go on any affliction promotion representing the affliction's difficulty to overcome. Higher is weaker as this % is the base percent chance of successfully overcoming the affliction every turn.) Note, a unit that acts in a turn does not have an opportunity to overcome an affliction so if you have an afflicted unit its best to let it rest so it can recover.

The chance, then, for overcoming an Affliction is the Affliction's Overcome Probability plus the unit's total Fortitude.

But usually, a sickness or poison is either made easier to overcome with time, or for particularly dangerous diseases and poisons, made more difficult to overcome with time. So that factor needed to be expressed.

iOvercomeAdjperTurn embodies this. The # you inject here, be it positive or negative, will add or subtract to the chance to overcome the Affliction (for the given afflicted unit) cumulatively for each turn the affliction has been possessed.

REMEMBER that positive means more likely to overcome! That might be a bit counter-intuitive at times.

Note: For now, putting this value on a poison will cause a unit that's been struck again and re-poisoned to re-set this value back to 0, starting the count over. Most poisons should be easier to overcome over time and this will be one benefit of attacking a poisoned unit repeatedly with the same poisoning unit, continuously refreshing the poison in the victim's system. A pending change may cause this to be rethought a bit though.


Assistance in Recovery
Then I got to thinking about how healer units could help other units overcome their afflictions. I figured they'd have two ways to go about this that would help us to flesh out healer unit promotion lines in an amazing display of variety, unlike anything we see on those simplistic units today.

The first method they could use would be to assist units to health with generic medicinal practices. This REACTIVE medicine would be embodied by a new ability that operated much like a parallel of -Generic Disease influence and Healing but where -Generic Disease influence would be proactive efforts to keep disease at bay among the populace of the local region, and Healing would represent first aid efforts to keep soldiers alive and recovering after all kinds of combat wounds, this tag would represent herbal cures and medicinally targeted treatments to all known Afflictions.

I call this generic ability to help local units to recover from afflictions:
iAid (as the base ability on a unit) and iAidChange (for a promotion to add or subtract the value of this ability on a unit that possesses the promo.)

Aid only helps local units and works much like healing in that only the strongest Aid value that exists among units in the stack will be counted.

So now we have Aid helping a unit to recover from diseases and poisons, adding its value in direct support of units in the same stack on their Overcome Checks. Therefore, to overcome a disease or poison, a unit gets a random result from 1-100 every turn it hasn't moved and if that number comes up underneath the iOvercome + totalFortitude + best local Aid value + total tallied up modifier of the # of turns the unit has had the affliction times the iOvercomeAdjperTurn value of the affliction, then the unit will overcome the affliction (meaning the negative promotion is removed.)

Additionally, I figured certain buildings would assist in recovery if a unit were in a city, like Hospitals, Healer's Huts etc...

So cities themselves can offer a sum total of Aid that adds to any best Aid value on units present to further influence recovery.

Buildings thus have the tag:
iAidRate Just like with units, only the strongest iAidRate building in a given city will add its value to the plot Aid total.

Furthermore, Hydro suggested that we allow access to certain resources, natural or manufactured, like herbs or pharmaceuticals, to influence the city's Aid rate. So now we also have the tag:
BonusAidModifiers to indicate the adjustment to Aid that access to a given Resource provides. Use the tag to list the resource and the associated adjustment to the aid rate in the city. These are cumulative so make sure not to overdo it here.

Note that this too can be negative so some Resources could actually be programmed to impede general recovery (like perhaps Tobacco. I'd say Alcohol except that its long been useful as a crude medicine actually.) But keep in mind whenever you're making a general bonus or penalty to aid, its not to a specific affliction but to ALL afflictions and represents the general care available.

Again, the difference between Healing and Aid here is the difference between bandaging, stitching, prioritizing emergency surgeries on injured patients, first aid and such VS Aiding and abetting a patient in his recovery from a disease, poison, or long term critical injury such as broken bones, torn muscles - physical therapy efforts really. Basically short term treatment of minor cuts, bumps, bruises, gunshot wounds etc vs long term treatment where prognosis is highly variable.

As a result of cities being able to offer this extra Aid strength to its local units, it gives our armies a serious homefield advantage against poisonings, diseases and criticals (if you play with that option.)


Outright Curing
The second way a healer could interact with and assist other units in recovering would be to have an outright specialists level of skill in healing a specific form of Affliction. What I've done here hasn't been well tested so could be buggy but I'm really hoping it works as planned. I followed the tutorials to the letter on setting up a 'mission' definition here.

The tags:
CureAfflictionTypes (as a base definition for a unit) and
CureAfflictionChangeTypes (to give a unit the ability when the promotion with this tag is possessed)
allow us to define the specific afflictions a unit has the skill to cure outright as a turn based action. When a unit possesses any of these it should get a mission option for each Affliction it can cure where that Affliction is possessed by one or more units in the same plot the healer is on. Selecting this mission will heal one (the first listed in the stack) unit that has the indicated Affliction (without fail) and end the Healer's turn.

This is the fast way for us to heal our units of afflictions. A clever player who realizes the enemy he's planning to invade is beset by a particularly communicable disease might bring with him a healer or two specialized in the elimination of said disease so as to keep it under control when his own units begin to suffer the effects of contracting the disease from combat with the enemy.

On a design note, whenever we create an Affliction, we should also define how and when healer units could gain access to outright healing of that affliction in this manner. It could be given to a certain upgrade along the healer unit lines, and/or be included on a promotion that's only accessible to healers at the technology level necessary to represent when our technology gives us the power to directly heal such an affliction.

This, more than anything, is a design feature that will allow us to greatly diversify our healer units, both the upgrade chains and the specialized function of a given healer unit in play. It will pay to know thy enemy in what you are prepared to heal.


Technology
Now then, as medicine advances, anti-venom, inoculation and medical nano-tech technologies emerge offering direct resistances to particular diseases and poisons. Thus we have a few tags to represent resistances and immunities:

TechCommunicabilityModifiers
Goes on the specific Affliction promotion definition to represent how much more difficult (or more easy it has become in some rare cases) for an Affliction to spread among units that belong to a civilization that has discovered the specified tech(s). List the tech, then the modifier to the Communicability of the Affliction.

TechOvercomeModifiers
Goes on the specific Affliction promotion definition to represent how much easier (or difficult) it has become to overcome that Affliction by units belonging to a civilization that has discovered the specified tech.
List the tech, then the modifier to the Overcome rating of the Affliction.

AfflictionFortitudeModifiers (for units) and
AfflictionFortitudeChangeModifiers (for promotions to offer the modifier to the unit possessing the promotion)
Defines the resistances mentioned above. Some units themselves may have a specific base resistance or weakness to a particular affliction that would be represented by listing the affliction and the adjustment to the unit's fortitude vs that affliction under the AfflictionFortitudeModifiers tag. Some promotions can provide units with specific resistances against the scourges of their day, thus can utilize the AfflictionFortitudeChangeModifiers tag to reflect this.

IF, however, the promotion simply provides a general overall ability to resist and recover from any affliction, a straight modifier to the unit's Fortitude value is better used. If we find ourselves listing off too many specific AfflictionFortitudeModifiers, we should probably reconsider and go with an overall Fortitude modifier instead. This is intended to represent various inoculations as equipments (even modern soldiers undergo a number of inoculations as a part of their basic training requirements.) but I'm sure we'll find more uses as we go for these tags.


Combat Classes and SubCombat interactions
We also have, to represent various Unit Combat interactions such as weaknesses or resistances to a disease or poison as a particular species or the ability to avoid being infected as a result of being in an armored vehicle or even encased in heavy plate armor (remember how many layers of SubCombat definitions we can employ now!):

UnitCombatCommunicabilityModifiers

UnitCombatOvercomeModifiers

These modifiers go on the Affliction definitions themselves to allow us to influence the ability to pass between and be overcome by various unit combat types.

Generally its a good idea to zero out our base Communicability and Overcome values on the presumption that we are considering a Human on foot.

When Cultural UnitCombats get defined and a method developed to pass such cultural designations onto units, this could get even more interesting, indicating some cultures as more or less vulnerable to various diseases (lots of research to draw on here.)


The Aftermath
Now when a Disease or Poison is overcome, often the Previously Afflicted will have been left with a newfound tolerance to that specific Affliction. When a Critical is suffered, it might be all the harder to overcome it the next time (my thrown out shoulder that I fully threw out three more times over the next five years and would repeatedly fall out of socket at the slightest tug until it had proper time to heal long term was a good example.)

These effects are embodied by the following tags that go on the Affliction Promotion definition:
iToleranceBuildup
The amount of additional Fortitude that the unit gains (or if negative, loses) against this specific form of Affliction when this Affliction has been overcome.

and:
bToleranceDiminishes
If set to true (or '1') it means the tolerance value attached to any given unit towards this particular affliction decreases (or increases if negative) by one every turn after the tolerance has been added (or subtracted) until it zeroes out.

Thus, if I overcome a Common Cold, I gain the Tolerance indicated in the Common Cold's Affliction Promo definition and that makes it that much less likely that I will catch it again and that much more likely that if I do I'll overcome it. But I'm only protected for a time and after a while that effect will diminish, thus the Common Cold would have bToleranceDiminishes set to 1 to allow this degradation of my Tolerance until I have lost all tolerance whatsoever.

If Tolerance is earned towards a particular affliction more than once it should stack.


That's enough for now to open discussions. Feedback, requests for tweaks, optionalization lines, clarifications, please let me know what you think so far and if you're confused by anything or have any curiosities for me to clear up.

I'm reserving the next few for further information on this system and to help summarize these tags for quick reference during any design process.

 

[Thunderbrd]

Part 2: How Diseases as Promotions interacts with Cities and Diseases as Buildings.
(At least according to the ingame option to-be, Advanced Diseases.)


From Cities to Units to Cities
So you might be wondering at this point how most diseases would initially get into the unit pool to begin with.

Generally, diseases would start in cities (although events and some spawning mechanisms to come may be another source.)

In accordance with our current design strategies, this system considers Diseases, as experienced by Cities, to be a Building definition. Not the kind you choose to build of course, but the kind that pops up if you've allowed your disease values to get out of control (and under this structure, a number of other modifiers as well.)

This means that the full design of most diseases would take place in two parts, on one side, a Building, and on the other a Promotion.

Just as units can receive a Disease Affliction by proximity to a diseased unit or in battle with a diseased unit, a unit can also receive a Disease Affliction as a result of proximity to the city itself (being on the city plot when the city is 'infected' by a given disease.)

So how does that work? How does a disease BUILDING translate into a disease PROMOTION on a unit?

This tag establishes that relationship. On buildings, we have:
DiseaseTypes

Yes, its capable of containing a list of affliction promotions that building represents. Why multiple? Because it was around this point in time that I started to consider that perhaps a single disease could be represented by a set of promotions to indicate the severity of a given disease rather than just one static promo.

However, for now, its probably best to keep diseases to one promotion each and only ever list one promotion here under the DiseaseTypes tag. I've got some restructuring to do coming up that will likely make this tag refer to an Affliction PromotionLINE instead of allowing it to haphazardly reflect multiple various diseases. (More on that later.)

Anyhow, what's in place now allows us to test things a bit if we feel like playing with the mod capabilities and gives us the function according to the one-promotion to represent a disease method.

Moving on.

When units are making proximity checks to see if they pick up a disease from units on the same tile, basically the city itself counts as a source of that disease utilizing the corresponding promotion to the disease building it has.

This makes it possible for a unit to contract the Disease Promotion from the city its in when the city has a Disease that corresponds to that Affliction.

Therefore, its important to note that the communicability definition on the disease still stems from the promotion definition and controls how likely it is that a unit will pick up that disease from the city its in.

This does not, however, mean that the promo's Communicability setting directly controls how likely it is for a city to get a particular disease (only influences if there are locally diseased units - more on this below.)


Limiters On City/Unit Disease Transmissions
Its important to note, then, that we also have the following bool tags, that go on the Affliction Promotions that represent the disease, to help us potentially limit transfers between units and cities:
bNoSpreadUnittoCity
bNoSpreadCitytoUnit
Again, self-explanatory. Though that last one means only spawns and events could initiate that disease to enter the unit pool. Generally, if a disease isn't MEANT to enter the unit pool, no designed Affliction Promotion is really necessary unless you want some of the few tags there that get inherited into the city system to be included.


How a City gets Sick
With the current Generic Properties system, diseases emerge at fixed Disease Property levels in a city and disappear as soon as those property levels go away. We can have those values vary based on some stimulus, and diseases can be filtered by a ton of varying prerequisites. We can make it possible to qualify to potentially pick up a disease if that disease exists in a city we're trading with, even if our city does not otherwise qualify for the disease based on our own city radius features. We can make the disease property itself have a natural ebb and flow with a varying degree of drag against the property value. And there's more that I'm sure those working this structure understand more than I do.

This was all a great platform to build an even more detailed system onto. So its important to understand that the Advanced Disease system simply adds more detail to this already existing Generic Disease Property mechanism.

Under the Advanced Disease system, disease buildings won't be automatically assigned when disease levels go over the iMinimum value of the disease building and retracted when it drops below.

However, the iMinimum value is still used to zero out the chance of an outbreak of a given disease (base Outbreak Level) at a 50% chance at that same Disease Property quantity indicated.

Every round, cities check through all diseases it doesn't currently possess for the chance of an Outbreak. So for a disease like the Common Cold with an outbreak level of say, 1, there's a 50% chance of an Outbreak of the Common Cold if the city's Disease Property Value is at exactly 1.

The actual base Outbreak Level as I will refer to it in the following text is considered to be the same as the iMinimum value.

Of course, if the disease doesn't qualify to go in that city due to the building's prereqs, its still not going to experience the outbreak. So all the same factors established for the more basic disease structure still plays into the picture here.

So the base outbreak level, expressed in the disease property building setting iMinimum, is obviously different from the Communicability of the disease as established on its Affliction Promotion definition. There should be some apparent correlation between those values in severity of course but in general, think of it like this:

• Communicability is how easily the disease translates between units and from the city TO the units and vice versa. It is defined on the Promotion end of the disease definition.
• The Outbreak Level is measure of how difficult it is for the disease can erupt in a population to the point that its affecting the city's values. It is defined on the Building end of the disease definition.

Example:

Spoiler :

The difference is nicely expressed when considering a disease such as Malaria, one of our first disease designs (that has yet to be developed on the promo side). Malaria easily breaks out in cities where its possible due to the terrain and latitude of the city as its spread by mosquitoes. But between units? It's probably possible since blood sharing could take place during combat with a low likelihood and a local outbreak could make it more likely for mosquitoes to carry local infections to military hosts but still somewhat rare for units to pick up malaria at all. But overall, the Communicability would be very low in comparison to the Outbreak level of Malaria.

Outbreak Level Modifiers
Now, of course, there are a number of modifiers to the Outbreak Level of any given disease.

• Aid
  The first of which is the city's AidRate, which directly reduces the chance of any given outbreak. Then any best Aid value on local units will also help to keep an outbreak countered. In short, these reactive treatments tend to keep outbreaks from taking place by taking good care of and quarantining the first to begin receiving the disease among the population.
  
  
• Trade
  There's also the following tag for the disease building:
  iTradeCommunicability
  Although the generic property system has considered transmission of its Generic Disease Property value between trading cities, it doesn't do so for the specific diseases themselves (not the way its set up to work disease now anyhow.)
  
  iTradeCommunicability allows us to set up the trade factor specifically for a given disease. Whenever the outbreak check is made for a given disease, the system will reference all cities that the city is trading with and add this value to the Outbreak Chance for every other trading partner that has that disease. (Or subtract if its a negative number, representing the odd case that somehow trading with a city with that disease makes it tougher to get that disease!)
  
  The down side of expanding extra trade routes...
  
  Therefore even a city with a very low overall chance of disease due to great sanitation and medicine in place could possibly suffer an outbreak of a disease when its trading with numerous less contained cities. Controlling disease outbreaks has always been a regional team effort (and in the modern world, a global team effort even among rivals.)
  
  
• Units in Proximity
  It stands to reason, as well, that if a unit can pick up a Disease from a city, a city can pick up a disease from a unit as well. Therefore, if any unit in the city has a disease (enemy or not so this gets a bit strategic if you've got invisible units with a nasty disease...), the Outbreak level of the disease is subtracted by the Communicability of the Affliction definition that correlates to the Disease building.
  
  
• Technology
  Technologies can also influence the Outbreak level of a given disease. The tag for designating this effect on a given Disease Building is:
  TechOutbreakLevelModifiers
  List the techs that the outbreak level changes at and how much the change would be underneath. Its common to think of techs as enabling us to better overcome specific diseases and yes, it would be normal that way. However, there may be some factors that make a disease worsen thanks to a technological development as well. So a positive number makes the disease less likely while a negative number makes the disease more likely to outbreak in the city after the designated tech is possessed.
  
  
• Building Effects
  And although some buildings can influence aid and thus the generic Outbreak level, its also possible for specific buildings to have a direct impact on the Outbreak chances of a specific disease. Some buildings can make it more likely to suffer a particular outbreak while others specifically make it less likely. In researching disease histories we might even find some new buildings just for this purpose. The tag for these buildings to use is:
  AfflictionOutbreakLevelModifiers
  List the disease by the Affliction (the promotion equivalent) and indicate the Outbreak modifier (up makes it tougher for the disease to emerge, down makes it easier.)
  
  
• Tolerance
  And again, as with units, when a disease is overcome in a city, the corresponding affliction is referenced to determine any established new Tolerance (or vulnerability if negative) to the disease that will be left behind on the city (and potentially telling that tolerance to diminish over time according to bToleranceDiminishes.)

Getting Over It
Recovering from a disease in a city takes getting the generic Disease Property value to dip below the Outbreak Level of the disease. Every pt the Disease Property is under the Outbreak level is a % value of recovery for the city. Just like Outbreaks are checked every round, the chance of recovery is also checked every round once recovery has become possible.

However, every turn a city has a given disease outbreak, the disease becomes more and more likely to have run its course, thus the outbreak level on an ongoing outbreak will increase by one every turn. It tends to be that all species eventually develops resistances to current disease threats. Even today, kids are born with immunities to AIDS simply because the HIV virus is spreading among the human pool. Additionally, as members of the population get sick and individually overcome the disease, they become much less likely to experience that disease right away and eventually the disease passes.

Remember, too, that any time you increase the Outbreak Level of a disease with any of the above noted modifiers, you will make it more possible to overcome the disease.

The Outbreak Level is also the 50% mark where the chance to catch the disease initially is concerned so unless your city has lasted until that Disease Level or beyond before catching the Disease, its entirely possible for the city to already be underneath the Outbreak Level as soon as its caught the bug, and thus immediately capable of recovery the round after it catches the disease in the first place.


Helpful Hints
Now, the most potentially difficult part of working with these all of these tags is keeping positives and negatives going the direction you intend them to. The rule of thumb here is to follow the following guidelines (presuming bad is more likely to allow disease to spread and be difficult to overcome):

1. Communicability: High is bad, low is good.
2. Outbreak: High is good, low is bad.
3. Fortitude: High is good, low is bad.
4. Aid: High is good, low is bad.
5. Disease Property: High is bad, low is good.

The reason Outbreak is a 'high is good, low is bad' situation is because you're manipulating the level at which the Disease Property value begins to make it possible to experience an outbreak and the level at which your Disease Property must drop to have your city recover from the disease.

Taken in all at once these tags can be overwhelming in volume and all with such similar naming so I felt it was important to explain the rational behind each in depth. In the last section here, I'll summarize them all up for you and do so by keeping them in their appropriate categories.


As an Option
The planned in-game option will revert our disease system to utilizing only the mechanisms offered by the Generic Property system and all those values that make that structure work.

However, all those layers of prerequisites and the basic outbreak levels established there will continue to validly interact with the Advanced Disease system when it is in use as well.

For systems or players that are experiencing intolerable delays between turns as a result of utilizing the Advanced Disease system, it will be able to be disabled at any point in time in play.

But without playing with that option, you'll lose a lot of the efforts to allow our diseases to display an incredible degree of complex dynamics that help them to accurately reflect their real world counterparts. Some players aren't as concerned to make the game features function more like reality and less like a game and they may wish to utilize just the basic system without the Advanced Disease mechanisms anyhow.

Nevertheless, this level of sophistication is the kind of detail we've sought to provide in every other area in C2C so adds a nice touch to our disease dynamics for those of us who appreciate that sort of thing.

 

[Thunderbrd]

101 Ways to Penalize a Unit
Tags for use in creating Affliction Promotions
(Beyond the usual -% Combat etc that we already have)​

In the generation of this system, I have given due consideration to some extra nasty effects we may want to give our Afflictions.

• iDamageperTurn: Each round the unit possesses the affliction with this tag, it takes this much health damage. This is the percentage of health that it is injured by each round. It doesn't stop the unit from healing, which obviously thus reduces, or potentially just balances out with, the damage being taken each round. If the unit moves and doesn't spend the round healing it still takes the damage. When the affliction is overcome, healing is what is necessary to recover. In many games, this is an effect known as DOT (Damage Over Time).
  
  
• iOvercomeAdjperTurn: This affliction becomes easier or harder to overcome with each turn the affliction is possessed. This is a tag for the whole promotionline affliction definition. Every turn the Affliction is possessed (any promotion on the line), this # adjusts the chance of overcome cumulatively. Thus some afflictions can be very easy to eventually overcome while others can become runaway impossible to address without greatly improved technologies.
  
  
• iStrAdjperTurn: This is also a form of Damage Over Time. It affects the unit strength directly and is a cumulative effect each round the affliction is possessed. As soon as a level of an affliction with this ability is overcome, the penalties inflicted from this tag (or in a more rare case, the BONUSES) are removed. So if the first level of a disease has a -1 in this value, that promo will reduce the unit's strength by one each round. If the unit's condition worsens and it thus winds up with the second level of the affliction and that level defines this value the same, only the amount of strength lost from the second level will be recovered when the condition improves back down to the first level - all the penalty points taken from that first level remain until it, too, is overcome. This can be fairly devastating but I believe the system makes 0 the minimum strength and it should thus not be inherently fatal to a unit regardless of how many - str pts they have lost as long as the unit can, at 0, be treated as any other unit that requires protection during its affliction.
  
  
• iWeakenperTurn: This is a cumulative general combat % modifier that accumulates for each round the affliction is possessed and in its recovery, operates as the above strength penalties. Massive penalties to combat will not every inherently be fatal to a unit but can sure make it worthless til it overcomes the affliction.
  
  
• bParalyze: Not to be confused with an inability to fight, this tag makes it so that the unit that has this affliction cannot move (is considered to be DOMAIN_IMMOBILE and operates under the same dynamics as the event that gets your ships stuck on reefs.) It should be coupled with large combat penalties, among other potential penalties, to indicate true paralysis. As soon as this tag is no longer on a promotion that the unit possesses, its ability to move returns.

We also have a few regulars that could be very useful for Afflictions:

• iVisibilityChange: To inflict blindness.
  
  
• iMovesChange: To create a reduction in movement.
  
  
• iMoveDiscountChange: To create a terrain has greater hindrance factor effect.
  
  
• iInterceptChange: Making it harder for the unit to hit an incoming air target.
  
  
• iWithdrawalChange: To indicate a unit with the Affliction should have a harder
  time escaping battle.
  
  
• iEnemyHealChange, iNeutralHealChange, iFriendlyHealChange: These 3 tags would be able to reduce the amount of injury healing the unit is capable of. For the sake of simplicity, I'd personally use all 3 equally in the case of applying any penalty to healing from an Affliction.
  
  
• iCombatPercent: A no-brainer basic Affliction-handy tag. Negative to impede the unit's ability to fight in general. Differs from the weakeningperturn tag above that indicates a CUMULATIVE modifier as this one is static.
  
  
• iExperiencePercent: A negative here would indicate a hindered ability to learn or recall any experiences while under the effect of the Affliction.

And some of the other Combat Mod tags can be handy:

• SubCombatChangeTypes: The affliction could ADD a whole combat class that could come with a sleu of various effects for a very complex interaction. NOTE: I don't currently have any uses for this kind of interaction in mind, just mentioning that it could be used and some design situations could call for it. It could simply be a combat class to designate a particular vulnerability to OTHER attack forms that are coming in with a bonus VS that combat class. There's a number of creative possibilities here.
  
  
• RemovesUnitCombatTypes: Removing a combat class could cause a unit to drop all its weapons that it had qualified for, lose other promos, all kinds of possible problems. Just placing here so we can keep it in mind as a possible negative effect.
  
  
• iAttackCombatModifierChange, iDefenseCombatModifierChange: One of the newest tags, if a state of mind or physical issue could somehow be more or less effective at impacting a unit's ability to attack or defend, these tags could be independently useful over use of the more generic Combat Modifier. It could also be useful to use combat modifiers of all kinds like terrain, features, combat classes, etc... if there's cause for it. For example: a penalty to attack and defense in Mountains and lesser so in Hills to indicate a portion of a Vertigo effect.
  
  
• iPursuitChange: A weakened ability to track or pursue - could be useful in a specialized nasal injuring attack against canines for example.
  
  
• iEarlyWithdrawChange: The unit might be a bit slower to attempt retreat, perhaps given to have less caution than normal as some disease and psychotropic effects or judgement hindering injuries may be capable of inflicting.
  
  
• iDodgeModifierChange, iPrecisionModifierChange: The unit has lost its sense of caution, reflexes, or is simply suffering from an intoxication, but has not lost its strength or stamina.
  
  
• iDigInChange, iFortCollatDefChange: The unit that loses an ability to develop proper defenses when fortifying could have a penalty here. Perhaps the unit is somewhat confused and in a daze and incapable of laboring to improve their defensive position. For many tags, like these ones, they should not be capable of penalizing beyond any benefits the unit might already have. But keep in mind that ALL defensible units can gain up to 5/rnd defense bonus from fortifying and that amount CAN be penalized with a negative iDigInChange. So if you have, say, a -10 Dig In, you'd lose all ability to gain any benefit from fortification UNLESS you had more than 5 Dig In value on that unit!
  
  
• iUnyieldingChange: Unyielding in many ways often represents the first manifestation of a Morale structure in the mod. A high Unyielding value is generally reflective of a unit that is not afraid to lose its life in battle and will tend to power through any greatly threatening situation in battle as a result. This ability would be poignant for robotic or emotion-less units as well. Nevertheless, since all promotions can be crafted to only affect certain combat classes, including afflictions, this can be useful to represent a mild 'fear' effect as a negative value - the unit becomes less willing to face threatening situations that might cause them to flee from the fight (from Repel or Knockback.)
  
  
• iStrAdjperRndChange: Already as a negative, this tag indicates the ability for the unit to lose strength (fatigue) each round in combat so it becomes EXTREMELY useful for affliction effects that indicate the unit is not fully up to the task and while it may feel somewhat capable at the beginning of the fight, would weary quickly and potentially lethally as the fight goes on.
  
  
• iStrAdjperAttChange: Much as above, Tires is the negative form of this tag and it makes sense for mechanical units that have been sabotaged to perhaps feel the effects of that sabotage more with more activity in a small period of time. This is also useful when impeding Onslaughting or Stampeding units to make each attack less likely of success.
  
  
• iStrAdjperDefChange: The Affliction with this as a negative value would be one that tends to wear at the emotional sense of determination and love of country that fuels a defender under onslaught. Each attack in a round would bring a greater sense of growing dread and loss of confidence and as a result, a lesser capacity to survive the next attack.
  
  
• iWithdrawAdjperAttChange: This unit grows clumsier and slower with each flight from a fight within a given round if the value here is negative. Its nerves are 'Frayed' with each retreat.
  
  
• iLungeChange: As a negative, reduces the ability of the unit to take advantage of a surround and destroy bonus when attacking. Could be coupled with other effects to indicate less movement, less conviction, and simply a reduced initiative.
  
  
• iDynamicDefenseChange: As a negative, represents a unit that is jumping at shadows and is more unnerved by the near presence of other enemy units thus gaining an increased penalty when a Surround and Destroy benefit is being employed against it.
  
  
• iStrengthChange: A static reduction to base Strength as long as the affliction remains on the unit. As its static, and since afflictions don't compile with previous affliction effects on the same line, its important that if you want it to remain or worsen, it should be reflected as the total Strength deficit at each promotion level of the affliction.
  
  
• iFortitudeChange: Many diseases and poisons, even some injuries, reduce the effective immune system of the afflicted. This would be a good generic way to represent this effect in a static manner.
  
  
• bStampedeChange: Some afflictions might make animals more prone to losing control in combat and carrying on the fight until either they or all opponents are destroyed.
  
  
• bRemoveStampede: Other Afflictions might pacify a normally ultra aggressive animal, giving it less cause to attack until death.
  
  
• bAnimalIgnoresBordersChange: Some afflictions, like the Rabies disease, would cause an animal to lose all fear of humans.
  
  
• iEnduranceChange: Many afflictions open up a unit's overall tolerance to cold and heat damage and make them more likely to exhaust in battle. A negative here would indicate that.
  
  
• PropertyManipulators: Obviously, a diseased unit would be more likely to make the whole region they are in more likely to suffer from diseases in general as their mere presence represents a microbial threat that can distract the immune system from any present threats, including the very disease they carry.
  
  But also consider that some affliction mental states might make one more prone to commit and promote others to commit crimes in their area as well.

Hopefully this begins to inspire some imaginable effects

 

[Thunderbrd]

Reserved for a tag summary and examples of use for ease of design reference

 

[ls612]

Hm, a lot of very interesting ideas here. However, I would prefer that we get a more conventional and basic disease system working and tested before jumping into this, as that way we will be able to implement this in a more gradual and hopefully stable manner.

 

[Vokarya]

Hm, a lot of very interesting ideas here. However, I would prefer that we get a more conventional and basic disease system working and tested before jumping into this, as that way we will be able to implement this in a more gradual and hopefully stable manner.

I agree with this. I think we are doing a lot with concepts that are clever from the mathematical/coding level, but don't seem to play as well as they look. Right now, I'm having some issues with how crime rates are calculated and how they are swinging wildly from turn to turn.

 

[Thunderbrd]

Hm, a lot of very interesting ideas here. However, I would prefer that we get a more conventional and basic disease system working and tested before jumping into this, as that way we will be able to implement this in a more gradual and hopefully stable manner.

I plan to work out the disease promotions and other afflictions as part of the combat mod module (in quarantine until well developed and nicely tested). So that part is going to be very gradual, or rather eventual. I mostly want you guys to:

• Be fully aware of this structure when designing any base disease buildings now so you can more effectively pave the way for these dynamics (much more to come as you can see from the reserved post notes).
  
• Consider playing with the system with a test or two if you're developing other diseases.
  
• Offer any feedback on these dynamics, requests for tweaks, suggestions for improvement etc... before any kind of xml work gets locked in under these structures and has to be adjusted later due to a new innovative idea. I've got a few tweaks in mind to adjust how affliction promos may play out in general and will discuss that once the 'what I have so far' is fully explained.
  
• Discuss how some diseases from real world examples would operate under these systems so we can find any gaps etc...

But yeah, this is not an overnight project to develop these out. I just fear that without the team being in full understanding of what's to come here we might be doing a lot of work that will need to be undone to an extent to get it to harmonize correctly.

I don't think we've 'gone there' with anything yet, and I don't see any specific causes for such concern, but I figure if y'all are working on any disease base structures now it could be useful to know what we've been enabled to do here.

I agree with this. I think we are doing a lot with concepts that are clever from the mathematical/coding level, but don't seem to play as well as they look. Right now, I'm having some issues with how crime rates are calculated and how they are swinging wildly from turn to turn.

I've seen your concerns elsewhere and I can understand this perspective. The pollution systems have largely gone rather undiscussed after its implementation which I tend to think has a lot to do with us spending more time modding than playing through (I myself can't do much of that without running up against our current OOS issues so that's high on my agenda to help AIAndy address - hopefully before the next release so we don't further alienate multi-play players.)

The crime issue you mentioned, though, I think is actually a good thing for its dynamic. To an extent anyhow. The element of trade making crime a little less predictable probably doesn't hurt us too bad from a design standpoint because crime shouldn't be fully predictable anyhow and should on occasion frustrate even the best micro-manager because the nature of crime itself is in reality impossible to completely eliminate or get under complete control of any society.

I've been considering trying to work out a method for players to have the power to select the cities they wish to trade with. At the moment, the trade mechanism is entirely based on auto selecting the cities that will give the best revenue on possible trade routes. No longer is this the only consideration!

But Crime as a whole could be waaay further developed in its mechanism, much as I've done here with Disease, so that its a lot more dynamic and alive rather than so static as it is now. But I'm personally leaving it alone as I have SO many other projects to attend to.

Anyhow, I'm not putting all this forward so as to say this is the current big project so much as to say, this stuff is enabled in the dll, in a code perfecting phase, and will eventually interact with a lot of things we're currently doing so should be understood now. I fully agree there are other systems that have been rather roughly developed and could use some sanding at the edges, especially as they are in play right now.

 

[Thunderbrd]

Added the second portion of the Modder's Guide here.

 

[Hydromancerx]

Helpful Hints
Now, the most potentially difficult part of working with these all of these tags is keeping positives and negatives going the direction you intend them to. The rule of thumb here is to follow the following guidelines (presuming bad is more likely to allow disease to spread and be difficult to overcome):

Communicability: High is bad, low is good.
Outbreak: High is good, low is bad.
Fortitude: High is good, low is bad.
Aid: High is good, low is bad.
Disease Property: High is bad, low is good.

The reason Outbreak is a 'high is good, low is bad' situation is because you're manipulating the level at which the Disease Property value begins to make it possible to experience an outbreak and the level at which your Disease Property must drop to have your city recover from the disease.

Taken in all at once these tags can be overwhelming in volume and all with such similar naming so I felt it was important to explain the rational behind each in depth. In the last section here, I'll summarize them all up for you and do so by keeping them in their appropriate categories.

How will the AI know? Currently with the property system positive numbers are bad and negative numbers are good. Such as High Crime, Flammability or Pollution is bad but low Crime, Flamiblity or Pollution is good.

How will you tech the AI that High Aid is good and not bad?

 

[Thunderbrd]

Aid is not a property but rather an ability like healing. Aside from perhaps needing to help the ai understand the value of aid on a building, it does currently understand the value of aid on a unit.

 

[AIAndy]

Everything you have in Part 2 should not be specific to diseases. It should be a generic system as it could easily be applied to other properties (it is probably the better way to handle crime buildings as well).

Together with bAutoBuild it could actually form an auto build system.

 

[Thunderbrd]

How could you then plug in various elements that only effect disease? Like Aid, Tolerance, Local Unit communicabilities? At some point the equation must go from being generic to being specific wouldn't it?

I'm flattered to see you think some of this kind of dynamic would improve our methods of handling crime. But the only thing I really see that could apply there straight across would be the iMin being the 50% mark and the overcome method being similar in numeric process but very different in equation.

So if I was to more genericalize this structure, how would I plug in variables that ONLY affect disease? Where would I have other types, like crime, plugging in variables that ONLY affect crime?

Also, crime and other properties wouldn't have correlating promotions to draw some information from to guide the process. So how would that be made more generic?


Consider too that I'm looking at all this and thinking it might be best to take much of the info on the Disease promotion and transfer it over to the PromotionLine instead. This would be so that every instance of an affliction being picked up increases the severity to the next promotion step while every instance of overcoming the affliction would decrease the severity (or remove if on the lowest severity) to the next lower promotion on the line.

How could THAT be molded into a more generic system?

I'm not asking to scoff... I'm really asking. I recognize that your understanding of coding is far greater than my own and that you have a mind that's very good at breaking down individual elements of complex relationships into fundamental building blocks of processes. Mine doesn't work too well that way, seeing only each individual structure as completely unique.

 

[AIAndy]

How could you then plug in various elements that only effect disease? Like Aid, Tolerance, Local Unit communicabilities? At some point the equation must go from being generic to being specific wouldn't it?

You see elements that only effect disease, I see parameters of an auto build model. What is Aid in the case of diseases, might be some other property in crime that is specified in XML for this specific building.

I'm flattered to see you think some of this kind of dynamic would improve our methods of handling crime. But the only thing I really see that could apply there straight across would be the iMin being the 50% mark and the overcome method being similar in numeric process but very different in equation.

So if I was to more genericalize this structure, how would I plug in variables that ONLY affect disease? Where would I have other types, like crime, plugging in variables that ONLY affect crime?

You use the expression system or a property or attribute name in the XML to bind the right parameters for this building.

Also, crime and other properties wouldn't have correlating promotions to draw some information from to guide the process. So how would that be made more generic?

I don't see how some of the information actually needs to be on the promotion here. It can be isolated from the promotion and you could just have the link by being able to specify a promotion that increases the build level for each instance on a unit in the city.

Consider too that I'm looking at all this and thinking it might be best to take much of the info on the Disease promotion and transfer it over to the PromotionLine instead. This would be so that every instance of an affliction being picked up increases the severity to the next promotion step while every instance of overcoming the affliction would decrease the severity (or remove if on the lowest severity) to the next lower promotion on the line.

How could THAT be molded into a more generic system?

I'd say the promotion part of diseases is mostly a separate system. It might well be included in a more generic system but I haven't thought about that part yet.

I'm not asking to scoff... I'm really asking. I recognize that your understanding of coding is far greater than my own and that you have a mind that's very good at breaking down individual elements of complex relationships into fundamental building blocks of processes. Mine doesn't work too well that way, seeing only each individual structure as completely unique.

The key is not only breaking it down into building blocks but also seeing it as an instance of something broader that is only a disease model if some parameters are set in a certain way.

 

[ls612]

I think that the existing property system should be more polished first before adding this. This would be a great second level to the Generic Property System as AIAndy points out, but the existing Property code has display and/or calculation issues as Vokarya and JosEPh have pointed out that need fixing first before we integrate this into the Generic Property System.

Regarding Disease specifically, I think that DH should add his Disease system first and we can test and balance that before moving on to this more complex mechanism. That way the implementation would be more gradual and stable.

 

[Thunderbrd]

@AIAndy: Ok, I can see the point on most of that. However, there's a few things that I come up against repeatedly as I try to consider how to make the system generic.

One is where generic properties interact with other kinds of calculations that necessitate a hardcoded reference to a particular property.

For example, Aid on units is a base unit ability enhanceable by promos. It interacts with all Afflictions and isn't envisionable to me as something that would be convertible to a generic property function. It would interact with the parameters of the property and perhaps with a bool on the property setup declaring something as specific as 'bAidInteraction', which wouldn't apply towards any other type of property other than Disease anyhow (unless I suppose we end up making other KINDS of diseases like those that stem from a Radiation property or from the pollution properties. Actually... on that thought that makes sense.)

But to say that Aid would be able to function as a generic system that interacts with any sort of property would be unimaginably difficult to design and utilize in XML. I suppose you could see it as a kind of Effect Control but then in that kind of generalization its hard to see the difference between an effect that reduces the value of a generic property from an Effect Control. At that point, generically, its meaning is reduced to something very hard to visualize.

To me, at least, from my current perspective. I'm saying all this so you can perhaps tweak my perception somehow so as to make it seem more clear and possible to me.

The other thing here I'm considering that I have a tough time with is how difficult these generic systems are for our XML guys to grasp. By utilizing very specifically named tags, I'm able to make it fairly clear what they do... how they influence the system. But as many times as I've read through the tutorials on the property system, I've still yet to think I have the full picture of how it can all be programmed to function and what all abilities we really have at our disposal. I'm quite certain its a much more capable system than I think any of us can currently envision using it for. But its potential is tough to access because its really quite difficult to think of HOW to make it do what we want it to. And this is largely a result of the vagueness that these generalized taglines carry.

With such specified tag names, it may still be difficult to manipulate and tweak the structure from the xml modder's side, but its a bit easier nevertheless. I could run the risk of losing myself in my own design if I went too far into genericalization.

And the last issue I wanted to bring up was, I felt bad enough putting a switch in place for the disease mechanism to branch off of your programming. In general, I'm extreeeeeemly reluctant to want to mess with anything you've done in the code. Not only do you very comfortably work with a number of coding methods I've never seen or know anything about outside of your programming, making it beyond possible for me to cause a major bug in your processes, its also your design. And I have too much respect for you to have gone in and made such a major extension throughout your files where it would apparently belong.

So all in all what I'm trying to say is a) that I can see how much of this COULD be generalized but I struggle with some points that have extensive complex applications far outside of the generic property, b) I'm worried that to include all of this within the scope of generic programming would make it very difficult for our designers to flesh out, and c) I don't like messing with other people's designs, especially when my understanding of them is limited and my respect for the one who put it there is as much as I feel towards you.

And let me add, I'm very open to gradually working more and more of the details of the final disease equation into the generic structure if we're working very closely and are very clear with each other on how to do so. (And on that note I have to say its a shame I so easily get lost whenever you try to explain anything to me. This is my problem though... I'm just not up to speed with as many terms as you wield with the confidence that comes with the territory of familiarity.)

We could take one element and convert it to a generic process one at a time. Then, eventually, it could become so complete as to allow us to absorb the whole equation into the generic system.

On the positive side here, I've been thinking about this all day and I do see a number of interesting ways the added structure can be utilized in other generic systems. So perhaps my main contribution here is to come forward and express, in code, the manner in which I'd like this system to mathematically function. If we adapt all that into a more generic system, I'm thinking it would be pretty amazing in the final result.

@ls612: I'm not of the opinion that there's a flaw in the properties system, not that I can see anyhow. There's probably some text manager work there still but a lot of that seems to have been recently addressed. The problem I think we currently have on our plate there is one of two prongs. We need to be able to explain the mathematical process to the player more transparently still and we need to be certain we want the xml settings to be as we wish them to be. Are they tweaked according to what we want to see happen effectively or do we need to make a few numeric adjustments? I'm not pinning any blame on the mechanism itself in otherwords.

Additionally, I've been extensively searching to try to understand what DH did there and without looking directly at his module, I have zero for reference. I think I might need to make a tweak in the switch that redirects disease properties to this system to disable that switch until I can make an option or we start absorbing the whole mechanism into the generic. I've realized I might've created a problem there that needs fixing that's currently keeping diseases from functioning at all... ugh. I'll be working on that fix when I can find some time this week.

 

[AIAndy]

@AIAndy: Ok, I can see the point on most of that. However, there's a few things that I come up against repeatedly as I try to consider how to make the system generic.

One is where generic properties interact with other kinds of calculations that necessitate a hardcoded reference to a particular property.

The game object wrappers provide a way to make references to that kind of value not hard coded.
It is called an Attribute and if you expose aid there, it can be linked from the XML.
The expression system can use attributes so you can also use an expression which allows for some more freedom.

Check this piece of XML from the crime property source in the handicap info. It links to the population despite that population is a hard coded part of the city:

        	<iAmountPerTurn>
        	  <Div>
        	    <Mult>
        	      <AttributeType>ATTRIBUTE_POPULATION</AttributeType>
        	      <Constant>5</Constant>
        	    </Mult>
        	    <Constant>2</Constant>
        	  </Div>
        	</iAmountPerTurn>

 

[Thunderbrd]

Fascinating! I'll have to look more into that. How, exactly do you expose a hardcode calculated value to an attribute then?

 

[AIAndy]

Fascinating! I'll have to look more into that. How, exactly do you expose a hardcode calculated value to an attribute then?

Best search for all references to ATTRIBUTE_POPULATION. It is quite easy.

 

[Thunderbrd]

Update

Its going to take a bit to go over the above and edit it, which is a project I'll wait to work on once the Combat Mod is in a more complete state and I'm between projects.

For now, as promised, I'm posting some explanations of adjustments recently made to the above information.

I also want to mention, first off, that one of my next projects is to fulfill AIAndy's request to make the city disease structure more generic so the process can apply to more than just diseases and be based less on direct correlation between promotions and buildings, which after some consideration is a far better approach. It can still be made optional and setting up combat mod options will be one of the next project thereafter.

But this round of adjustments to the project have more to do with making some changes in the afflicting and healing from afflictions for units.

The following now applies:

1. While Affliction promotions do continue to be considered Afflictions by a boolean tag, generally ALL afflictions should now be related to a Promotion Line that is given the indication of being an affliction from that PromotionLine tag definition, even if there is only one promotion on that line.
   
   
2. Each Affliction PromotionLine represents a particular ailment, be it a Poison, a Disease, or a Critical Injury.
   
   
3. Each Affliction Promotion on the PromotionLine represents a severity of that particular affliction. The lesser the severity, the lower the LinePriority, which I'll refer to as 'level' for purposes of this exposition.
   
   
4. When recovering from an affliction, a unit takes a step down in severity, and completely recovers if the severity was only at the first level. For example, if a unit has Viper Venom I and overcomes it or is cured of it by a healer unit using the Cure mission, it will completely overcome the Affliction. But if it has Viper Venom II, one instance of overcoming the poison will reduce the affliction to Viper Venom I instead. This works the same for all Afflictions.
   
   
5. When being poisoned, a unit will earn a level of the affliction each time it is hit with the same type of poison. To achieve this, now the AfflictOnAttack tags will indicate not just a given Affliction promotion but rather an Affliction labeled PromotionLine instead.
   
   
6. When contracting a disease, each time the unit contracts the disease it gains a level of the affliction rather than a particular affliction promotion itself. Thus the whole PromotionLine now carries most of the Disease definitions such as Communicability and such. This is not to say that worsened forms of a disease cannot make the unit's disease communicability stronger... more on that in a moment.
   
   
7. When being struck by a Critical, a recent adjustment has made it possible for the criticals that can be delivered to be filtered by the delivering unit Combat Class (if no Combat Class is defined in this list which is defined on the specific Critical Promo, then any Combat Class can inflict this critical.) Furthermore, when a unit delivers a critical, it is possible for the critical to be any promotion along the promotionline its attached to, thus, for example, a Crushed Bones promo, being perhaps the 3rd level of the 'Broken Bones' PromotionLine, can be delivered in one strike and would then take 3 instances of overcoming to fully repair as it would take healing down to 'Fractured Bones' (level 2) and then down to 'Sprained Bones' Level 1 and then overcoming that before completely healed. (Remember that Cure missions can make this happen more than once in a turn for a unit.)
   
   
8. Poisoning is no longer automatic on striking a hit, nor is it always going to take effect after the battle is resolved. AfflictOnAttack is now a Structure based tag and can take the following statements:
   • AfflictOnAttack: indicates the PromotionLine this unit's attack can afflict.
     
     
   • iPoisonProbability: the base % Probability of inflicting when you strike your opponent in battle. The overall chance is also influenced by your unit's Poison Probability Modifier (iPoisonProbabilityModifier for units, iPoisonProbabilityModifierChange for promos) which indicates the unit's extra or deficient skill in ensuring a poisoning strike will be effective. The overall probability is also directly reduced by your opponent unit's Fortitude (which already helps to avoid catching a disease.)
     
     
   • bImmediatePoison: Designates the poison as being able to take effect immediately in battle upon making your first successful injuring strike.
   
   Most human units gain the ability to poison via a promotion, so the following tags apply to promotions:
   • AfflictOnAttackChange: Indicates the Affliction PromotionLine this promotion is either adding the ability to utilize to the unit or modifying in some way.
     
     
   • iPoisonProbabilityChange: Adds to the probability of this particular Affliction being delivered. If the unit didn't naturally have the ability to poison with this affliction, the default probability that's being modified here is a base 0 so the 'change' becomes the final base probability.
     
     
   • bImmediatePoisonAdds and bImmediatePoisonRemoves, makes it possible to give one additional cause for this affliction to take effect immediately or remove one cause for this affliction to take effect immediately. So its possible to take a promo that actually delays your poison's effect or take one that makes that effect immediate.
   
   
9. Diseases can worsen or improve and since being in proximity to another unit or in a city that has a disease can make that disease spread to your unit, including simply HAVING the disease (counts as a source that can cause the unit to develop a worsened case of the disease), it becomes necessary to be able to toggle the likelihood of a disease to worsen or improve as it traverses differing levels of intensity. Some of this also applies to recovery for all Afflictions. The following tags, all of which now go under the PromotionLine definition for the Affliction Line, needed to be implemented:
   • iWorseningProbabilityIncrementModifier: If the Probability of the disease worsening should grow or reduce with greater severity, this tag should be employed to modify the % chance of that check. This is a moot point if the disease has the bNoSpreadUnitProximity tag and the unit is out of reach from any other possible source (a city with the disease or avoiding being attacked by a unit with the disease).
     
     Short and simple, each level of the disease the unit has will add, cumulatively, this value to the chance to worsen at the next opportunity to do so.
     A negative number is probably more common than a positive one as most diseases tend to get easier to overcome as the body fights it harder and harder as it worsens. Some, however, become impossible to overcome as it worsens. Take Syphilis as a generic example... curable, even able to be overcome if it hasn't reached later stages, but in the last stage there's no way to fix it we know of.
     
     
   • iWorsenedCommunicabilityIncrementModifier: Some diseases are more likely to be passed from unit to unit or city to unit or vice versa or via combat if the disease is in a worsened form. If the disease under development should be harder or easier to be contracted from your unit as a source as the disease worsens, this number will cumulatively add or subtract from the Communicability factor as the disease takes steps up in levels.
     
     
   • iWorsenedOvercomeIncrementModifier: I think we're beginning to get the picture. Worsening and overcoming is entirely possible in the same round and can actually help a unit develop a stronger resistance to that disease. IF you want the disease to be easier or harder to be overcome by a unit as it progresses in severity, this number is the one to toggle. This one can apply not only to diseases but to any Affliction since all afflictions are handled the same in their overcoming and healing mechanisms.
   
   
10. Cure missions are now indicated by AfflictionLine as a necessity of the above changes. I also improved the selection criteria for AIs on the promos that enable healers to Cure specific AfflictionLines. They'll now check in to the status of their army to see if and how many and how many local units have an affliction they might be able to begin healing if they take a particular cure enabling promotion. Thus they'll ignore the ones that they have little cause to be concerned about and instead go for more generic healing benefits instead if they aren't suffering widely from afflictions but will most certainly take curing promos that would help them in their current state.

I believe that's about it. There could've been a few other things but this is all that I can think of that applies directly to this subject matter.

In summary, the short explanation of what I've done is primarily to make all afflictions have stages of lesser and greater effects and generated methods to govern the contracting, worsening and improving of a given affliction.

 

[Hydromancerx]

@Thunderbrd

While not every disease is the same have you considered not every poison is the same? Such as ones that stun, paralyze, cause hallucinations, blindness, blood hemorrhaging, sedation, etc. For instance a rogue may not be strong enough to take on an army but if it can paralyze or sedate a unit in order to get past them. While on the other hand in combat an archer may want a strong poison/venom that quickly takes out the enemy before they can reach them. Or even worse a hallucinogen that causes the units to attack their own units by accident.