UnDocumented MH Bot Pathing hints

[Nelsona]

Lol age
I forgot something, but... there is another factor which I could figure toward editing generally. Actors at a moment might ignore math (or NOT) when are placed in Editor and we want an exact location. You can take in account 2 UU (UnrealUnits) error.
Let's see what is about.
MonsterHunt will need a MonsterWaypoint which has a cylinder 30 × 30 UU. Let's put this actor on some 0 UU ground for Z axis and then let's see if location on Z axis will be indeed 30. Cough ?

MHB_Tut31.PNG (63.01 KiB) Viewed 12164 times

Editor at placing this actor actually preserved 2 UU pushing it UPPER having 32 UU height from ground zero even if actor has a 30 UU collision-height.
Why these mentions ?
I went to check exactly when a WayPoint in original MonsterHunt in a plain situation goes UnReachable and pawns cannot see it from a random map spot far away from it. It looks like we can still have it when is placed at 79 UU and later... at 80 UU it won't be found. Considering that a single UU might do damage for whatever situation, when Editor is adding 2 UU error at preserved/predicted location, things are not going to work as supposed.
I'm not interested to find how much is processing engine whatever InventorySpot availability when these are located into whatever 40.999746 z location making some math toward movement with additional fragments for these crapped numbers.

[Nelsona]

Let's move with a small dodge. Speaking about converted CTF maps to MonsterHunt (majority can be deleted forever).
The most of things toward Bot Pathing according to CTF teleported to MonsterHunt are useless:
- AlternatePath - will have a meaning of a PathNode and nothing like an AlternateRoute;
- TranslocDest - paths passing through are discarded;
- JumpSpot is... tricky depending on situation;
- FlagBase = Spam Errors fest.
In mean time we can discuss here some common CTF problems and BotPathing.
Main Problem - Collision cylinder of FlagBase
This is initial amnesia from Epic forgetting how small is Bot - if this thing is adjusted on a higher position with only 20 UU, FlagBase won't have too many Reachable directives. Previous mapping contests at UT99.org were showing some tutorials in how to never mess these... objectives after all, regarding to brain-fart about design. Nothing is more evil than when cube-drawer called "mapper" now days has decided to pull Flag higher because this is the best position instead of doing a small tech taking a few seconds and leaving path alone.
Let's see a random sample with Flag Location problem.

MHB_Tut32.PNG (1.1 MiB) Viewed 12148 times

The flag here looks pushed higher ? Is this Reachable ?
YES, because FlagBase is low as you might see collision cylinder. And why does it look higher ?
Because actor might have an Advanced Editing for showing hidden properties - lousy things might occur if mapper is failing here:

MHB_Tut33.PNG (868.58 KiB) Viewed 12148 times

PrePivot property opened in advanced editing can be scaled on Z a bit higher making Flag to look less buried in the ground but definitely location is the same as in original. This Flag looks higher but... it's reachable.
Why I have mentioning this editing ( that's why it's called EDITOR after all ) ?
Because even in MonsterHunt mapping, you might see some funky decorations crapped up in original and you might want to see them colliding properly. You might set viewport for showing Actor RadiiView and carefully adjusting these PrePivot values according to whatever tree trunk Vs leafs and such - if that stuff is more complex than for a cylinder, then time has come for BlockAll things toward these needed collisions. XC_EditorAdds has a short route for advanced actor editing in single click without writing commands in console. For these decorations you might take in account DrawScale and adjusting cylinder properly. What's the deal with BlockAll ? Certain chunks might still pass through claiming actors fell out or world, definitely for me this is not how to cover the lack of geometry build. These are good for decorations with various configurations not very suitable as simple cylinders.

[Nelsona]

Moving boat with a summary so far. For making solid/good paths in UT generally not only MonsterHunt:
- paths have to be navigable;
- paths might have one-way;
- objectives reachable on ground;
- preventing dual routes impossible to follow;
- doing forced connections only if environment is permitting;
- adjusting their location using brain not guessing.

Of course, there are more options to make a mess generally. Next stage is adding PathNodes but not having paths. This is only a load without any purpose of use.
Imagination: Sitting in spot, looking at sky and suddenly you can see a... PathNode. Well... what is that for ? A non-sense loading iterators speeding up bit by bit reaching to boundaries in some moments... A good map is not a map with content added just for having actors loaded.
When player generally and bots cannot reach at PathNode masking it with/inside their body that one is not that useful especially when is not connected nowhere.
I can sample here a lot of NEGATIVE things done over years, but it won't be nice to do that, people will take this as a defaming quest on purpose.
Probably it's way better any description and showing "How to" rather than "look what mess did this guy" - you'll see what I mean by looking at Levels in Editor. But maybe a few of those pretended "original" mappers will need a bit of tinkering in nose for their "samples". We want to learn these simple things at least now at two decades later than never.

