Quick answer: Elemental reaction bugs come from combinations. Whether a reaction fires depends on which elements are applied to a target, their order and timing, and the reaction rules that match. Capture the element states present, the incoming element, the rule that matched or failed, and the resulting reaction so a wrong or missing reaction can be reconstructed.
Elemental systems promise emergent combat: apply water then lightning and get a shock, freeze a burning enemy and get steam. That promise is built on a rules table that matches combinations of element states, and the bugs that emerge are precisely about which combination was present and which rule fired. A player reporting that two elements did not react, or reacted wrongly, is describing a specific state of element auras on a specific target. This post is about capturing the element combination state and reaction resolution that makes these emergent bugs reproducible.
Reactions are combination logic
An elemental reaction is a lookup: the system sees the elements currently on a target, an incoming element arrives, and a rule decides what happens. The richness comes from the table being large and order-sensitive. Applying fire to a wet target differs from applying water to a burning one; some elements consume each other, some coexist as auras with durations. The bugs live in the gaps: a combination with no matching rule, two rules that could both match, or an element that expired a frame before the reaction would have triggered.
These bugs are emergent, which is exactly why they are hard. The system works for the combinations you tested and breaks on the one a player stumbled into. They cannot tell you that the target had a half-second of residual frost aura when the lightning landed; they only know the shock they expected did not happen. Without the element states present at the moment of application and the rule resolution, you are searching a combinatorial table for a case you cannot name.
Capturing the element state on the target
The core data to capture is the set of element auras on the target at the moment a new element is applied. For each, record the element type, its remaining duration, its strength or stacks, and its source. A reaction that failed to fire is usually explained the instant you see that the prerequisite element had already expired, or that its strength was below the threshold the rule required. The target's element state is the precondition, and the precondition is what players cannot observe.
Capture the incoming element with the same detail: type, strength, and the source applying it. Order and timing are decisive, so a timestamp on each application matters. Two players can apply the same two elements and get different reactions purely because the application order or the gap between them differed. With timestamps on the existing auras and the incoming element, you can reconstruct the exact temporal arrangement that produced, or failed to produce, the reaction the player expected.
Rule resolution and priority
When a reaction misbehaves, you need to see how the rules table resolved. Capture which rule matched the combination, or that none did, and if several could match, the priority logic that chose between them. A frequent bug is two valid reactions where the wrong one wins, or a more specific rule being shadowed by a general one. The player sees a steam reaction where they expected a freeze; only the matched-rule record explains that a broader rule had higher priority than intended.
Record the outcome the rule produced as well: which elements it consumed, which it left, the damage or status it applied, and any new aura it created. Reactions often chain, where one reaction's output is another's input, and a chaining bug is unreadable without the intermediate states. Capturing the before, the matched rule, and the after for each step lets you walk the chain and find the link where consumption or priority went wrong, instead of guessing at a cascade you cannot see.
Reproducing a reaction from captured state
With the target's element auras, the incoming element, the timestamps, and the matched rule recorded, a reaction report becomes a deterministic scenario. You set up a test target with the captured auras and durations, apply the incoming element with the recorded timing, and watch the rules table resolve. If the wrong reaction or no reaction reproduces, you have isolated it; if not, the captured state usually names the missing factor, often an aura strength or a duration that the live build computed differently than your test.
These captured combinations are excellent regression fixtures because elemental tables are notoriously fragile. Adding one element or tweaking one rule's priority can silently change dozens of interactions. Re-running real reported combinations after each table change tells you immediately whether you broke an existing reaction or shifted a priority. Given how much of an elemental game's appeal is the consistency of its reactions, protecting that table with saved real-world cases is among the highest-value tests you can keep.
Setting it up with Bugnet
Bugnet's report button captures game state automatically, which suits elemental reactions perfectly. When a player reports a reaction that did not fire or fired wrong, you attach the element auras on the target with their durations and strengths, the incoming element, the timestamps, the rule that matched or failed, and the resulting consumption as custom fields. The player describes the surprise in a sentence while Bugnet preserves the combination and resolution that caused it, so you are not hunting the rules table for a case nobody can name.
Occurrence grouping folds a recurring reaction bug into one issue with a count, so a broken or exploitable combination many players found rises above the noise. Filter by custom fields like element pair, target type, or matched rule to pinpoint the offending entry fast, and crashes during a reaction-heavy fight arrive with stack traces and device context. The combinations, the rule resolutions, the duplicates, and the crashes all live in one dashboard you can sort by how many players each affected.
Keeping an elemental system honest
The practical discipline is to make element state and rule resolution observable. Keep each target's current auras snapshot-able and log every reaction with its inputs, matched rule, and outputs. Attach that to reports automatically so a player who triggers an unexpected reaction hands you the full combination without knowing they did. None of this dilutes the emergent feel; it just means the emergence is auditable when it goes wrong.
Elemental systems get more entangled with every element and rule you add, and the joy of them depends on players trusting the reactions to be consistent. Capture combination and resolution state early, and you can extend the table confidently, checking new rules against real reported states instead of imagining the matrix. Your reactions stay coherent as the system grows, and the emergent moments players love stay reliable instead of devolving into a pile of edge cases.
Reaction bugs are combination bugs. Capture the auras present, the incoming element, and the matched rule and an emergent surprise becomes a case you can replay.