House of Fools

Modifications that can be done "manually"
After previously writing these builders - PathsLinker works exclusively in UGold227 (maybe U227 as well) NOT in UT - we might have UT maps with desired navigation routes. By example if a path is passing nearby a wall and we can see Bots often hitting that wall, we can remove those paths (are two paths between 2 navigation points as we learned before) if we do have alternate options around - we force pawn to move through other points, even getting items.
Let's see how do we do these manual removals of paths.
When we are not adding any new node but deleting paths we don't need to re-link Navigationpointlist because all points were connected before and we don't need to do changes.
Let's see this sample in UGold: PlayerStart and InventorySpot spotted in image are going to be disconnected - as you see they have different types of reachSpecs depending on how Engine could move Scout when these have been created. Red path is definitely a "small-size" one while green path is a "medium-size" type where a common skaarj can use it, white means bigger than that.
We open PathsLinker with a right-click of mouse on builder's icon, we scroll options until we get on disconnecting feature and nodes hooking feature. We select PlayerStart in stage 1 - 1 point at time: Here we set bGet1stN1 option to True and then we "build".
Then we are selecting InventorySpot - the same 1 point at time: We have bGet2ndN2 option to True and then we "build".
If we are clicking over N1 and N2 - fields should be completed with data - names of these two nodes.
And now we are selecting Option bDisconnectN1toN2 to True and we "build". Builder will remove ONE path going from PlayerStart to InventorySpot explaining a bit about wrapping of remaining reachSpecs. Screen (viewPort) will get a refresh after OK confirmation - GUI in Editors is a slow thing, it won't refresh data all time.
The result of this task is here - Green Path has been "vaporized". If we want to remove the Red Path too, we need to follow the same steps getting InventorySpot as N1 and PlayerStart as N2 and then "building" a path removal.
In the right terms this PathsLinker is a Builder but... a builder capable to destroy as well not only to build.
If we are doing the same steps for the second Red Path, we will get this: These two Navigation points shown in first image aren't connected anymore.

There is a second way to remove such a connection. We can ask MapGarbage about connections owned by PlayerStart by using bShowSpecs boolean option with PlayerStart Selected. Here we can see our reachSpec number as being 1888 - exactly as shown in previous post.
We are completing this number in PathsLinker and we use option bDeleteReachSpec. After "build" and OK confirmation we have this: The same result - Green Path is gone for good.
What else happened ? ReachSpec 1888 is gone but we do have another 1888 because all reachSpec are rearranged in array. For removing next Red Path we want to
do an examination which reachSpec goes to PlayerStart. Then... we do have ANOTHER 1888 which is exactly what we were looking for. So in this case we can repeat deleting reachspec 1888. Let's see what's happening... Clean as a crystal.
Any of these methods is not that fast as Editor builds these, it's preferable to adjust these paths here and there or else this manual cleaning task takes time - but... it's possible to solve X Spots with problems when pawn starts to be annoying while is navigating a bad spot.

Next Option Sampled - Adding a path - navigation point
We can start compiling a new thing for map in UT, we want all internal variables 100% UT compatible in MyLevel and not elsewhere outside of UT. After compiling new actor we drop it in map in order to keep it available... This is a new AlternatePath actor which is a new thing in map, we don't have anything for it yet, no paths and not chained into NavigationPointlist.
First thing which would be good to do it's causing a link of this actor in navigation chain using MapGarbage - doable in UT or in UGold as primary task. We should have a new NavigationPointlist which will include in chain our new actor(s). This is primary stage in bringing a new point without to use automated pathing script because it will ruin our previous pathing tweaks, if we did them.

Now map should be opened in UGold227 whatever because we need to create reachSpecs from/to the new navigation node.
Here it is: Here we can have options as follows:
- deleting paths between the two nodes nearby this AlternatePath;
- leaving paths between Nodes and just causing connections for both of them - or only one of them.
To me, it looks more suitable to not load more than is needed, So I will remove paths in this session, saving map and closing Editor and reopening them for next task. Here we need new connections otherwise leaving map like this will cause a break point and I did not figure Bots using an AlternatePath in this stage, it needs paths.
Good let's start in next session. We might be curious to see what PathsLinker recommends in Editor as collision parameters for future reachSpecs. It looks like the place is supporting even a Titan - reporting as text in log: Here we need some reachSpecs created - collision data is already copied because we did this test. As we can see, we don't need a jump or such for moving from PathNode to AlternatePath and neither in reversal movement. We will complete reachFlag 1 as being R_Walk and bTwoWay will be True, we use this bTwoWay because we want two connections: From PathNode to AlternatePath and other from AlternatePath to PathNode. After completing these we need to capture our N1 and N2 nodes like in previous case with disconnecting paths - N1 and N2 are Start and End for future reachSpecs and then for bTwoWay N2 and N1 will be Start and End.
Capturing N1 as selected PathNode: And Capturing N2 as selected AlternatePath: After having all data completed for these two future reachSpecs we have to launch "build" task. Description:
- reachDist is computed automatically but if you have some other recommendation it will be in account;
- after creating these two reachSpecs builder will report what did. In case that you have found something wrong - bad data completed or such - you can figure reachSpec number and you can remove it as described in previous posting.
After pressing OK button, ViewPort will receive a refresh and the newer added reachSpecs are shown (as lines). I marked some red things for pointing what is about. In next stage we can do the same with the other PathNode and AlternatePath because we want a full usable route here - we don't need to check collision as long as we have everything mainly in the same type of geometry so these should not be a problem - collision data is not reset, so it can be used for future similar connections. As you can see, we do have now 4 reachspecs connecting what we call a SmartAlternatePath into our navigation network. These paths can be tested using Plain commands RememberSpot and ShowPath OFF-Line - in a local game not a server. Okay, let's save map for now...
Note: If we don't like placement for newer navigation point actor, we can adjust it without anything else as long as it's not moved far away, it won't cause any damage.

The next: Some Hints
Certain CTF maps have a single reachSpec created for any of Flags and even both Flags and these are not like arrows from PathNode to a FlagBase, they are from a FlagBase to a nearby node or more nodes, having no logic connection coming to FlagBase - it's what we can call for real a One-Way path causing Bots to not be interested about any Flag located in its Base.
These do exist because some people are wanting another design but... they cannot manage this design - it's a reality demonstrated already X times.
One solution here would be this PathsLinker causing a single connection (with bTwoWay=False) to said FlagBase for completing the two needed reachSpecs between such two navigation points, and... testing if Engine is pointing Bot there because in certain cases plain DevPath can discard fake routes (a MH map was showing this with paths over a mover).
Second solution, if we want Goblin's originality - record location for this FlagBase, put it back down on the ground, build paths and then... move it back in old location previously recorded, that simple.
Third solution previously described in another pathing tutorial, just LEAVE these "ideas" and don't move FlagBase in any case. Build paths and... modify PrePivot for this "greatly designed" FlagBase as needed using advanced actor editing - perhaps this is a more advanced method for certain mappers, not a must-be after all.

Attaching a bit of animation with Paths removal by user/mapper.