Announcement

Collapse
No announcement yet.

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

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

  • replied
    Can confirm it works with 4.14. I thought I needed to download the engine source code but it turns out if you just make a new 4.14 c++ project, add the plugin folder to the directory, open and rebuild it will work nicely!

    Leave a comment:


  • replied
    [MENTION=407007]wandersonp[/MENTION] - thanks for posting the solution I haven't seen this issue yet, but still useful to know.

    Leave a comment:


  • replied
    I discover the issue, I just put the command at .uplugin file and works great.

    "LoadingPhase": "PreDefault",

    Originally posted by VSZ View Post
    I don't know either, hopefully someone is able to test and report, I'm busy with other work atm.


    I've never seen anything like this. Sounds like the engine is not able to find a properly compiled version of the FlyTo class.

    Is this a blueprint-only project or C++? Have you installed the plugin as a project-level plugin or engine-level plugin? Your simplest option would be to remove the plugin and copy it again (either from the the sample project or directly from the plugin zip file). In case we're dealing with corrupted files of some sort, try downloading the plugin and/or sample-project again.

    Leave a comment:


  • replied
    Originally posted by formatt View Post
    Has anyone tried compiling it for 4.14 yet? Any luck?
    I don't know either, hopefully someone is able to test and report, I'm busy with other work atm.

    Originally posted by wandersonp View Post

    hey Guys im trying to use the plugin at 4.13, but im getting always this red node after close and reopen my project. Someone have issues like that?

    Thanks

    Wanderson
    I've never seen anything like this. Sounds like the engine is not able to find a properly compiled version of the FlyTo class.

    Is this a blueprint-only project or C++? Have you installed the plugin as a project-level plugin or engine-level plugin? Your simplest option would be to remove the plugin and copy it again (either from the the sample project or directly from the plugin zip file). In case we're dealing with corrupted files of some sort, try downloading the plugin and/or sample-project again.

    Leave a comment:


  • replied
    Click image for larger version

