Announcement

Collapse
No announcement yet.

Pause blueprints when far away/culled?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Pause blueprints when far away/culled?

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

    Click image for larger version

Name:	3488b4845e606a8e2487b0173cb18b84.png
Views:	1
Size:	61.8 KB
ID:	1215724

    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!

    #2
    [MENTION=148180]Juice-Tin[/MENTION]

    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.
    Main channel:
    https://www.youtube.com/channel/UCGC...o9s3YcA/videos

    Comment


      #3
      I agree with [MENTION=172129]DarkGodsLair[/MENTION]; 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.
      Website: http://www.NonLocalitySoftware.com
      Facebook: www.facebook.com/NonLocalitySoftware
      Twitter: https://twitter.com/NonLocality_Dev
      Instagram: @nonlocalitysoftware
      Discord: ASCII#1124

      Comment


        #4
        Having tons of overlaps might be a PITA when you can still use Tracing / Get-Distance-To.
        You could just use a master gameplay-command loop that runs periodically by Tick / Timer.

        Comment


          #5
          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? .
          Main channel:
          https://www.youtube.com/channel/UCGC...o9s3YcA/videos

          Comment


            #6
            Originally posted by DarkGodsLair View Post
            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? .
            For sure, game design is pure artform and there isn't often a perfect answer for any use case.

            Originally posted by Juice-Tin View Post
            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.
            Agree with what DarkGodsLair said but...

            Attaching a box to the player as a detector tends to work best in interior spaces / small levels.
            But it sounds like the world in question is large. Are there any undulating hills / terrain etc???
            If so, are there points in the level that player(s) can climb to and see further in the distance?
            Then tracing between trap + player location periodically may help, you can still 'snooze' traps.

            Comment


              #7
              Just remembered, UE4 has Matinee property: 'Skip update if not visible'.
              Don't know with your set-up if you can substitute that for a Timeline etc.

              Comment


                #8
                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?

                Comment


                  #9
                  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.

                  Comment

                  Working...
                  X