House of Fools

Inventory - paths passing through - UT myths around.

I did not do more research in Unreal, but definitely for UT some people have a very false way of thinking and doing borked spots based on WRONG assumptions. When it's about an Inventory having a pass through, some people are saying that if inventory is removed or collected Bot won't follow that route.
EH - that's depending on game-type and what Bot wants because an InventorySpot can SUBSTITUTE a PathNode with no single issue - even is better for Bot's collision than default PathNode. Yeah men and women, and MonsterHunt will destroy this myth showing that geniuses from EPIC themselves did not have more clue about Bot Pathing, adding PathNodes like PathNode 112 and PathNode25 in CTF-Command which are NOT NEEDED at all, and not only here, assuming that InventorySpot will cause an EndPoint like a wall making pawn to stop there.
In DM, if Bot doesn't go there it's because of his native habbit in collecting items. If item is not there, there is no reason to roam area - what for ? This policy is applied in those rooms with paths but NO Inventory, routes are good but our Bot has no reason to go there.
In MonsterHunt if you have let's say the first tunnel done by using HealthVials, if first Bot has collected them, this doesn't means that next Bots won't start hunting because Vials are missing or when a mod is removing items. Cheap stories and fake news that can be checked - IF you can do paths and setup a MonsterWaypoint starting with POSITION 1 not Position 0 or when MonsterEnd has a valid route for being touched correctly.
I'll setup CTF-Command and then we can take a look at reachSpecs in order to prove with evidences that what I'm saying is the truth and not Bot type dreams.
Image Please... And let's see reachSpecs using some colors:

• Specs: InventorySpot98 - UpstreamPaths[0]=263 Start=PathNode26 End=InventorySpot98 RFlags=1 Dist=791
  Connected: PathNode26 to InventorySpot98.
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - Paths[0]=1656 Start=InventorySpot98 End=PathNode26 RFlags=1 Dist=791
  Connected: InventorySpot98 to PathNode26.
  NoReachFrom: InventorySpot98 to point 0 which means DefensePoint2
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - UpstreamPaths[1]=1679 Start=InventorySpot100 End=InventorySpot98 RFlags=1 Dist=210
  Connected: InventorySpot100 to InventorySpot98.
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - Paths[1]=1662 Start=InventorySpot98 End=InventorySpot100 RFlags=1 Dist=210
  Connected: InventorySpot98 to InventorySpot100.
  NoReachFrom: InventorySpot98 to point 1 which means PathNode113
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - UpstreamPaths[2]=1669 Start=InventorySpot99 End=InventorySpot98 RFlags=1 Dist=209
  Connected: InventorySpot99 to InventorySpot98.
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - Paths[2]=1661 Start=InventorySpot98 End=InventorySpot99 RFlags=1 Dist=209
  Connected: InventorySpot98 to InventorySpot99.
  NoReachFrom: InventorySpot98 to point 2 which means LiftExit1
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - UpstreamPaths[3]=258 Start=PathNode24 End=InventorySpot98 RFlags=1 Dist=186
  Connected: PathNode24 to InventorySpot98.
  oooooooooooooooo: oooooooooooooooo
  Specs: InventorySpot98 - Paths[3]=1655 Start=InventorySpot98 End=PathNode24 RFlags=1 Dist=186
  Connected: InventorySpot98 to PathNode24.
  NoReachFrom: InventorySpot98 to point 3 which means PlayerStart14
  NoReachFrom: InventorySpot98 to point 4 which means PlayerStart13
  NoReachFrom: InventorySpot98 to point 5 which means PathNode48
  NoReachFrom: InventorySpot98 to point 6 which means PathNode20
  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

Also there are paths which have no navigation capabilities due to their height but are navigable in reversal using jumping.
Our supposed EndPoint InventorySpot98 has connection with those two nodes causing a linked route which is passing through there doesn't matter if Evil Devil has eat UT_Eightball or not - here FLAG is game goal NOT items. Items are a secondary goal for freelancing case.

