Load sound-triggered traps with more safety #74198
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
None
Purpose of change
An enterprising modder was trying to use the
character_triggers_trap
event for eoc scripting and found out that sound_detect traps didn't actually require a sound threshold to trigger.Further investigation found that sound_detect is a (rather confusingly named!) vestigial trapfunc used only for initial testing sound-triggered traps. Sound-triggered traps definitely work, and we have an existing trap type (tr_dormant_zombie) which uses them.
Describe the solution
-Delete sound_detect trapfunc and associated trap. These were not encounterable outside of the debug menu and the trapfunc itself did nothing besides verify its function, so this shouldn't impact mods. No migration or save handling was provided (if a save does have them it will delete the trap on load after throwing an error about being unable to find it).
-Add some safety to our loading by throwing errors when invalid sound_thresholds are detected.
-Add dummy_trap function which always counts as triggering when called (thus calling the event bus) for our enterprising modder.
--I had originally added a dummy trap to traps.json as a sort of in-json documentation, but on reflection I found it hypocritical to be adding an unused trap in the same PR I was removing one. Maybe we should separate out the traps documentation from json_info.md and list(just list, not describe) the hardcoded trapfuncs so people can reasonably know they exist?
Describe alternatives you've considered
Actual documentation for traps?
Unit test for sound-triggered traps?
Testing
Game loads, dummy trap calls event bus when stepped on
Additional context