Map's Navigation Network - extra-options

Development assistance and tutorials here.
Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sat May 16, 2020 8:35 pm

To discuss through images what manual navigation optimization means, I'll show you the difference between what the Editor's automatic script does versus User Intervention that can guide movement exactly the way it wants.

This is what the Editor does:
Original.PNG
Original.PNG (281.21 KiB) Viewed 211 times
Here we have the user option:
Customized.PNG
Customized.PNG (273.71 KiB) Viewed 211 times
We admit that when a Bot goes close to an Item, it will go directly to it ignoring the surrounding navigation elements. Doesn't matter the Red color, these paths are suffice for a brainless Bot, it will use these because they are for a creature having 30 × 50 Collision, which is enough for Bot.
Here, we have the freedom to direct the movement as we wish, without elements that are not useful to us. I'm not bothering you by presenting the data that is added to the navigation network that the Editor does and that only loads the map with unnecessary data.

All these can be done in UGold227 using: MapGarbage + PathsLinker. Optional we can start a basic network with XC_EditorAdds inside UT Editor and later removing what we consider less suitable for us.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sun May 17, 2020 5:51 pm

Now is the time to answer a question that has not yet been asked. I do it in advance. PathsLinker will be updated then...
If we have a tunnel where we want to manually add navigation paths, and we already have a lot of work done by hand, we don't want to allow the Editor to guess and ruin our work. The user may be wondering about the size of the collision to be used in the reachSpecs navigation specifications. PathsLinker had a small test sequence for a path between two navigation points. I preferred to speculate how big the test unit was and respectively the collision data are logged and even filled in the builder, ready to be used in the given context. If the Editor reports a problem with the navigation parameters, we can put two small things on either side of the tunnel - left / right and then measure the distance between them. We divide this into two. So we find out the maximum collision radius of the creature that will move around here. We can use a similar method for Collision Height. Usually such things are needed if Editor claims a Not Navigable spot for some reason - it's recommended an "In-Game" check for whatever problem. Method is not very accurate but it helps as a small guide.

Testing stage which will be available for next release:
Scout_Suggestion.PNG
Scout_Suggestion.PNG (890.64 KiB) Viewed 200 times
The two navigation points are tested if a creature can move between them. The values it fits into will be reported and we even have the data filled in automatically, we just need to instigate the builder interface a bit (click around boxes) and then we see the collected data. We don't need GIANTS here - maximum used it's for a Titan, but we can figure if spot it's well navigable.

In the next update we will have some default rules followed. That is, the distance is not calculated between WarpZoneMarkers, Teleporters, Elevator combos. We use 100 and 500. We can adjust the rest as we want, if we want. I haven't seen any problems so far, but I think it's better to follow normal standards.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Fri May 22, 2020 5:59 am

Bump: Update done - proposed release initially was May 25, I'm not sure if this is very Important.
PathsLinker_05_25_20.7z
(145.57 KiB) Downloaded 3 times
Update notes:
- we can declare whatever distance in a reachSpec if we want that else builder is computing distance itself - except combos: WarpZoneMarkers, Teleporters, Lift specific ones;
- testing two points makes tester's collision data to be captured and completed as references for a potential future reachSpec dedicated to that spot. Some time it's wise to do such test in order to figure if exist a good reason for which Editor did not added a path in that spot. Other paths behind ledges might be done even if they are not having a trace/visual contact each-other - experienced mappers can figure where such things are doable.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sat May 23, 2020 5:44 am

I studied the facility related to the part with the R_Door navigation flag. It's not very special, UT supports this flag just like R_Fly, only here it takes into account the creatures that have bCanOpenDoors. In other words, it is not a flag that has too much to say about doors, it only restricts exactly as R_Fly does for those who do not fly. It can be used even where we have no doors, it simply limits the poorly intelligent creatures to navigate such places, ie they will find alternative routes if they exist.

Code: Select all

	inline int calcMoveFlags()
	{
		guard(APawn::calcMoveFlags);
		return ( bCanWalk * R_WALK + bCanFly * R_FLY + bCanSwim * R_SWIM + bCanJump * R_JUMP 
				+ bCanOpenDoors * R_DOOR + bCanDoSpecial * R_SPECIAL + bIsPlayer * R_PLAYERONLY); 
		unguard;
	}
