[Suggestion] Pick nearest/furthest update

I use pick nearest/furthest all the time. However, I run into problems when one Sprite attempts to find the nearest of its own kind. I would love the function to be updated so that pick nearest/furthest never returns the instance which called the event, or at least a setting to exclude it. I find myself having to do extremely complicated workarounds, and would appreciate a change.

Thanks,

Ryan

Try filtering to exclude the UID of the sprite you don't want chosen.

Try filtering to exclude the UID of the sprite you don't want chosen.

Could you give some kind of example pseudo code? I get where you're going but am unable to replicate it.

I'd be happy to see this workaround, but I don't think it negates the initial suggestion. If you ask a person where the nearest human is, they will not point to themselves. It's really unintuitive and not useful for an object to find itself with this kind of function.

ryguydavis,

Sorry, a bit too brief on the help because I was using my phone. Try something like the images below. You just need to grab the UID of the object that has been selected (in my examples I use a mouse click) and then exclude that UID from the group of objects that you wish to consider for the pick nearest action. You can use a family (that contains the selected object type) or put the UID in a local variable to fulfill this requirement - all depending on how you have your game set up. If you choose to use a variable, just ensure you Pick all so the sub-events consider more than just the selected object. Take a look at these and let me know if they make sense or not...

[attachment=0:2rkvvu0f][/attachment:2rkvvu0f]

[attachment=1:2rkvvu0f][/attachment:2rkvvu0f]

Ah, yes that does the trick. Thank you for taking the time to provide an example. This is literally a year's worth of headache.

I'd still love an additional option added to the nearest/furthest condition. It seems like a more elegant solution than three events and a variable. I'll happily use it for now, though.

Thanks!