Need help with overlapping problem

I want to check whether my player character is in the light sphere of a flare blueprint. I do this by using a collision sphere that’s about the same size as the influence of the light source, and the Begin and End overlap nodes. Like This:

It’s simple and efficient, and in most situations it works perfectly. However, when two flares are located close enough to one another for their collision spheres to overlap (a situation that is unlikely, but definitely possible during gameplay), and the player is moving from one flare towards the other, it creates a situation where the OnComponentBeginOverlap node of the second flare is triggered before the OnComponentEndOverlap node of the first flare. This means that the InFLareLightSphere variable can be set to false while the character is still in the light sphere of the second flare, as is shown in this diagram:

How can I prevent this from happening? I’m trying to avoid ray casting and GetDistanceTo as those functions can become less efficient over long distances (I’m planning a rather large map). However if there is no alternative, I can make my peace with one of those options.

Thanks in advance!

Use “get overlapping actors” node and check if character still overlapping first sphere

Thanks for the reply! However, I’m not quite sure how to go about this… I’m still a bit noobish and was hoping for a more step by step answer. Also, I can’t check which flare’s sphere the character is overlaping, only if it’s overlapping “Flare_LightSphere”, seeing as they are all spawned from the same class blueprint as the character throws the flares. This means that at the moment any begin or end overlap event occurs, the GetOverlappingActors node will always return the player character, and there won’t be a different scenario I can use to generate a different answer, thus rendering the information form the GetOverlappingActors node useless. It’s essentially redundant code.

I could also just be misunderstanding you completely, so if you would be so kind as to elaborate on your answer, I would greatly appreciate it. :slight_smile:

so u wanted this?

https://.com/watch?v=m9O0JcsVuy8

no idea why video lagging, probably bad export to YT. Script may contain bugs, i not tested it extendly.

Yes! I knew there had to be a solution. To sum-up what this would do in my situation, the second flare will only effect the variables if the character is not in the Light sphere of the first flare anymore, and if the character is overlapping both, it delays the activation of the second light sphere until the character is only in the second flare’s light sphere? If I understand it correctly, it will work nicely. I just have to replace the material instance node in the video with set nodes for my InFlareLightSphere boolean.

Thank you so much! This has been driving me mad! I will give it a shot and report back!

Edit: Tried it, and it works great. For the Begin overlap event I just used GetOverlappingComponents instead of actors, since the light sphere is a component and not an actor. You sir, are the real MVP. Thanks!

Just in case some one needs it, here is my final solution:

I would probably do it in a slighly different way…
Instead of directly setting the “InLightSphere”-Bool of the player, I would introduce an integer-variable like “LightContactCounter” or something like that. Your firstly shown events of begin- and end-overlap would then simply increment or decrement that integer.
In the character blueprint I would then perform a check: If “LightContactCounter” > 0 then “InLightSphere” = True.

That system should deal well with your above described situation with two overlapping light spheres, as shown in that scheme:

I did not entirely understand your blueprint but it appears a bit complicated to me, or does it involve other functionalities?

EDIT: Or… actually… I probably would not use the “InLightSphere”-Bool anyways^^ I mean, having the counter is enough, so whenever you need to perform a check if the player is in the light (where you would use your bool) you could simply check if the LightCounter is > 0 or not. Thereby you would avoid unnecessarily setting the bool, as it does not provide more information than the LightCounter itself.