Name:	error flyto.png
Views:	1
Size:	64.8 KB
ID:	1118709

    hey Guys im trying to use the plugin at 4.13, but im getting always this red node after close and reopen my project. Someone have issues like that?

    Thanks

    Wanderson

    Leave a comment:


  • replied
    Thanks a lot for this, it is awesome! Has anyone tried compiling it for 4.14 yet? Any luck?

    Leave a comment:


  • replied
    However, I rarely need the game indoors, voxels bigger no problem

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    Glad to hear!

    Keep an eye on the logs from time to time (especially during complex usecases like the inside of the glass enclosure). It will keep you informed about query timeouts or other pathfinding issues (due to voxels size being too large, etc). I did notice some debug spheres showing up in your video and those are usually an indication of some pathfinding issue that the logs will tell you more about.
    My map is large, so the voxel is relatively large, if I reduce the voxels size, will greatly increase the load time, but the size of the map for my game is still relatively small. I tried to use unbound volumes, but sometimes there will be serious performance problems.

    Leave a comment:


  • replied
    Glad to hear!

    Keep an eye on the logs from time to time (especially during complex usecases like the inside of the glass enclosure). It will keep you informed about query timeouts or other pathfinding issues (due to voxels size being too large, etc). I did notice some debug spheres showing up in your video and those are usually an indication of some pathfinding issue that the logs will tell you more about.

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    @<a href="https://forums.unrealengine.com/member.php?u=94612" target="_blank">wuyukang</a> - Hey, I didn't watch all 6 minutes of that video, but here are some recommendations based on what I observed:
    1) Have you looked at the Pursuit example (5.A) in the sample project? Your behavior tree needs to make sure that the Fly To task is retriggered whenever then player-to-bot distance has exceeded a certain threshold. Without this the bots will just hang around at their last travel point waiting for something to happen. Check out the sample project's Pursuit behavior tree, Service_Pursuit_Helper blueprint and SimpleAbortWrapper decorator to see this in action.
    2) Check the logs and see what kind of pathfinding failures (if any) are reported there.
    3) For initial testing, reduce the number of A.I. bots to just one instead of three. Once you fix all pathfinding issues for a single bot and know everything is working then you can start adding more.
    Thanks for your help, I use your behavior tree and now the navigation looks right. I added 10 bots, no problem. Thanks again for writing this awesome plugin.

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    [MENTION=43607]rcdarcey[/MENTION] - For debugging unbound volumes you need to get their center point by calling FVector myLocation = VolumeOriginAt(FVector WorldLocation); and then manually draw the volume yourself. Best option would be to make a new function by porting the rest of the code from Debug_DrawVolumesAroundPoint.

    Make sure you remove all dependencies on FDonNavigationVoxel* by using its FVector equivalent functions. Unbound managers do not store any volumes in memory at all so you're always dealing with FVectors instead of pointers. This is what allows the "infinite" pathfinding feature while making them much slower as a trade-off.
    Thanks, [MENTION=14603]VSZ[/MENTION]! I'll look into that if I end up sticking with the unbound volumes. In the short term, went back to bound volumes to help debug and figured I'd keep it that way for performance reasons until (if) my levels ever really required them.

    Leave a comment:


  • replied
    [MENTION=43607]rcdarcey[/MENTION] - For debugging unbound volumes you need to get their center point by calling FVector myLocation = VolumeOriginAt(FVector WorldLocation); and then manually draw the volume yourself. Best option would be to make a new function by porting the rest of the code from Debug_DrawVolumesAroundPoint.

    Make sure you remove all dependencies on FDonNavigationVoxel* by using its FVector equivalent functions. Unbound managers do not store any volumes in memory at all so you're always dealing with FVectors instead of pointers. This is what allows the "infinite" pathfinding feature while making them much slower as a trade-off.

    [MENTION=94612]wuyukang[/MENTION] - Hey, I didn't watch all 6 minutes of that video, but here are some recommendations based on what I observed:
    1) Have you looked at the Pursuit example (5.A) in the sample project? Your behavior tree needs to make sure that the Fly To task is retriggered whenever then player-to-bot distance has exceeded a certain threshold. Without this the bots will just hang around at their last travel point waiting for something to happen. Check out the sample project's Pursuit behavior tree, Service_Pursuit_Helper blueprint and SimpleAbortWrapper decorator to see this in action.
    2) Check the logs and see what kind of pathfinding failures (if any) are reported there.
    3) For initial testing, reduce the number of A.I. bots to just one instead of three. Once you fix all pathfinding issues for a single bot and know everything is working then you can start adding more.

    Leave a comment:


  • replied
    Hi,VSZ
    In my game Ai always follow the players, but I found that the player position change Ai Pathfinding is not always updated, how should I do?

    Leave a comment:


  • replied
    [MENTION=14603]VSZ[/MENTION],

    Another quick question for you...

    I moved over to use your "unbound" navigation manager a while ago. It's been working great, but ran into an issue and tried to use DrawDebugVolumesAroundPoint to help debug, but that no longer seems to display any volumes with the unbound manager. Is that expected? Looks like this call right at the top of the function is returning null.

    Code:
    void ADonNavigationManager::Debug_DrawVolumesAroundPoint(FVector Location, int32 CubeSize, bool DrawPersistentLines, float Duration, float LineThickness, bool bAutoInitializeVolumes/* = false*/)
    {
    	auto volume = VolumeAt(Location);
    	if (!volume)
    		return;
    ...
    Thanks!
    - Ryan

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    So the behavior tree framework itself is the only bottleneck here?

    If so, one trick I can think of is to move your bot via velocity (tick based) rather than via offsets (AddMovementInput based). You will still use AddMovementInput to set a "desired velocity" but this velocity will be consumed in your bot's tick. That way even if the behavior tree is busy realigning itself between tasks your bot will continue to be mobile for those few frames thus creating the illusion of continuity.
    GAH! Brilliant. Super simple solution. Just reduced braking deceleration in Character Movement Component and looks perfect. Thank you!

    Originally posted by VSZ View Post
    Great to hear from you too! My project will releasing very soon and I can't wait to share Drunk On Nectar with the world
    Great to hear! Super stoked to see the final product. Definitely let people know here when you release. My reach isn't too far on the internet, but I'm totally happy to echo any marketing efforts you have.

    Leave a comment:

Working...
X