Announcement

Collapse
No announcement yet.

DoN's 3D-Pathfinding / Flying-AI system (with full source!)

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

    #91
    Howdy! This is incredibly useful. I've been struggling to get functional flying AI in my project and this is the only thing that's looked promising to me.

    With that said, I've hit a snag. Not a bug, just a snag.

    Click image for larger version

Name:	ue4_donflying_behaviortree.png
Views:	1
Size:	82.0 KB
ID:	1109003

    I'm having trouble getting my flying pawn to chase the player. It flies between waypoints fine, but whenever the player steps into its vision cone it loses confidence. It will fly to the player's location, but then it stalls and waits. If the player reactivates its senses by making a noise or stepping out and into its vision cone again, then it repeats.

    I've tried to replicate the same behavior tree you use in your sample project, and it looks very simple, but I'm having trouble.

    Anyway, cheers and thank you.
    You can e-mail me at cinebst@gmail.com.

    Comment


      #92
      I'm having trouble getting my flying pawn to chase the player. It flies between waypoints fine, but whenever the player steps into its vision cone it loses confidence. It will fly to the player's location, but then it stalls and waits. If the player reactivates its senses by making a noise or stepping out and into its vision cone again, then it repeats.
      What's your BTD_CheckDistance doing? I was running into problems using a standard UE4 distance check (can't remember which one and don't have access to my project right now) cause there was a (bad) assumption made in the function that in order for the distance check to return true, there was an additional check to ensure there was some minimal vertical offset between the characters that had nothing to do with the point-to-point distance.
      Check out my ★★★★★ UE4 plugin if you want to go fast!
      • Feedback Event Factory: Perfect for managing sounds, particle systems, force feedback, camera shakes, time dilation, animations & more...all within a single Blueprint!

      Comment


        #93
        [MENTION=31122]Cinebeast[/MENTION] - The first thing I'd do is to dock your behavior tree window alongside the viewport and watch watch exactly how the control flows when the player gets close enough. If there's any setup issues or if your nodes aren't aborting along expected lines this will immediately let you know.

        Pressing the ' key with your bot on the screen activates Unreal's AI debugger which will automatically set the behavior tree's debugger to pick up your bot's actions. This is useful because the behavior tree needs to know which AI controller it should show you debug info for and ' key automatically does that while also displaying both the pawn's name and the pawn's controller name too.

        If you can record a GIF/video of the viewport and BT tree alongside that would help too. Sometimes I do this myself for really complicated behavior tree scenarios where things happen so fast that you need to record a video, slow it down (in VLC, etc) to learn exactly what the behavior tree is doing!

        Steam Early Access: Drunk On Nectar - The Nature Simulator

        UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

        Comment


          #94
          Here's my Check Distance decorator:

          Click image for larger version