Let me introduce some funky trap used here and there - some people know how to put links but not how to cap these links in order to not see A.I. doing un-succesfully stunts in a way back. So to speak let's NOT do impossible to follow paths. I will sample 2 cases in the same image and completing another instance after that.
Image please... In this image mapper (I saw such case in some map - no names here) made a route from an upper spot to a lower way making sure about connections. However, this can be a problem - LEFT CASE with LiftExit-PainPath(LiftCenter)-LiftExit. Why ? Because route from bottom to the top is available as the other way, Bot waiting a lift which will never come or running in place like a stupid trying to reach at Mid-point. In Case from right side two PathNodes are connecting these properly especially if we don't have a high spot causing damage - available for Lift Combos too. If we speak about falling in water, we can put LiftExit Unreachable from Next PathNode in order to gain One-way and to not make Bot to try going up. Trying somehow to recreate route as shown at the right of previous image, but doing this at bottom, at end of fall.

Somehow this one way should be like here: Last LiftExit is a bit higher Unreachable from PathNode but LiftExit is well connected with PathNode and them pawn from Level won't try to get on this route.

Before to speak about doing specific MH routes in one way style, we can debate something about Movers and then you don't have to be scared but you can be shocked or slap your face or whatever you think it's needed. I will sample here Bot Trivia Vs lousy logs - and this way is not recommended, it's very frustrating.
MOVER (called Lift) moving vertical.
Default setup for such a Mover is BumpOpenTimed. Good...
Sometimes maps are logging whatever:

LogFile wrote: Warning: "...." is BumpOpenTimed. Bots don't understand this well - use StandOpenTimed instead!

