Grindstone, Bangles & Damage over Time

A small tick base makes a flat bonus powerful

Grindstone authors +15 to BaseDamageBonus for 6 seconds using the NonStacking trait. It is a flat internal bonus, not +15% and not automatically +15 displayed damage. Blaze Bangle and Blight Bangle have separate added-hit and status payloads.

MMC_Damage's missing Health input falls back to 1. In a qualified attack with that fallback and otherwise neutral factors, adding Grindstone changes the base from 1 to 16. Burning's −2 coefficient gives requests of −2 and −32; Poisoned's −4 coefficient gives −4 and −64. The 16-fold ratio is a conditional arithmetic example, not a universal measured multiplier or proof of exactly 20×.

Community reports support a large interaction, but do not establish controlled gear, target, patch or tick-by-tick measurements. The selected status builder writes Duration and copies attack-source tags; it does not write Health. Selected game-global hooks are no-ops, but all surrounding components and callbacks have not yet been excluded as possible input writers.

A bangle hit and its later status are different calculations

The selected added-damage consumer requires an exact melee attack-source match. Matching bangle buffs collect statuses in a set, while one selected additional instant-damage view is overwritten by later matches. Two active bangles can therefore collect both statuses without proving two independently added instantaneous components. Actual iteration order remains unresolved.

The bangle's extra instant component has authored base 2. The hit-to-status event forwards its attack source and a literal magnitude of 1, rather than the final direct-hit damage. The reviewed forwarding path does not automatically copy a critical tag into the status.

Attack tags can qualify a tick for the flat attack bonus. A melee source tag can qualify weapon-power and empowerment factors. Those facts do not automatically make a periodic tick a critical, an instant hit or a recipient of every melee-damage modifier.

Status duration, periods and recalculation

Full Burning has a −2 coefficient, a 0.5-second period and a default duration of 4 seconds. Full Poisoned has a −4 coefficient, a 1.1-second period and a default duration of 15 seconds. Both enable execution on application and use NeverReset for their periodic timer. These are not enough to assert an exact tick count at expiration or after reapplication.

Burning.Short uses a 0.4-second period and Poisoned.Short uses 0.8. Application exclusions distinguish short and full variants. Never substitute a short variant's period for every source of that status.

Negative-status duration is default duration × source negative-duration-given factor × target negative-duration-received factor × event magnitude. Positive statuses use their positive-duration counterparts. A value of 1 is neutral.

All 47 reviewed damage captures are non-snapshot captures linked to actor attribute aggregators. Periodic execution recalculates its modifier before applying the coefficient. Later ticks can therefore use changed resolved attributes, including a Grindstone bonus appearing or expiring. This does not establish the order of buff expiration and a simultaneous tick, nor an extra tick whenever an attribute changes.

The resolved full Burning and Poisoned policies use AggregateByTarget with stack limit 1. The child NeverReset setting survives inheritance from NonStacking, whose own raw default is ResetOnSuccessfulApplication. The selected duration policy refreshes on successful application. The recovered timer rules below still require explicit frame timing and expiration-policy assumptions before generating a scenario.

Reapplication can change whose damage is used

For an accepted authoritative reapplication of the same full-status effect definition, the native stack path replaces the stored specification with the incoming specification and keeps the stack count capped at one. AggregateByTarget does not require the same attacker. The replacement includes source context, source captures and set-by-caller inputs; this branch does not select the stronger damage value.

A weaker source can therefore replace a stronger source on this recovered path. Later periodic calculations use the latest accepted specification and its linked source attributes. This matters when one player has an active Grindstone bonus and another player reapplies the same status. It is a conditional native-code result, with no co-op gameplay measurement yet.

The full-status NeverReset policy skips the periodic scheduling block on accepted refresh, including that block’s additional on-application execution request. Duration refresh is a separate operation. Refreshing a status is therefore not grounds to add another independent damage stream or assume a fresh immediate tick.

Application acceptance is essential: overflow denial and nonauthoritative control cases preserved the old specification. Immunity, short/full variant exclusions, reactive callbacks and online replacements remain separate checks. Matching uses the gameplay-effect definition identity; sharing a related tag is insufficient.

