UnDocumented MH Bot Pathing hints

[Nelsona]

Audience:
MH Mappers interested at not doing only shitty empty cubes but willing to help OFF-Line Players playing with Bots. I'll try to explain some facts as much as I can. If explanations are not great I will ask Heston to fix grammar here if he wants to help a little bit.
This is not an exact Goal about doing paths assuming you know to do well connected paths and what are those "A.I. paths", if not stop reading and don't waste time ...

Starting with something...

- If you want to add bot support to your map (very highly recommended), you can use the MonsterWaypoint actor (found in the classe-browser: Keypoint -> MonsterWaypoint). Just put the MonsterWaypoint actors wherever you want a bot waypoint to be, like near a button or a lever, or just along the path through the level. Set it's Position property to tell the bots in which order the waypoints must be visited. Set the first one at 1, the next at 2, then 3, and so on. You can also enter the Event tag of a particular actor so when the bot gets to the waypoint, something can be triggered to happen.
...

So as a forgotten target, MonsterEnd is another secondary objective in default MonsterHunt by Shrimp - here and there I'll explain what does XC_MonsterHunt and other MH2 types by self person VS original MonsterHunt.

Mapper should take in account simple factors for MonsterHunt according to Bot power in finding these MH goals or not finding them. We don't have here default games based on a NavigationPoint - Flag from CTF is based on FlagBase, Domination is based on ControlPoints, Assault has a guide "nearestPathnodeTag" as a target location for nasty located Forts (AS-Mazon - chains), DeathMatch has InventorySpot actors which are guiding Bot based on natives (engine and bot code). MonsterHunt has a keypoint and a trigger as goals for Bot. These are limitations but... not impossible to do some Bot support if we understand term "Reachable" in UnrealEngine1.

Reachable = moving pawn from his current location to a nearby Actor/Goal using current locomotion method and capable of camping touching that spot probably at 640 UU distance if not 512 UU for safe case but I think it might go up to 800 UU according to original docs if map is not a bad-ass big one ruining DevPath. Now imagine a higher goal if it will ever be reachable... Also speaking about Target location VS Navigation Network - Reachable doesn't happen if any nearby node cannot be seen directly and passes through a mover - doesn't matter if is a NON-Solid Mover - it won't be reachable.

A CaveAt for MonsterHunt - when a MonsterWayPoint is touched, Bot won't roam anymore in that area unless has something triggering it there - so to speak objective goes completed after a single touch. In other versions by myself, Bot cannot touch this actor if has an enemy, so it has to eliminate monster for completing the goal...
Protecting MonsterWayPoint with a mover might be a good idea or a bad one depending on situation. MonsterWayPoint needs a nearby NavigationPoint accessible using "current locomotion needed" - swimming included, which is way more easy. Bot can swim up-down as wants.

Sampling now through a few lousy images - what - how - when - etc. Bot while is seeking for such a goal will trigger engine to do some processing. Engine will compute nearest NavigationPoint to our target actor if has a Reachable way to this target. If yes, will process paths up to pawn's seeker location pointing Pawn to a nearby node which is heading to that last PathNode nearby Target point by point. Even a BlockedPath is good here when it's the LAST one before reaching at target. Let's go to "protecting target" task - mover opens AFTER killing connected monster. What is the deal if monster is still alive and door closed/open and options:

MHB_Tut00.PNG (16.89 KiB) Viewed 11534 times

For:
- Default MH - Bot won't find this MonsterWayPoint - unreachable to last PathNode - there is a Mover on the way.
- XC_MonsterHunt - Bot will go to nearest Pathnode trying to open door - using NATIVE hunting feature from Engine.
- Other MH2 type - Bot blabbering around last PathNode - still moving to this area.
________________________

MHB_Tut01.PNG (17.09 KiB) Viewed 11534 times

Strategy "Last Node Inside"
Since last PathNode is very closer Reachable to goal, definitely Bot will push door trying to do everything for reaching there - GOOD CASE.
________________________