The reality is that if "tags" are properly set, mover is correctly set from all angles. Bot not understanding this Lift(, I'm talking with you, Epic) ?
I assure you that we don't have here too much miss-understanding as we have CHEATING - read 100 times, CHEATING. Bot is cheating, you'll be shocked to see in some maps like CTF-Mafia by example how a bot can summon a lift when needs it without to blink while player does nothing here - only translocator will help against falling hard.
How goes scenario ? Bot is on top, Mover-Lift is down. If Bot consider that will fall harder and has to wait for Lift, if mover is a Door-Type using BumpOpenTimed, you'll be surprised to see Bot moving mover by itself without any trigger. A triggered Mover is recommended in MH for such cases as in the rest of similar instances Mover Up - Bot Down. Lifts done correctly (no kidding here) are done in map MH-Demons][, yeah, the rest of things over there are jerky, map might crash games due to settings used at Monsters and Factories but can be a pretty good sample about MH Bot Pathing - okay, not perfect but... according to Lifts mapping that is an entire "How To" - I won't sample images here because map exist so anyone can look at it directly.
The evil mover case is sampled in a map which shows this reality called DM-PlonkyMover or such located somewhere at UT99.org as a negative sample because player will go crazy... If you cannot find it I will add here as a "Don't do this" sample. Usually mapper is "working hard" to block Bot from getting items granting advantage to players and they are going mad when things are done vice-versa blocking player and unlocking Bot-Only stuff.

MonsterHunt specific navigation - Assault style.

In the most of cases we are advancing in Level without the need to come back - exist exceptions too but let's see one-way-attack.
As the name is self explanatory, in default DevPath from UE1 it's supported a feature less known and well suited for MonsterHunt (only CTF-Coret uses this) called bOneWayPath.
Um... Cough,... what does this mean ?
This means that our NavigationPoint (even default PathNode) as first step is making it bDirectional (AdvancedOptions - in defaultproperties menu - right click on said actor). Once done bDirectional we can rotate it into whatever direction. What direction ? Roaming direction, and then in NavigationPoint section looking for bOneWayPath value and setting it True.
Arrow should point direction of A.I. movement. Routes here are passing through this node in the way pointed by arrow. The issue: Editor sometimes will try to pass over this node for some reason linking Node from a Previous spot with another Next one trying to open a route back - Evil Editor - and might bypass said node with restrictive route - for some such cases I used TWO or three Nodes well oriented for preventing dumb A.I.
Will work like a barrier - BlockedPath when Pawn wants back but is allowed to crawl map by advancing only.

Another case is desperation not Bot Pathing, such a map (not crusher one) is a version of MH-Egyptica where Bot is pushing a mover opened (a dumb idea more exactly) in horizontal plane and blocking routes (right before facing Titans). Solution would be probably more suitable to open mover in a vertical plane.
But I want less writing and more visual samples about BADLY messed up (MH) Bot Pathing. Image Please... Bots here in very rare combat situations are getting over door, after killing Titans (and dying later), they are following the SHORTEST route which is heading through opened door not away from door on the long alternate road... which means going nowhere in the most of cases...
What's the big problem here ? Trick with Mover's polygons won't work. Map has brushes stripped out (jerky stuff here) and then cannot be rebuild because will almost get vanished. For this particular situation the answer is SPREADING nodes, less PathNodes and even probing bOneWayPath if necessary in certain direction, because here it's full pathing desperation not Bot Pathing. A version which I managed to solve will look as here... Routes here are heading away from Mover-Door preventing some links due to nodes positions and nicely giving a travel without to collide it. This Edit has full Bot Support, simple as that.
If you ask about those places at left from Titans room, they don't really need so many paths because Bot can head to a nearby node if by chance is wandering around and is capable of finding navigation network, still being in seeking range. Original map has 99 PathNodes and some version was even crapped up, edited version has... 46 PathNodes and is full operational with no issues.

A few notes around UnrealEngine 1 according to DevPath.
This Christmas for me was constructive and disappointing in the same time. I had a bit of time for looking over newer XC_Engine version 22 where Higor extended a bit some options toward capabilities doable in run-time. One of things is reachSpec handling which is not possible without new assets added to UT. Nothing except UT's Editor won't define paths in default UT. However, I must inform you sadly that UE1 seems to have whatever features in DevPaths which... are not used. Are not used... because UT' s Editor will never do such paths - never so far. If we speak about Flight more exactly, XC_Engine shows that navigation is possible but nothing is editing/mapping it - so far only in run-time is doable with lousy mutators. Paths here are... hell knows how should be mapped because main criteria is Level's ground after all... but can be a start for supporting Flight type stuff and implementing this in A.I. - if people can do it, else some creatures like Mantas and Co. can be definitely configured better for assaulting.
I ran some tests in a map like done a letter "U" with BIG nodes having no reaching data each-other just "visiblenoreach", DevPath has brought Monsters to me correctly... It's not about setting up Water-Zone and doing paths incompatible with a fly (- swim directive), it's about REAL aerial paths connectable and usable by flying A.I. combat units. I'm hoping to see this stuff done by Higor... as an extension for Editor - a smarter one getting all UE1 resources. We had these in Engine two decades and... None usage... At least it works, that's sure.

And now let's move back to routes blocked and let's see in a simple graphical format for understanding purpose, what exactly BlockedPath does. Each tutorial which I read is sampling As-Mazon as main sample but, I did not see many MH maps done properly here, people were doing stunts and passing over BlockedPath with other nodes shortcut-ing it and making it useless. BlockedPath it's not a FearSpot making bot to wander around being "scared", BlockedPath means: DON'T GO THAT WAY - BUT... YOU'LL DO IT LATER.
BlockedPath should lock the shortest route to whatever game-goal when some door is not unlocked yet in order to make Bot to play normally rather than pushing a closed door.
Let's see this scenario: Here if Bot goes from "Start" to "Target", there are two possible routes: Marked with Green, and another way unused because the road it's longer there. By Using a BlockedPath we can motivate Bot in first part of game to follow only longer route from top of image and completely forgetting the bottom one - that green one. In second part we can unlock green route later...
Question: Does AlternatePath helps ?
Answer: NOPE. AlternatePath is a random thing used ONLY in CTFGame. Even if it would work, by taking a random route, Bot might have a chance to not pick such thing at a moment and following a closed road, pushing some door-wall not opened yet, looking stupid.

Question: Does AssaultRandomizer helps ?
Answer: Definitely Not, we do not have Assault game calling null borks and neither attackers and defenders as teams, and then except mooing at game with errors, the rest is a nonsense.

Okay, let's lock green route for first match stage. Recommending some position toward Bot ? Umm... we won't use inventories here for causing shortcuts and not much philosophy, but one of nodes replaced with BlockedPath, this one will have a Tag according to an EVENT performed at a moment when BlockedPath is virtually turned in a "UnlockedPath" in a way of saying.
Before explaining what's happening here let's check image: I marked here four nodes a. b. c. d. for some explanations.
When this route is having a BlockedPath actor you shouldn't think that Bot will come closer to Point d. and returning - unless you order some cover task and drive it step by step - chance to mess BlockedPath making it to bypass that if a door won't block access in front of it. Else for Bot alone attacker ENTIRE ROAD from a. to d. is CLOSED TOO making route to be deviated by Engine right from cross-roads point and NOT later. If you have some inventory around making Bot to move there, it's possible depending on situation to see Bot oriented to a node behind BlockedPath and shortcut-ing it - bad CASE. When BlockedPath it's used don't waste time adding inventories around. This is Blocked and that's all. Editor might do unwanted connections over BlockedPath when paths are too many around, for BlockedPath default requirement is to have nearby nodes using only two connections and not a "star". To mention here, between b. and c. or between c. and d. you might have a door unlocked at once with BlockedPath or two doors, the last being connected with BlockedPath - even EVENT assigned to door might be used as Tag for BlockedPath, or other triggering way.

For next debate we can sample when BlockedPath becomes useless this being entirely mapper's goofing.

All right, let's see how do looks whatever Level with BlockedPath entirely with NO PURPOSE. What is about ? In simple terms is about causing shortcuts over this BlockedPath because of wrong usage. In many cases might happen like in image below: In first case InventorySpot it's just creating two (in reality 4 paths) links with these connected nodes allowing pawn to follow this route and ignoring BlockedPath.
In second case (down side) we do have some nodes too close each-other and we gain a link unwanted for this case. This link will create a shortcut over BlockedPath making it USELESS as well. This situation is generating pointless bytes in map increasing size and not working as should.

Which is the main conclusion ?
BlockedPath it's only a NavigationPoint setting directives for Navigation and it doesn't do any "Boo" for scaring Bot. Bot racing around and following player closer will not have any deal with Navigation as long as player is Reachable. Bot will follow player as long as can see it, it will check paths when Player is not visible and neither directly reachable.

Extra techs: SpecialCost and SpecialHandling
Audience: Mappers able to write 4 to 10 lines of UScript using some basic logic for A.I.

SpecialCost is a function which DevPath is processing for a navigationpoint which has a property bSpeciaCost = True.
Result must be in two ways: return 0 if paths has to be free, return 100,000,000 if path has to be blocked - reacting like BlockedPath or like a normal PathNode. Such a Node is mother or bitch for Pawn Seeker depending on condition set. Let's sample into english for the moment not in UScript:
- Pawn has 10 health or less - return Blocked = 100,000,000 - pawn has to roam before reaching here to gain health, else it won't pass;
- Pawn has bigger than 10 health - return Free = 0 - pawn has free way for what wants to do;

- Pawn has a low rated weapon - return 100,000,000 - should roam before reaching to this node in order to gain a rated weapon;
- Pawn has a high rated weapon - return 0 - allow passing through this Node if pawn has a mission goal toward.
And so on - Level designer might use imagination for various scenes.
Biography for writing such thing: JumpSpot, HuntNode PowerNode (by myself in various maps and patch files).

SpecialHandling is a function called if exist (yeah, engine can test if Node has or not this function... lol) when pawn is about to reach at this node - it's on a node behind it. This function is used usually in LiftExit points setting up a new "MoveTarget" when pawn wants to follow this node. If Lift has a trigger, point seeker to trigger instead if mover-lift is not closer - or such. This can be used as an extra tactical situation for shooting something or... jumping over a spot or... hell knows what situation can be generated by mapper's creativity (if has some). Me personally I used this once for pointing Pawn to some InventorySpot where some Jumpboots were needed for passing over another "jumpy node" requiring Jumpboots. These being set with a better RespawnTime. For the case good case of this Node, it returns Self as a MoveTarget. If other bad case is encountered, this can be None making pawn to wander around. By any matter this node MUST HAVE a result even if is NONE unless engine will crash like an ass as it does with player scanning paths through a WarpZoneMarker or even a TranslocStart - that's crap but can be solved if admin owning target server wants this.

A Dark solution: Protecting certain map to run everywhere by implementing such a feature and making player to crash a server running unauthorized said "fantastic" map. Not many people are understanding pathing so only a few guys will deal with it... If you need a private map for certain server/community - protecting map from being hosted by moron admins can be done this way - using UT bugs in your favor - remember this.

Which one is more expensive for engine ?
Definitely the node using SpecialCost called by seeker when does a network scan passing through this node - Node by Node - it is advisable to have here a quick condition rather than more iterations. SpecialHandling might have a "more smarty" code because is called when pawn seeker is closer.

Continuing with a bit of real facts about increasing A.I. performance.
It says: Bot cannot use a door by shooting at button. Probably if button is far away and not in direct door view it's true... but not really when button is handy somewhere around entrance closed with door. Even if UT has no stock support for such a task, A.I. has sequences that can be mounted head to head resulting in something a bit more smarty. Basic explanations. Bot comes from base through node B moving to A. Node B is special too but it has no effect... node A will have effect because does a query if bot can trace it, if not, node says shoot that thing (node is configurable by mapper - as should do with a LiftExit but here things are different a bit using NAME of target actor and NAME of Door), Bot will shoot node as long as a trace is not available directly and it's hitting door. If trace is available and door is moving, Bot will wait for door to stop moving. By any matter if engine goes crapped "forgetting SpecialHanding" Bot will have a denial using "FearSpot" connected with Door VIA a second dispatcher toggling fear in timing with door in order to gain again SpecialHandling stuff. These are using Dispatchers for preventing Bot to deal with Unreachable buttons by connecting door with button directly. If these are directly connected Tag-Event, Bot will attempt to reach at button brutalized by Mover code. So this happens also if Bot comes back through A for point B. Point A can be seen but we might have point B not seen and then we have to shoot the other button... these are cross-connected through door.
It's way more understanding by looking at game action and at a direct small map sample in Editor: The test is simple, fire a MH game Off-Line (map doesn't include any objectives and no other purpose than learning), and use 2-3 Bots freelanced for default MonsterHunt. At order "Attack" due to fascinating original MH controller they will run in place doing nothing. In XC_MonsterHunt they don't need any order. Go figure how do they move around.

