Map's Navigation Network - extra-options

[Nelsona]

Another seldom problem which I see after the trip through UGold of an UT map was linking navigation chain after pathing tweaks/completions.
Nodes having iLeaf = -1 which means out of map, placed into void were excepted. The ugly thing, these were not exactly into void, they were in map, dammit, extremely navigable.
September version of MapGarbage will take in account these "void" nodes if they do have referenced reachspecs.
In other hand, if map has suddenly this "zone problem", we won't save screwed map, before linking All required Nodes in Navigation Chain we might want to re-open map, RE-BUILD all geometry - brushes are needed here, and checking again if Navigation Chain does not have corruptions or important elements missing...
We can check lost actors with option bFindVoidBuggers.
MapGarbage did not delete Nodes with reachSpecs but it was excepting nodes with iLeaf -1 from being in chain - this iLeaf goes retarded for reasons which are escaping me...
Future version won't except referenced nodes from being in reloaded in navigation chain disregarding iLeaf stupidity if they do have Paths or upStreamPaths.

[Nelsona]

Another advanced pathing stuff.
Chapter: Let's detonate and vaporize that visibility myths with nodes that needs to be visible each-other.
This criteria is good for figuring how Editor is tempted to connect paths - we don't want them through walls, but not all time paths through floors are an impossible route or a hazard. They can work flawless. As long as after 20 years of UT we do have possibility to manipulate/delete and create reachSpecs or to deploy new reachSpecs in run-time, I'll present what is doable in a run-time patcher in map DM-Curse][ which also can be added in an edited copy of map. Of course, Bot will follow that way without any single problem. For safety, in run-time I connected Pathnode61 to PathNode38 - a path through that hole also undone in original.
In this map PathNode63 doesn't have any visual contact through floor with InventorySpot368. If we are connecting a reachSpec using R_Walk + R_Jump flags which means number 9, Bots can use that path more often that you can think about if we are removing other jumpy buggers heading down and looping Bots around ledges. If Bot is hitting the same floor in various speed cases, we can setup some invisible blocker for actors around opposite side of the hole for making it to fall through hole when it bumps obstruction and resume what it wants later. So to speak we can cause a bug in our favor making Bot to follow a route against "rules" and working flawless.
What does this means then ? This means that if Pawn CAN MOVE using current locomotion method from Point A of map to a Point B you can have a PATH ignoring if these are visible each-other or not - once again Teleporters are not always visible and neither all lifts specific combos but they work demonstrated in original stock maps.
Let's take a look at said navigable spot:

CursedOtherWay.PNG (1.06 MiB) Viewed 9285 times

Mid Finger at Pathing Stories...

[Nelsona]

Bump Timer:
New Info looks required.
Audience: some Single Player / Coop / Monster Hunt mappers and similar enthusiasts.

Rules here can be simple but... you might want to know how simple and what Editor does to you...
#1 "MonsterPaths" - as Engine internals are calculating are drawn in old Editor as Blue Paths;
#2 "BotPaths" are... Red because this was their "color" decision;
#3 TheIssue - Editor needs another color (added in 227) for some intermediate paths. Here thin monsters and Bots are moving but not a SkaarjBerserker which is part of another category - "Big Size".

Lol, how do we need to set our Patrols and AlarmPoints in this case and to do them well ?
If you have done settings for linking them in a patrol or alarm chain we need to find out if creature can follow these or it's just stupid as a rock.
Let's see the Candidate intended to follow this Path:

Sp_Candidate.PNG (7.47 KiB) Viewed 9069 times

Our battle lord is bigger somehow than others

Sp_Candidate_tiny.PNG (7.18 KiB) Viewed 9069 times

Due to their different size here can be a problem if path is 30 × 50 at reachSpec collision parameters. Not all "Fighters" can have a route open. Krall is activated for navigation but Berserker won't really move as intended.
Can we see this cylinder acceptance data ?
Not at this moment - perhaps in future.
Are we lost then ?
No, we are not lost. We have to get on Skaarj suit and testing spots using our old stock commands RememberSpot and ShowPath.
First we need to grow up using a Text macro loaded with a few commands as follows:

Code: Select all

set TournamentPlayer CollisionRadius 35
set TournamentPlayer CollisionHeight 56
set TournamentPlayer DrawScale 1.5

When you are sending this macro command you see yourself growing a bit.
Now you have to walk around alarms until you are nearby target point.
Send command "RememberSpot". Now you need to move back where Monster is delegated to get into alarming stage. Once reached there send command "ShowPath". If Lamp navigation-beacon spawns on a nearby PathNode or even at our first AlarmPoint, we do have Paths Open for SkaarjBerserker usage, if nothing happens then our Blue Paths are "too small". If area is large enough, probably PathNodes are too close to walls or there are some occlusions.
You can walk a bit on the way to our target area sending ShowPath command from time to time. If Lamp suddenly spawns, Paths from that point are good, but previous ones have buggers and those should be examined in Editor more carefully - trying to align them well in center of some tunnel or such.

If Editor won't create these requirements even if area is permitting movement, then time has come for PATHSLINKER and 227.
You don't need to delete reachSpec, you can Edit reachSpec from these alarms with big numbers. I made such paths having 60 × 80 and... nothing goes wrong guaranteed. Number of reachSpec going from AlarmPoint1 to AlarmPoint2 as a virtual example is shown by MapGarbage Editor builder.
As result in 2020 we can have ALL sort of paths for our needs, a Monster can be locked into an area using this way in reversal, making path more small than monster and monster will not be accepted as Path Seeker if is too big. ReachSpec lock-down is faster than any SpecialCost written in UScript because is taken at C++ Processing Level X times quicker than UScript from UT packages.

Impossible Possible
Behemoth is a Pawn closer to DevPath limits 70 × 70 in UT - at least this is what I know so far.

SP_AtLimit.PNG (7.15 KiB) Viewed 9066 times

A single tiny occlusion can head to a rejection if reachSpec goes to a lower Level. Of course, Behemoth is not intended to do more stunts but at least it might be patrolling. So if you say that in Editor you'll have a long bad time grinding teeth and trying a Patrol for a Behemoth I will say: I'm not 100% agree here - if won't need to jump (there is a way even for that), plain rooms demonstrated navigable using "GrowUp" macro can have good reachSpecs inside them.
This map opened in 227 can deliver data about these patrols (reachSpec Index Number) and... you can inject 115 × 110 collision size. Here we are talking already about Titans. Engine is calculating routes using a plain comparison, nothing is affected by numbers if they return positives at testing and then Pawn is accepted because reachSpec doesn't seems to clamp at a maximum value and they never bothered to do max values possible - their bugs goes our advantage because we want Titans smarter than the rocks which they are throwing.

[Nelsona]

Next subject:

Glitchy glitch
Reasons for using MapGarbage and PathsLinker - in a translation different said, capability to handle manually reachSpecs as a major need in our pathing works - especially where XC_PathsBuilder aka <reachSpecs Saver> at a moment does crazy stuff even it saves a lot of data from being added in Level.
Maybe you can imagine a long path passing over a hole where pawn can jump, if that path is too long Pawn after resuming navigation will get next MoveTarget exactly the point closer to him, the previous point where he was coming from - all is stupidly looping out of purpose until he is facing a threat, he dies and the "threat" keeps looping too... If you cannot imagine this scenario I repainted some images and using Editor because I'm not bother with demos where paths are not visible and probably is hard to understand without a heavy video processing which I won't do today and neither next week. Let's see the stage explained a tiny bit.

20201026_204251.gif (1.12 MiB) Viewed 9055 times

Character in movie is Xan showing us the "How To".
Xan says: I got Pulsegun and I think the nearby RocketLancher is suitable for some battling. Me PickingDestination according to my script. Okay, I'm moving to PathNode, oopssy I have to juuuump, lol, wow I did it - What did I tried here ?... Umm... PickDestination says now move to the Nearest Reachable Navigation Node - back to InventorySpot, lol.

And if Xan is mainly alone, it will loop here all day long and all time here. Over such holes, we need to add paths in a smarty way, Pawn should always land over the second HALF of distance between these nodes connected over the hole. If pawn is landing in first HALF of distance, PickDestination will return as MoveTarget the closer node and this Node is exactly the Start of jumpy route pointing Pawn back in previous place. We don't really need these jumps all time. PathsLinker is able to create what reachSpecs we want based on BRAIN, EYES, and a bit of Experience. It's what automated Scripts are not doing... YET.

MapGarbage shows the reachSpec index driving from InventorySpot to PathNode and we can remove it using PathsLinker. What's the deal ? Xan will move through other route having a smaller jumpy reachSpec and... continuing navigation. The reachSpec from PathNode to the InventorySpot doesn't really do damage. Xan is landing after Jump exactly where it needs to be and it will be driven to the PulseGun according to desire code and PickDestination. The route in reverse is a looping spot due to Uber distances specific to XC assets which also have other issues but that's another chapter which will require some images - probably a movie which I will have to capture. There is about HEAD obstructions blocking pawn in a hilarious way and other funky jumps which not even human good at BT gaming is unable to perform. PathsLinker is the tool for these jerkish reachSpecs. 80% of usage for PathsLinker is reachSpecs destruction - here I adjusted a bit code for speed-up human activity toward disconnecting two points, that's another discussion.

Alternate Solution:
Custom Bots capable to register routecache 1 and leading there if reachable post jumping, and resetting data during death. Not an easy task and not the most wanted method, we can have paths because we have tools.

Beer time ON !

[Nelsona]

Bumping timer has arrived: Subject: Those Stairs...
It comes that Edy Goblin known by friends as UnrealEditor (from any UT version) in certain types of stairs won't map paths known as reachSpecs due to general angle of stair but which somehow it's climbable.
For understanding what exactly is about let me introduce the stage:

One_Way_Stair.PNG (873.2 KiB) Viewed 8766 times

In image we do have whatever XC assets for showing exactly paths/reachSpecs as they are - built by Editor out of tweaks. It's a simple situation showing a One-Way, Bot won't go up for items as long as there is no path heading to vial and Flak stuff.

Q: Is possible to have a reachSpec for going up and map being ready anytime for a proper Bot Support without extra-tweaks and trips through various Editors ?
A: Yes, it is.
A simple solution here without moving any Navigation Actor is having something simple in MyLevel - a new Zone

Code: Select all

class MorphPathZone expands WaterZone;

/*
	This is only for connecting nodes - purpose is mapping paths in Editor - they will have reachSpecs with R_SWIM reachflag = 4
	Bots are not having issues here since they are capable to swim so they won't discard these routes.
	In run-time zone is a normal one and then it needs a wise placement for Navigation Nodes or else generating
	impossible paths won't be nice.
*/

simulated Function PreBeginPlay()
{
	bWaterZone = False;
	Super.PreBeginPlay();
}

defaultproperties
{
	ViewFlash=(X=0.000000,Y=0.000000,Z=0.000000)
	ViewFog=(X=0.000000,Y=0.000000,Z=0.000000)
}

In can be added and compiled in MyLevel (in map itself), and all geometry parameters rebuild. If you ask what is about: What has to do a zone with Pathing ?, - the answer can be deducted already from what we read before - current locomotion method for reaching from point A to point B. If you are "talking" with Editor telling him about Water, definitely paths in water are linked anywhere Up Down Left Right with desired Swimming ReachFlag known as R_Swim. Zone described above is water in Editor, it turns itself into a Non-Water zone during map's run-time so the game is normal.
How does it look then new "environment" ? It has two faces: Water in Editor, and a Dry Land in run-time. But... because in Editor there is water, DevPath will build Paths with swim flag which is not really denied by Bot as long as Bot can swim if it has to. Let's see the picture:

Two_Way_Stair.PNG (917.96 KiB) Viewed 8766 times

Even color is shown different. Bot in run-time will quickly climb stair - perhaps might have small random stepping issues but... it works. Actually Engine is pointing perfectly all route to the goals. In this case you can see the new zone in image, map is supporting paths rebuilding X times with the same results - including 469 assets done until now.
Q: And then ?
A: And then it's time for evidences.
Without moving anything, rebuild paths here:

DM-Stepping_No.7z

(10.56 KiB) Downloaded 331 times

And later you can do the same thing here without other moves.

DM-Stepping_Yes.7z

(10.57 KiB) Downloaded 345 times

See differences... Just for a detonation of myths and lousy stories.
Right now I cannot define a name for this pathing solution by tricking zone property.

In other cases for preventing connections impossible to navigate out of water, we can use whatever non-solid cube/cylinder/cone having portal type faces and claiming this "morph-zone" inside. All it needs is finding a good position of nodes in order to gain Two-Way connections.

[Nelsona]

Next chapter is around subject pathing but... maybe it's more like... cosmetics.
OldSkool mapping using Plain UT Editor show in ViewPort at port's flag "Show Paths" internally known by C++ friends as SHOW_Paths being a sort of "enum" variable. I would like to find an automated solution for triggering it from UScript when user wants to examine paths in MapGarbage and with eyes. Paths are those lines drawn between navigation points which newer assets are using them as Arrows.
What is about ? Tutorial - those with 1 star from 5 stars toward tech information are explaining that Red Paths are heavy when we already know that is about BOT ONLY paths and far from being denied if reachspecs are connecting nodes.
And then ? And then let's completely ruin their fantasies and let's ask them about these colors:

TheColors.PNG (1.17 MiB) Viewed 8744 times

Ahem, boys and girls. Definitely if we don't like RED we can use... Yellow - they can be seen better preventing your eyes to get tired of stupid red lines. Else... Monster Paths can be more than a dark Blue.
We are talking about drawFlags and configuration taken accordingly.
These are here in old versions

Code: Select all

			// Draw all paths.
			if( (Viewport->Actor->ShowFlags&SHOW_Paths) && Viewport->Actor->GetLevel()->ReachSpecs.Num() )
			{
				for( INT i=0; i<Viewport->Actor->GetLevel()->ReachSpecs.Num(); i++ )
				{
					FReachSpec& ReachSpec = Viewport->Actor->GetLevel()->ReachSpecs( i );
					if( ReachSpec.Start && ReachSpec.End && !ReachSpec.bPruned )
					{
						Viewport->RenDev->Draw3DLine
						(
							Frame,
							ReachSpec.MonsterPath() ? C_GroundHighlight.Plane() : C_ActorArrow.Plane(),
							LINE_DepthCued,
							ReachSpec.Start->Location, 
							ReachSpec.End->Location
						);
					}
				}
			}

As I told already if you can understand a bit what is about prunedpaths are not shown - you can ignore the bugged comment - yes even the code comment is bugged in UT - NOT ALL PATHS ARE SHOWN, geniuses...:

Code: Select all

...
...  && !ReachSpec.bPruned
...

but what it's being shown is extremely configurable, lol. Let me light up a bit what is about - C_GroundHighlight and C_ActorArrow. Cough ! Ooops, it's not the Covid-19, it's UnrealTournament.ini - friends are calling it UT.ini.
We can open said file in a Text Editing application such as NotePad++.
Section is called

Code: Select all

[Editor.EditorEngine]
UseSound=True
CacheSizeMegs=256
GridEnabled=True
SnapVertices=True
SnapDistance=10.000000
GridSize=(X=8.000000,Y=8.000000,Z=8.000000)
RotGridEnabled=True
RotGridSize=(Pitch=1024,Yaw=1024,Roll=1024)
GameCommandLine=-log
FovAngleDegrees=120.000000
GodMode=True
AutoSave=False
AutoSaveTimeMinutes=3
AutoSaveIndex=5
C_WorldBox=(R=0,G=0,B=107,A=0)
C_GroundPlane=(R=0,G=0,B=63,A=0)
C_GroundHighlight=(R=0,G=100,B=200,A=0)
C_BrushWire=(R=255,G=63,B=63,A=0)
C_Pivot=(R=0,G=255,B=0,A=0)
C_Select=(R=0,G=0,B=127,A=0)
C_AddWire=(R=127,G=127,B=255,A=0)
C_SubtractWire=(R=255,G=192,B=63,A=0)
C_GreyWire=(R=163,G=163,B=163,A=0)
C_Invalid=(R=163,G=163,B=163,A=0)
C_ActorWire=(R=127,G=127,B=0,A=0)
C_ActorHiWire=(R=255,G=127,B=0,A=0)
C_White=(R=255,G=255,B=255,A=0)
C_SemiSolidWire=(R=127,G=255,B=0,A=0)
C_NonSolidWire=(R=63,G=192,B=32,A=0)
C_WireGridAxis=(R=119,G=119,B=119,A=0)
C_ActorArrow=(R=163,G=163,B=0,A=0)
C_ScaleBox=(R=151,G=67,B=11,A=0)
C_ScaleBoxHi=(R=223,G=149,B=157,A=0)
C_Mover=(R=255,G=0,B=255,A=0)
C_OrthoBackground=(R=163,G=163,B=163,A=0)
C_Current=(R=0,G=0,B=0,A=0)
C_BrushVertex=(R=0,G=0,B=0,A=0)
C_BrushSnap=(R=0,G=0,B=0,A=0)
C_Black=(R=0,G=0,B=0,A=0)
C_Mask=(R=0,G=0,B=0,A=0)
C_WireBackground=(R=0,G=0,B=0,A=0)
C_ZoneWire=(R=0,G=0,B=0,A=0)
....

Probably as you can see... these vars are there and... taken if we did some changes BEFORE opening Editor. We can adjust their colors as we want. Color codes are R G B and applications like Paint can reveal R G B values so you can have your desired colors...
A few minutes later you can ask a mapper if he/she knows what does that means a Magenta path line . I don't think you'll get a good response - it's a lottery.

Next Stage: I think MapGarbage can be educated to Switch colors from inside Editor letting user to pick what is suitable for his needs - only for original Editor.

Edit: Let me show you something... Send command "preferences" in console. See this section - yes, all colors can be edited from there in all assets, even in mutators if they are correctly scripted and not using guessing.

EditColors_for dummies.PNG (21.63 KiB) Viewed 8653 times

[Nelsona]

I think it's time for bumping this thread in order to discuss Boxes Chapter. Discussion it's here because in a Basic tutorial not everyone understands what UU is, aka UnrealUnit.

Let's start with a small introduction: DM-Deck16][ - a known map where Bot it's not interested about PulseGun from that middle box unless is heavily ambushed and it will try desperate to gain any weapon during combat. As for Flak nearby Vials ( where is that annoying flickering lamp ) it's the same story: Weapon taken only during a closer combat.
What do we have as main "Data" ? These Boxes having items placed on them looks accessible easily in game difficulty setting HardCode mode.

HC_Setup.PNG (20.95 KiB) Viewed 8668 times

These are defined from a cube brush having 64 UU. Usually Editor is not mapping incoming routes for these Boxes even if we are following rules, placing nodes properly and letting Editor to do the Pathing task. These items if are points part of a route to something, are navigation breakers as long as they do not have incoming paths. Let's create a scenario:

O_No_Box.gif (923.11 KiB) Viewed 8668 times

Here all are placed by Editor and paths mapped by Editor.
Bots are getting over this Box only when they fight doing various tactical moves and finally reaching to the Flak. When a Single Bot spawns here, or has no enemy, it won't move anywhere - maybe if is wandering closer to "ThigPads" item.
Good... This was buggy Intro...

Now it's time to see what is doable without to ruin original Bot navigation through the map and allowing movement over the 64 UU Box and motivating it to gain item and keep moving ahead.
The two described breaking nodes can be pushed upper on Z axis with 27-28 UU. Plain collision at 50 UU over ground will gain additional 27-28 UU which means around 77-79 UU over ground (if Editor does an automated correction). This height is almost at boundary if are we talking about Bot's reachable capabilities when it's using default locomotion method. Perhaps we might want to go at 27 if 28 does damage in our spot. What we get here ? Surprise ? No... It's just Goblin... pretty stupid for being fooled when it's mapping paths using Scout WITHOUT other extra-hacks...
Let's see how do these are looking like:

O_Yes_Box.gif (966.68 KiB) Viewed 8667 times

Oh well... Bots are jumping on the Box and Over Box moving extremely motivated at Flak. Yes, number of reachSpecs is bigger, we have paths to the Box and... more than that - here it is advisable to optimize network properly without adding a lot of extra useless paths.

Naughty whining...
I don't use 469 or whatever XC assets... How do I know if my InventorySpot from Box is not a breaker without incoming paths ?
Answer:
Logically from single line images you cannot see reachSpecs (yes, Polge, exactly...) but... we can use advanced Actor editing for our InventorySpot after sending command ShowInv letting these visible.

Plain_View_Question.PNG (519.55 KiB) Viewed 8664 times

We have here Monster-Paths and Bot-Paths according to calculations executed by Sir Edy Goblin aka Unreal Editor.
We can do an advanced check (EditorActor Name="InventorySpot...") whatever is called.

Plain_View_Answer.PNG (419.74 KiB) Viewed 8664 times

If we are looking here, we have some data which we won't keep in mind but we track the logic of these facts:
- Paths numbers means that this node has outgoing paths - normal for such a higher point;
- UpStreamPaths has a single number in this case (27 UU height)- perhaps we can gain two if we are trying other closer locations for these nearest nodes (even a few little floating points higher 27.5, 27.8, 28 UU) - which means that our InventorySpot has one incoming connection done by a reachSpec having 7 as index number in reachSpecs array and Bot will move away using any of those 4 Paths, so accessing network through this spot it's possible. Either way is this one:

Plain_View_Answer_1.PNG (414.81 KiB) Viewed 8662 times

MapGarbage can show exactly what connections is having this Node.

CaveAT: In classic difficulty settings - see first image from this post, such a map won't be a charm if low skilled Bot cannot jump on the Box - this formula it's addressing Difficulty Levels as HardCore and upper...

Post Notes:
#1 Nodes have to be moved upper or lower only for good reasons unless you want your paths to be buggy or gone for good. You don't want Nodes pushed upper in ramps - don't say I did not warn you.
#2 Alternate method for a box or a similar situation is a Navigation Combo LE-LC-LE known as LiftExit-LiftCenter-LiftExit - these are an extra-charge causing more reachSpecs. Why ? Because a combo needs at least 3 Points and not 2, a LiftCenter any type (including child classes) won't link with a PathNode or InventorySpot but only with a LiftExit which needs to be connected at said Inventory or else nobody will roam there unless a tactical situation requires a stunt or such.
#3 Noobs are hardly punished here, if anyone steals the map and wants to set a Classic Difficulty game, Bot will react like moron - there are chances for them to not understand what's going on - "OMG, Bots are dumb" - not that dumb as the dumb thief mindlessly stealing files...

[Nelsona]

Bump - Return with Updates concerning 2021 2022.
Presuming that we can have visible ReachSpecs/Paths in normal formula - arrows more exactly, we can see what routes can be found or not as arrows pointing road point to point until goal is closer - reachable.
However we might want to know why our arrows are not helping a Bigger Pawn to crawl map up to the target Location even if paths seem normal and Bots are using these. Either way if we look at map in plain UT, paths are Blue - supposed good.
Let's see the facts as Introduction and Explanations.

A ReachSpec/Path created between two nodes and shown as a Line has in reality a few parameters that are processed during navigation calculus. Some of them are factors capable to discard a creature which is not having movement capabilities required by our path. Path/ReachSpec has internals as follows:
- Index - this is a sort of "name" for Path recognized as integer number - these are found inside lists usually not visible in navigation Nodes but visible in advanced actor editing mode;
- START - This is the Point set as Start Location for roaming forward to the End - as variable this is an actor but... mainly NavigationPoint;
- END - This is the point set as End of this Path where Pawn is supposed to reach - if is accepted - because...;
- CollisionHeight - is the maximum height of a creature that is accepted for this Path - bigger is rejected;
- CollisionRadius - is the maximum radius of a creature that is accepted for this Path - the fat is discarded;
- ReachFlags - there are values concerning movement capabilities - pawn which cannot jump or swim is rejected from this path if swimming or jumping is needed;
- Distance - here is the Length of Path in UU (Unreal Units) - engine uses this data for allocating the shortest route;
- bPruned - aka byte Pruned - if this is Zero, Path is normal, if this is One as value, we do have an invisible path which is a shortcut over two nodes - not route A B C but routing A C directly.

And then, a not very "large" Path (concerning CollisionHeight and CollisionRadius) + required ReachFlags (movement capabilities) might discard Pawns which are too fat/big for this Path. Yes, we do have common Paths for Kralls set as Blue but... these can be useless for a SkaarjWarrior whatever.
Indeed, in previous UT ages this was a problem heavy to be investigated and not shown where is the bugger path. Why this "WAS" an ugly problem ? Because now days we do have a tool which is capable to do a complete report of Paths included in a navigation node references and also reporting ALL ReachSpecs from map.
Suspect tunnels can have Nodes which are using Names such as PathNode23 PathNode25 etc. All we need is reading the report and figuring what paths are there.
Such a report is gracefully delivered by XC_PathsWorker updated to the latest version. This tool is a builder Plugin for UT Editor and using XC_Engine at least v24 for capturing data from our Paths-Lines. If whatever Path has parameters too small for a SkaarjWarrior (path is closer to a wall) we can adjust this ReachSpec for our Warrior if we know that pawn has no issues in moving through spot or else it goes stuck there.

Another stage is... some "mental attack". Let's see what is about when Editor aka Goblin aka Trash Maker does paths for us.
- it has no ReachSpecs logically limited even if the same Engine is processing up to 1000 navigation nodes - Interesting huh ?
- it might "forget" to add some ReachSpecs in navigation chain leaving them outside and even doing more than a Node can host;
- it does "MonsterPaths" accepting Pawns until 70 × 70 as collision cylinder - even if bigger boys can follow a Patrol or an Alarm - demonstrated by custom enlarged paths - Yeah, "nice" joke of Goblin;
- it does even two reachSpecs connecting the same two nodes - Teleporter stuff directly visible and reachable - lol - sometimes we can use this feature in our favor - some brain is needed here and we can have some better connections for flight and special jumping;
- it does combo paths even if LiftTag is not defined connecting bullshit long routes through walls;
- it doesn't allow custom Nodes for warps in order to allow testing map without crushing game;
- nobody will ever see flags like R_Fly R_Door R_PlayerOnly done by plain UT Editor - but Engine recognizes them in run-time;
- it does funky routes in ramps due to "solution" used for probing with Big First - Small Last. Big Boy is reaching better to a higher node than the smaller pawn;
- it does impossible paths through some stairs/grates even if no usual Bot Pawn can ever step there;
- it does normal paths through teleporters and Pawn is automatically hijacked from initial route elsewhere out of its will;
- probably more.

The most of these "jokes" have been solved in XC_PathsWorker, here also we have capabilities to define our paths as we want. Whenever Pathing Script is forgetting some connection we can have it from elsewhere or defining a new fresh Path. Rules are normal, any new needed node has to be linked in Navigation Chain and then Paths can be defined at a later time post-main-pathing.