Direct modification of a creature’s resistance table is not natively supported (at least, based on current available APIs and exposed methods in most TFS-based engines). In other words, there is no straightforward function that allows you to mutate the intrinsic resistance attributes of a Creature instance at runtime.
However, there is a practical workaround.
You can leverage
Creature Events, particularly those hooks that intercept damage processing (e.g., events handling primary/secondary damage values such as onHealthChange). These hooks allow you to dynamically adjust incoming damage before it is finally applied to the creature.
To associate this behavior with specific creatures, you have a couple of options:
- Static mapping approach
Maintain a Lua table indexed by creature name (or race/type), where you define custom modifiers. During the event callback, you check whether the target creature belongs to this set and apply your transformation logic accordingly.
- Dynamic tagging via storage
If your engine supports per-creature storage, you can assign a storage value during onSpawn. This effectively “tags” the creature instance at runtime. On subsequent damage events, you simply read this storage to determine whether the modifier should be applied. This approach is more flexible and avoids hardcoding logic by creature name.
Conceptual Example
Assume a creature has a built-in
95% sensitivity to Energy damage. This means that, from an incoming 100 Energy damage, only 95 damage is effectively applied after internal resistance calculations.
Importantly, this base resistance remains unchanged — you are not modifying the engine’s internal resistance table.
Now, suppose you introduce a custom modifier via a Creature Event that
increases incoming elemental damage by 20%.
The flow would be:
- Incoming raw damage: 100 Energy
- Engine applies base resistance (95% sensitivity):
→ 95 damage
- Your onHealthChange hook intercepts this value and applies a +20% modifier:
→ 95 * 1.20 = 114 damage
Final applied damage:
114
Key Insight
This method does
not override resistances, but rather
post-processes the damage after the engine’s internal calculations. Conceptually, you are introducing a secondary transformation layer in the damage pipeline.
Advantages of this Approach
- Does not require engine-level modifications
- Fully scriptable and extensible
- Works per-instance (not just per creature type)
- Compatible with existing resistance systems
Limitations
- Order of operations matters (you are modifying post-mitigation damage)
- Can become harder to reason about if multiple scripts stack modifiers
- Requires careful handling to avoid unintended scaling (e.g., stacking multipliers)
An orientation:
Check this .lua, i think your TFS/Canary can be similar (because Blacktek have relation with TFS about Luascript functions)