Hey,
I'm thinking about using this in a demo scene for my plugin.
But... I have a feature request. No rush, and no biggie.
I have a rig set up on a character, with zones. When the player is not near enough to any zone (outer threshold), I want to trigger a state change. The same for if the player is too close to create any further "sensor" feedback (inner threshold). The way it looks now, I would need two instances of the plugin if I want to categorize movement as 1) in range, 2) too far, and 3) too close. Both instances would target the same receiver, but only one would have "scaled" + "outer threshold", and the other instance would just have a threshold serving as the "inner threshold".
If I'm understanding correctly, that's the use case I have in mind.
The 1st plugin I released can be used to "geofence" areas of an environment (CollidersAsTriggers), Sensor can track and form interactions based on where in the geofenced section the player is in, and then the SimpleStateMachine plugin can be used to create all of the states / changes that should be applied outside of the sensor triggers (eg. moving the character/player/Atoms - changing their appearances, physics - setting off animations, etc. etc.). Just those 3 simple plugins themselves could create a lot of the types of interactions users don't get to see much, despite the high quality of scenes coming out. Some of the best ones quality-wise seem to have the least-pleasant / flexible interactions.
Sure, I could use another Atom, with CollidersAsTriggers, to handle "too far" and "too close", similar to how I use it for geotracking. If Sensor didn't exist, it would be an okay solution. But that case is better suited with visible boxes/shapes, as if serving as the edge of a map/level, or when special geometries are needed.
It would be much better in a design sense, to keep separation between triggers related to "proximity" using Sensor, and triggers located to geofencing AROUND the player, with CollidersAsTrigger.
Hope that makes sense.