Name:	ue4_behavior_distance_check.png
Views:	1
Size:	53.9 KB
ID:	1109142

          Nothing fancy, as you can see. I'm using this same decorator in a similar behavior tree for a land-based enemy, who works fine.

          I cobbled together a gif of the tree and the viewpoint in tandem:

          http://gph.is/292viCn

          I do a bit of hopping around, weaving in and out of the enemy's attention. As soon as I weave in, it wakes up and flies to me, but it will only fly to where I was standing when I weaved in, instead of continuously following me.

          Basically the enemy will fly to wherever the player was last standing and then spams that branch. I don't think the player's position is being updated -- then again, if it weren't, wouldn't the "Close to player?" branch be activated? So I don't know.

          Weirdly enough, I don't think I've ever made a gif before. It's easier than I thought it would be.

          Anyway, thank you for your help.
          You can e-mail me at cinebst@gmail.com.

          Comment


            #95
            Looking at the last part of the GIF where the bot stalls, the Combat ---> Fly To execution path is repeatedly aborted and then re-activated, so "Fly To" barely gets a chance to run itself. We need to understand why your "DummyState" keeps switching rapidly between "Combat" and "Something else" (the GIF doesn't show that part of your BT).

            During initial testing it's useful to turn on the debug visualizer in the Fly To node (under Debug Params -> "Visualize Optimized Path"). This will tell you exactly when paths are generated and what they look like. Also check your "Output Log" for any error messages from the navigation system.

            I'm also curious to know what "FlightLocationKey" points to in your "Fly To" node, where are you setting it from and how often you're setting it.
            Last edited by VSZ; 06-27-2016, 03:13 PM.

            Steam Early Access: Drunk On Nectar - The Nature Simulator

            UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

            Comment


              #96
              Checking the output log, I see I'm getting a lot of errors like this:

              Destination (XYZ) is outside world bounds. Please clamp your destination within the navigable world or expand world size under settings if necessary.

              That sounds bad. Something to do with the World Dimensions of the Don Navigation Manager, maybe?

              As for your other points: FlightLocationKey is being set at the beginning of the tree in a service:

              Click image for larger version

Name:	ue4_bat_bts_dummystate.png
Views:	1
Size:	43.9 KB
ID:	1109163

              Every tick we check to see if some variables have changed, including the player's position, which is saved as Target Location, which is later used by the Fly To node. I know that part is working because I can see the vector updating at runtime, the Fly To node just doesn't seem to recognize it.

              The Dummy State seems to be working fine too -- as soon as the player's spotted it switches from Patrol to Combat, and it sticks there. (According to the behavior tree panel and a print string.)
              You can e-mail me at cinebst@gmail.com.

              Comment


                #97
                Originally posted by Cinebeast View Post
                "Destination (XYZ) is outside world bounds. Please clamp your destination within the navigable world or expand world size under settings if necessary."

                That sounds bad. Something to do with the World Dimensions of the Don Navigation Manager, maybe?
                Absolutely. The plugin is telling you that you're doing pathfinding outside "world bounds" so your query will simply be rejected.

                Use the DonNavigationManager actor to increase the size of the navigable world to fully encompass your world.
                N.B. the larger the bounds, the longer your game will take to load the map.

                "Infinite" / Unbound worlds are also supported as an experimental feature (v1.3 onwards) so if you're willing to trade lower pathfinding performance for being able to pathfind anywhere (with zero load time for your game too) then check out this post of mine to turn that feature on. I thought people would have been really excited by that feature but no one seems to have noticed that post lol

                If your map is small, I recommend just increasing the size of your navigable world and keeping it bound. Any additional load time you incur will not be that bad in packaged builds (if you're debugging Visual Studio in DebugEditor mode you'll notice a real hit though).

                Always keep an eye on the output logs. The plugin uses logs to communicate common issues and their resolutions too.
                Last edited by VSZ; 06-28-2016, 06:23 AM.

                Steam Early Access: Drunk On Nectar - The Nature Simulator

                UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

                Comment


                  #98
                  That was it! The enemy flies to the correct point now.

                  However, he'll only follow the player if they make a move after the enemy has stopped flying. If the player gets out of the enemy's way and holds still, even if he's twenty feet away, the enemy won't follow until he moves again.

                  This has the effect of making the enemy look like it's blind, only reacting to noise or abrupt movements, but it's not really what I'm going for.

                  And in the behavior tree, the same issue persists. The "Fly To" node in the right branch is still being spammed, despite the fact that the player is out of reach.
                  You can e-mail me at cinebst@gmail.com.

                  Comment


                    #99
                    Originally posted by Cinebeast View Post
                    However, he'll only follow the player if they make a move after the enemy has stopped flying.
                    Two issues here:

                    1) If your bot is not chasing the player's updated location while it is still traveling, that is expected behavior (see "live pursuit" below).

                    2) If your bot is totally dead after traveling once (until the player comes near again) that's got be a a setup issue in your behavior tree!

                    Your DummyState is probably no longer "Combat" because the bot went out of the player's range OR your service is constantly flipping it between Combat and Patrol for some reason; only that or a rejected query (logs will tell you) would explain the spamming on the right branch.

                    --

                    Live Pursuit

                    Back to 1) - FlyTo node doesn't provide this out-of-the-box! It is a low-level task that simply 1) solves a path and 2) moves your pawn along that path.

                    In my game I use a simple distance delta check during pursuit and abort FlyTo based on that. If the distance between the "last known target location" (i.e. the location we're currently moving to) is significantly greater than the "live target location" (i.e. the current location of the pawn we're chasing) then I abort and restart the FlyTo task using a boolean decorator.

                    Maybe you can chain a boolean decorator (for easy aborts) with your inverse distance check. You'll have to play around with it a bit to get the aborts firing correctly though.

                    --
                    Plugin enhancement idea:
                    The plugin can be enhanced to provide "live-pursuit" functionality OOTB (using a TargetActor" BB key), but I'm extremely busy working on my project right now and can't commit to this, so managing it in your behavior tree and service is your best bet for now.
                    Last edited by VSZ; 06-29-2016, 02:28 AM.

                    Steam Early Access: Drunk On Nectar - The Nature Simulator

                    UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

                    Comment


                      Thanks for the pointers, let me see.

                      I checked the output log and I am getting some more errors:

                      DoNNavigationLog:Error: Pawn's initial position overlaps an obstacle. Pathfinding will not work from here, pawn needs to move to a nearby free spot first.
                      DoNNavigationLog:Error: Error: Invalid Destination (XYZ) passed to navigation path solver


                      I'm sorry to say I don't understand these.

                      Originally posted by VSZ View Post
                      In my game I use a simple distance delta check during pursuit and abort FlyTo based on that. If the distance between the "last known target location" (i.e. the location we're currently moving to) is significantly greater than the "live target location" (i.e. the current location of the pawn we're chasing) then I abort and restart the FlyTo task using a boolean decorator.

                      Maybe you can chain a boolean decorator (for easy aborts) with your inverse distance check. You'll have to play around with it a bit to get the aborts firing correctly though.
                      I like the sound of this, but I'm not sure how or where to implement this. How do I get the inverse distance check to recognize the difference between the "last" and "live" target locations and abort accordingly? I'm very much a behavior tree novice.

                      Seems like I'm getting closer and closer to what I want, though. Thanks again for the help.
                      You can e-mail me at cinebst@gmail.com.

                      Comment


                        Originally posted by Cinebeast View Post
                        [I]DoNNavigationLog:Error: Pawn's initial position overlaps an obstacle. Pathfinding will not work from here, pawn needs to move to a nearby free spot first.DoNNavigationLog:Error: Error: Invalid Destination (XYZ) passed to navigation path solver
                        Simply put - you can't tell a bot to travel inside a floor or a solid brick wall or inside a player's collision geometry (more on this below) and expect it to work. It has to be an empty/free/open spot that no physX collision body is occupying. The plugin tries its best to find alternate spots for you but if it can't, you'll see the "invalid destination" (or origin) error message.

                        3D pathfinding is complex to use and debug, there's no way around that I'm afraid. It took me more than one year to perfect 3D navigation for my bots and it still has some rough edges. You'll have to decide whether that level of technical complexity is something you have bandwidth for in your project.

                        Now since your bot's destination is the player itself, it's highly possible your pawn's mesh or weapon or some other prop is sharing a collision channel with the navigation obstacle channels (WorldStatic/WorldDynamic by default). A pawn's collision geometry should not be allowed to interfere with pathfinding. If it does you'll see the kind of log errors you posted. Configuring all collision channels in your project to play nicely with the navigation system will take time to get right.

                        Originally posted by Cinebeast View Post
                        I like the sound of this, but I'm not sure how or where to implement this.
                        It's almost exactly the same as your current distance check, you'll just need to do it in your Service node and use a blackboard boolean to force aborts on FlyTo whenever you need to. Instead of checking the distance between your player and the bot this new function will simply check the distance between the player and the last known location of the player that the bot is currently traveling to (i.e. the value of "FlightLocationKey" blackboard key). If it exceeds a delta threshold you abort FlyTo.

                        To implement this you'll need a solid understanding of how BT Aborts work, how the "Abort On Value Change" functionality works and on how to use blackboard booleans as decorators in general. This will definitely take a lot of time and patience to setup if you're new to behavior trees so try to go slow and be prepared to set aside a few days or even a week for getting it right.

                        Steam Early Access: Drunk On Nectar - The Nature Simulator

                        UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

                        Comment


                          Okay, I've been trying to set up what you suggested and I'm not quite there yet. Here's my tree again:

                          Click image for larger version

Name:	ue4_bat_bt_abort_flyto.png
Views:	1
Size:	73.3 KB
ID:	1111301

                          All I've added is that decorator on the Fly To node. If the AbortFlyTo bool is set -- or rather not set, the name's a little confusing, I'll change it -- the node should be aborted.

                          In my service up top I have this:

                          Click image for larger version

Name:	ue4_bat_service_abort_flyto.png
Views:	1
Size:	102.9 KB
ID:	1111302

                          In theory, if the player's location exceeds the location stored by the pawn's distance check, the AbortFlyTo bool should be appropriately updated. Unfortunately, I'm not having any luck. The threshold is currently something like 300, but I've tried other numbers. Either the bool is never changed and the pawn flies like he's always been flying, or the bool never switches back -- and so the pawn never flies at all.

                          Am I on the right track here or did I misinterpret your suggestion?
                          You can e-mail me at cinebst@gmail.com.

                          Comment


                            Your approach looks correct, but this kind of setup needs a lot of careful fiddling and state management to get right. It is perfectly normal that it's not working yet

                            Things to watch out for:

                            1) If distance threshold is exceeded you should promptly update the new destination onto "BB Key Target Location" or bot will not fly to new destination. I'm not seeing you do this in the screenshots!

                            2) "BB Key Target Location" should never be updated while the bot is busy chasing. That will mess with your distance check. I can't see where you're setting this value from so I thought it worth mentioning.

                            3) Initial state of the "abort boolean" should always be true, thus allowing the upstream decorators (DummyState->Distance) to flow unhindered to FlyTo.

                            4) Corollary of #2 - Each time a new pursuit begins (i.e. Patrol to Combat switch) you should reset the boolean to true to start on a clean slate.

                            --

                            So I think you get the picture - all these are potential failure points. Take the time to slowly work through the end-to-end execution, it's a great opportunity to perfect your BT knowledge too!

                            Steam Early Access: Drunk On Nectar - The Nature Simulator

                            UE4 Plugins: DoN’s Dynamic Mesh FX | DoN’s 3D Pathfinding

                            Comment


                              Hey this is just fantastic you've done a GREAT job programming all of this in. I can't thank you enough for your contribution!!

                              I would love to see this develop further! I think the Epic team needs to take a look at this and seriously consider adding it to their code-base, it's just awesome!

                              Keep up the great work, my faith in humanity has grown stronger today!

                              Comment


                                I've been working with what you suggested, but I'm not sure what to make of this:

                                Originally posted by VSZ View Post
                                2) "BB Key Target Location" should never be updated while the bot is busy chasing. That will mess with your distance check. I can't see where you're setting this value from so I thought it worth mentioning.
                                Right now Target Location is updated every tick in the service at the top of the behavior tree. You say it should only be updated when the bot is not busy chasing the player, but could you clarify what you mean by "chasing?"

                                Should I add a new "Is Chasing" boolean that flicks true when the bot is moving toward the Target Location and turns false once they reach it? And should I manage this sort of thing in the behavior tree or in the controller? I don't see any of this in your own project, so I'm grasping at straws a little.

                                Thank you again for your patience!
                                You can e-mail me at cinebst@gmail.com.

                                Comment

                                Working...
                                X