MHB_Tut02.PNG (15.54 KiB) Viewed 11534 times

Mover is Open or it's no longer blocking access - Completely reachable in all versions.
________________________

MHB_Tut03.PNG (15.21 KiB) Viewed 11534 times

Mover Is open but we do have a higher location - Pawn will never camp there = UnReachable.
For:
- Default MonsterHunt - no target found = roaming map as in a DM if exist paths and Inventories.
- XC_MonsterHunt - if this MonsterWayPoint is not in a very high spot, Bot will still move into area having even chances to touch this;
- Other MH2 - the mostly crawling area trying to touch it - might be successful.
_______________________

MHB_Tut04.PNG (16.06 KiB) Viewed 11534 times

Definitely a bad idea but still good for XC_MonsterHunt, and some MH2 types depending on FastTrace response (XC_Engine... ??)
_______________________

MHB_Tut05.PNG (16.09 KiB) Viewed 11534 times

For next goal as MonsterEnd - final trigger ending game. Location:
- Cannot be found in Original MonsterHunt - Mover is blocking route;
- Can be found in XC_MonsterHunt and Bot will attempt to reach at End pushing mover - so to speak will roam in this area;
- Other MH2 types - depending on versions can be or not found - at a moment, Ending map by Bot was not a goal for me making player to camp and waiting Bot to do the job.
_______________________

MHB_Tut06.PNG (17.32 KiB) Viewed 11534 times

Definitely this is a BAD idea but... XC_MonsterHunt might still be useful if location is not insane higher.
_______________________

MHB_Tut07.PNG (16.57 KiB) Viewed 11534 times

Mover open or no mover - due to placement, this End will not be found in original MonsterHunt but the Bot might have access to routes in XC_MonsterHunt once again if placement is not crazy higher.
_______________________

MHB_Tut08.PNG (16.27 KiB) Viewed 11534 times

Here is a screwed cylinder for special touch but placed correctly according to Bot's height (middle of Body) and then, because there is no occlusion on the way This actor can be found because is reachable from a nearest PathNode.
_______________________

MHB_Tut09.PNG (15.82 KiB) Viewed 11534 times

This situation is a map goofing. MonsterWayPoint is reachable from nearest Node but... one of PathNodes on the way cannot be reached by running in this case (not water case) so Bot will NEVER find any route in ANY MonsterHunt version. Such nodes might be shown in blue in Editor because a pawn can fall from high Node to lower Nodes very easy but not reversal.
_______________________

MHB_Tut10.PNG (15.83 KiB) Viewed 11534 times

Mover is open or unused - Last Nearest Pathnode exist on the way but... Goal is over a hole. I did such a testing map for XC_MonsterHunt during coding stage. Definitely in original MonsterHunt such a location cannot be found but this is a cake for XC_MonsterHunt where Bot will move to this goal trying to touch Actor and jumping for reaching there.


And let's quote a few samples adds where maps could be or they have started as good ones and going to trash later.
ICRedone(Rex) - if MonsterWayPoints actors would be properly counted and routes properly connected map would be navigable Up to end zone. After touching last MonsterWayPoint - good bye attack. Even if human is helping with monsters End will go UnReachable due to a sudden "portal" Mover covering End - cya Bot, you are stupid because mapper doesn't know Bot Pathing.

If map MH-Freeky+SBfix would have good Bot routes (broken nearby train station for sure), if closer Bot is killed while the last Queen is dead (Queen LOL) - A mover like a Portal will cover End making it UnReachable because last nearest PathNode is outside of Portal and will accomplish a bad situation sampled. Tracing codes are not asking collision - if mover is there chances to end map by Bot is mainly NONE but can still work in XC_MonsterHunt.

