House of Fools

This chapter is supposed to help mappers which have knowledge about what a Bot does need for roaming into a Level/Map - paths, navigable paths.

Here discussion (a monologue like) will be about fine tuning done to navigation network in order to gain desired results. For figuring bugs and bad connections Editor has nothing but... we do have a few toys and some information. If no one bothered to explain details, I'll try my best.
So, for an advanced map pathing task we might need advanced things. Editor add-ons like XC_EditorAdds coming with XCv23 might be helpful in editing because it shows paths and direction of such a route between two NavigationPoints. I'm using nearby XC stuff some builder which I was modifying for a few time. I called it MapGarbage because it helps me to remove garbage from map - In this topic I might call GARBAGE those links between two Navigation nodes causing ugly Bot glitches and not only for Bot.
This is the builder: For fans of adventures, setup is described in document and it works like MapPurger by Gizzy. This builder in exchange has completions. Window is opened at pressing right-click exactly as for other builders, size is hard-coded in Editor except internal data separator... User will pick an option doing setup TRUE and pressing BUILD button. Activity is logged in Editor's log file and this can be opened in Editor for figuring output text done by Builder - paths are explained in text format. This requires selecting a PathNode or such and making true bool value called bShowSpecs and then building button. That's about looking if my PathNode has incoming paths End=MySelectedPathnode or if some paths are starting from here Start=MySelectedPathNode.

For continuing pathing campaign first we have to use some bad samples and a solution or two solutions for fixing problem/s.

I'm going to take a random example of a MonsterHunt map supposed to have paths but... is a false alarm as shown basically by XC_EditorAdds in a matter of seconds. In image we can see PathNodes and a selected LiftExit. If Pathnodes are well connected in both directions, for LiftExit we cannot say the same thing. LiftExit is connected to PathNodes but there is no connection coming to LiftExit from these two nodes - so this route is broken, a Bot will never go to the train by itself only called closer step by step. If primary image shows what is about. Let's see what MapGarbage is saying: And let's see what we have - a report for LiftExit0 - the one selected:
- an Upstream says that LiftCenter has a path to this LiftExit;
- A Path starts from LiftExit to some PathNode;
- A path starts from LiftExit to another PathNode;
- another path starts from LiftExit to LiftCenter.
Here we cannot see where are paths from some PathNode to this LiftExit and/or another PathNode to our LiftExit. This will confirm what first image shows, Bot has no route to the MonsterEnd. This is only first bug.
Next Bug comes from LiftCenter placement and stupid Train design like a pig trough and LiftCenter will never reach in a position for making bot to move out of Train not to mention that killing Queen makes MonsterEnd Unreachable. This is an example of a map requiring ADVANCED pathing knowledge and NOT really EXPERT pathing.

Let's see options from stock's assets:
- another combination of LiftExit - LiftCenter -LiftExit using a MaxZDiffAdd value and placing LiftCenter lower than default placement with a few units;
- cheating with a default teleporter - this is way stupid.

Let's see community assets:
- a blind teleporter forcing Bot to jump - not teleporting - helped with Bot specific kicker if Bot goes retarded;
- swJumpPad tweaked a little bit.

Special XC assets:
- do a connection using Event from a PathNode set as Tag for selected LiftExit - in older XC version a la v21 using Event from Pathnode to the Name used by LiftExit - this is too simple for a failure.

Here is a connection - this is in fact the single tricky connection making Bot to reach in last area, and of course here we do have ANOTHER train more closer to Bot requests and extra lightning. In image we do have even a few extra paths making Bot to move out of train's way if by accident was dropped there .

Capture the Flag - if you can
This post is about something from past - whatever CTF map where Bot Support was mandatory but... later about these habits and let's mind problem.
Blue team was able to head and get RedFlag never returning Home at their BlueFlag. Red Team never attacked Blue base for getting flag but roaming around and playing TDM known as TeamGamePlus.
It we take a look at BlueFlag, design brain-fart made Flag obviously unreachable. And because we speak about a good Bot support toward design let's see first the initial crap. This is the FlagBase navigation point containing FLAG which here is invisible and it goes visible when has a carrier - speaking about map's run-time. FlagBase is exactly what we see when CTFGame starts.
We do have a problem here: Arrows (Paths) heading to this Flag are ... missing. We have arrows from Flag to whatever points but nothing coming here.
Why paths have to be here ? Because the nearest NavigationPoint to the flag is the reference for DevPath when Pawn is looking for a route to this flag, yes, that is the main criteria. FlagBase being much over ground, it's not only natively bigger but mapper went busy to make things worst.
What is doable here ? Good question. Let's see how do looks a high big-ass flag but REACHABLE from all map's spots. It looks like FlagBase has now at least 3 direct Paths heading to the location making it reachable but... we can adjust PrePivot for this thing making it to look higher and... this is very noticed in game too not only in Editor. Due to direct images I think I don't need to ask MapGarbage about other evidences showing the same thing.
Command used for adjusting FlagBase without EVER moving it is
editactor name="FlagBase1"
where FlagBase1 is named Flagbase navigationPoint - never but never push them higher unless you know what you do.
And then map might have a good game flow if Flag problem is being solved .

