I wanted to update the Proximity behavior, and I know lots of people have had various issues with it so I figured I would ask for feedback before the next update. For one thing, I think the settings are confusing:
“Closest object only” means “search all objects within the proximity and only return the closest one”.
“Only trigger once” means pretty much what it says, but…
With “only trigger once” disabled, it still only triggers once per frame (on the first object it finds), but it will continue to trigger after the delay setting.
I’m thinking of changing the settings so that we have this instead:
These options:
Output first object found (best performance)
Output closest object found (same logic as current “closest object only”)
Output all objects in proximity
Plus the checkbox “Only Trigger Once”
Where:
“Output first object found” + “Only Trigger Once” would only fire once
“Output closest object found” + “Only Trigger Once” would only fire once
“Output all objects in proximity” + “Only Trigger Once” would fire for each in object in proximity, but only once and then not trigger again
Does this make sense? I am a bit afraid that the “Output all objects in proximity” + “Only Trigger Once” combination will still be confusing, since it technically fires more than once. Anyone have objections, or better suggestions?
Oh and the x/y does nothing I think.
I’d like it where the X only triggers for the horizontal proximity and Y for vertical.
Just “out” would be like the output as it is
in my experience attempting to use it, it doesn’t seem to work at all. For example I wanted a proximity on the player to wherever they walked, specific blocks around the player would be destroyed if in proximity, and replaced if outside of proximity. This didn’t work. Then I tried something else with it, allowing an object that follows the player but stops if in proximity, and continues once the player changes it’s position, thus changing the proximity. This didn’t work either.
Well, destroying blocks within a proximity would work - but replacing them when not in proximity would be tricky, since the proximity trigger doesn’t fire when not close to something.
Having an object follow up to a proximity is also possible with the current version, here’s an example: http://flowlab.io/game/view/788617
Let’s say I have a block with a block above below left and right, for the proximity all, is it going to keep firing different numbers for each direction, or try to make a single number as an equation for all the numbers together? Say for example I choose a filter for 233, and when the proximity triggers 233 on that axis, because the block is close enough, then it triggers the filter, but is it going to do that for each direction? Or is it some sort of equation? I’m trying to figure out if this new version of proximity will be able to detect when you’re surrounded or not.
@“Mhx Ar” - I think the answer is yes, if I understand you correctly.
If you had a player at position (1,1) (grid positions, not pixels, for easy discussion), and a set of enemies at (1,0), (0,1), (2,1), and (1,2), then the proximity trigger would return the values (1,0), (0,1),(2,1),(1,2) in sequence (but maybe not in that order). You could use this to figure out that you were surrounded, but it would take a bit of logic to do so.
As long as the number output changes, the rest isn’t important, because I just need to be able to trigger more than one filter within the same second. 233 is just outside of 7 grid distance, which is about as far as the radar goes, I believe, but don’t quote me on that. Anything closer than 64 pixels would normally sound like I should use collision, but collision doesn’t repeat if you rub, only if you crash. If I stand on the ground, the collision below me does not repeat until I bump the ground again or rub a different object while walking. That’s why I’ve always had issues with the jump locking, when a bottom collision didn’t register. I can now use proximity to filter immediately below me, and not register the same ground object type if it is above or to my left or right. I’ve been trying to make a perfect glitch free jump system for years. This is great. Also would be useful in that tetris example I was working on before.