Customize DoT tick schedules

[DaloLorn]

Problem Overview

Generally, the persistent effects for DoTs such as bleeding, burning, or poison are built with a _WatchRule of eGameRule_PlayerTurnBegin, causing them to tick at the start of the unit owner's turn. This is usually okay; the only exception I've heard of so far has been Requiem Corrosion, which would be pretty painful if it ticked before you had a chance to heal it.

However, with the use of Highlander features such as #89 and #629, and mods such as TeslaRage's Ablative Vests, or Iridar's Vest & Plating and/or Armor Overhaul, these effects have the potential to guarantee an inordinate amount of medbay time for anyone affected.

Proposed Solution

Add new configs, similar to those in the above-linked features, to override the default tick schedule. As I assume eGameRule_PlayerTurnEnd is the only other legitimate option for a DoT's _WatchRule, Boolean flags seem sufficient:

[XComGame.X2Effect_Burning]
BURNED_TICKS_AFTER_TURN=true ; Make burn and acid DOTs tick on turn end

[XComGame.X2StatusEffects]
POISONED_TICKS_AFTER_TURN=true ; Make poison DOT tick on turn end
BLEEDING_TICKS_AFTER_TURN=true ; Make bleeding DOT tick on turn end

That said, this solution lacks granularity: X2Effect_Burning is used for almost every custom DoT in the community, and it may make sense for different damage types to have different behaviors. Simply recycling #89's design seems... inadequate, and more refinement is warranted. If one is going to the trouble of making such sweeping changes to the game's rules, OPTCing against half the modding community will be an inelegant and needlessly laborious process when a few extra lines of code could solve it at the source.

To resolve this, a list of damage types could be provided to cause the inverse behavior, e.g. radiation burns ticking on turn start when everything else ticks on turn end (or vice versa, as is more convenient to a given modder):

[XComGame.X2Effect_Burning]
BURNED_TICKS_AFTER_TURN=true             ; Make most burn and acid DOTs tick on turn end
+BURNED_TICKS_REVERSE_SCHEDULE=Radiation ; But make radiation DOT tick on turn start!

; Or if the default is to tick on turn start...

[XComGame.X2Effect_Burning]
BURNED_TICKS_AFTER_TURN=false            ; Make most burn and acid DOTs tick on turn start
+BURNED_TICKS_REVERSE_SCHEDULE=Radiation ; But make radiation DOT tick on turn end!

Alternatively, a single config could cover everything burn-related, simply enumerating all damage types that break from the vanilla default:

[XComGame.X2Effect_Burning]
+BURN_TYPES_TICKING_AFTER_TURN=Radiation ; Make radiation DOT tick on turn end!

This is a functionality I'd also like to backport to #89, for the same reasons, but I'm not sure about the protocol here. Would that be considered an update to the original feature, or would it require a separate issue?

Either way, backwards compatibility seems to demand keeping the original config and adding an exclusion/inversion list, lest we break existing mods relying on that flag.

Can Self-Serve?

Yep. I'll open a PR soon, after I'm done setting up my dev environment and running the appropriate tests.

[chrishayesmu]

As I assume eGameRule_PlayerTurnEnd is the only other legitimate option for a DoT's _WatchRule, Boolean flags seem sufficient

There's one other interesting case: eGameRule_UseActionPoint. I could certainly see somebody wanting a ruleset where DoTs don't hurt if you don't move, mirroring the behavior of acid in the original Long War for XCOM: EW.

If this was 2017 and numerous big overhauls were still on the horizon, I'd strongly push for making this work for both game rules. Here in 2025, I don't have as strong of an opinion, but I do think it's worth consideration. I will say that it's possible this doesn't even work, because I don't see any calls to BuildContextFromGameRule(eGameRule_UseActionPoint) in the code, so it may be a defunct game rule. A simple test could probably rule that out quickly.

[DaloLorn]

Ooh, interesting. I'd need to redesign the API a tad, but I don't mind...

Perhaps a struct mapping burn damage types to watch rules, and a pair of watch rule configs for poison/bleeding?

[faanlez]

My question is that is this something the Highlander needs to have or could you just use OPTC to change these?

[DaloLorn]

It would take an extensive campaign of identifying and adjusting the relevant effects everywhere. Feasible for the base game, irksome for a single TJ-scale modlist, nigh-impossible for public release.

There is also precedent for this change: This is exactly as OPTC-able as #89 and #629 were, on the grounds that it touches the exact same helper functions as they did, and changes exactly as many properties of the affected templates as they did.

[faanlez]

Honestly, I don't like those in Highlander either, really, because it doesn't guarantee all poison or bleeding or burning effects are actually adjusted. Mods can have their own effect code that doesn't get affected and this will have the same problem.

It's really not that difficult to programmatically detect damage over time effects by going through all places that have effects and casting to the specific class or checking effect names or other properties to see if it's a damage over time effect and of which type.

So okay, there is precedent for similar config toggles but they were ill-conceived in my honest opinion. They are not the only examples of such missteps in Highlander.

[DaloLorn]

Revisiting this conversation because A) Bio Division proved your point, and B) I'm approaching the point of opening PRs for my other stuff and need to get this resolved one way or another:

going through all places that have effects
Would this be iterating on all the ability templates in the game, to find all persistent effects attached to those templates (and then run tests on them)? Or am I overlooking some other mechanism by which a debuff might be attached to a unit?

So far, I figure I'd need to:

• Poison: Check for any X2Effect_Persistent with an ApplyOnTick array containing X2Effect_ApplyWeaponDamages where EffectDamageValue.DamageType == 'Poison'˙.
• Bleed: Same, but with Bleeding instead of Poison.
• Any kind of burn effect: ... I could check for X2Effect_Burning, but honestly, I can probably just do literally the same thing again, but for whatever damage types I want.
• Elerium Poisoning: Uhh... really just the same thing again, now that I look at its code.