Today's Post.
Bot skating at wall trying to move at a lower point and looping.
Theme: hacking/removing such a bad path in Editor.
Sample taken is map DM-1on1-Sph3res-v2.unr, doesn't matter author because Editor did this mess not the author, happily boosted by Engine movement code toward bAvoidLedges bStopAtLedges Pawn's deal or such, really doesn't matter right now for me because there is a solution for Editing map if during testing stage such spots have been found.
The said bad path here is that one linking LiftExit2 with PathNode0 offering a looping route for Bot. In first step of debugging we need to find a path Starting from LiftExit2 which has End PathNode0. So we have to select LiftExit2 (from that node there is no chance for a route to LiftExit because Bot will not fly) and query a bShowSpecs at MapGarbage.

MapGarbage wrote: oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - UpstreamPaths[0]=58 Start=LiftCenter0 End=LiftExit2 RFlags=Special =32 Dist=500
Connected: LiftCenter0 to LiftExit2.
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - Paths[0]=83 Start=LiftExit2 End=PathNode0 RFlags=Jump Walk =9 Dist=922
Connected: LiftExit2 to PathNode0.
NoReachFrom: LiftExit2 to point 0 which means InventorySpot92
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - PrunedPaths[0]=86 Start=LiftExit2 End=InventorySpot85 RFlags=Walk =1 Dist=740
ShortcutConnected: LiftExit2 to InventorySpot85.
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - UpstreamPaths[1]=609 Start=InventorySpot60 End=LiftExit2 RFlags=Walk =1 Dist=280
Connected: InventorySpot60 to LiftExit2.
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - Paths[1]=59 Start=LiftExit2 End=LiftCenter0 RFlags=Special =32 Dist=500
Connected: LiftExit2 to LiftCenter0.
NoReachFrom: LiftExit2 to point 1 which means InventorySpot84
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - PrunedPaths[1]=82 Start=LiftExit2 End=PlayerStart0 RFlags=Walk =1 Dist=747
ShortcutConnected: LiftExit2 to PlayerStart0.
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - Paths[2]=84 Start=LiftExit2 End=InventorySpot60 RFlags=Walk =1 Dist=280
Connected: LiftExit2 to InventorySpot60.
NoReachFrom: LiftExit2 to point 2 which means InventorySpot83
oooooooooooooooo: oooooooooooooooo
Specs: LiftExit2 - PrunedPaths[2]=85 Start=LiftExit2 End=InventorySpot67 RFlags=Walk =1 Dist=679
ShortcutConnected: LiftExit2 to InventorySpot67.
NoReachFrom: LiftExit2 to point 3 which means InventorySpot76
NoReachFrom: LiftExit2 to point 4 which means InventorySpot59
NoReachFrom: LiftExit2 to point 5 which means PathNode39
NoReachFrom: LiftExit2 to point 6 which means PathNode36
Specs: +++++
Specs: ReachSpecs Flags summary:
Flg: R_WALK = 1
Flg: R_FLY = 2
Flg: R_SWIM = 4
Flg: R_JUMP = 8
Flg: R_DOOR = 16
Flg: R_SPECIAL = 32
Flg: R_PLAYERONLY = 64
Specs: +++++

