I have configured the following two settings in TakenDamageSettings:
Condition A: “Attribute A hits” – White filter, no hitstop
Condition B: “Attribute A hits and Switch A hits” – Blue filter, with hitstop
When arranged in this order, the first hit applies the white filter, and the next hit applies the blue filter. Hitstop is applied during both hits.
If I reverse the order of Conditions A and B, the white filter is always applied, but hitstop is also applied.
What is the specification behind this behavior?
I had assumed that the arrangement order determined priority, and that only one setting meeting the conditions from top to bottom (or bottom to top) would be applied. However, it seems as though both Conditions A and B are being applied.
I have registered several TakenDamageSettings, but the branching conditions can only check for attributes and switch states (on/off). Since I cannot set conditions for when a switch is off, it is very difficult to configure settings so that conditions do not overlap.
The three main things I want to know are:
Is the priority of TakenDamageSettings from top to bottom or bottom to top?
Is only the first setting that meets the conditions applied, or are all matching settings applied?
If settings are applied simultaneously, does this apply only to filters, or also to damage multipliers, hitstop, and all other parameters?
I would appreciate your guidance. The version is 1.41.
Whether priority is applied from top to bottom or bottom to top
Whether only the first condition is applied, or all of them
There is no priority. Conditions are simply executed in order from top to bottom, and all conditions are executed. Since all conditions are applied, the filter set last will be the one that is displayed.
Whether only filters are applied, or also damage modifiers, hit stop, etc.
All of them. Damage modifiers (the HP reduction itself is repeated for each count), hit stop, sound, flashing, damage numbers displayed — everything is executed according to its respective settings.
First, it should be noted that the design does not account for overlapping conditions. It is designed on the assumption that attributes and switches will be configured to prevent overlaps. However, as you pointed out, the inability to set “when the switch is off” is indeed a problem.
I will add the ability to configure “when the switch is off.”
Thank you. Thanks to your guidance, I was able to understand the specifications accurately.
I also appreciate you considering the conditions for turning the switch off. If I could add one more request, I thought it would greatly increase flexibility if variable values could also be used as conditions. I apologize for making an unreasonable request, but I would be grateful if you could consider this again when the opportunity arises.