Map's Navigation Network - extra-options

Development assistance and tutorials here.
Post Reply
Nelsona
Posts: 578
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 18 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 681 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: 578
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 679 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 679 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 679 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: 578
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 670 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 670 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: 578
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 624 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 624 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 624 times
Final result of this hackish solution will be like here:
BPA_09.PNG
BPA_09.PNG (644.47 KiB) Viewed 624 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: 578
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: 578
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 561 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 560 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 -

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

Re: Map's Navigation Network - extra-options

Post by Nelsona » Sat Jul 20, 2019 7:46 am

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
MapGarbage_07_19.zip
Updating by replacing any prior version with this one.
(206.51 KiB) Downloaded 12 times
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
Removal.PNG
Removal.PNG (9.03 KiB) Viewed 317 times
Then Editor will complete their real names used in map
Removal_00.PNG
Removal_00.PNG (9.75 KiB) Viewed 317 times
Removal_01.PNG
Removal_01.PNG (9.19 KiB) Viewed 317 times
Build Button will do the action and the console will have this log:

Code: Select all

Disconnector: Found Connection from LiftExit2 to PathNode0 with reachFlags = 9, removing ReachSpec reference...
Disconnector: Compacting paths list in LiftExit2 if possible...
Disconnector: Searching UpstreamPaths reachSpec reference into PathNode0...
Disconnector: There is no Upstream from LiftExit2 to PathNode0 described in PathNode0.
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.
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: 578
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Fri Oct 25, 2019 5:28 am

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).
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: 578
Joined: Sat Sep 30, 2017 5:03 am

Re: Map's Navigation Network - extra-options

Post by Nelsona » Wed Oct 30, 2019 8:02 pm

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.
ExtraCost_Toggling.gif
ExtraCost_Toggling.gif (23.18 KiB) Viewed 72 times
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 ...

Code: Select all

class BlockedPath extends NavigationPoint;

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

defaultproperties
{
     ExtraCost=100000000
}
And we'll change it to something else just a little more advanced ...

Code: Select all

class PathToggler extends BlockedPath;

function Trigger( actor Other, pawn EventInstigator )
{
	if ( ExtraCost > 0 )
		ExtraCost = 0;
	else
		ExtraCost=100000000;
}

defaultproperties
{
     ExtraCost=100000000
}
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.
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