Bingo !!! Path having ID 83 and going into LiftExit2 as Path[0] has Start=LiftExit2 and End=PathNode0 - Bugger found.
Step 2 preparing destruction - we are using lower console for sending a small "letter" with following content: Something shows up and even we can do the same thing for PathNode0 - if we want to... Some special properties are open - usually I have direct access to these due to my stock Editor used - for common users they need to open special properties - advanced actor editing.
The Third Step means Looking for Paths[0] property which must have a number there - 83 for our case as shown by Mr. Garbage.
And now we have to take in account other specs, number 1 will go as number 0, number 2 will go as number 1 and then number 2 must have value "-1" for not having duplicate ReachSpec. It's a sort of "Walking Byte". Final result of this hackish solution will be like here: Like I said, we can READ navigation specifications, we can ruin them correctly, but ONLY Editor can manipulate them because they need an identification number (83 was our bad path) and this path can be removed from Node's paths references.
Extra-Note: In this Case PathNode0 is not having index 83 in upstreamPaths - in theory it should be there and it has to be removed too, but here is not. This is a bug produced by Editor when paths are too overcrowded causing glitches in updating lists properly.

Solution Biography:
Epic showing this method in TranslocDest navigation point for games that do not include translocator. What UScript can do, definitely Editor can do too, and this goes directly in map itself.
Path Line is still shown because reachSpec still exist in map's reachSpecs array, but this path has no pointer in navigation network (we deleted it) so it's discarded in paths processing task, and bot will take Lift-Way and no longer trying to jump and hitting wall and retrying and so on.
Greetings goes at Epic for a solution which I could manage to "copy".

Beeping something as a recall. There are also reachSpecs Shown by Mr. Garbage as "ShortcutConnected" but not as lines in Editor called PrunedPaths. If such a path exist making a mess like above, it should be nullified as well because Engine might guide Bot through such a short route and then first hack won't be enough for discarding "impossible navigation". In a plain field even destination Node might host such a reachSpec and causing pawn to still follow that evil way. Document explained such situation and saying that paths have to be moved around - sometimes this is breaking network - this is not an answer Mr. Polge, not an answer at all. We do need to "SEE" plain stupid paths in Editor because that's why is called EDITOR - purpose is Editing not blabbering blindly through Level. At this time PrunedPaths are not shown by anything, Mr. Garbage can log them if exist. A Pro Editor should be able to select such a Path Line and DELETING IT on demand - but we need to do a manual work as long as Editor is at miles away from a Pro thing.
Note: in patch plugins for NavAdder which I did last time I had to take in account these entirely INVISIBLE paths as well and to remove them if they were causing issues.

Update:Usually in navigation chain if everything is right an Index of a ReachSpec is found in Source/Start of the path in Paths[x] list and the same Index should be found in upStreamPaths[x] list from Destination/End of the path. Here in term path (/aka ReachSpec) I'm talking about the travel data processed between Two Navigation Nodes not the route between Seeker Location and Goal Location. Entire route usually has more such paths.

Chapter notes toward advanced pathing strategy.

Certain MH community was always working at MH junks (those are not maps like that) trying harder to block monsters from roaming map and resulting a sort of ZERO bot support. Actually all jesters are living with idea that a map having paths is a hard deal, monsters are too aggressive, too active and might track hunters. Can tell you some tricks ? - Maybe you already know them...
- Paths in small tunnels (also through boxes) configured with tweaked PathNodes won't allow a fat-ass monster to pass and to hunt around - not a problem then;
- Paths with a SpecialCost defined might be "educated" to discard monster seeker and even dropping it to Waiting state instead of attacking/hunting;
- PathNodes set as bPlayerOnly it's possible to not negotiate with Monsters that much unless monster can see player directly;
- bOneWayPath turned to monsters and not from monster to player will never point routes in both directions;
- maps having a way-down geometry, like configured in a sort of stairs formula won't allow all monsters to "fly" at player.

But... the most important thing which now days can be used is - with a bit of coding skill - or low skill, using a reference pawn for pathing map having definitely a small size and printing a smaller collision in reachSpecs. XCV23 is permitting a custom Scout which can be... like a Bot.
A sample which I was using these days: I did not see XC nav-mapping code but I could figure in attached paths such restrictive paths when Reference Pawn was small, also last time I was toying with a map and I could see Brutes by example not so roamers as they can be at a moment. A small pawn won't have too many options for big monsters and if stage is completed with tiny spots, definitely monsters should not be a big problem - if goal of a map is to have no challenge.
To summarize: we don't have to ruin Bot Support for OFF-Line player because some "expert" has no clue about pawns and especially navigation properties.
Else those admins could ask support for a mutator having a few kilobytes able to ruin paths for making their "great hunters" happy about lousy creatures unable to do an a$$ in that Level.

Update: Normally I'm recommending your paths minimized as number without using double routes - the shortest is taken anyway. Plain DevPath discards processing Navigation chain at 1000 Navigation Nodes. When more intersections are found in map - more routes, engine might process them for figuring the shortest road. More data = More closer to a rejection.

