Pause blueprints when far away/culled?

Hello, I’ve got a fire trap blueprint that shoots fire at random intervals:

3488b4845e606a8e2487b0173cb18b84.png

There’s going to be a ton of these placed all over the world, and I’m afraid they’ll reduce performance by running even when unseen and miles away.

Is there any way to stop blueprints from running when far away? Any way to see if they’re visible, etc.
Should I redo the blueprint so it runs on the tick function (more control) instead of endlessly playing through the Beginplay?

Any help or ideas is appreciated, thanks!

@Juice-Tin

Instead of using the Event BeginPlay, you might look into using a custom event. Call it whatever you want. Then add a collision box or sphere or whatever you prefer as shape and make it scale it up to the activation range you want to use to kickstart the blueprint.
Here is a little vid I made for you:

https://vid.me/Tv6x

You have already your own behaviour, so just focus on creating a custom event, a call for the custom event, a component overlap, an end component overlap and a boolean variable + some branches to determine that you are actually the player in range. Would be bad if maybe an AI would run into one of these. If you want to have an AI run into one of these however, just remove the branch == nodes and the branch nodes on the overlap events :).

Hope it helps.

I agree with @DarkGodsLair; keep your trap code, but remove the begin play. Add an overlap that overlaps what characters you want, and with the radius you find acceptable. Use the OnComponentOverlap event to fire a sequence:
1: Start your looping trap code
2: Start a looping check if the player is overlapping via tick or timer
If the player is not overlapping, then close the loop (probably using a gate or a branch with a boolean). Close the gate with the OnComponentEndOverlap event as well. This makes sure that if the end overlap doesn’t get called that the trap stops firing.

If it is only on “OverlapPawn”, it is nothing to worry about. The problem with tracing however is that it is dirt cheap, but in which intervals it should fire off and activate which trap will be a pain. It starts being problematic if you have multiple traps, where only one would get activated at a time. To avoid it, you would need to use multitraces, which might be fired off frequently and get performance unfriendly. If he has tons of them, it will literally confuse the heck out of the linetrace and the Get-Distance-Too, because the trace can’t decide, which trap to activate and deactivate.

Or you could ditch both of our options and just use a collision sphere/box on your player character to periodically check, if stuff is in range. And if they are, they will be saved in an array and the custom event can be triggered through a for loop. This approach has a downside too and can lead to lag, if you have a bunch on them on one moment.

Both methods are valid, but it really depends on your end game design. We can only help as far as the question goes. But the really difficult areas must mostly be tackled by the game designer itself :).

Jumping through various hoops everday in terms of game development, right franktech? :).

Thanks for the advice guys.

I was also thinking, what if I use Tick event to check the distance of the player, and allowed the trap to run if the player was within a certain distance?
Same idea as the big collision box without cluttering up the scene. Would that be low on performance, constantly checking player distance?

I personally had a ton of issues with “activation colliders”, both on and off the player, as they tend to block the odd line trace from time to time, causing a weird hard to track bug.

I keep a list of all active objects in my game state, and periodically (every 2-3 seconds), I go through that list and check their distance to the player, deactivating as needed.