House of Fools

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: Here we have the user option: 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.

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: 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.

Bump: Update done - proposed release initially was May 25, I'm not sure if this is very Important. 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.

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. 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.

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...

Moving that at next thing.
A screwed navigation network might have a missing Node, or whatever evil reference at a missing node placed elsewhere 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...

I think it's time for next dance...
MAPGARBAGE June 2020
We can have bunches of checks and finds through Levels - if we want quality. Some of problems, as usual, can be more or less found/solved by using this builder type plugin for UT Editor - so far has compatibility with UGold227h too, for me it was fully functional. The two new features have been added and Icon has been changed a bit for figuring newer version. This will be done from now on for preventing confusions here and there. Tool Tip helper messages will also show update version - I think month and year should be suffice instead of numbers... If you want numbers or other names feel free to adjust this builder as you need... It will require some stock "adjusting" for compiling these codes.

Bump-Timer active.
Before talking about next version of MapGarbage builder/helper/plugin for Editor (UGold227h included), let's see what is about items aka inventories from a map - a common DM map having as navigation goals weaponry ammo armors and so on, these capturing Bot's attention.
As we know (or don't know...) each Inventory is generating some Navigation point called InventorySpot showing to the Bot where to move for collecting everything as possible if navigation network it's consistent. This actor by default has bHiddenEd=True which means it's hidden in Editor, but it might show up by using command in console "ShowInv".
Here might be questioning if this simple automated InventorySpot can be expanded in child classes for doing various tasks not only as a simple Navigation Point items-marker. Technically we can have some code doing different things but Editor won't use this Navigation Point during pathing process and then we need to work in another way. These stages can be as follows:
- writing in Mylevel or outside a new InventorySpot;
- compiling it and adding it where it has to be - recommended as Static/NoDelete thing for not messing with net codes but... it's up on your wishes;
- if this thing is generating an item or has to be linked with item, first step is Building Paths;
- testing paths would be welcomed and recommended;
- now we can add some Inventory almost in the same spot - usually on the ground;
- using Advanced actor Editing we claim for this Inventory as MyMarker the name of our new ExpandedInventorySpot;
- the same task would be done for ExpandedInventorySpot claiming markedItem this Inventory added manually;
- both previous jobs are not needed if our ExpandedInventorySpot does this automatically in map's run-time.

ExpandedInventorySpot can have also a reaction like in Chaos case but... linking items properly not what Chaos is doing - that's stupid, seriously speaking.

All we need to know is that Bot is moving for items with a positive desire and having a "MyMarker" and this "MyMarker" having our item as "markedItem" else Bot doesn't know how to find item unless Bot is a smarter one not plain UT Bot.

Useful assets that can be used multiple times can be compiled in whatever U package that can be imported in MyLevel any time for preventing other dependencies and potential version mismatch errors or various reactions at foreign recompiled bugged packages.

Right now I have such an InventorySpot which is a real charger. It is ONE generating a minimal paths charge but he can spawn/swap more items over time and linked with itself properly. Items are not a need to be there, just this thing. Editor is capable to connect it into network and causing usable paths.

The only problem is that ANY InventorySpot - more or less custom - will get vanished at rebuilding/deleting paths, it's why map needs testing for these using common PathNodes and before to be replaced with another custom InventorySpot after a major testing of paths placement.

For a bit or clarification I'll post two images: Editor and Run-Time for the same Map.
This is common Plain UT view of a Blue-Base (CTF map): And then what's happening when map is running: Even if in Editor there is nothing to see where those small tool-boxes are placed, during run-time there are created random items which are swapped in this case at each 25 seconds. When Bots are retreating or operating whatever combat state, these are goals as long as they are identified as Items linked in paths Network - except those ammo nearby weapons as long as those are mainly collected as long as Bot is coming closer for weapon and then it has some desire for ammo too. This InventorySpot doesn't need a major extra-work, just a few items configured at will, if it's empty, it will generate weapons from BotPack randomly. It's why in run-time map has weapons but... it's empty in Editor, lol.

This can be called a basic prototype of a Dynamic Map. In such Dynamic Maps we can have other various changes more or less random or more or less configured for certain hours, days, and so on.

Bump:
Another things in account toward special tweaks. There are maps which might have whatever manual work inside them. If we want to swap desired weapons we have to connect new items in map as original items in order to be recognized by Bots, while the process of rebuilding paths might solve items problem, we are going to lose several manual tweaks bringing buggers back in stage or no longer having manually added reachSpecs. This will require a bit (or more) of manual work and advanced actor editing knowledge. Even if we are advanced mappers this is boring and time consuming. What we do then ?
Updated July 2020 version of MapGarbage might be helpful for 20 items selected delegated to be replaced in a single click and taking a few seconds depending on mapper's clicking/writing speed - we are declaring name of class which will be used as replacement. Navigation links are copied too saving us from wasting time with editing advanced properties.
Package is below: And then here we have features:
- replacing selected items with a defined class - bReplaceItems;
- putting down over-powered lights using bDownLights and related values - IfMoreThan, AdjustTo, RadiusBigger, RadiusAdjust – detailed explanations are found in document;
- selected items/actors aligning at fixed 3D coordinates using bGridPlacement option.
The last option I'm using if I want my node placed exactly in the middle of a tunnel or a hallway without floating bits, then I'm cleaning OldLocation data saved using bCleanLocBytes option.
Bmp Icon used in editorres folder is modified for suggesting version of this builder. All install steps and features are described in document.

And now... a bit of re-examination toward some old maps well executed - surprisingly yes, there are good maps, okay, perhaps some PathNodes can be lowered a bit but maps is well executed and no junk reachSpecs are hosted inside - DM-Backup it's one of them.
Else if we want, we can speed up DevPath by getting rid of extra-paths which Editor was doing. In this case PathsLinker might not be the right tool because it is addressing maps with simple paths (XC paths), not maps with PrunedPaths - all plain devs are doing these junks. In maps with PrunedPaths this data will go into trash as long as reachSpecs are re-ordered but not mentioned in PrunedPaths by PathsLinker. In other hand, if we want to adjust such a map (done in old school style) I've adjusted code from PathLinker for taking these in account too, and doing things properly even for these plain devs. I could try to set an option for turning PrunedPaths into normal visible paths but... that's another theme... perhaps not needed - reachSpecs can be un-pruned but I have no clue about what collision do need these or this data can be skipped from being adjusted, more about this later.

So far I have to setup more tests in plain maps without XC paths for figuring if removal of 10 reachSpecs are operated correctly. After testing stage, we can have a public updated version of PathsLinker builder tool addressing those invisible PrunedPaths as well.
For testing if map doesn't have borks created, we need an update at MapGarbage as well, after testing we can have an improved updated version. Perhaps some additional checks at Nodes placed too high - supposed less reachable which might loop pawns. A single testing line might not be enough, this can be inconclusive but... ramps might fail to report evil nodes and then... solution chosen so far can be the right one.