Bumping forward: Pathing without NavigationPoints - read again - It's not wrong making Bot to do something without a NavigationPoint but... a trigger.
In original A.I. document that ledge problem was described and recommended some lousy solution.

Doc wrote: In some situations, bots may get stuck on the edge of a ledge where it runs into a wall. This occurs because of a threshold problem. Bots won't jump off ledges until the angle of their destination is greater than 45 degrees from the ledge direction. If they run into a wall right around this threshold, they may get confused. The solution is to adjust the NavigationPoint they were trying to reach, or add an intermediate PathNode.

Very stupid, no kidding... in certain situations it ruins route purpose, in others this is hard to avoid - even without a wall might be causing borks because ... Mr. Polge ... your dumb sh!t Bots are NOT JUMPING when they have to.
Community solution - inspired from Jumper class addressing only ScriptedPawn not Bot - it's what I've called Bot_Jumper - added around node which has routes down connected in hilarious angles. All it does is to say: Bot, jump immediately in direction of your target point. Definitely Bot won't get glued at ledge anymore and will launch his "flight" to target. Used and tested in MyLevel: It can be triggered (turned off and on - maybe is needed somewhere) and has adjustable "reflex-type" response "frequency".
I used 0.08 - 0.1 (seconds here). If JumpZ is not set will call Pawn's jumping capability if can jump. Demo is map running in M.G.S. CTF-BeerWars_Rv19. If you look at it you'll see those jumpy down-way routes bugging Bots - and they are solved using... Triggers. I could remove paths as presented but is too much data to hunt, more easy is telling to Bot: Jump, moron, just jump !

Pathing combined with triggers is used since... 1999. Bot is capable of triggering a lift correctly set so I did not reinvented the wheel, I was only polishing it.
A sample where such things might occur: Bot here wants to gain ripper and/or ammo but it's on this platform. Because of angle, it move around ledge but suddenly the ground is completely masking destination making it unreachable. Bot will return to previous PathNode attempting to retry way-down. Only a combat situation or another desire for an item will make it to quit following this way. By adding a Bot_Jumper it won't track the ledge... but will jump attempting to land in desired target-point. If this jump in other cases might be casing another Wall-hit or a Ground-Hit, can be used a blocker or something causing to fail on purpose that false jump cutting that "flight" and causing a fall to destination area.
It's about a very small keypoint or such able to bump into actors, a piece of geometry might cause missing path.
Here can be used for a deliberated failure a sort of trigger reducing Bot velocity at touching it.
Another solution depending on situation might be a combo with lower LiftExit pushed upper in order to not create impossible Way-Up route because these are Two-Way things - of course paths heading to the top can be deleted from nodes as well. In this case Combo is helpful LiftExit-PainPath-LiftExit.

Bump timer - Another solution for a bad reachSpec removal.
In 2019 we cannot only remove a nasty route which was making Bot to look like a dumb moron by editing NavigationPoint Actors, but we can use a more simple solution as well - a new feature added in MapGarbage Editor Add-on. Version released July 2019 will have as follows:
- bDisconnectN1toN2 completed with two names N1 and N2 - Point which is Start and Point which is End for the bad reachSpec.
- bCheckZones - we do not need more than 64 zones (0-63) and /or multiple ZoneInfo Actors in the same zone - that's stupid;
- bScanDefences - a scan for DefensePoint actors in order to figure how many are assigned to team 1 and to team 0 in order to have a good balance. A texture for a better visibility it's assigned for these which is reverted to default when this check is repeated - toggling textures with required color.

For said path removal we have to add names of NavigationPoint making a path from N1 to N2. Reversal path from N2 to N1 is not touched unless we want it removed too. Considering above map DM-1on1-Sph3res-v2.unr as a sample. Builder might remove that bad angled path as follows:
- bDisconnectN1toN2 set to True
- N1 means LiftExit2
- N2 means PathNode0
By pressing Build button builder will remove reachSpec listed in NavigationPoints and not pathLine which still can be seen in map but unused from now on.

