Is your feature request related to a problem? Please describe.
Dialogue conditions are an amazingly versatile JSON-driven system, and @Ramza13's excellent work allowesit to affect the game outside of conversations. Having effect_on_conditions trigger on set effect intensities would allow for unhardcoding a lot of player-only effects (blood loss messages and toxin symptoms, for example), while additionally filtering on affected body part could be used to enhance sequential localized effects and potentially unhardcoding the bite -> infection progression for the player at least.
Describe the solution you'd like
Expand u_has_effect to include an optional check for the intensity level and affected body part of the effect, and allow u_add_effect to specify the same fields.
Describe alternatives you've considered
Maybe a single field to direct u_add_effect to add any effects to the same bodypart if its condition was a u_has_effect on a local effect, but that sounds potentially janky.
Additional context
As an example, blood loss' messages begin at player_hardcoded_effects::820, moving those out to JSON would also allow them to be snippet-based and as such a bit less repetitive.
An expansion would be putting this information into variables and allowing u_add_effect, etc to pull these specifications from variables (if not already possible in general).
Is your feature request related to a problem? Please describe.
Dialogue conditions are an amazingly versatile JSON-driven system, and @Ramza13's excellent work allowesit to affect the game outside of conversations. Having
effect_on_condition
s trigger on set effect intensities would allow for unhardcoding a lot of player-only effects (blood loss messages and toxin symptoms, for example), while additionally filtering on affected body part could be used to enhance sequential localized effects and potentially unhardcoding the bite -> infection progression for the player at least.Describe the solution you'd like
Expand
u_has_effect
to include an optional check for the intensity level and affected body part of the effect, and allowu_add_effect
to specify the same fields.Describe alternatives you've considered
Maybe a single field to direct
u_add_effect
to add any effects to the same bodypart if its condition was au_has_effect
on a local effect, but that sounds potentially janky.Additional context
As an example, blood loss' messages begin at
player_hardcoded_effects::820
, moving those out to JSON would also allow them to be snippet-based and as such a bit less repetitive.