[Nelsona]

Heading to a route which looks... Rocket Science ?
MonsterHunt, CTF, DM, ETC. have a common ground speaking about A.I. Navigation - it's about DAMN LIFTS.
Last time even if it was about a few mapping contest types, where people have to show their best, plonks weren't an exception, I mean messing up LIFTS or simple not doing paths over there. MonsterHunt it's way loaded with such junks based on guessing.
For learning this problem I'll use some strings and NOT images. Why not images ? Because this means SPAM.
In stock maps like DM-Deck16][ or CTF-Gauntlet or others, there are GOOD samples of a LIFT pathing and what setup is required - they can be checked many hours without damaging anything - DO NOT SAVE any stock map. Guaranteed I did not see any Computer exploding when user opened such a map for looking at it and at "How To" - this is one of good learning methods rather than reading 100 pages or watching fake tutorials on YouTube added from some lost region of this planet.
What things are under track ?
- Tag used by Lift Mover and InitialState;
- LiftTag mentioned by those THREE navigationpoints involved in route - they can be even more when have to - LiftTag can be found by opening their properties and not only adding them in map without purpose - this word will be the same as the TAG used by Mover-Lift;
- alignment for each key-frame of Lift - A.I. should have exit reachable unless they are coming back.
What else is good to know toward a lift it's how to inform A.I. about a higher platform that needs a step-height. Here we can discuss details using simple images.

MHB_Tut34.PNG (21.13 KiB) Viewed 12122 times

In image you will see what is MaxZDiffAdd value and when it's used. When Lift Entry is lower, or simply LiftCenter for Combos it's on a box higher than entrance point, we might want to declare how high is this height or else Bot might be waiting a lift which will never come in desired position. I'm not convinced that less intelligent pawns might use such paths but here Bot it's in charge.

[Nelsona]

As a recall about an Event occurred in a MH map. Horizontal Elevators.
Types like MH-Cliffs2 having horizontal elevators/lifts might convince Bot about a fake navigation motivating them to jump out of Lift too early and falling into a death hole or another bad thing causing a loop in that zone.
Solutions for this default stock problem are as follows:
- using an educated Bot - that's up on user;
- using a trigger/actor controlling Bots on a mover base - UScript knowledge required;
- using a "Reachable Prevention" method - a box-brush making LiftExit used as exit point to be Visible/Reachable when lift/elevator is closer enough for a jump - smarty mapping here and no scripts is/are needed.

I used this last solution with success. Exit is not visible but it becomes visible when Mover is closer to ledge and a jump is doable with no failure.

Another situation is whatever Train types. Not all of them were working fine for a simple reason. If train it's like a pig trough with a lower LiftCenter, this one won't have as a reachable point the exit navigation actor. Bot keeps waiting train to get into position but it won't happen, returning and looping there forever. Advice is to forget such a design for train, I did not see too many such troughs in Real Life - it's a Brain-Fart and such thing was even poorly designed not only messed up at Bot chapter.
For any mover it is advisable to have exit accessible closer and similar height location with LiftCenter when Lift is on exiting keyframe not higher and not too far. Default reachSpec here claims 500 UU distance. If Exit is too far, Bot might stay in lift expecting to get closer to exit.

In MH maps where Bot should not try to return ever in a previous area, bOneWayPath used will lock routes back to spawn room and keeping them into an advancing stage, especially when such an elevator is causing troubles at the way back - are needed two such box-blockers.

[Nelsona]

Also related to MonsterHunt and the ins and outs that produce unnecessary data hosted on the map, in addition to MapGarbage facilities that can prevent overloading with navigation specifications, we can look at how many specifications we have and how the engine is forced to calculate routes. Our target is somewhere below 3000 reachspecs. For more of these we are not responsible for whether or not artificial intelligence is working properly.
We have not come to any conclusions toward using the featured functions from XC_Engine, but by using plain UScript we can somehow count how many specifications are on the map in approximate numbers. We talk about that because we have the shortcuts that are also specifications and we have old specifications used previously that the Editor does not remove, just adds other new without too much logic. Of course, we can eliminate the garbage if we know how to clean the map in several sessions, but not every map maker comes to terms with quality. A simple script that shows a minimum of specifications (without shortcuts) is like this - it's really very simple, no joke.

Code: Select all

function CountReachSpecs()
{
	local int I;
//	local Actor Start, End;
	local NavigationPoint N;

	foreach MyMap.AllActors(class 'NavigationPoint', N)
	{
		if ( N.Paths[0] > -1 )
			I++;
		if ( N.Paths[1] > -1 )
			I++;
		if ( N.Paths[2] > -1 )
			I++;
		if ( N.Paths[3] > -1 )
			I++;
		if ( N.Paths[4] > -1 )
			I++;
		if ( N.Paths[5] > -1 )
			I++;
		if ( N.Paths[6] > -1 )
			I++;
		if ( N.Paths[7] > -1 )
			I++;
		if ( N.Paths[8] > -1 )
			I++;
		if ( N.Paths[9] > -1 )
			I++;
		if ( N.Paths[10] > -1 )
			I++;
		if ( N.Paths[11] > -1 )
			I++;
		if ( N.Paths[12] > -1 )
			I++;
		if ( N.Paths[13] > -1 )
			I++;
		if ( N.Paths[14] > -1 )
			I++;
		if ( N.Paths[15] > -1 )
			I++;
	}
	log ("This map has"@I@"ReachSpecs shown in Navigation Network.",'NumReachSpecs');
}

I will also put the shortcuts separately for a little more detail in the log file.

[Nelsona]

I see that not once do people get angry when they are reminded that there is no need to have more of the same maps without solving what they have broken inside. An interesting chapter about what can be done to simplify a map that has many navigation points without the purpose of navigation is to prevent the creation of navigation specifications, the Editor does not understand what we do not need. If we are not fans and do not understand the advantage of XC_EditorAdds, we can prevent the creation of useless paths through SpawnPoint actors or even Inventory actors using simple tricks and MapGarbage helps us. If people do not understand how things are simplified because they are not used to thinking, we can little mind them to understand why we do not like the production of UNR garbage files.
The first move is to have a copy of the map without the navigation network created. We delete Inventory actors and build the navigation - using MapGarbage we can "sink" in void the SpawnPoint PlayerStart actors, meaning those we can get rid of when we aim for clear navigation without end-routes. AFTER creating paths and saving map, we can load previously saved map with Inventories and we can copy-paste them back in map with items deleted. Now we don't need to rebuild navigation network, we are leaving it simple but having items without pathing borks.
How to get rid of paths through SpawnPoint actors and PlayerStarts as for QueenDest actors not intended for being in use by Bots ? MapGarbage does a long-time task for you in a second or less, also here you might have some "extra-items" removed for a more simple navigation as described above.
Before building final navigation network, in cleaned map we are moving these away into void - here won't have reachspecs but are still part of LinkedList. We are building paths and then we put them back - all it needs it's toggling two boolean variables and setting up how "deep" these have to be moved.

Hck_Paths_0.PNG (11.42 KiB) Viewed 11659 times

Variable bHidePlStarts will move these unwanted for linking Actors lower with a distance defined by User - 2048 written by me here when is set to True and build button is pressed. After Pathing process we are putting this back to False and the other bRestPlStarts will be True followed by pressing Build Button.
PlayerStarts and all stuff is back in old place and have no reachspecs data and no connections, these being with no use in this case.
Results are like here:

Hck_Paths_1.PNG (1.35 MiB) Viewed 11659 times

Clean Starts.
_____________

Hck_Paths_2.PNG (624.48 KiB) Viewed 11659 times

Clean SpawnPoints completely operational. These NavigationPoint actors are actually part of NavigationPointList but they do not include navigation directives, so to speak less data and less reachSpecs.
This strategy it's useful when map has a lot of SpawnPoints - yes, a recent map MH-Invasion or how was renamed without actually to have major improvements just getting over boundaries when things can be definitely done better - including Queen problems, using MyLevel but that's a different story and not a "cube-drawer" task. Guaranteed game won't crash at DevPath because we are not deleting anything we are just convincing Editor to register only a minimal charge and other adds are not affecting navigation network only if one of points registered is deleted.

What should we remember? Even if we have blind navigation points without specifications, they are part of the navigation list that must be kept intact - otherwise we have holes that interrupt the navigation process. We can add points to the map but we don't have to delete what's already here for final MAP-SAVE stage.

Probably I have to adjust a bit one of these old maps and making some real corrections, explained with a document included on a "How-To" demo purpose.

[Nelsona]

Bump: Still Hints
I think I owe more explanations about reducing number of paths, a lot of bytes can be excepted from being added in our great MH map. Great means that map can be a medium sized one, we are adding whatever ammo, armors and such. In a spawn room these can be damaging for plain DevPath in Editor mapping a looping bug in such spot. Heck, we want our items in spawn room because game instance makes use of them. Bots fighting around items are tempted to get them according to combat, internal combat directives, which means that we don't really need InventorySpots created and all those bugging paths. How do we convince Editor to not map so many paths in the room ? It's not hard, I think it's even too simple.
We can select ALL ammo by example using a console command or MapGarbage -> option bFindAnActor and defining subsequent Class -> Ammo.
Alternate Solution is command SET AMMO BSELECTED TRUE

After this Super Duper selection of AMMO classes - ALL AMMO, we can use from Editor's Menu Command CUT. Exactly, we are moving these in clipboard. WE can PASTE Clipboard content in a new file in Whatever Notepad Text editing Application. We are even saving file as a t3d file.

Okay, ammo are stored/saved elsewhere. We are building other fresh paths right now using left-over things: Armors, PathNodes, etc.
And then ? Then we are importing using FILE - Import... Menu-Command our saved t3d File containing ammo and checking Box Import in current map.
All Ammo should be back in map, you won't rebuild anything, just doing a map-save task and leaving paths simple out of extra charge.
Let's look at something simple, but still over-charged.

SmallCharge.png (778.84 KiB) Viewed 10414 times

Which can be more simple than that in this format:

SmallerThanSmallCharge.png (753.09 KiB) Viewed 10414 times

I used here plain original UT paths view not arrows and extra techs just for looking more familiar. In second image, Bots can roam for weapons but they might load ammo as well because are on their way or in a closer combat instance. Nothing goes rammed here in a normal MH game.
All these operations are not needed at all if you are dropping all Ammo in a group - a hidden group - and using last XC_EditorAdds for pathing map. All hidden items won't go in account for mapping paths.

What exactly can be encountered in such cases if some game/server uses mutators replacing items ?
Mutators are making lousy things here. Items unmarked and replaced using plain replacement might not spawn anymore after they get picked up. Poorly coded mods will suffer, not advanced mods. If map is not aiming a super duper modded server these are not causing anything damaging. The other way is reducing number of items and accelerating RespawnTime to a faster value than default for loading more players in a short time, 3-5 seconds should be a decent value. You might want to see also map MH-Templar for good ammo settings.

It is not advisable to remove PlayerStarts during pathing process because they need to be chained in NavigationPointlist - here MapGarbage builder is helping at hiding them into void for not being processed with reachSpecs and bringing them back after pathing, they will remain part of the navigation chain for being processed properly by FindPlayerStart function specific to Team-Games, or else player can spawn at random elsewhere.

Next stunt is doable if some MH admins with a "large amount" of intelligence are bitching at your tweaked map because their items have problems at replacing them - those without marker. If they want markers, let's give them markers - but still keeping paths at minimum.
How to do this ?
After importing t3d file with extra items we won't rebuild paths, we have all technology available. MapGarbage has an option named bAddInvSpot using variables InvSpot and InvSpHeight.
If our imported Ammo actors are still selected (we select them back if they aren't, like was specified above) we can complete InvSpot variable with original name InventorySpot and defining a height in variable InvSpHeight for location, majority are upper than item-ammo itself, we can use 22 to 28 or more or less (Unreal Units means this chosen value). And now after pressing build button all selected items (ammo and/or others) will have added an InventorySpot connected myMarker<->markedItem but empty, they do not include any paths/reachSpecs, are just added for wrecks and poorly coded mutators doing replacements at items. Everyone should be happy now, mutators replacing items "properly" and Bots unlocked easier by Engine from such an overcrowded spot. Technically InventorySpot navigation type actor is not visible in Editor but... the builder might put these visible. You don't have to retry this command because it will load more such InventorySpots over selected items loading map with actors out of purpose if they still cannot be seen. InventorySpot has as default property bHiddenEd = True - I think variable name is self-explanatory enough and it doesn't need discussions.

The newer Navigation Actors added as InventorySpot types are not chained and then MapGarbage might report a broken chain. This is not truly a broken chain as long as these navigation points are "isolated", they are not referenced anywhere being added post-pathing - MapGarbage is discovering new "adds" even if they are not damaging, it would be more processing if they are checked for corruption points and this check is useless in this case. However, we can connect them into navigation chain if map's zoning build is correct and nodes are not reported into void - MapGarbage does this UnLink and Relink. They might be out of navigation data, but can be linked with the rest of navigation actors. Paths seeking process will have a bit of charging in this case because Navigationpointlist is grown with new points. This is not critical but internal processing cycles are incremented as well.

Thread might be completed based or not on requirements or taking in account various works.

[Nelsona]

Okay, another sample of SPAM - an entirely pointless charge as long as this map doesn't have any kind of Bot Support but... thanks to the Holy Spirit of UT we do have reachSpecs... for sales. Excuse me, but here it's needed medical help.

SpamStorage.gif (594.84 KiB) Viewed 10389 times

Lol.
How many for no purpose ? Here they are...

SpamStorageCount.PNG (2.16 KiB) Viewed 10389 times

A reminder, you don't have to work like here in XXI century... This is a how NOT to do MonsterHunt maps.

Yes ! It's a fixed one, no wonder... and no names in here...

Yeah_A_FixedOne.PNG (411.9 KiB) Viewed 10388 times