MHBotyMan4 is a tester mutator which I did for testing purposes acting exactly as default MonsterHunt. Probably version5 will have some extra features explaining better if way found is a default good or an XC forced one. It's better to see mappers learning "HowTo" for default MonsterHunt. Human player tester is a Pawn in this game and then, several routes can be found like in Bot case when XC_Engine is unlocking JumpSpot which won't accept seekers different from UT BOT class in plain UT.

[Nelsona]

Okay, for next chapter let's see what's the deal with paths blocked more or less permanent, what does that mean ExtraCost and dealing with such things.

Plain UT has something used and inspiring some mappers to development. It's called BlockedPath which has a very simple code.

Code: Select all

class BlockedPath extends NavigationPoint;

function Trigger( actor Other, pawn EventInstigator )
{
	ExtraCost = 0;
}

defaultproperties
{
	ExtraCost=100000000
}

This NavigationPoint has a high ExtraCost - insane limit for blocking all seekers having possible routes which are passing through this point. Route here is unavailable by any matter, until something is triggering this actor turning it into a default PathNode. There is no reversal action which means locking route back. That one has to be in MyLevel - custom - which for MonsterHunt will require some little stunt.
As mapper I would use this Node for those doors not open yet in order to prevent Bots to push closed doors if they decide to gain some item from behind the locked door. This Bot habbit doesn't look so great but we have to not use such Node on the way to our next objective - a bit of logic is required here.

Stock Assets less or more incompatible with MonsterHunt:
- AssaultInfo - intended for toggling Assault routes - clearly has nothing to do with MonsterHunt spamming games with errors - be smart and forget this one, this Navigationpoint it's exclusive for Assault;
- AlternatePath - most wanted here and there has NO EFFECT in MonsterHunt being part of CTFGame - not even in a DM has nothing for toggling routes - like I said toggling a path is not done in UT but Engine do supports such stunt;
- DefensePoint - maybe AmbushPoint if you have a monster tweaked a bit...

As a note for advanced mappers... any PathNode might go blocked/unblocked using an external actor which can be moved over a node or another in case of flaws without rebuilding paths being a non navigation actor and without to affect anything - it works that way too. Probably this is the best method for toggling routes rather than messing up with borked stock assets and without to rebuild paths 1000+ times .

A sample of such triggered thing dealing with NavigationNetwork can be added as MyLevel thing. Code might be like this (used in patch files)

Code: Select all

//Using this class for any PathNode turning it into a blocked path
//or unblocking path using a trigger method
//If map doesn't have any trigger I spawn something - UT has resources for timed actions
//if bEnabled it won't allow passing through spot and another route should be available

class PathsToggler expands Keypoint;

var() bool bEnabled;

event PostBeginPlay()
{
	InitialState='TrackAndLock';
}

final function CheckAndLock()
{
	local NavigationPoint N;

	foreach RadiusActors(class 'NavigationPoint',N,CollisionRadius*2,Location)
	{
		if ( N.ExtraCost < 1000 )
			N.ExtraCost = 100000000;
	}
}

final function CheckUnLock()
{
	local NavigationPoint N;

	foreach RadiusActors(class 'NavigationPoint',N,CollisionRadius*2,Location)
	{
		if ( N.ExtraCost >= 1000 )
			N.ExtraCost = N.Class.Default.ExtraCost;
	}
}

function Trigger(Actor Other, Pawn EventInstigator)
{
	bEnabled = !bEnabled;
	if ( bEnabled )
		CheckAndLock();
	else
		CheckUnLock();
}

auto state TrackAndLock
{
Begin:
	Sleep(2.00);
CheckActivation:
	if ( bEnabled )
		CheckAndLock();
	else
	{
		CheckUnLock();
	}
End:
	GoToState('');
}

defaultproperties
{
	bStatic=False
	bCollideWhenPlacing=False
	bCollideWorld=False
	bHidden=True
	bMovable=True
	CollisionRadius=30
	CollisionHeight=30
}