For next session and better understanding how useful can be "specialhadling", Node has small stuff for player in order to figure when SpecialHandling is "talking" to pawn seeker - here is very basic, just for figuring when specialhandling is getting called ignoring door stuff for player. In order to apply things in a bit of practice we have to debate "Path debugging" features which engine has because we need to be capable of navigating. For this case if anyone knows how to check paths like A.I. does, these nodes will inform player seeker about shooting option. Monsters have no support here because... not all of them can shoot buttons and Skaarj is retarded at this point.

Before taking a break here until some random people will have some interest, let's see default speech about...

AnOldDocument wrote: Tweaking and Debugging the Navigation Network

After placing and "defining" the navigation network, the level designed should tweak and debug it by watching bots play the level. The designer should the game as a spectator, and add first one and then later several bots to the level. The designer can watch them play, advancing through the bot cameras using the fire button, and looking for problem areas. If the bot currently being viewed seems to be acting strangely, using the console command verbose will indicate what it is thinking. After the play session, reviewing the log file may also provide insight to problems.

If the bots don't seem to understand how to get to a certain destination, the designer can use the rememberspot and showpath console commands to look for breaks in the navigation network. When the rememberspot command is used, the current location is saved. Subsequent showpath commands will cause the best visible NavigationPoint on the path to the remembered location to become visible. If no NavigationPoint becomes visible, there is no valid path to the remembered location.

