Health, Shields & Displayed Damage

Damage popups have their own scaling

For a supported source slot and nonzero weapon multiplier W, displayScale = (1 + (ItemPower − 1) × 0.05) / W. Power 101 gives a numerator of 6; Power 143 gives 8.1. If a packet is B × W × otherFactors, multiplying it by this display scale cancels W in that expression.

The display helper and raw Health/Shield application are separate. Final popup formatting, rounding and every message consumer are not fully traced. A larger floating number cannot by itself establish the same increase in actual health removed.

A damage request can be rejected or clamped

The selected negative-Health handler rejects invulnerable targets and negligible magnitudes. An accepted modifier then passes through native attribute storage and its bounds. Overkill, a minimum Health bound and float32 precision can make health lost differ from the requested magnitude.

For a potentially lethal effect carrying the SW.Status asset predicate, the handler rejects the entire modifier when the target has NoExecute or the effect has StatusNonLethal. It does not simply reduce Health to 1. With Health 100, a qualifying nonlethal request of 20 can apply, while 100 or 150 is rejected.

A follow-up static trace shows the runtime effect finalizer adds the current type tag to both asset and owned tags. Generated Burning and Poisoned effects therefore receive their SW.Status descendant tag on that path. The additional NoExecute or StatusNonLethal condition is still required; this does not make all damage over time nonlethal.

Nine further controlled native checks connect GetAllAssetTags to the Health gate: definition asset tags and dynamic asset tags are combined, while target-owned status alone does not substitute for an effect asset tag. The sublethal cases bypass this tag check. Tag union and parent expansion remain explicit engine fixtures; this is not a full actor-lifecycle test.

Shield routing depends on the effect's binding

The reviewed negative-Health path redirects to Shield only when current Shield is positive and the effect's ProtectedByShield value is positive. Its missing-binding fallback is zero. Having Shield points alone does not select that branch.

In an isolated native fixture, Health 100 / Shield 50 receiving damage 80 with protection enabled leaves Health at 100 and clamps current Shield to 0. The selected routine redirects the whole request; it does not split off another Health modifier. This is not a universal no-overflow guarantee: reactive listeners, persistent modifiers and alternative paths were excluded from that fixture.

The conditional poison example can now be carried through isolated Health storage: from independent Health-100 targets, a request of 4 removes 4 and a request of 64 removes 64 under the supplied neutral conditions. Actual bangle-to-target gameplay bindings still have to be closed before this becomes a general build prediction.

Other survival and maximum-health rules

The separate damage-packet path has conditional survival protection. The shipped player definition uses player-count thresholds of 40%, 60%, 70% and 80% for one to four counted players. When enabled, a lethal packet must meet both the damage threshold and current-health threshold; its damage is then reduced to current Health minus 1% of maximum Health, with a nonnegative final result. This is distinct from the status handler's all-or-nothing rejection.

For a valid owner and nonzero old maximum, the HealthMax callback writes clamp(currentHealth × newMax / oldMax, 0, newMax) as the new Health base. It preserves the fraction in that callback; other equipment, healing or respawn behavior can do additional work.

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 ↗