Definitely if you want something like this compiled in MyLevel this will be a priority, which means compiling it BEFORE loading MonsterHunt.u file as explained as being a priority before starting MH mapping in raw tutorials, because compilation will fail at using original MonsterHunt unless you are working with modding version done by Kelly, otherwise your map will have un-compiled junks entirely useless like those MH-AsmodeusAions supposed maps or how are called.

[Nelsona]

Solid Navigation Network.

To debate some spots navigable but not very linked by Editor. Bot jumping from a ledge on next ground easy but Editor did not do paths connected - , said Goblin.

MHB_Tut11.PNG (16.76 KiB) Viewed 11490 times

Okay, because we have more brain than Editor Goblin, we have solutions - yes, we do have more than one solution at this point:
- using a combo LiftExit-PainPath(LiftCenter)-LiftExit;
- using two fake teleporters like in some 512k map by Chamberly and Higor - this one is connecting those two with any matter;
- zoning map properly and if area has no much z axis game set zone as bWaterZone before building paths and reverting zone back post pathing - be careful here because Bot won't fly...;
- using XC_PathBuilder from XC_EditorAdds happily connecting what we want when we want. For me this is solution number one.

[Nelsona]

Next chapter: Bunches Buggers

Some Spawn locations used for Players and Bots might have PlayerStart actors, maybe some weaponry and whatever Node heading forward. Let's say that we need that collection of PlayerStarts and then, Editor's devs might head to some bugs making Bot to loop like it's a crazy ass when in this spot are too many Nodes. Bug is coming from computing routes build by Editor, not seeking function is bugged but mapping function causing something called PreviousPath for multiple NavigationPoints and Engine won't pass through that messed up thing. Bug was shown in images in another mapping topic. Definitely this bug needs advanced editing for figuring it, but we can see it in game without any Rocket Science.
How to get rid of these duplicated wrong values added by Editor Goblin ?
I was thinking here because not even XC builders will not ignore PlayerStarts to be mapped and... result might be ugly screwed up. But we need PlayerStarts listed in navigation array due to relics mods and some game controller which has primary deal with these linked Nodes needed for starting player named PlayerStarts. Once figured solution I did even a builder helper in mapping doing this task, but mapper can do it manually as well. Builder is for mappers which don't want to spend 3+ weeks doing a still screwed Navigation or are too lazy, or too old, or a bit sick, or... whatever.

