AI War 2:Modding Special Mechanics

Please Refer To The Main Special Mechanics Page

For general explanations of what these special mechanics ARE, please visit the Special Mechanics page as a reference.

Cloaking

These must be set up as their own system on an entity, and they don't have all those usual weapon-specific properties. They may exist on their own, or next to other weapon and non-weapon systems.

These have only one attribute that must be set:

• cloaking_points defines how many cloaking points the ship has.
  • The more of these a ship has, the longer it will take enemy tachyon beams to decloak them.
  • A good standard value for these is 1000.
  • Assuming that the number of points is at least 5, then the number has no other effect; but if the number is less than 5, then this also will affect how many times the ship can fire before decloaking, since these are integer numbers and at least one cloaking point will be removed every time the ship fires.
• cloaking_points_added_per_mark is optional, and defines how much stronger the cloaking system gets for each mark level beyond the first.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there are two values defined that you can override in sub-xml files if you wish.

• balance_current_cloaking_percent_loss_from_firing defines the percentage (as a float between 0 and 1) of cloaking points lost each time the ship fires. The default is 0.2.
• seconds_to_wait_before_recloaking defines how many seconds the ship must wait while having zero cloaking points left and not taking any cloaking damage before it can re-cloak. The default is 5.

Tachyon Fields

These must be set up as their own system on an entity, and they don't have all those usual weapon-specific properties. They may exist on their own, or next to other weapon and non-weapon systems.

These have three attributes that must be set, and one optional one:

• tachyon_range defines the circular area that is being irradiated.
  • Tiny2 is the standard for ships where tractoring isn't their main priority. Small4 is the standard for units that are focused mainly on tractoring. But the field sizes vary pretty widely.
• tachyon_hits_albedo_less_than is an albedeo value between 0 and 1. If this is not set to something above 0, the tachyon field will not work!
  • Something in the 0.5 to 0.7 range is the most likely area you want to be in. Most tachyon fields should not be hitting the absolute top of the spectrum, or else things that are intended to be quasi-perma-cloaked won't work. But then again, sometimes you want an ultra tachyon emitter to deal with them, too.
• tachyon_points is how many cloaking points to remove from each enemy ship within the field per fifth of a second.
  • So if the value is 50 (which is a very common value), then it would reduce the cloaking points of a ship by 250 per second, thus taking 4 seconds to completely reveal an average-strength cloaked ship of 1000 cloaking points.
• tachyon_points_added_per_mark optionally lets you increase the tachyon points per mark level by the stated amount.

Tractor Beams

These must be set up as their own system on an entity, and they don't have all those usual weapon-specific properties. They may exist on their own, or next to other weapon and non-weapon systems.

These have four attributes that must be set:

• tractor_count defines how many beams this emitter can send out at once.
• tractor_range defines how long the beams can be.
  • VeryTiny2 is the standard for ships where tractoring isn't their main priority. Tiny4 is the standard for units that are focused mainly on tractoring.
• tractor_hits_albedo_less_than is an albedeo value between 0 and 1. If this is not set to something above 0, the tractor beams will not work!
  • Something in the 0.3 to 0.5 range is the most likely area you want to be in. Tractor beams should not be grabbing highly-shielded targets.
• tractor_hits_engine_gx_less_than is an engine gravitic exponent (gx) value between 1 and 25. If this is not set to something above 0, the tractor beams will not work!
  • If the albedo is middling, then this should also probably top out at around 15.
  • However, if you crank the albedo lower, you could shoot this one higher, and vice-versa. These could thus specialize in hitting certain types of ships without hitting ships that are too powerful and central.

Gravity Fields

These must be set up as their own system on an entity, and they don't have all those usual weapon-specific properties. They may exist on their own, or next to other weapon and non-weapon systems.

These have three attributes that must be set, and one optional one:

• gravity_range defines the size of the gravity field.
  • Normal1 is the standard for units focused primarily on gravity disruption.