by Steven Polge - if you can ever imagine how much work was behind these things...
I feel like I owe some explanations due to the lack of words and typo mistakes by an english speaker (then do not wait more from me) which in other doc was claimed as being some cheating commands and here is called "debugging". It's like we have to know cheating commands for debugging a Level - Lol, Polge, where is your mind ?

Light me please....

I want to see if A.I. Pawns can reach to a certain location X. I will move to that location in an OFF-Line game and input command "RememberSpot", after that I will go back usually to Spawn location and using command "ShowPath" - no quotes. If a path is available, a LAMP spawns on a nearby (Path)Node. By moving to lamp and touching it, will spawn(/move) on another to whatever Node location. If user is repeating movement and touching operations, these lamps are going to drive player closer to location where command RememberSpot was sent in console. This means StartSpot has a Navigable route to said probing location X because this ShowPath command was able to show point by point nodes linked to target spot like Artificial Intelligence does (aka Bot or such). If nothing happens, path is broken - look at game-log.
In said "map" - it's only a demo thing, when SpecialHandling gets called, Human Player (you) can see a Blue Big Message on screen. It happens if you could figure how to use RememberSpot and ShowPath commands.

Cons - A rude awakening (it's not the MH map called like that) it's POLGE and Co.
By using said command in a plain UT for warpzones game will crash when paths are around such point, debugging in such a map is not possible. If you want a clear image of pathing you need a "modded" Engine.u file which is not my problem at this moment. Good...
Other answers toward whatever nasty path problem from a map can be checked and explained for anyone interested.