House of Fools

Audience: People able to understand what is needed in a navigation network for artificial intelligence (Bots, Monsters).
_________________________________
We start with a test.

Whoever is not capable of understanding the two pictures below (bugs shown), there is no need to waste time with reading what is explained further. The Start:
I took as an example a messed up map, CTF-Glacier][-CE105. We have a problem at accessing flag, both flags more exactly.

Another problem is common even nowadays not only in the past, combinations of special points, so-called COMBOS.
The shown combination is not just wrong using LiftCenter instead of TranslocDest, but it is a blind way that does not go anywhere. Perhaps a Bot who is close to LiftCenter will somehow be able to follow an enemy using this path, but the chances are quite minimal.

The first problem that does not help us is this unnecessary agglomeration of navigation paths because all the time the Engine calculates the shortest path, the other adjacent paths are almost all the time without utility.

XC_PathsWorker has the ability to create simpler navigation paths, better visible to the human eye, it helps us to see what is missing and where it is missing. When there are fewer data, the process is running faster, and the map reduces its dimensions.

However, in the current context, not even our tool won't do navigation paths to flags because they are placed upper, and somehow pushed at the wall.

We first start adjusting the location on the Z axis with 40 UU lowered - for FlagBase actor(s).
The data entered for the production of navigation paths is as follows:
- scanning radius around a point - 600 UU;
- internal paths limit - 4 out of 16 - 4 directions/4 connections;
- the size of the agglomeration with objects pickups - 20 UU - BunchSize;
- we choose large sizes for paths - bTryMonsterMode - True;
- we do not keep the old navigation network - bKeepOldPaths - False;
- PlayerStart actors are not excepted - bAvoidStarts - False.
Hit BUILD. The result is positive, we have a navigation path as an entry to the flag.
Now we climb the flag back to its original place. Even if the path does not seem too valid, FlagBase has a large collision cylinder that is enough to do its job when artificial intelligence touches it, even if our Bot fails to get to the center of this target point. In an ordinary situation, a navigation node in this way can cause loop movements, but in this situation there is no problem because the route will be changed when the flag is taken.
At this moment we select FlagBase and examine what connections it has with the rest of the navigation network. The path to the flag seems wider than the path that comes from the flag, however, both are valid and can be used normally. Why did I specify in the blue color a generic medium path ? Because this XC_PathsWorker goes with the dimensions of a navigation path of up to 117 × 112 UU aiming to ensure navigation by all the creatures from UT's stock.
The problem with the flags-goals is solved, but here we have some issues to be taken into account. Anyone trying to edit the map, it will only bring the original errors back into the stage - no path to Flag (both Flags) - due to the new map design.

Instead of having 7451 paths / REACHSPECS, we do have under 2000 - taking into consideration that there might be a need for small additions. We must not forget that an over-crowded navigation network and configured with Editor itself has errors that do not help us.

This is "original" state - the bugged one, tuned like that from original CTF-Glacier where Flags weren't having these implemented issues from CE105 (WC Edition if you ask me). Continuing with BUG #2...

Error Number 2 is the path linking a LiftExit from the bottom to the End Point LiftCenter from Flag's platform and which has nothing in common with artificial intelligence in this case, because a LiftCenter has no special directives for a jump on height or on length using tools from Pawn's Inventory such as UT_JumpBoots or ImpactHammer or Translocator. We assume that this would have been a shorter escape way to the bottom, not for assaulting Flag.

XC_PathsWorker can do all sort of paths-connections. In this hypostasis we can connect a navigation point next to "LifterCenter" to it using a unidirectional path, preventing Pawn from doing lousy things.
The manual connection option can be successfully guaranteed if the possibility of movement between the two points is being tested first. We are using bTestReach option with these two navigation points selected. The engine runs a "pointreachable" test and shows us the results of how high can be the creature capable of moving between the two points - and if this is possible. Awesome ! This path can be very logic. Collision data is automatically copied to the "TempReachSpec" structure in which we need to specify "reachFlags". We can use R_Walk = 1. The next Path/ReachSpec now needs a "Start" and an "End". These will be captured one by one using "bGetNodeA" having the selected pathnode and then "bGetNodeB" having "LiftCenter" selected. We ensure that bOneWay variable is set to True. At this time we are putting on TRUE the variable "bConnectAtoB" because we use the Build button. The result goes as follows: PathNode521 is now forced connected as One-Way to the LiftCenter3. LiftCenter actors are going connected by builder using 410 UU as hard-coded distance and not 500. I took this decision from here: "LiftCenter" looks addicted to a 2DDistance of 400 UU - I said 410 UU...

Solution number 2.
This connection can be solved without a new ReachSpec defined as 1799. We can pick the useless bugger ReachSpec going from LiftExit to LiftCenter for giving it a navigation purpose.
This is another stage in which XC_PathsWorker has the power to move paths/reachSpecs elsewhere - bAutoMoveCDtoAB.
We collect the 4 variables one by one to initialize the moving-path process. And now we have the result. If we do not like the navigation path parameters in the new location, they can be changed because the index of this path was automatically copied to the "SpecIndex" variable - 1014 in this case. bModifySpec option can adjust a ReachSpec leaving it referenced in its location - we can change reachFlags or collision data. bAutoMoveCDtoAB does the other need by removing Path from old Place and placing it in the new place.
Here the route to the enemy flag from platform is null through Liftexit-LiftCenter-PathNode, but for return we have the path of course open - it can be tested. We can jump from the height, but we can not fly there - without special directives which a LiftCenter will not provide.
Technically speaking, the re-located path is used by smart creatures because it has R_Special = 32 as "reachFlag", but the parameters can be changed at any time according to the new requirements - it is not the case because the next link is also addressed to smart creatures - jumping down to LiftExit.

Chapter 3 - maps corrupted more or less accidentally.
Here navigation chain can be screwed up, remaining ReachSpecs are pointing nowhere causing a critical game crash.
When map has a special paths-build, we might not want to waste time re-doing entire work again. Bot Support can be somehow fixed here under 1 minute.
Entering the stage MapGarbage. Ooops, indeed something it's missing and it's badly screwed up. In this moment we can report ReachSpecs with XC_PathsWorker - if we want to see them. Editor.log file can be renamed as a TEXT file and opened later in NotePad - we might want them used later.
Here is the report: In next version of XC_PathsWorker we can have some clue about missing stuff. Either way something is wrong here: From 367 to 385 we do have some "NONE" actor referenced in ReachSpecs which are still placed into navigation network - this stage is the game crusher.

All right, let's apply some fixing.
#1 UnLink navigation chain with MapGarbage. If we have lousy data concerning Zones for nodes and for preventing them from being a problem we can check-fix zoning data with option bCheckFixActorsZones. All of them should be normal - nothing has needed any fix.
#2 We are re-linking Navigation Chain. Right now navigation chain is normal having all Navigation Points connected - linked in chain.
#3 We defragment ReachSpecs with XC_PathsWorker - incomplete ReachSpecs will no longer be referenced in navigation chain. Good, now map saved as an updated version it's no longer crashing Bot games - probably for MonsterHunt this is not an answer, but it worth trying this when map has more manual work which is time consuming for being reconfigured again.

HINT: Offending ReachSpecs can be re-used elsewhere in map by Editing them with XC_PathsWorker based on their "SpecIndex" and "TempReachSpec", then applying the defrag option. All valid ReachSpecs are remapped in Navigation Chain so we can recycle these debris data.