Map's Navigation Network - extra-options

Development assistance and tutorials here.
Post Reply
Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Map's Navigation Network - extra-options

Post by Nelsona » Sun Feb 24, 2019 5:18 pm

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:
MapGarbage_02_19.zip
MapGarbage version February 2019
(197.27 KiB) Downloaded 6 times
For fans of adventures, setup is described in document and it works like MapPurger by Gizzy. This builder in exchange has completions.
BPA_00.PNG
BPA_00.PNG (71.38 KiB) Viewed 180 times
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.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sun Feb 24, 2019 6:14 pm

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.
BPA_01.PNG
BPA_01.PNG (665.51 KiB) Viewed 178 times
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:
BPA_02.PNG
BPA_02.PNG (22.8 KiB) Viewed 178 times
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.
BPA_03.PNG
BPA_03.PNG (1019.92 KiB) Viewed 178 times
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 Image.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Mon Feb 25, 2019 10:59 pm

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.
BPA_04.PNG
BPA_04.PNG (1016.81 KiB) Viewed 169 times
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.
BPA_05.PNG
BPA_05.PNG (797.87 KiB) Viewed 169 times
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 Image.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Tue Mar 05, 2019 4:37 pm

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.
BPA_06.PNG
BPA_06.PNG (804.08 KiB) Viewed 123 times
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:

Code: Select all

editactor name="LiftExit2"
Something shows up and even we can do the same thing for PathNode0 - if we want to...
BPA_07.PNG
BPA_07.PNG (605.12 KiB) Viewed 123 times
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".
BPA_08.PNG
BPA_08.PNG (634.46 KiB) Viewed 123 times
Final result of this hackish solution will be like here:
BPA_09.PNG
BPA_09.PNG (644.47 KiB) Viewed 123 times
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.

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.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Thu Mar 07, 2019 5:53 pm

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:

Code: Select all

class SlowScout expands Scout;

defaultproperties
{
	bCanSwim=True
	bCanjump=True
	bCanWalk=True
	bCollideWorld=True
	bCollideWhenPlacing=True
	GroundSpeed=180
	JumpZ=150
	WaterSpeed=110
	bCanDoSpecial=True
	bAvoidLedges=True
	bStopAtLedges=True
	CollisionRadius=20
	CollisionHeight=40
	Physics=PHYS_Falling
	AirSpeed=120
	AccelRate=100
}
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.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Nelsona
Posts: 442
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Wed Mar 13, 2019 11:01 pm

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:

Code: Select all

class Bot_Jumper expands Triggers;

var() bool bOnceOnly, bEnabled;
var Pawn Pending;
var() float Frequency;
var Vector Direction;
var float Distance;
var() int JumpZ;

function Timer()
{
	if ( Pending != None && Pending.Health > 0 && Pending.MoveTarget != None && !Pending.bHidden && Pending.bCanJump )
	{
		Pending.SetPhysics(PHYS_Falling);
		Distance = VSize(Pending.MoveTarget.Location-Pending.Location);
		Direction = (Pending.MoveTarget.Location-Pending.Location)/Distance;
		Pending.Velocity = Pending.GroundSpeed * Direction;
		if ( JumpZ != 0 )
			Pending.Velocity.Z = JumpZ;
		else
			Pending.Velocity.Z = FMax(200, Pending.JumpZ);
		Pending.Acceleration = Direction * Pending.AccelRate;
		Pending.bJumpOffPawn = True;
		if ( Bot(Pending) != None )
			Bot(Pending).SetFall();
	}
}

function Touch( actor Other )
{
	if ( !Other.IsA('PlayerPawn') && Other.bIsPawn )
	{
		Pending = Pawn(Other);
		SetTimer(Frequency, false);
		if ( bOnceOnly )
		{
			Disable('Touch');
			Disable('Trigger');
		}
	}
}

function Trigger( actor Other, pawn EventInstigator )
{
	if ( bEnabled )
	{
		bEnabled = False;
		Disable('Touch');
	}
	else
	{
		bEnabled = True;
		Enable('Touch');
	}
}
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:
Ledge_Failure_Sample.PNG
Ledge_Failure_Sample.PNG (525.94 KiB) Viewed 60 times
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.
Alternate_Ledge_Solution.PNG
Alternate_Ledge_Solution.PNG (534.95 KiB) Viewed 59 times
In this case Combo is helpful LiftExit-PainPath-LiftExit.
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -

Post Reply