The real issue here is the validity of payload. After your actor has been blown up, the node memory reserved for this behavior tree task is no longer valid and since the payload is obtained from the node memory, it is invalid too.
The quickest workaround for you will be to ensure that any A.I. being destroyed aborts all its behavior tree tasks prior to expiry. Aborting the Fly To task will instantly tell the manager to clean up the active pathfinding request so by the time its done the pawn(/payload) wonât turn out to be a dud. Calling BTComponent->StopTree on your behavior tree may be sufficient; whatever approach you choose, just test to ensure Unreal is calling UBTTask_FlyTo::AbortTask before your pawn is destroyed.
A plugin-level fix is going to be involved at this stage. It will require removal of the void* payload used by the existing result delegates and replacement with a non- structure (containing weak pointers to the ownercomp and a copy of the ActiveInstanceIdx).This will ensure that payloads will always be received by value rather than by reference. I probably wonât be getting around to this any time soon, so for those who areât able to code this fix, higher-level workarounds like the one above are suggested.
PS: OwnerComp is a TWeakObjectPtr (internally a struct, rather than an object pointer), so IsValid() / Get() / etc are guaranteed to be safe operations :)
Ah okay, cool. Calling BTComponent->StopTree before destroy is no problem. Thanks!! I figured the same about TWeakObjectPtr (IsValid() / Get()), but was in a hurry to get to bed, lol. Thanks for this great plugin man.
Great plugin you have here man, I can see a lot of effort has gone into writing it really so you should be really proud of yourself Anyway I just wanted to ask about how scalable it is. Cause in my scenario, I want to simulate about 4000 actors at the same time (worst case) and just having 200 with Ignore repathing for direct goals turned off gives a horrible performance and there seems to be a huge memory leak when that happens too. The thing is that if I leave it as true, the bots go through the obstacle, am I doing something wrong here? also the map is huge, so the voxel size is set to 10,000. I know this will affect the accuracy but I think with that Boolean set to true, there should be no problem?
Your answer will be of great help, and thanks again
Thank you It was written over 2+ years for my game
Thereâs many different things to discuss here, but Iâll skip to workflow recommendation first:
Recommended workflow for large maps:
The plugin supports an âInfinite/Unboundâ manager which should be your go to for large worlds or procedural worlds with ever-changing collision geometry. See documentation for setup instructions.
CPU Performance:
All workload is distributed over multiple ticks so the plugin is guaranteed to never eat up your CPU beyond a fixed workload. You should use the *MaxPathSolverIterationsPerTick */ MaxCollisionSolverIterationsPerTick variables to configure what the acceptable fixed workload is for your project.
Memory:
What youâre seeing is not a memory leak, but lazing loading of the Bound managerâs various caches. The bound manger was simply not designed for huge worlds because the memory cost quickly becomes unreasonable.
The good news is that the Infinite/Unbound manager scales up to any map size without costing you any extra memory! However because it is cacheless, the performance of the infinite manager is significantly lower than than bound manager so youâll need to keep MaxPathSolverIterationsPerTick very low to maintain your frame rates.
Most people arenât aware of the Infinite map size feature apparently, but it is a big part of the pluginâs offering and ideal for certain kinds of projects.
Thanks a lot for your fast reply man I tried the unbound and itâs pretty much what we need when the parameters are optimized for our needs so thanks for mentioning that. Only problem is that repathing based on dymanic obstacles, doesnât work properly. It only works if an obstacle is static and hasnât moved by the time of initial requesting of a path. If the obstacle moves, the actors pass through it almost all the time. Are there certain parameters that I should be changing to help with this issue? Like voxel size? Also is dynamic repathing there anyway for the unbound manager out of the box?
Repathing is not currently supported in the unbound manager Iâm afraidâŚ
Technically possible, just hasnât been implemented. Off the top of my head youâll need to store the collision listeners in a new data structure that supports arbitrary volume ids (eg: TMap<FSomeVolumeIdentifierStruct, TArray<MyCollisionListeners>) and youâll also need to implement an unbound version of ScheduleDynamicCollisionUpdate that analyzes the voxels occupied by a given dynamic obstacle (using the same âvoxel collision profileâ technique used by the bound manager) and fires off delegates to all interested pawns (using the new TMap). Cleaning up listeners after a pawn is done with path traversal is necessary too. You might run into some other niggles as is always the case with things like this
Itâs been an amazing ride with this 3D-pathfinding plugin which started it all; I hope finds the new mesh-painting plugin just as useful, and hopefully even more so!
Hi ,
I love the work youâve done on DON Flying Navigation! We are planning on using it for our game we are developing. However, we are using a source built version of the engine, and I was wondering if there is any you can supply a .zip of the plugin files for 4.16 as you have done in the past? As far as I know, itâs not possible to use marketplace plugins on the source built engine. And we would really like to use yours!
Hey, there should definitely be no issues using a marketplace plugin with a source build, Iâve done that often.
Just install the plugin on a binary version of the engine first and then *migrate *it out from there to your own projectâs plugin directory or your custom engine build.
So move the plugin from <YourBinaryEngineInstall>\Engine\Plugins\Marketplace to <YourProject>\Plugins or <YourCustomBuild>\Engine\Plugins\Marketplace (havenât tested the latter case, because I usually put mine with the project)
After that you may need to open your projectâs Build.cs file (âYourProject.Build.csâ ) and add the âDonAINavigationâ module as a public dependency.
Trying to use this plugin in 4.16 but there is an error when compilingâŚ
ERROR: UBT ERROR: Failed to produce item: E:\ProjectSurvival\ProjectSurvival\Plugins\DonAINavigation\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-DonAINavigation.suppressed.exp
Total build time: 11.22 seconds (Local executor: 0.00 seconds)
LogModuleManager:Warning: Found module file E:/ProjectSurvival/ProjectSurvival/Plugins/DonAINavigation/Binaries/Win64/UE4Editor-DonAINavigation.dll (API version 3299760), but it was incompatible with the current engine API version (3452394). This is likely a stale module that must be recompiled.
LogInit:Warning: Still incompatible or missing module: UE4Editor-DonAINavigation.dll
Hey tbjbu2,
Iâm not sure if this is the same as your error, but when I was adding the DON Navigation Plugin to my UE4.16 Source, I found that it was getting confused in the DonNavigationManager.h looking for methods called by a UBoxComponent*, and I fixed this by adding a include line in DonNavigationManager.h as follows:
include âRuntime/Engine/Classes/Components/BoxComponent.hâ
Maybe this will help. If not, it looks like your DonAINavigation.dll is an older version than the Engine, perhaps if you do what said, download the 4.16 and the plugin from the marketplace and copy it over to your source build. You may still have to include the box component header.
Youâre seeing a setup/environment issue of some sort rather than a compilation issue. Hereâs a thread that has a few different solutions, more can be found online too.
Gist of it being: Try cleaning up the intermediate, binaries folders (in the plugin) to compile from scratch again; if itâs a blueprint-only project try adding a blank C++ class; if itâs a source build try some of the suggestions from earlier in this threadâŚ
Assuming youâre using the marketplace 4.16 version and not an older download meant for previous versions of the engine.
Without knowing whether youâre building from source, or a Blueprint-only project or which version of the plugin you downloaded for your testing, itâs hard to say what could be going wrong.
All the latest versions are already uploaded, either on the marketplace (4.16, 4.15) or in the title post. There isnât any other version which would make a difference Iâm afraid.
Some environment issue specific to your project/build setup is coming into play here, which is why more information about your setup is needed.
Anyway I just wanted to ask about how scalable it is. Cause in my scenario, I want to simulate about 4000 actors at the same time (worst case) and just having 200 with Ignore repathing for direct goals turned off gives a horrible performance and there seems to be a huge memory leak when that happens too. The thing is that if I leave it as true, the bots go through the obstacle, am I doing something wrong here? also the map is huge, so the voxel size is set to 10,000. I know this will affect the accuracy but I think with that Boolean set to true, there should be no problem?
It was written over 2+ years for my game 
,