Strategy is based on Reachable definition, Nodes are linked/connected if are reachable each-other (it's not about visibility as main criteria). We can convince Editor about these starts as being unreachable by selecting all group (usually in a plane field is OK) and we pussh them into ground under a control thing - out of room by adjusting their Z Location. Sample: if they have Z = -512 we can add "2" resulting Z = -2512 and they are gone intro void UnReachable. We press BuildPaths or command for defining paths and after that we can remove that "2" from Z axis at section Movement Location for default properties and PlayerStarts are coming back from ground UnLinked with stupid values. Their Navigation directives are empty so I can give an advice, put them higher from the floor at 200+ UU (UnrealUnits) because nobody dies when spawn from a higher spot making them to be Out of processing for a nearby bot, and then our Bot will follow nearest Reachable node without to mind any PlayerStart - because these are Navigationpoints as well which can substitute a PathNnode and, like everything excessively used, they won't help at all when are too many in the same room.

MHB_Tut12.PNG (34.36 KiB) Viewed 11473 times

In image shown above with ViewPort set for a better Navigation view, there are three paths in Spawn room because PlayerStarts are there in Navigation list but not connected, having no reachSpecs (aka reachFlags in a way of saying because these have different meaning ) - we are about to discuss these later.
Said builder helper is addressing also other Navigation things: SpawnPoints placed higher or not and used by CreatureFactories, QueenDest Nodes way too big and not well suited for Bot's Navigation due to height needed for Queen. These are automated by builder using a single value chosen by user - building paths and then restoring them based on the same value. Trick is simple and helping enough. I will share builder with integrated stuff when it will be done because has more features than this one, I'll explain it in the right place.

[Nelsona]

Color (Colour) of my Dreams - said a singer in a song - and some people are looking at this in Editor.

Meh, If you are curious, you can see more maps with game-play having paths on Z axis like but, we don't see Bots coming from down spot to upper spot even if that path is a blue line not an ugly red line which tutorials are describing as a bad one - HALF true, quarter not True, quarter WANTED like that.
What is about ?
A PathNode is placed on a ledge connected in blue with a lower one. This route as blue as it looks like it's connected in ONE direction up-to-down by Editor using strategy for ground units, if that zone is NOT a WATER zone.
How goes this thing. Such a line is recorded in map with invisible data - mapper cannot see this but using "tools" is somehow "visible" in numbers formats or whatever if you have other tools. Imagine line between those PathNodes as being a reachSpec. ReachSpec is data processed for each of these lines by Engine for a Pawn seeker. Engine as primitive as it is don't have more failures here as raw and old as it is - okay has some... bubbles, but not that nasty.
What is processed except deducting links from Node to Node until target is reachable from last node. ReachSpecs will include some stuff:
- Distance from These two Nodes - required to process Movement if I'm not mistaking;
- Collision parameters - a big one won't follow a small spot because... he won't fit into path - you have to figure if XC_Engine has screwed this...;
- Who is Start and Who is End for this path - bidirectional paths have End and Start both of these Nodes in some two paths in paths index - each path is registered like that;
- ReachFlags - major factor here - here engine will process pawn's physics and extra-capabilities for taking that path. Pawn Should be capable of swimming if path is passing through water. If we have a small stair pawn should be capable of jumping - the same for a higher located Node closer to a ledge... A pawn swimming and capable of flying is superior here because actually that one can reach where it wants using any locomotion wants from these two featured. If pawn cannot walk and collision is permitting, pawn can follow ground routes by Flying on low level. Default PathNode is over ground at 50 UU, so if a pawn is smaller in height, definitely can track that way while is flying.

After testing and doing some stunts, majority of those borked maps have bugs here, at reachFlags, nodes won't allow jumping and then... route is uni-directional if a node is too high from the rest but that one should be next target. Pawn won't even blink to that route. Some stairs by adjusting Nodes a bit for them will develop a reachFlag translated as having a number value 9, which means requirement for jump and for walk, all plain paths on a straight field have value 1 here - default path reachFlag.
And what is about those teleporters and Combos LiftExit-LiftCenter-LiftExit ? Those have reachFlag 32 which means special navigation, I think here brainless pawns won't really navigate here too much, but smart monsters (BRAINS_Human at Intelligence) and Bot will take these as cakes...
When Map lacks in building jump flag, probably we can force a 32-special reachFlag which definitely can make pawn to run in a wall if is being wrong set because that route is considered a very good one.

And RED ?
Red path is created by Editor when a pawn tester ( called Scout ) used by DevPath having 52×50 collision cylinder is not taking a path without to hit a wall but it was taking that route after shrinking size - in this way Engine is adding Collision parameters to reachSpecs. When pawn has to go smaller, path is no longer blue, but definitely smaller pawns like a Bot will not deny that route as red as it is as the rest of more thin pawns. Here you might have some monster limitation in roaming all over the place and sitting inside his yard. So you don't have to be afraid of RED, but you can track if a wall is not too close to the path - will affect Collision from ReachSpec. Paths are added if probing pawn is not colliding walls while is moving from a Node to another directly.

[Nelsona]

Next subject: Movers (various bridges or such)

MH can be rich in options and people are intended to say that "Bot is stupid" - which is very true. Bot's stupidity it's in many cases an advantage for mapper because mapper can fool them - sometimes like when a man has to fool a woman in order to make things to work properly. If not, MH mapper has no skill - actually for me it's not MH mapper, that's reality, unfortunately. Some of these dudes are doing experiments for years learning nothing, others are learning quickly and they go more skilled with each map done - enough here.
The tech in various bridge types is to HAVE PATHS over these - yeah, blue lines not mental stories.
How goes this stuff ? Editor has building options that can work in multiple stages NOT ALL Builds in the same button pressed.
Stages: Geometry, BSP optimisation, lightning, Paths - yes,these paths might be build in final stage rather than doing 1000+ builds at once with geometry, and recording those history type reachSpecs.
Good let's see if Editor can map paths over a mover opened later (bridge) which is supporting navigation after whatever previous objective accomplished.

Let's see a simple case (I don't have here right now a bridge but...), let's see what is about. You must show polygons for this mover before to add and build paths.

