House of Fools

Returning to the Trash-Lord aka MapGarbage.
Here I won't add major changes but... something for Navigation Chain - planed for this month.
If it's reconnected after disconnecting it (for completions or whatever tasks), it will wrap Nodes with objectives first, attempting to speed up internal routing procedures... Routing starts with goals, then is reversed, then is mapped RouteCache points. It's an attempt to reduce iterations if possible...

Update Time:
First post has been updated with Builders as follows:
1 - MapGarbage:
- Wrapping Navigation Chain in certain order not just harvesting Points based on C++ iterations.

2 - XC_PathsWorker
- Adding bInWaterWeSwim - XC Paths that are using Walk and or Jump flags inside water are set back as Editor does R_SWIM and not other way (without movement logic);
- bRealDistance - useful for updating certain nodes moved post-pathing in order to match Real Distance - even some COMBO paths are touched when are having small distances - 1000 UU for a small route doesn't make any sense;
- bDisconnectSelection - Selected Node(/s) will have all Paths that are including them Nulled - if node is planed for deletion all references from Network pointing to trash Node must be removed for preventing references to nowhere - next option will clean all Network for such useless routing data stored in map;
- bCleanRoutingJunks - will remove (like MapGarbage) all related routing chains created during Paths Building process by Edy Goblin aka UT Maps Editor;
- bDisconnectTwo - Two Selected Nodes (even more) will have Paths that are connecting themselves each-other removed - this way getting rid of an Evil Path goes easy as a pie - All Left-Over nulled Specs can be cleaned later in final stage with prior option (bCleanNullSpecs).

Applied a small code update at MapGarbage - it did not affect the task but causing builder to print two errors.

For XC_PathsWorker probably next option is added for completions using XC internals, it was doable so far in a few steps but... simple might be better.
On Interface... Working like here... It seems that by using the corresponding XC_Engine version, builder is capable to work in UT patch 469d like in prior versions...
There will be more tests before any future release.

Several Tests Conclusions

It can be used to connect navigation points where gaps are found.
However, simple maps without special nodes can be fully populated with navigation specifications if "InventorySpot" actors are added. It does not make navigation better where navigation points are misplaced and making blind guesses. It is necessary for the user to know this chapter because such Builder-Plugins are not tutorials and they don't have human eyes. It only helps the user to perform certain manoeuvres to avoid over-crowded paths where there are many navigation points, so we don't expect to see errors made by us fixed by this "Builder".
The strategy used seems to be based on internal "Engine" functions, we can see the useless default "Scout did not fit" error messages, as usual without any clue about the location of the problem.
The "MaxDistance" variable left at ZERO seems to default to 1000 UU. I note that very small values are not supported, in which case the default 1000 UU is applied.
This "MaxDistance" will be alleged maximum distance where a Navigation Point might have connections at other Points. It's working normally at 500 650 700 850 etc, so here we can have a bit of user optimization.

Brother "Builder MapGarbage" can be used to deploy "InventorySpot" actors linked normally with their Inventories and in next seconds map is ready for creating Paths - it seems a bit faster without that "Progress Bar". Pathing map this way will require the selection of all Navigation Points, also "MapGarbage" can do this task in no time.

Edit:
By taking as a sample Deck16][ map, this way of pathing map works like here, we can actually have our custom types of InventorySpots or whatever... or we can simple except some Inventories that are too close each-other.