Twenty-four controlled native cases cover stack lookup, replacement and scalar inheritance. A conditional adapter matches twenty-one of those cases, rejects eighteen invalid inputs and tracks changing source attributes at explicitly supplied execution times. It does not generate tick timestamps, DPS or final Health loss.

Frame timing, catch-up and the last tick

Execution on application is registered through the timer manager. It is not a synchronous damage call in that branch. Whether it can run in the current timer pass or a later one depends on the registration phase and the GuaranteeEngineTickDelay setting. The live setting and authoritative frame timing have not been measured.

The selected timer manager processes an active deadline only when its internal time is strictly greater than that deadline. A due repeating timer computes trunc((internalTime − deadline) / period) + 1 callbacks. The normal timer wrapper used here leaves max-once-per-frame disabled, so delayed frames can request multiple calculations in one pass.

Before removing an effect under the tested ClearEntireStack policy, the duration callback checks its periodic timer. If no more than 0.0001 seconds remain and the effect is not inhibited, it can request a final periodic calculation, then clear that timer. Equal deadlines follow the native heap order; they do not have an assumed universal priority.

In controlled native-code scenarios, four-second Burning requested nine calculations with 1/32-second frame steps and ten with supplied 0.5-, 1- or 4.5-second steps. Fifteen-second Poisoned requested fourteen with 1/32-second steps. These are conditional engine scenarios with matching supplied clocks, bound delegates and an explicit expiration policy. They are not measured gameplay totals or evidence of a client-frame-rate damage advantage.

The conditional timeline calculator matches all thirty native timing cases and rejects twenty-two invalid inputs. In a saved Poisoned scenario with neutral factors and an explicitly absent Health binding, a supplied +15 flat bonus from t=1 to t=7 produces six requests of −64 and eight of −4: −416 internal signed modifier units in total. This sum is not final Health loss, displayed damage or DPS. Application acceptance, live attributes, clock steps and policy remain explicit inputs.

Rejection, immunity and paused status ticks

Applying a status and allowing its ongoing effect are separate decisions. The recovered component checks application requirements first; enabled removal requirements can also reject it. Ongoing requirements can suppress an existing effect without rejecting creation. Required tags must all match, while any matching ignored tag blocks that predicate. An owned child tag can satisfy a parent requirement; owning the parent does not satisfy a child requirement.

When owned tags change, a valid active effect first checks enabled removal requirements. Otherwise its ongoing requirements request active or inhibited state. Empty removal requirements do not remove every effect. Authority and the explicit client-removal switch affect whether removal checks run; these controls cannot be omitted when composing a scenario.

Six native transition sequences, covering sixteen transitions, preserve the existing periodic and duration handles for the tested NeverReset status fixtures. Setting the same inhibited state again does not rerun the transition handlers. In those fixtures, suppressing then resuming a status does not restart its periodic clock. Reactive listeners, cues and granted abilities were empty in the test, and the complete live object/default-copy path remains unverified.

A software-composed Poison example uses the earlier +15 flat-bonus schedule but supplies immunity from time 2 through time 8. It produces eight requests instead of fourteen, with a signed modifier sum of −92 instead of −416 in that specific schedule. These are requested modifier units, not final Health loss, displayed damage or DPS. The immunity schedule is an input, not a newly observed gameplay fact.

The selected status application virtual call now resolves to the traced core. The three inspected definition-component application callbacks make no further specification changes in the native fixture. This does not exclude all live delegates or establish that the Health and ProtectedByShield inputs are always absent.

Fire and electricity have a distinct fusion rule

The recovered fusion path combines Burning and Conductive into Overload, removes the constituent statuses and authors 2.3 seconds of fusion immunity. No Burning + Poisoned fusion row was found in the shipped table. Fire and electricity therefore cannot always be modeled as two unchanged parallel statuses. Overload damage and the exact fusion/immunity schedule remain unresolved.

Sources & data coverage

Reviewed local game tables and selected native instructions from Windows build 1.1.1.0. Original-instruction tests use synthetic actors and engine services. They are not gameplay measurements; online overrides have not been observed.

Reviewed evidence manifest and scalar data ↗