MHB_Tut13.PNG (240.55 KiB) Viewed 11450 times

After showing polygons you might add actors over mover like for other brush - warning because job is not done and this won't be funny if it's not finished.
Build paths and check if Editor added path lines. Here will be used only commands for PATHS and leave alone geometry for the moment until paths are created and connected as should.
And now you want to build map (geometry related stuff and NOT paths) unless you will lose those connections, uncheck paths build box before rebuilding.

MHB_Tut14.PNG (14.6 KiB) Viewed 11450 times

Whenever you add an actor (light, sound, and such) or you are moving a light from map previously added, you have to do some map re-build but... you don't have to re-build paths because navigation has nothing to do with light or a new decoration from a wall, it's only producing useless junks in map increasing size with no purpose.
After doing trick with mover's polygons, map will need a geometry rebuild unless some render will get stuck making map unplayable so take in account stages described.
To summarize stages shortly:
Stage 1: Initial Geometry build;
Stage 2: Preparing Movers for receiving paths;
Stage3: Build Paths and AFTER THAT...
Stage4: Building Geometry ONLY without paths.
This is not a hard task, it's a logic task.
I found a sample done for my private self party:

MHB_Tut15.PNG (891.08 KiB) Viewed 11437 times

Here I could figure some changes between default DevPath and the other solution coming with XC_Engine. Why these "FLOOR" checks have been removed ? Because it was suggested in that stupid mindless comment by one of EPIC's league genius? By following advice A.I. becomes retarded trying to navigate when mover is NO LONGER a Floor. Solution to mitigate this "FIX" it's a custom node tracking "Floor" as it should be in original natives and it has been removed...

[Nelsona]

Dark Side of Navigation
Here it's about some bad goofing which are heading to a CRASH or to retarded Bots - standalone game or server. Some of these maybe are fixed in XC_Engine but I would not count on too much magic.

Problem and advice Number 1.
DO NOT DELETE ANY NavigationPoint without to rebuild paths AFTER this stunt. NEVER, but NEVER forget to rebuild paths after such a change. You can ignore what some stupid kids are saying - those never doing a MH map with full Bot Support - and listen to those with a minimum of experience which were doing not a single MH map with full Bot Support operational. Such a missing point is End and Start for some route set in a reachSpec, when this thing is removed but called during Navigation processing (even twice) will deliver exactly a C++ null deal which won't be like in UScript equal with an Accessed None - this native processing will head to an instant crash. Pawns in maps are looking for paths in order to gain a route to player enemy, DO NOT MESS here like some idiots were doing multiple times. Adding a point is not a critical situation, it's just... maybe useless, but removing a registered thing from a map it's like you are removing with brute force a package causing a HOLE. Even array NavigationPointList will have gaps when such an element is suddenly missing with no rebuild.

Number 2
Forget a LiftExit and a LiftCenter not only not having the other "exit" and/or having LiftTag = None and causing other connections with other Nones through walls or using that same LiftTag for every single such point from map. This "high tech" I found at some "wizard" mapper from Brazil - DO NOT follow this way of doing and forget what the genius said.