Builder July 2019 Builder has a small Window and this might be a bit frustrating - this is hardcoded in Editor's natives but we can still manage boxes and editing them:
Completing names and resizing Box for visibility Then Editor will complete their real names used in map Build Button will do the action and the console will have this log: Here the option might help in making other maps where Editor simply is ignoring your OneWay path causing links which we have never asked for. Strategy is mapping a road normally and disconnecting such a sequence making Pawn to follow only one direction. In long lifts where Bots are dying crushed we can simply remove one of paths heading down-way and Pawn has to follow another safe route (must have another way) which is preventing him to die, but letting routes heading on top untouched.
I cannot say that all mappers are understanding how do these devs are working but for me such a builder is preventing headaches in hunting reachSpecs and doing the dirty task for me.

Next Subject is about Special Considerations/Features of a Navigation node and How do these work. Before explaining, I'll use some translation in order to figure words wrapping, I have to prepare something animated because words might be causing confusions, each language might have a sentence where two people are understanding two different things, and the third thing is the translator from English to another language which is understanding the FAKE third situation which might not be even closer to the real explanation. Will going to happen next days, then a low skilled coder might figure how to write some stuff in his private nodes from his unique map (if it's unique - someone will steal it claiming what nice stuff was doing - we have such "geniuses" in UT community no worries, like everywhere).

Let's clarify what it means to block / unlock navigation points for artificial intelligence.
A very high ExtraCost causes our creature not to follow that path regardless of where the dynamic node is. When the node returns to an ExtraCost zero the path is free for crossing, we usually prefer to block / unlock shorter paths because they are preferred by Engine rules. As an example we can look at BlockedPath, the stock actor used by Epic - not too smart, it's true, all it does is change its ExtraCost when activated by an instigator.
The community or the map maker can alternate this ExtraCost and causing the creatures to alternate navigation, if we want to see schematically how such a situation would look like, we have the animated image below. Let's explain what is happening. The node that has a large yellow dot in the middle is a PathNode that changes its ExtraCost value by some method - this is not the subject but the effect it produces. Xan wants to reach the red target and will use the shortest path if this node does not have a high ExtraCost value. When the value is high - blocking value - Xan will move to another alternate route because it has no valid links on the shortest path with a low ExtraCost. Wherever this navigation node is on the shortest path will produce this effect if it has no connections over it creating shortcuts and completely ignoring it.
Similarly, a path is blocked in a navigation point that includes a cost change function by calling the SpecialCost function when the default variable bSpecialCost is True - this can be automatically changed by the navigation node itself in PostBeginPlay as an example where I used it. The difference is that the access is made conditional, does not represent a permanently blocked path or it is blocked depending on the conditions that are required. JumpSpot is such a Node but it also includes another feature called SpecialHandling that we'll talk about later.

What would such a node contain that is changing ExtraCost itself or it's externally changed according to ExtraCost value ?
Let's follow the BlockedPath actor and create another MyLevel actor ... This is the original ... And we'll change it to something else just a little more advanced ... If we use a Tag that corresponds to an Event caused by some other actor that acts so repetitively, this actor will change its value and it's blocking / unlocking the path.

After a short pause with the explanations, also related to the advanced navigation chapter we have a problem that we must finally discuss because lately I see so much love for map changes but the boys do not quite understand what actually happens and what stupid things they do, for us these being useless.
Engine header sample - some resources acquired were posted on Internet by some dudes and then I've accessed those web links because my mouse didn't have any pain, it's only an object after all .
We are talking about the number of navigation specifications known as variables called ReachSpecs and which have a limit defined as a constant. When I refer to UT in the default format without XC_Engine, I'm inclined to think it's not a good idea to have a stupid ReachSpecs number, well over 3000. I'm not surprised by some of the reactions that creatures have in such maps, at some point I don't think they find the way to the target anymore.
How do we find out what the map load is? Well the MapGarbage version December_2019 has two new functions:
- Counting ReachSpecs, including shortcuts known as PrunedPaths variables in navigation points. We can thus reduce their number to be below the constant limit of the engine.
- The second problem concerns those decorations meant to be destroyed by weapon damage but which are statically set by the mapper who does not realize how many fragments will be created and how much engine work for them. Those with bStatic = True won't be removed, and they keep creating fragments continuously.
Builder turns these SELECTED decorations set as bStatic into BlockAll actors and sets them with the same look. These new actors no longer cause the production of fragments harmful to the performance and map do looks as in original idea - aiming reworked maps.
And here it is the toy:
Builder December_2019 And now... Let's see a smaller load map but because of its huge size it makes it impossible to navigate in UT stock but it works using XC_Engine. And to look at a small map, but which has no optimization, is extremely loaded and this is not very useful. The second new feature it's working like here: That's all for the moment.