ZOA Conditions

ConditionDuration carries a DurationType and two numbers, and the type decides what those numbers mean. Infinite lasts until something explicitly removes it, which is right for equipment passives and toggled states, and its Tick does nothing at all. Timed treats Duration as seconds and counts it down against delta time, expiring when it crosses zero. TickCount treats Duration as a number of ticks and TickInterval as the seconds between them.

The tick loop is where damage-over-time lives. The instance accumulates delta time and, while the accumulator exceeds the interval and ticks remain, it subtracts the interval, decrements the remaining tick count by one, and counts a fired tick. Tick returns how many fired during that update, which is normally one but is two or more after a frame hitch, and the service re-raises that count on its Ticked event. A poison that applies damage per pulse has to read that count; a handler assuming a single pulse silently loses damage on a stutter.

The three static factories are how you build them: ConditionDuration.Infinite, ConditionDuration.Timed with seconds, and ConditionDuration.Ticks with a count and an interval.

When Apply runs and the entity already has an unexpired instance of the same condition id, the definition's StackingPolicy decides the outcome and no second instance is ever created. There are five policies and each answers the question differently.

None does nothing and returns the existing instance, which suits a binary state such as sprinting. Stack adds one stack, capped at MaxStacks, and raises StacksChanged only if a stack was actually added, so a re-application at the cap is silent. Refresh resets the remaining duration to the definition's maximum and clears the tick accumulator without touching stacks. StackAndRefresh does both, which is the classic damage-over-time behaviour where each new hit deepens the effect and resets the clock.

KeepStrongest compares definitions rather than instances. It sums the absolute additive values plus the absolute distance of each multiplier from one across both definitions' modifier lists, and if the incoming definition scores higher it removes the existing condition and applies the new one, inheriting the existing instance's source. Otherwise the existing instance stands. That is how two different grades of armour buff coexist without stacking into something unintended.

MaxStacks is only meaningful when the policy is not None, and the condition asset clamps it to at least one on validate.

A ConditionModifierEntry is authored data: a StatId, an additive term, a multiplier where one means no change, an evaluation Order, and a ScalesWithStacks flag. Its ToStatModifier method converts it into the StatModifier struct that com.zoa.stats evaluates, and that conversion is where stacking becomes arithmetic.

When ScalesWithStacks is false, the entry's values pass through unchanged no matter how many stacks are present. When it is true, the additive term is multiplied by the stack count, and the multiplier is scaled around one, so a 1.2 multiplier at three stacks becomes 1.6, not 1.728. The excess scales linearly because compounding makes high stack counts explode, and linear growth is what a tooltip reading plus twenty percent per stack promises.

Every modifier a condition produces carries a source string of the form condition: followed by the condition id, so a stat that came out wrong can be traced back to the effect that moved it.

ConditionInstance implements IStatModifierSource, which is the same interface every other modifier source in the project implements, so an instance can be fed straight into stat evaluation. It caches its modifier list and only rebuilds when the stack count changes, and an expired instance returns an empty array.

The aggregation step is IConditionModifierPipeline. CollectModifiers gathers every modifier from every unexpired condition on an entity, and the overload taking a StatId filters to one stat, which is the cheaper call when you only need one number. ConditionTracker implements both the service and the pipeline, so the same object that owns the instances is the one that answers the query.

The final evaluation is StatBlock.Evaluate, which sorts the modifiers by Order, then walks them applying additive first and multiplier second for each entry in turn. Order therefore carries weight: a plus ten that runs before a times two is worth twice as much as one that runs after it, and a condition that intends to be a final scalar wants a high order.

ConditionCategory is a single required enum value describing behavioural intent: Buff for positive effects, Debuff for negative ones, Environmental for neutral world state such as wet or irradiated, State for internal mechanics such as reloading or aiming, and Passive for equipment-granted bonuses. It drives UI grouping, icon styling and dispel interactions, and GetByCategory queries it directly.

Tags are a free-form list on the definition and a condition can carry any number. They exist for the cross-cutting queries a single category cannot express: fire, dot, movement. GetByTag matches them. The rule of thumb is that category answers what kind of thing this is, and tags answer what rules it participates in.

DefaultConditions names the shipped ids across all five categories, from poisoned, bleeding, burning, slowed, stunned, weakened, suppressed and irradiated through regenerating, haste, damage_boost, armor_boost, shielded and adrenaline, the environmental set, the state set, and equipment passives such as scope_accuracy and heavy_armor_slowdown. Custom conditions should pick ids that do not collide with these.

Conditions do not tick themselves. The owner calls Tick with an entity id and a delta, or TickAll to advance every tracked entity, and TickAll snapshots the key list first so that an expiry firing a handler that touches another entity cannot invalidate the iteration.

Within one entity's tick, each unexpired instance is advanced, a non-zero tick count raises Ticked, and anything that has become expired is collected into a reusable buffer. Removal happens after the loop, and each removal raises Removed. Instances that were already expired when the tick started are collected and cleaned up in the same pass, which is how an instance force-expired by gameplay code gets its Removed event on the next tick.

Four events cover the lifecycle: Applied when a new instance is created, Removed on expiry or explicit removal, Ticked with the number of ticks that fired, and StacksChanged when a stack is actually added. A re-application under a Refresh policy raises none of them, because nothing observable changed except the clock.