Number 3
Translocator chapter - MonsterHunt controllers so far (any) have no deal here and original MonsterHunt was proposed as a challenging game not a crap for zero skilled players. When you want to convert a map to MonsterHunt requiring such stunts, discard such ideas right from the root.

Number 4
False imagination - Kicker and Jumper have NOTHING with A.I.
Jumper does a jump for a MONSTER ONLY, if Monster has a purpose to go there - using A PATH. These two (Kicker and Jumper) are not NavigationPoints, so no navigation directives are here unless other special codes are taking control over A.I. in a way or another from outside - "pushers" with other words.

Number 5
Fake gaming stuff - I did paths in game using whatever PathLogic. There is no logic path at all in there - that simple - I swear. Coders can confirm what I'm saying. All pathing reachSpecs creating requires C++ natives to run and not plain UScript mutators.

Number 6
Useless Load - Not only some spots should not be under 50 uu each-other (I recommend more) but even those ramps requesting paths at 300-400 UU might be a FALSE information provided in Bot Pathing tutorials - "Fake News" like Mr. President said. I cannot promise more inspiration but I would do some map with loooooong ramps where paths which are connected at 700 UU are working PERFECTLY.
What is about those 300-400 UU recommendations ? IDK - plonks and guessing maybe because usually a PathNode in a heavy ramp can be Reachable and not that reachable causing loops, sampling CTF-Command here by EPIC (not by me) with ramp in Blue Base being an utter crap which they never bothered to fix (like CTF-Coret fixed natively in UT patch v436).

Number X+. Various moves done to these nodes breaking locomotion logic which engine is processing. Heading to RAMPS problems in next post.

[Nelsona]

My Ramps - I want them perfect

First of All let's see some conditions toward reaching at a NavigationPoint. PathNode was initially part of SP maps where Monster can track an AlarmPoint (if you have ever hear about such things) and then finding that route or... Patrolling. In UT coming later, nothing is changed here but... we do have some Bots which are way smaller than a monster PathNode remaining the same... this is plonk #1 which mapper should take in account.

MHB_Tut16.PNG (32.56 KiB) Viewed 11401 times

Hello, is this pawn capable of Navigating to Node location ? Somehow yes, for me it's a half-miracle. Parts of pawn's body can touch location of this Node Not entire cylinder but somehow can sit in that spot like it's defending (the whatever base).
More true from Editor:

MHB_Tut17.PNG (25.12 KiB) Viewed 11401 times

This is a Pawn having Bot's collision and nearby we do have a PathNode set for showing collision. Plain area should work normal.
And NOW I'll setup a Negative Instance exactly from borked spot a la CTF-Command where FlagCarrier looks dumb.

MHB_Tut18.PNG (44.8 KiB) Viewed 11399 times

If you cannot predict the movement in ramp, let's figure why this node placed on ground (it's original) cannot be exactly "taken" (some internal bool value from a node) because 0 (zero) parts of Pawn's body are able to stay on Node's range touching location, Pawn IT'S too damn low compared with Node.

MHB_Tut19.PNG (39.67 KiB) Viewed 11399 times

When carrier passed, a battle situation making it to retreat or a tactical move did the magic, else this node is just a junk, a really bad spot. Here collision and placement of Default PathNode is creating myths and people are talking bu||sh!ts in tutorials. Pawn is a bit under PathNode when is supposed to reach at PathNode and it will retry from previous one, unless something has "helped" him to pass forward and then it will keep moving - it's pure luck.
And What am I supposed to do in such case ?
First move before adding a "Ramp Node" is adjusting its properties according to our "path user" aka Bot Aka an entity having at least 40×18 UU cylinder. Then add node. If node goes retarded (refuses to be placed) see other default property called bCollideWhenPlacing and if that thing is True, set it False. If spot has this location and there is no BSP bug in that spot, it should be placed without to perform any other stunt with Mouse. Node definitely will go in a lower position/location, pawn "climbing" ramp might really reach there properly because they have a closer location in space when are colliding together. I did an experiment in this map and I would not speak without evidences. Definitely PathNode112 from CTF-Command is located too HIGH. AVOID such things in your maps. As for CTF-Command, PathNode26 and some InventorySpot created by UT_Eightball or other thing around, and are suitable for causing a navigable link while Mid Node 112 it's an intruder which is doing only damage rather than helping.
By removing all paths, PathNode112 and rebuilding A.I. Paths using default button I got this report:

