Get random reachable point in radius with MINIMUM distance?

[Krileon]

I’m currently getting a random reachable point in a large radius for use with my AI spawn system, but the problem is I want this to have a MINIMUM distance so the AI doesn’t spawn too close to the player. I tried using a while loop to keep trying for a safe spawn point, but sometimes it fails and they’ll spawn really close to or on top of the player. Is there a better way to do this? Below is what I have so far.

[BIGTIMEMASTER (Aljav)]

you could move the origin to the minimum distance that you want from the player

[herb64]

The problem, why it sometimes fails is, that the GetRandomReachable function is just called again when executing the return node. You should save the random location in a local variable, then doing the comparison, and when distance is large enough, return the vector in that variable.

[jaspos]

EQS Environment Query System is handy for this.

[anonymous_user_c2dfcd1a]

Perhaps you could first select a random rotation around the circle, then a random vector distance in that direction with a minimum distance? It’s best to avoid doing a while loop checking some random condition like that, as there is no upper limit to the amount of time it could take to meet the criteria.

[Krileon]

@BIGTIMEMASTER

you could move the origin to the minimum distance that you want from the player

That won’t work as I need to spawn things in a radius around the player. That would spawn things in a radius around a point away from the player and would put the player within the allowed spawn radius.

@herb64

The problem, why it sometimes fails is, that the GetRandomReachable function is just called again when executing the return node. You should save the random location in a local variable, then doing the comparison, and when distance is large enough, return the vector in that variable.

It’s a While Loop. I don’t need to store anything here. It continues until the condition is no longer true, but sometimes it gives up. My guess is some sort of infinite loop protection as the while loop might be going for too long.

@jaspos

EQS Environment Query System is handy for this.

Now this looks interesting. How well does this perform though? Will look into giving it a try, thank you!

@anonymous_user_c2dfcd1a

Perhaps you could first select a random rotation around the circle, then a random vector distance in that direction with a minimum distance? It’s best to avoid doing a while loop checking some random condition like that, as there is no upper limit to the amount of time it could take to meet the criteria.

I’m pretty sure the long running while loop is why it’s failing sometimes. It gives up likely due to some looping protections. I’m needing an entirely random point around the player with a minimum distance. It’s a shame the get reachable point function has no minimum distance check, but looks like the EQS can do it.

[herb64]

@Krileon Yes, it is a while loop. You run the GetRandomReachable point, check against distance to player, WHILE the condition is not met. Once the condition is met, the while loop Completed pin fires. And what do you do? You start the return node. And what does the return node do? It gets a location - and guess what: this triggers the GetRandomReachable point function AGAIN, now resulting in a NEW random loc - which sometimes does fit, sometimes does not, because this one does not get checked again. Translated into C++, what you do is a

return(GetRandomReachablePoint());

Give it a try, or maybe I provide you with an example, but currently my shader compiler runs like hell
And it is not an infinite loop protection or something like that - this one indeed gets catched by the engine - you would notice that.
Doing stuff in loops is not the most elegant way, but in case of your values of 5000 and 1500 for the radius, the probability of getting a hit after some tries is good enough to go for it. In case of radius 5000 and minimum 4900, the situation would be a different one.

Here we go with an example now: calling function on key press:

Version 1, basically doing the same as you do, just storing the vector and printing that value, but feeding return node from the Function call:

Result: the returned vector never matches the one used for the distance calculation, but MAY fit the condition:

LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-5141.560 Y=1221.355 Z=11.324
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-5405.434 Y=496.017 Z=8.116
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-4678.604 Y=713.170 Z=8.789
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-5147.684 Y=1025.016 Z=10.000
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-5226.066 Y=1271.573 Z=10.915
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-4768.378 Y=889.593 Z=10.388

Now with storing the vector for the calculation of distance AND returning that same value from the function:

LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-4850.130 Y=431.126 Z=13.676
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-4850.130 Y=431.126 Z=13.676
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-4791.527 Y=1184.487 Z=12.074
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-4791.527 Y=1184.487 Z=12.074
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-5098.527 Y=1292.245 Z=13.485
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-5098.527 Y=1292.245 Z=13.485
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Try again
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Good point found in function = X=-4947.943 Y=1223.375 Z=14.631
LogBlueprintUserMessages: [HenryCharacter_C_0] Herb64: Returned by function = X=-4947.943 Y=1223.375 Z=14.631

You also can see, that there are not so many retries needed even with my radius ratios being worse than yours, so the loop is a good option.

For your radius values of 1500 minimum and 5000 for the range, if I calculated correctly, chances to get a random value too near to the player is around 1:35. Simply calculation with the circle surface for the 5000 radius and the surface area for the 1500 radius: roughly getting 1:35 ratio. So there’s nothing bad with your approach using a loop, just do it the correct way.

The EQS might be a little bit overkill just for that simple purpose, while this one is definitly something to check out.

EDIT: looks i did a wrong calcluation, ratio is 1:11 - still good value

[BIGTIMEMASTER (Aljav)]

@Krileon

That won’t work as I need to spawn things in a radius around the player. That would spawn things in a radius around a point away from the player and would put the player within the allowed spawn radius.

I was thinking that you choose a random angle from the player, go out between desired min and max distances, define that as the origin, and then the random reachable spot can be a small radius from that.

[Krileon]

@herb64

@Krileon Yes, it is a while loop. You run the GetRandomReachable point, check against distance to player, WHILE the condition is not met. Once the condition is met, the while loop Completed pin fires. And what do you do? You start the return node. And what does the return node do? It gets a location - and guess what: this triggers the GetRandomReachable point function AGAIN, now resulting in a NEW random loc - which sometimes does fit, sometimes does not, because this one does not get checked again. Translated into C++, what you do is a

Ahhhhhh I understand. Yeah that makes perfect sense having looked at it again, lol. Thank you! Will adjust it and give it a try!

@herb64

For your radius values of 1500 minimum and 5000 for the range, if I calculated correctly, chances to get a random value too near to the player is around 1:35. Simply calculation with the circle surface for the 5000 radius and the surface area for the 1500 radius: roughly getting 1:35 ratio. So there’s nothing bad with your approach using a loop, just do it the correct way.

Awesome! Thank you!