• gravity_hits_engine_gx_less_than is an engine gravitic exponent (gx) value between 1 and 25. If this is not set to something above 0, the gravity field will not work!
  • This should generally not be higher than 15, most likely, but a slowing field is one of those things that is only a deterrent -- rather than an outright blockade -- and so having them all the way up to 25gx but with not too much slowing power might not be a bad thing.
• base_gravity_speed_multiplier is a floating point number between 0.05 and 1.
  • You actually can probably set this to higher than one to create a gravity acceleration field, but it would only hit enemies so that's a bit odd.
• subtracted_gravity_speed_multiplier_per_mark is optional, and is a float that defines how much lower the multiplier goes per added mark level.
  • Defining this as something like 0.1, with a base speed multiplier of 0.9 would make it so that mark 1 is 0.9, mark 2 is 0.8, mark 3 is 0.7, etc.
  • If this would ever cause the total multiplier to drop below 0.05 (5%), then it will cap itself at 5%.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there is one value defined that you can override in sub-xml files if you wish.

• max_gravity_multiplier defines that minimum floor for a single gravity generator's speed multiplier. The default is 0.05.

Bubble Forcefields

Simply assign a value greater than 0 to the shield_points attribute on an entity, and it will gain personal shields. Then assign shield_size_scale, and it will become a bubble forcefield.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there is one value defined that you can override in sub-xml files if you wish.

• time_to_regen_bubble_forcefields defines how long, at most, it takes a bubble forcefield to regenerate without help. The default is 120 seconds.

Personal Shields

Simply assign a value greater than 0 to the shield_points attribute on an entity, and it will gain personal shields. Do NOT assign shield_size_scale, or else it will become a bubble forcefield.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there is one value defined that you can override in sub-xml files if you wish.

• time_to_regen_personal_shields defines how long, at most, it takes a personal shield to regenerate without help. The default is 30 seconds.

Engine Stun

Define the base_engine_stun_per_shot on the system in question as being an integer value above 0. This is how many seconds' worth of stun the system will do to targets it hits every time it hits them.

Optionally, define added_engine_stun_per_shot_per_mark, again as an integer. This is how many extra seconds' worth of stun the system will do if the mark level of the ship is above 1. So if this value is set to 2, then it will do 2 extra seconds of stun at mark 2, 4 extra seconds of stun at mark 3, etc.

You must also define engine_stun_to_engine_gx_less_than as being some value above 0. If this is not defined, the default value is 0 and thus the engine damage will never be applied to any ships! The typical engine gravitic exponent (gx) that you would assign to this field would be something like 15 for a typical engine-stunner, or up to something like 25 if you want to have a world-ending engine stunner that can even hit Arks and dire guardians and the devourer golem and other ships that you really would not expect to be able to stun. Probably best not to go that high, or you may create a super weapon that breaks the balance of the game.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there are two values defined that you can override in sub-xml files if you wish.

• max_engine_stun defines how long any ship can be stunned, at most. The default is 60 seconds.
• engine_stun_multipliers_by_stun_seconds defines how fast ships can move per remaining seconds of stun. The default values are: 1,0.9,0.7,0.6,0.5,0.3,0.1,0
  • Anything number of seconds above the last entry in that list will take the value of the last entry in the list.

Paralysis

Define the base_paralysis_seconds_per_shot on the system in question as being an integer value above 0. This is how many seconds' worth of paralysis the system will do to targets it hits every time it hits them.

Optionally, define added_paralysis_seconds_per_shot_per_mark, again as an integer. This is how many extra seconds' worth of paralysis the system will do if the mark level of the ship is above 1. So if this value is set to 2, then it will do 2 extra seconds of paralysis at mark 2, 4 extra seconds of paralysis at mark 3, etc.

You must also define paralysis_to_ships_mass_tx_less_than as being some floating-point value above 0. If this is not defined, the default value is 0 and thus the paralysis will never be applied to any ships! The typical mass tonne-Exponent (tX) that you would assign to this field would be something like 2 for a typical engine-stunner that is just going to hit fleetships and turrets and whatnot, or 5 if you want to include starships and some other larger units, or 10 if you want to include Arks and other very-large ships, or up to something like 19 if you want to have a world-ending paralyzer that can even hit the devourer golem and other ships that you really would not expect to be able to paralyze. Probably best not to go that high, or you may create a super weapon that breaks the balance of the game.

