Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Request for feedback - Proximity Behavior

edited January 10 in Announcements
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:

1) "Closest object only" means "search all objects within the proximity and only return the closest one".
2) "Only trigger once" means pretty much what it says, but....
3) 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:

1) Output first object found (best performance)
2) Output closest object found (same logic as current "closest object only")
3) Output all objects in proximity

Plus the checkbox "Only Trigger Once"


"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
  • X and Y output the X and Y position of the object that triggered the proximity block. I think it already works the way your suggesting?
  • 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:
  • 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.
  • Maybe we can add pairs of Coordnates for compatability with multiple objects.
    Also, at this point I think a stepper should replace the slider
  • edited January 9
    @Mhx Aîr - 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.
Sign In or Register to comment.

| make games in your browser
@ 2017, All rights reserved.

Contact us

Get In Touch