When does the Editor create this R_Door flag? Answer: Probably when it will create the R_Fly flag - mainly never, ie it has nothing to do with what we want, these being user-defined flags, in other words we create them if we need them. R_Door may not be of real use to us on whatever special map.
Intelligent creatures are able to navigate such more restrictive paths, so for MonsterHunt maps we use different paths and restrictions because R_Door doesn't do much. In other hand a creature which is not having bCanDoSpecial=True won't navigate through Lift Combos and such 32 R_Flag.
However, as an information for anyone who wants to test such areas, when we talk about the navigation of a terrestrial/ground creature, we need
R_Walk and R_Door. As result, the data will be 1 + 16, so the flag in this path will be 17. Here we are talking about changes made manually or created manually because the Editor will not create them, not even UGold227 Editor.

Warnings for Nelsona:
#1 If you want to work with that "paths-sharing" method in finding routes you have to align well properties for Pawn Seeker with properties for Pawn Roamer or else Roamer won't go through all spots if Seeker is denied by Engine based on reachFlag requirements.
#2 You cannot change anything as wanted in your old MH mods if paths have bPlayerOnly=True - this means that reachSpecs have R_Playeronly and even if you are changing that boolean to False, reachSpecs are not automatically modified in run-time - UT won't do this, so path will remain restrictive exactly as it is.
#3 I understand why did you fail here and there - it's because we do not have DOCUMENTS explained properly, actually I cannot claim Bot Pathing tutorials those lousy descriptions from poorly written old tutorials. People will still do a guess work exactly because in XXI century we don't have a real documentation regarding to this chapter.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sat May 23, 2020 5:33 pm

If you ask me why we could use collision cylinder specification paths for a Titan, I will answer you simply: A Titan, so less intelligent in appearance, can patrol and therefore implicitly navigate specific areas - wider, dedicated to its dimensions, although UT has as a common criterion for navigation specifications 70 × 70 UU.
Here we can say that we have a completely wrong choice in UT by default, any creature can use the navigation functions because they are rooted in the Pawn class.
The reason why a Titan cannot be persuaded to patrol is simple or we have even more reasons:
- we do not have PatrolPoint actors;
- we do not have the correct settings;
- we use a Titan with default dimensions and UT will never build such navigation routes. This is what we are talking about when it comes to manual navigation optimization.
Is it still possible to see a Titan patrolling? Yes, it (they) already exists, I modified such a map, because I used the UT Editor, I set the Titans(s) delegated to patrol with smaller dimensions, I wrote the settings for the patrol correctly, and... it (they) did this job properly - better than in Coop maps with fake or messed up patrols. Some "Arden+..." map version was completed like that...
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 876
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Wed May 27, 2020 8:13 pm

Moving that at next thing.
A screwed navigation network might have a missing Node, or whatever evil reference at a missing node placed else where and everything looks fine in first examination - checking each node might take ages depending on map size. Solution would be rebuilding map's navigation network.
However if we want to study for confirming such a screwed navigation network I have worked at two options in MapGarbage:
- bCheckNavChain - this will do a double scan to all navigation nodes for figuring and comparing linked list VS number of Navigation Actors. Surprisingly or not, if Linked List does looks fine even when a node is removed (funky Editor Stage), by iterating through these actors we can see that number of Nodes might be different from Linked List and then we do have some confirmation about a screwed up network.
If some "genius" duplicated by accident a node and deleted the original, we can have something like a copy but... Node won't match reachSpecs referenced because it has another name and the rest of data is original. Here bug is crusher and we cannot figure by simple counting if map has such stunt operated. Then we do have even as a next hint the next check.
- bCheckFakeSpecs - when a node wants to be a copy of a deleted one having original data but not being the original in any way, we can catch this fake copy node and log it because referenced reachSpecs hosted in this false node won't have its name inside them. This also can be helpful for checking integrity of navigation network when we do some reachSpecs modifications and we want to know if map has been badly screwed up because of recounting feature which U227 has and we might be doing wrong things. If map was corrupted, navigation has to be rebuild or... remapping all data correctly. And then, moving reachSpecs back into corresponding nodes means a lot of iterations - maybe another time I'll look if reconstructing network using map's data without rebuilding paths is possible or not. The problem here is that we cannot know which ones of reachSpecs means PrunedPaths. DescribeSpec function doesn't show ALL reachSpec content, disregarding name used which wants to be self-explanatory but it's not how does it sounds like. Subject recovering navigation from reachSpecs array is a bit difficult at this point without a new native support written in an advanced programming language which I cannot write at this time (I think not even in future...).
After testing various ruined maps exactly for this purpose, I'll release an update if it's helpful for someone else...
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Post Reply