History
As a follow-up to the discussion regarding #3079, which proposes entirely preventing Fire (F) and Konstant (k) from being allowed in the same custom recipe, this issue is dedicated to exploring, testing, and documenting specific edge cases where the two skills can peacefully coexist without causing problematic logic or UI breaks (as discussed in #1802 and elsewhere).
A Brief summary of the three issues caused by F and k
- UI Display Glitch: The user interface fails to show valid attack indicators or communicate legal fire choices due to the disjointed math ranges created by Konstant dice.
- Inverted Math Bug: The engine incorrectly assumes fire support always reduces a target value, causing calculation loops to flip and malfunction when a Konstant die introduces negative values.
- Value State Retention Bug: The engine doesn't log which physical die receives fire points; because normal dice reroll, this goes unnoticed until a Konstant die is involved and fails to retain its permanently modified post-attack value.
The purpose of this issue
@blackshadowshade has expressed interest in pursuing a solution that reduces the problem space, rather than implementing a blanket ban or attempting a comprehensive programmatic fix for all possible interactions. By identifying "safe" combinations, we can potentially preserve design flexibility for things like: testing custom recipes (on staging), creating and adding new buttons to the production site, or allowing additional RandomBM configurations. I have offered to help identify where Fire and konstant play nicely by performing testing on the staging site.
Initial Safe Instances & Edge Cases Identified
F(1) and k(X) in the same recipe
Reasoning: A 1-sided Fire die $F(1)$ cannot actively contribute fire points from its base state because it cannot be turned down lower than 1. Because it cannot fire assist other dice under normal conditions, it avoids the problematic overlapping logic loops with Konstant dice.
F and k on the same die: Fk()
Reasoning: Initial observations suggest that when both skills reside on the exact same die, they do not seem to trigger the conflicting interaction bugs found when they are on separate dice in the same recipe.
these both assume F and k do not occur elsewhere in the recipe
Next Steps & Testing Goals
History
As a follow-up to the discussion regarding #3079, which proposes entirely preventing Fire (F) and Konstant (k) from being allowed in the same custom recipe, this issue is dedicated to exploring, testing, and documenting specific edge cases where the two skills can peacefully coexist without causing problematic logic or UI breaks (as discussed in #1802 and elsewhere).
A Brief summary of the three issues caused by F and k
The purpose of this issue
@blackshadowshade has expressed interest in pursuing a solution that reduces the problem space, rather than implementing a blanket ban or attempting a comprehensive programmatic fix for all possible interactions. By identifying "safe" combinations, we can potentially preserve design flexibility for things like: testing custom recipes (on staging), creating and adding new buttons to the production site, or allowing additional RandomBM configurations. I have offered to help identify where Fire and konstant play nicely by performing testing on the staging site.
Initial Safe Instances & Edge Cases Identified
F(1) and k(X) in the same recipe
Reasoning: A 1-sided Fire die$F(1)$ cannot actively contribute fire points from its base state because it cannot be turned down lower than 1. Because it cannot fire assist other dice under normal conditions, it avoids the problematic overlapping logic loops with Konstant dice.
F and k on the same die: Fk()
Reasoning: Initial observations suggest that when both skills reside on the exact same die, they do not seem to trigger the conflicting interaction bugs found when they are on separate dice in the same recipe.
these both assume F and k do not occur elsewhere in the recipe
Next Steps & Testing Goals
Run comprehensive automated or manual testing on staging to verify if Fk() dice consistently behave safely.
Identify and define the exact mathematical or logical boundaries where F and k interactions break the engine.
Propose an arbitrary or narrow rule restriction that minimizes UI/engine changes while keeping safe custom designs playable.