Code: Select all

oooooooooooooooo: oooooooooooooooo
Specs: PathNode26 - UpstreamPaths[0]=1673 Start=InventorySpot98 End=PathNode26 RFlags=1 Dist=791
Connected: InventorySpot98 to PathNode26.
oooooooooooooooo: oooooooooooooooo
Specs: PathNode26 - Paths[0]=276 Start=PathNode26 End=InventorySpot98 RFlags=1 Dist=791
Connected: PathNode26 to InventorySpot98.

InventorySpot98 is Node created by UT_Eightball which has a direct navigation to "PathNode26" at distance 791 UU, YEAH people, navigable in ramp at 791 UU... as described by those two fresh reachSpecs number 1673 and 276.
Fix me if I'm wrong...

MHB_Tut20.PNG (939.5 KiB) Viewed 11391 times

LOL Cannon...

[Nelsona]

Special Environments: Pathing These ? Do they work ?
Well, such a special zone can be unfriendly due to that PainTimer which zone has and then pawn might be interpreted by engine as having an obstruction in movement returning it to previous spot. Assuming that completing an objective will turn zone into a normal one, we might want to allow Bot to navigate to next goal after doing a part of mission. There is such a tweak in SK_Tarmation2. After destroying that core zone won''t be a damaging one - Bot support does the task.
Okay, and how to make paths in a damaging zone having 10 damage points per second ?
Depending on zone size and damage and/or items protecting pawn roamer, can be used a combo LiftExit-PainPath-LiftExit. In PainPath we can define damage used and pawn will pass only if has immunity at that damage - if used - allowing nearby items for getting immunity. In other case we have to execute other task before passing through there and then PainTimer won't allow too much pathing or when gravity is modified.

What we do ?
Paths are done in normal situations so the zone will be normal for a while. Add and build paths and then executing a zone modification or even build if it's needed without touching paths - remember water case for building some routes. That's a solution. Definitely Editor won't add paths in a LavaZone - there I have doubts to see pawns passing, as long as the pain makes pawn to return - here we can add in stage some kickers for "motivating" pawn to feign burning but advancing in Level rather than retreating back.
Gravity pushing pawns upper is probably never good and any such setup deviating movement during navigation as overall reaction from zone, definitely even Scout will have issues at probing spots, if this tester pawn is pushed at wall there won't be any path and I have doubts to not see Bot stuck like a balloon at roof.

For next hints I'll setup some ambience and I will report other various tricks for creating jump type paths over small stair and not plain fields.

[Nelsona]

Stair steps or such obstructions.

Usually when such a thing is not passing over 48 UU Editor might add Jumping flag creating a navigable route. If stair is 32 UU and you put nodes properly path should work flawless else only zone hacks are helping but... in a classic match with low Skilled Bots they are going to crawl looping and trying to pass with no success. In a hard-core setup and using a zone hack at doing paths (Water trick) they can pass even over 64 UU - but I don't really recommend this way of doing for stepping on stairs.

MHB_Tut21.PNG (547.2 KiB) Viewed 11380 times

In image we do have 64 UU step requiring a jump doable in hard-core mode. As result, because this is not compatible with classic's mode step height passing over 48 UU, Bot has no route to minigun, but... we might have routes using reachFlag 4 - swimming, by hacking zone - doing paths and reverting zone after pathing. As result, in a hard-core game setup Bot will deal with navigation and might pass for getting minigun - two bots in such environment are slaughtering each-other constantly.

Next subject MH and not only MH - Inventory Myth.