In the global external constants xml, located in GameData/Configuration/ExternalConstants/, there is one value defined that you can override in sub-xml files if you wish.

• max_paralysis_time defines how long any ship can be paralyzed, at most. The default is 20 seconds.

Ion Damage

Define the ion_percentage_per_mark_level_lower on the system in question as being a floating point value between 0 and 1. A value of 1 would be a rating of 100% per mark level, as noted above, whereas a value of 0.2 would be a rating of 20% per mark level, as noted above.

You must also define ion_damage_to_albedo_less_than as being some value between 0 and 1. If this is not defined, the default value is 0 and thus the ion weapon will not be able to hit anything and will never fire! Ideally this ion_damage_to_albedo_less_than should be something like 0.5 at most, in order to not allow ion weapons to insta-kill Arks and similar high-quality ships. That gets to feeling kinda funky.

That said, you could define something with a super low damage per mark level (0.05 for example for 5% damage per mark level difference), and then an albedeo rating of 1 (so that it can hit absolutely any ship), and then you've got a pretty interesting gun that's powerful against low-level ships, particularly so against higher-health or higher-shield ships (since it's all percentage-based), but not insta-killy at all. So there are cases where you might do all sorts of things.

Vampirism (Self-Healing)

Simply define self_healing_portion on the system in question. A value of 1 will do equal healing to the attacker that it did damage to the defender. Note that a ship's health can't be increased above 0. A value of 0.5 would heal the attacker by half the amount of damage it dealt, and a value of 2 would do twice the healing compared to the damage it dealt.

Self-Damage

Simply define self_damage_portion on the system in question. A value of 1 will do equal damage to the attacker and defender. A value of 0.5 would do half damage to the attacker, and a value of 2 would do twice damage to the attacker.

Repairs To Ships (Engineering)

To set up a ship as able to assist, you must define an assist_range on the ship. Most engineers use VeryTiny3, or Tiny3 if you want it to be a bit larger. As the mark level of the ship increases, the range will automatically increase by the assist_range_multiplier that is defined on the central MarkLevel definitions that you can see in GameData/Configuration/Balance_MarkLevel.

You also must define at least one metal flow sub-node on the entity. In most cases, you will actually want to define multiple. The purposes available are as follows:

• RepairingHullsOfFriendlies lets you repair the hulls of ships, which will also revive any lost sub-squads (if any) as appropriate.
• RepairingShieldsOfFriendlies lets you repair the personal or bubble shields of ships.
• RepairingEnginesOfFriendlies lets you remove engine stun from ships.

Rebuilding

To set up a ship as able to rebuild, you must define an assist_range on the ship, with the same notes on that as are on repair/assistance above.

You also must define a metal flow sub-node of the entity with a purpose of RebuildingRemains.

Assisting Ship Construction (Also Engineering)

To set up a ship as able to assist construction, you must define an assist_range on the ship, with the same notes on that as are on repair/assistance above.

You also must define a metal flow sub-node of the entity with a purpose of AssistConstruction.

Claiming Neutral Entities

To set up a ship as able to claim neutral entities, you must define an assist_range on the ship, with the same notes on that as are on repair/assistance above.

You also must define a metal flow sub-node of the entity with a purpose of ClaimingNeutrals.

Area of Effect Damage (Circular Variants)

~*~

Area of Effect Damage (Beam Variants)

~*~

Multi-Shot Salvos

~*~

Zombification

To set up a weapon as able to use zombification, you must add the line <death_effect_damage type="Zombification" tier_name="Parasite"/> to the weapon. The tier name determines the amount of zombification damage done, via the following mechanic: It acts as a multiplier on the damage done by the weapon. For example, Parasite tier zombification has a mutliplier value of 20, so a weapon dealing x damage would deal 20x zombification damage. A full list of the tiers is located in ...\AI War 2\GameData\Configuration\DeathEffectType - look for the section on zombification in KDL_VanillaEntries.xml You may also wish to add the line added_target_evaluator="ZombifyAsPrimary".

Example statblock (Based on the weapon of the Parasite unit.)

   <system name="WR" display_name="Parasite Bolt"category="Weapon" firing_timing="OnlyInRange" damage_per_shot="70" range="Normal4" shot_speed="Normal" rate_of_fire="Normal" shot_type_data="ParasiteCurvedPinkShot" added_target_evaluator="ZombifyAsPrimary"> <death_effect_damage type="Zombification" tier_name="Parasite"/> </system>

Nanocaustation

Nanocausation works in a similar manner to Zombification, and the associated details are found in the same folders. You may wish to look at some Nanocaust units as an example.

Metabolization

Nanocausation works in a similar manner to Zombification, and the associated details are found in the same folders. A good example unit to look at is the Metabolizing Gangsaw, which you can find in the basegame's fleetships folder.

Spawn Camping

~*~

Weapon Systems Damage (Strength/Reload/Range)

~*~

Personal Shield Penetration/Damage-Boost/Penalty (With Variants)

~*~

Armor Crush/Compression (Low/High Armor Damage-Boost)

~*~

Implosion (High Energy Damage-Boost)

~*~

Regen (Personal/Field)

~*~

Regenerator (Global)

~*~

Attrition (Personal/Planetary)

~*~

Spawning Drone Ships

~*~

Hydra

Spawning of Hydra heads is actually done in several different ways: Units such as the Parasite, Stingray, Vanguard and Warbird Hydra simply spawn their heads on death.

However, this is not the only way in which Hydra heads are generated. For example, Zenith Warrior scourge use a different Hydra head spawning system, in which they spawn heads as they take damage. In this case, the spawning unit must be given two XML attributes:

build_points_per_damage_taken="x" (A sensible starting value for x here would be 1.)

unit_to_make_with_build_points_from_damage_taken="UnqiueUnitNameOfTheHeadUnit"

The number of buildpoints required to spawn a head is given by: (Maxhullhealthofspawningunit+Maxshieldhealthofspawningunit)/(Marklevelofspawningunit+1)

Damage Reduction Field

~*~

Damage Amplification Field

~*~

Damage Reduction Field

~*~

Chain Lightning Weapons

I'm just dumping this here for future reference of anyone who cares: This is as of 15/07/2022, so things may change. Chain lightning notes: 1. The ingame DPS calculation lies totally. It assumes that maximum_number_of_targets_hit_per_shot="N" can be reached, even if the lightning weapon's maximum number of bounce properties can't reach this number. Furthermore, it can also be too low, since the maximum_number_of_targets_hit_per_shot="N" does not actually limit the number of target hit to N, but to N+1. If you set it to 1, the main target and a secondary target will be hit. It ALSO totally ignores aoe_and_beam_damage_multiplier_to_non_primary_target.

2. increasing beam_chains_out_to_max_targets_from_each_source="M" to values of M above 1 does not change the above behaviour, the total maximum number of targets hit remains N+1.

3. aoe_and_beam_damage_multiplier_to_non_primary_target="P" is given values as a percentage, so damage done to the non-primary target is =primarydamage*P/100, and does what it says: it applies to all targets other than the primary, and does NOT apply more than once in longer chains - if the priary target is hit, and the beam chains three times, without splitting, all three secondary targets take =primarydamage*P/100 damage. This value can be set higher than 100 to create a weapon that does more damage to the secondary targets than the primary. Value defaults to 100 if not specified - if this is the desired behaviour, it is better to not include the property at all, since if the property is included but set to P=100, it makes a slightly clumsier tooltip than leaving it out altogether. (If included, tooltip specifies 100% of base damage, if not included, it just says full damage)

4. beam_chains_out_to_target_min_range="200" this is respected, but values like 200 are *very* small. Similarly max range.

5. number_beams_to_fire="Y" can be included in the statblock, will not throw errors, will affect the ingame DPS calculation, but the weapon will not actually fire the extra beams, either visually or in terms of actually doing damage with them. You should use shots_per_salvo="Y" instead.

So real Damage per shot is given by WeaponDamage+(WeaponDamage*min(numberoftargetspossibletochainto, maximum_number_of_targets_hit_per_shot="N")*(aoe_and_beam_damage_multiplier_to_non_primary_target="P"/100), while ingame dps meter thinks the damage per shot is based on WeaponDamage*maximum_number_of_targets_hit_per_shot="N". (Where numberoftargetspossibletochainto is an unholy combo of the real geometry of the battlefield and the maximum chain numbers.)

Wards

Small note: Wards count as stationary targets for the purposes of things like only_targets_static_units="true" and target speed-based damage bonuses.

Weapon Points

To set up a unit to use weapon points, you must add the line

max_number_of_weapon_points="n"

in it's main XML block, where n is whatever number you want to be the maximum. Then, to set up it's weapons to use weapon points, you can use the lines

number_of_weapon_points_to_gain_on_firing="p"

for weapons that should generate points, where p will be the number of points generated per target hit by the weapon (The In-game description is somewhat ambiguous, but this is the number gained for *every* target hit, not per shot fired.). Note furthermore that this interacts somewhat annoyingly with shot compression: A stack counts as one target for the purposes of gaining weapon points, even if 10 "shots" have been fired at the stack for damage purposes and the like. Be sure to consider different stacking levels if using a multishot or area of effect based generator.

number_of_weapon_points_to_consume_on_firing="q" additional_damage_modifier_per_weapon_point="r"

for weapons that should use points, where:

q will be the number of weapon points consumed for each target hit by the weapon. (Note that this really does mean for each shot, a multishot weapon firing s shots, or an aoe weapon hitting s targets, will consume qs weapon points. Further, a weapon will only ever consume exactly this many points, shots cannot be partially empowered. If a weapon has enough points to empower it's damage against some of it's targets but not all, it will empower as many damage instances as it can, and the rest will be of base strength. The behaviours are not affected by fires_salvos_sequentially being true or false. Finally, note that weapon points will not be needed for the weapon to fire, if they are not available it will fire but deal it's base damage.)

Perhaps an example would aid clarity. A weapon has 100 weapon points available, and number_of_weapon_points_to_consume_on_firing="30". The weapon hits 5 targets, whether by being an area of effect weapon, being a multishot weapon, etc. Then 3 targets will take the boosted damage, 2 targets will take the base damage, and the unit will have 10 weapon points remaining. The weapon gains no points in the meantime, and fires again. It hits 5 targets, deals base damage to all five, and the unit still has 10 weapon points remaining.

Now let's consider another example. A weapon has 100 weapon points available, and number_of_weapon_points_to_consume_on_firing="30". The weapon hits 2 targets. Both targets take the boosted damage, and the unit will have 40 weapon points remaining. The weapon gains no points in the meantime, and fires again. It hits 2 targets, deals boosted damage to one, base damage to the other, and the unit still has 10 weapon points remaining.

Now, it is also important to understand that a stack counts as one target for this purpose as well. So if the weapon hits a stacked unit with stack size >s, and thus only hits that stack, it will only consume q weapon points, and the stack will take damage equal to a boosted hit against all s targets (ignoring overkill.) This means that when using weapon points to empower AOE or multishot weapons, it is important to consider how many targets may be taking boosted damage in the different possible stacking situations.

Finally: (rq+1) will be the multiplier applied to the weapon's damage. (So for example, a weapon firing against one target and consuming 10 points to empower itself with an additional_damage_modifier_per_weapon_point value of 0.5 will deal (0.5*10+1)=6 times it's base damage.

What about if the unit using weapon points is stacked, you ask? I have no idea, test it and find out. ;)

Further note as of 29/10/2022: Weapon points do not amplify corrosive damage if the weapon is partially normal damage and partially corrosive. I don't know about fully corrosive shots.