@erol_demirci It’s an open source project so he and everyone can do with it what ever they want. Dev is not and most probably will not update it. So its just a good thing that someone who has knowledge did it for us.
I don’t think you understand @Freymox , this is a marketplace item, not something you download from a website and distribute on a forum free of use. No one can really say what the legal ramifications are, or what the rights are of a forum user with regard to Marketplace content that is not theirs. Using the MIT license to modify at your own will is one thing, but posting the owning website’s Marketplace item without permission of the author or Epic is not a smart move. I would place bets that it’s simply forbidden to do so.
Despite all that mumbo jumbo, what is wrong with providing instructions on HOW to do that on your own? Again, one removes themselves from any legal trouble, and, they educate others on HOW to do something. It is a win/win for the community.
The last thing I would like to say is this: That file is suspect, and will always be because it is NOT provided by Epic’s marketplace. It was not provided by and guaranteed by Epic to be free of security issues; it was not overseen in any way. The author DID provide an update to 4.23, so what makes you or others feel the author has abandoned the product? Perhaps they do not get involved in the forums any longer, or, they are rigorously testing it against 4.24. Simply testing against one person’s project is not sufficient to say it ‘works’, and is thus the reason I feel the author is not publishing it yet. Nevertheless, no one can argue the fact that this is a product on Epic’s marketplace, which has legal terms, which I am sure bans anyone from simply just posting the software on a forum regardless of how one feels. There are rules.
He does make a good point, its better to learn how to do it as it will not work in the next version. The steps for building it are very simple really.
- Create an empty C++ class in the original Example project under a previous version that has a supported plugin version.
- Make a copy of that Example project and rename it to signify it is your working version for 4.24
- Copy the plugin from your Engine versions Marketplace location into your new working project Plugins folder and using a text editor edit the .uplugin file so the engine version line reads 4.24.0
- Delete the old visual studio solution, vs and intermediate.folders from the working project as these are for the wrong engine version.
- Right click on the working Projects uproject file and select 4.24 version of the engine from the list, this will generate a new VS solution, .vs and intermediate folder which will let you rebuild the plugin binaries for that engine version as well.
- Open the solution and Build, this should update all your binaries including the Plugin binaries.
- Run the project and make sure there are no errors reported, and that the plugin is enabled, if not then enable it and restart the editor.
I’ll update my post and people can contact me directly for that link if they want the quick and easy.
Hi Everyone, here is an alternative way to do it if the previous post’s steps do not work:
Here are simple steps to take (not the cleanest method, but it gets the job done): You will need Visual Studio 2017 at minimum (up to you to ensure you’re on at least the minimum version). This also comes without support or warranty.
-
Open a new C++ project in 4.24 (blank with no starter content is all you need).
-
Create a new plugin (I used Third Party Library template) Name the plugin DonAINavigation. Close the project.
-
Go to the project folder in the filesystem and open Plugins folder. Delete the Source, Content, and Resources folders. Intermediate and Binaries do not matter because that is POST packaging… You can leave them there, will not hurt and will not cause any errors.
-
Copy the DonAINavigation Source, Resources, and Content folders from the 4.23 Engine\Plugins\Marketplace\DonAINavigation folder (I described this in an earlier post) and paste them into the Plugins folder from step 3.
-
In the DonAINavigation folder in the ENGINE structure (from step 4) open the DonAINavigation.uplugin file using a text editor and copy its contents. In the project’s Plugins\DonAINavigation folder, there is also a DonAINavigation.uplugin file. Open that, delete everything inside, and paste from the contents you copied.
-
VERY IMPORTANT! In that text, there is field called: EngineVersion, and it should have a value of “4.23.0” with the quotes. Change the 4.23 to 4.24. Save and close the .uplugin file, and close the source file as well.
-
Open the project. It may ask if you want to update the project file. Nothing wrong with clicking OK.
-
Open Plugins, find the new plugin with the familiar icon and click Package (little tiny text right in the middle of the plugin box). It will ask for a location to output the package contents. You can put it anywhere (simply create a new folder in the project root, call it PLUGINPACKAGE). Make sure either the folder is highlighted, or, you have entered the folder and click Select Folder.
-
The packaging process should start. It may take a few minutes to completely package the plugin.
-
When done, DELETE the contents of the project’s plugins folder, and paste the DonAINavigation folder from the output into the Plugins folder. Open the project.
-
If done correctly, open Plugins and see if the plugin is enabled, if not, enable it, restart the engine, and see if you can access the API. If so, go to step 12 to make it available for all projects using 4.24.
12 Close the project, CUT the DonAINavigation folder from the project’s Plugins folder and paste it in 4.24 Engine \Plugins\Marketplace.
- Open any project using 4.24, and you should have the plugin available for use (may need to enable it). Now the plugin will be available engine wide.
IF YOU GET AN ERROR C1853 IN THE LOG, GO HERE: [SOLVED] fatal error C1853 on Plugin Packaging only - C++ Gameplay Programming - Unreal Engine Forums
You’re Welcome.
2 Likes
Anyone has idea why Im getting these? It never stops at point. And if I put wait after fly to it just keep floating in air.
[video]https://gyazo.com/7969ff85a3b8455b9575ec60974213b4[/video]
Hi @Freymox ,
The only time I’ve seen the drift off like that is when the search query doesn’t respond in time, OR, the point you’re trying to go to is not reachable. Are you familiar with the DonManager object’s properties? Specifically the arrays that identify types of collider identities as obstacles? Also, do not adjust the DonManager scale in the world outliner, and instead, use the DonManager properties X Y Z values to increase the size of the DonManager that way.
One way you can check the first suggestion is (this OR that) is by enabling all the debugging options in the blueprint node. Do that and then post another video if you still can’t figure out. If you see a bunch of red dots around your point, and it never actually hits the point, and the distance from the ai to the destination is MORE than what the threshold is defined in the Blueprint node, then most likely the destination is inside a collider that is marked as an osbstalce (world dynamic and world static are obstacles by default… is that box a world dynamic or world static collision type?).
-Erol
Hi @erol_demirci,
Here is a video - [video]https://gyazo.com/cdce54ee6b790bf61bcbe5638e0c19db[/video]
My way-point collision is set to nocolission. and I even add it as “Actors to ignore for collision” I haven’t couched DonManager at all. Im using example project to figure out why my sistem is not working.
I’m using charachter instead of pawn. could that be a problem? And I use my own way-point instead of what is used in example. Cold any of these cause a problem?
Hey @Freymox ; Even if the waypoint collision entry is set to ‘no collision’ (like a trigger or a volume without a collider) it should still have a collision type entry, and it is likely WorldStatic or WorldDynamic if you have not changed it. This entry is a member of the array of obstacles in the DonManager. The object does not need collision turned on to become an obstacle, only the entry in the obstacles array in the DonManager is required (which those two entries are defaulted into the obstacles array). Please check the Waypoint mesh(es) to ensure none of them are of the types that are defined in the obstacles array. Better yet, you can past images of all the meshes’ collision properties that make up the waypoint so we can see their enumerations.
Character is a subclass of pawn, and I do not believe you need the pawn class to use this plugin. I could be wrong, but I believe you can even attach it to actor and it would work, provided it has movement components for the actor to move. Character comes with a movement component on its own so that should not matter. If you really want to test it, you could try creating a pawn and giving it a FlyingMovementComponent (I think it’s called) to see if that helps, but I believe the issue is what I pointed out earlier.
-Erol
[USER=“2727902”]erol ademoski[/USER] I did a change and still nothing - Screenshot - 49d2fa294f92e0d28d56e3beba0b728c - Gyazo
If I change maximum proximity required form 15 to 30, then at least it goes farther than fly to in behavior three. As u can see in this video - Untitled: Jan 21, 2020 9:13 AM.webm - Google Drive
at least it prints out hello. But my BP don’t understand, that AI is in a place, becouse after reaching the point in just floats in the air. It’s not stopping at way point.
Good evening!
I guess I finally found a problem with this plugin. The navigation manager failes to find the shortest path after some dynamic collision update happenes. It can surely can find some path, but as far as I can see it would be based on some cached previous path. Is there any way to clear all this cache?
Here is the video, which represents the issue:
And here the basic project, which I’ve used:
Hi @Freymox : Are you using a Behavior Tree with the flyto node? if not, what is it supposed to do after it reaches the destination? I’m kind of confused… if there is only one instruction which is to fly to the flyto node, and there is an expectation that it stops automatically when it reaches the destination, I believe that may be the issue. It wont just stop unless you tell it to stop (I believe). Also, did you test using Pawn type with a FlyingMovementComponent? What collision type is that volume’s mesh set up as?
-Erol
erol ademoski I just found a solution for my problem. Apparently I just needed to increase **Breaking friction factor **to get instant stop. It seems, that’s a way how Pawn in demo sample stops. Demo Pawn deceleration is set to 8000. that gives them instant stop. So when I increase my character Breaking friction factor from 2 to same 8000, it’s not floating in air anymore,but stops right a way, and in my behavior tree everything gets triggered as it should be.
Will do some testing, bet it seams like, these was a problem and it’s fixed. Hopefully will help someone to save some time. 
Hi @Dain_Torson ,
I am not sure if this will help, but, in his documentation youtube video, he goes over what happens when the dynamic collision system finds an obstruction in its path. At 28:50, he goes into custom navigation queries. He goes over, in short, what happens if the Dynamic Collision Listener reports something… see if that helps you any. Important part is at about 30:00. He never talks about caching (not sure if it is something the plugin does or not) but, the sourcecode is small enough for you to take a peek and see if you can find anything on that subject.
-Erol
Thanks for the reply, @erol_demirci,
I’ve searched through the plugin code and found that there actually is a pathfinding cache (TMap<FDonNavigationVoxel*, TArray <FDonNavigationVoxel*>> NavGraphCache variable), which as far as I can see is never being cleared. I haven’t managed to develop a quick solution for that without breaking the plugin (mostly a performance of the plugin). Luckily it seems that the unbound version of the manager doesn’t have such limitations, so I think I’ll stay with it for now.
Hey @Dain_Torson , Is it possible that cache is cleared when the Navigation Path Query is re-run? The path query, I would think (without looking at source code) would clear the cache because the path would not change and would run into the same obstacle it already picked up.
Perhaps it is on a timer? I could be wrong, but I thought I remember in the video he mentions some timer for something to run (though that could be the Dynamic Collision Listener). In the video, he does say though, that you have to re-run the Path Finding Query when the Dynamic Collision Listener returns with an obstacle (perhaps the reason is to clear that cache along with generating a new query ? )
-Erol
@erol_demirci
I’m absolutely positive that it’s not; I’ve checked all of the variable’s usages: the map is never being cleared.
Dynamic Collision Listener fires only if an obstacle appears on previously known path, but not when obstacles disappear.
Hi @Dain_Torson , I understand the Dynamic Collision Listener only fires (a callback) if there is an obstacle along the calculated path. Just to be clear, (i do not mean to be redundant), when you run the Schedule Path Finding task, are you saying there is not code to remove any previously found path? If not, then how is the cache being managed? Are you saying it just grows and grows for the duration of the level’s existence?
It doesn’t make sense, why in the video, he would state that if the Dynamic Collision Listener fires, you must re-run the Schedule Path Finding task again to get a new path, if that did not clear some cache (previously enumerated path).
-Erol
Hi @erol_demirci!
That is exactly what I’m saying.
There are the all of the cache’s usages:
And it’s kinda make sense for relaively small volumes. Cache is basically a map, which maps FDonNavigationVoxel pointer to it’s neighbours (also FDonNavigationVoxel pointers). There gonna be 6 of them, because FDonNavigationVoxel is a cube. So there gonna be 7 * 4 = 28 bytes of memory usage for every cached voxel. Given the playable space of 100x100x100 meters and voxel size of 1 meter we gonna get approximately 28 Mbs of memory usage for fully filled cache, which is not very much in the whole game scale. Though that is very unlikely to happen because the algorithm always prefer choosing the cached voxel over discovering new ones.
Hey @Dain_Torson Question: In the calculation: 7 * 4 = 28 bytes: Are you saying that one voxel is 4 bytes? If so, how did you find that to be?
-Erol
@erol_demirci Cache map doesn’t contain voxels per se, only the pointers. Size of a pointer is 4 bytes, if I’m not mistaken.