House of Fools

A few other hints and/or rules:
- a Network node can be a bit moved in spot if is not good without even to rebuild paths - no major problems are here;
- adding/removing a node to network heads to a rebuild. By adding a node it has to be placed in network, by removing a node, reachSpec array will have a hole crashing game when parts of network which are registered are missing - NEVER delete a node without rebuilding paths after that;
- paths can be forced with combos LE-LC-LE but this must be done knowing well geometry in that location in order to not create routes impossible to follow;
- a JumpSpot is not a magnetic field distracting Bot to jump if has no exit and entry - such a LiftCenter actor is never linked by Editor with a PathNode, these are blind points without LiftExit types and if you look well at those "awesome" junks, they do not even have any Path-Line heading from and to them. Here image shows a BAD situation, I moved this a bit for a better visibility, what has to be noticed -> it doesn't have any connection with network and neither definition for LiftTag, no entry and no exit. As another note, here nodes are placed at around 300+ UU which is causing way TOO MANY for this simple geometry, to not mention those never reachable, entirely without purpose: Here these two are demonstrating what I said in first post: Made sure a pawn can reach at your PathNodes and even resting there if wants. These two being in air, a pawn running/walking will NEVER reach there, Editor did not connected them at all. But... we do have some bullshit map saved and shared - good for use in learning "How Not to do" things.

A few explanations about Editor and how navigation directives are set.
In Actor class tree > Pawn > there is a pawn with a special purpose, Editor uses that VERY INTENSIVE - more than you can ever think, it's called Scout.
Scout is not very enhanced with wizard type properties or able to perform more stunts like in movies, is a probing pawn which Editor is using to test spots - that's why paths building takes time. This Scout is calibrated in multiple Collisions according to map's geometry and a path is defined if this Scout can be moved between points WITHOUT to Hit walls - collisions parameters which Scout has during tests are being set in reachSpecs. This is an array containing reachSpecs that cannot be accessed in plain Editor, we can read some data from this array but we cannot really change it how we want. Building network without having borks means a clean way between Nodes (except teleporters, lifts, or other custom things - various jumpers, etc.).
Perhaps for now it's enough for basics. We should practice pathing in plain maps and then we can switch to another chapter - advanced - which is... very beautiful and entertaining.

Completions Bumping

So far, I may not be quite clear. Let's see, however, what is happening on a DeathMatch map with a solid navigation network but which is not showing much interest for A.I. - Bots, more exactly when they are not too determined to navigate in random directions, just very briefly.
What a Bot wants when decides to move ?
When Bot starts roaming usually he will find himself weak, wants to get stronger for defeating potential threats. Which means he wants items - inventories. Here comes Engine with computing whatever desire of item vs path length - how long takes to get something useful.
Inventory is not part of navigation network directly there are other sort of actors placed in Level. Here we need to know that once placed inventories in map we can clean map - removing all current paths - ConsoleCommand: Saving map and closing Editor. Opening Editor and Map and firing command Now we have a clean map with a fresh navigation network and something new hidden pointing path lines over items. No... these Items don't have more relations with navigation network but we can input another command: And now some eagle/dragon head is visible around inventory - that's a navigation point called InventorySpot and this is reference point for making Bot to figure that map has far away Items than can be collected.
Concept here is similar to Husband and Wife - let's see the picture accordingly: In image we have an UDamage known as DamageAmplifier which is Inventory, and then we have InventorySpot which is a navigation point. By opening advanced properties (for figuring masked properties) we can see these cross references - blue lines, why Bot knows about DamageAmplifier and why DamageAmplifier is a navigation goal. InventorySpot18 from map has as markedItem this Udamage2, UDamage2 has as navigation handler (myMarker) InventorySpot18. If these relations do not exist, no navigation is available to said item and then Bot might get this item when is fighting closer to it. If we have items "unmarked" this way this is not a big problem but we won't see Bots collecting them until they are placed around other items or routes which are targets and they are motivated properly for loading them - desire for item in certain situation.

To summarize: If we want some Inventory to be part of Bot's mission, all we need is (re)building navigation network - in final stage of map in order to gain an InventorySpot accordingly. We don't need to rebuild this X times when we work at geometry, it's a dumb thing to load a mountain of junk reachspecs when map it's not done yet because each rebuild of paths without cleaning map will leave old junk reachSpecs behind. If Inventory it's not part of Bot's mission, this pawn won't move for it.

Another extra-note toward reaching to an optimized map-size and cheap methods for reducing size.
1. By using an advanced path builder and spreading navigation nodes properly we might have a network more simple with less data;
2. By using MapGarbage for removing old paths we have other bytes deleted because a navigation point has a few more data unused in run-time - Epic's brain-farts for some never come "development".
3. Editing plonks by Editor itself, I tested these.
Let's figure by example properties of PathNode Class before adding it in map: And now let's see PathNode Placed in map: Allow me to explain what I see. While default PathNode has no TAG defined - it's None, once added in map Editor is tagging this actor with a string - no, it's not empty or a null thing, it's a string which means bytes, yes, new bytes. Why this tag ? Well... heck knows...
If we copy PathNode from map and PASTE it in Notepad whatever we can figure all properties assigned out of default. One of these is this TAG.
What did I do ? I selected ALL NavigationPoint actors and I removed Tag or placing there "." a dot, a single character. One of 300k contest maps has been reduced with 1147 bytes by only removing this useless tag from Navigation Actors and Inventories. By culling textures and removing other references with XC_EditorAdds other 300k map went to 250k - 50kb have flew away.

Bump for chapter Basics in making a Navigation Network.
We do have fresh samples in how not to do combos - these will result in broken routes and useless map charge: The reality is, when a navigation route has a single line missing from the entire road, a Bot won't move through that route. It might go closer if exist some item for his interest but here is not that case.
Let's explain simple what is here. Nodes are doing line by line a road to a LiftExit supposed to be start of the jumping stunt to the JumpSpot. And then ? And then good night. From any of these JumpSpot-s forward there is no line linking any of Next Nodes on the way - they are like an End-Point. Bot won't move there just to get back for no reason. The only usable routes are connections from LiftExit actors to those nodes placed lower. Bot might jump if has a valid purpose - fighting or picking a nearby thrown weapon.
Let me see, duplicated maps with a few adds and nothing fixed are out of my interest. Here we should have probably a Single combo having a Minimum of 3 Points and letting Bot to use as that it wants, else we might need at least 2 Combos which means 6 Navigation Points. These routes usually are Bi-Directional not One Way and then Bot is tempted to move around this road.
Of course, if we do have a solid knowledge about how do these work, later we can disconnect not needed paths - even deleting them because by using tools described in the other advanced navigation topic we can take control over paths as we want without letting automated script from Editor to blindly do only what it knows to do when it comes to paths building.
What is usable from these paths ? Let's see: All Valid routes have uninterrupted paths-lines and not Ending somewhere in the middle of road - These ends going into a JumpSpot not connected, not to an InventorySpot have no purpose, all valid lines are heading down from ledge and that is the movement way - not jumping to nowhere.

Bump around basics. I forgot this detail
A not very funny bugger, which I think belongs to plain Bot Pathing, might be a very small so called ramp, but this is not climbable without a desired velocity. Pawn starting to move if is closer to such "ledges" must jump, Bot is not really doing this because is not really treated as wall, it runs in place.
I'm trying to show some image with bugger a bit grown. This small ramp causing random movement locks can be covered with a Bot_Jumper for some positive results (if pawn is not fighting and falling around), but we can use a BlockAll for covering ramp, purpose is to cause a sort of wall obstruction under Pawn's "MaxStepHeight" value. This way Pawn will step over BlockAll, else a kicker addressing Bot can be helpful. If your map has such a navigation area you should take in account that here can be often seen troubles...

The next basic scenario
I'm beginner, I like a map, but something is wrong with these paths. How can I get some help from MapGarbage ? Does it help at something or this is just a fancy nothing useless in all ways ?

Solution:
Let's recall certain RULES ignored and forgot or never known by mappers at random.
A PathNode is recommended to be left alone as Editor has placed it or even adjusting its location in a lower spot with 8-10-12 UU (UnrealUnits). Some of these dudes for unknown to me reasons are used to move them manually upper or in whatever place hoping to a sudden Bot flight which doesn't happen unless Bot used is a custom one, but... we need valid PATHS for stunts not only ONE-WAY lines Up to Down and nothing in reverse which a plain PathNode is doing. Usually highly pushed nodes and those having no Incoming Connection are a problem when MapGarbage is reporting these: In this scenario we don't have a JumpSpot or Teleporter or a WarpZoneMarker. We do have a plain path which needs to be normal, but... it's not.
Commands used here in MapGarbage Editor tool are bCheckNoReachPaths and bCheckNoPasses. At this moment I'm not aware about any Editing tool reporting Paths and pointing a nasty spot.

Okay, I want to put PathNode(s) back on the ground because rebuilding paths doesn't do anything, map is the same.
Good, you don't have to waste time painting Nodes and trying your best mouse moving skills, we select one or two or all bad PathNodes. We open properties and we set:
- bCollideWorld to True
- perhaps bCollideActors to True
We switch view to Actors : RadiiView - right click on Viewport top menu bar area. Now all Selected PathNodes are moved a bit lower using mouse as you do with actors generally - bottom part of cylinder can be a bit buried in floor - floor polygon lowered than the ground. Leave them selected and partially buried in floor - we need only to see their texture - entire apple visible. Use MapGarbage's option bGridPlacement. Now all selected PathNodes are pushed at Fixed coordinates, but because they are colliding world and actors, Editor will adjust their location in a decent height location - even with a floating number on Z axis. Now you can set above properties back to False: bCollideWorld, bCollideActors.
You can use again bGridPlacement option and now they are aligned more clean. After this stunt you can see all nodes previously buried Located properly over ground except those badly messed up which will need another adjusting. Next move is rebuilding paths for another test operated with the same builder. When all these are solved, the option bCleanLocBytes will remove their data which is about Old Location - for moved PathNodes.

You can adjust these with a free hand movement but not all maps have a good visibility and builder is definitely faster.

In final stage PathNode1 has all connections making Bot spawned in map to roam for HealthVial. Every single Plain PathNode needs to be connected in such main routes or else no path can be found for the HealthVial.

Bump time: I collected new data with regard to Basics when it comes to Bot Pathing whatever and rules that have to be taken in account and or more or less forget.

Some tutorials are saying that in ramps nodes need to be placed closer for some "visual" reasons, else they say that nodes should stay as Editor is placing them or else bad things are happening. Due to UT469a public release, we do have a generic image from map DM-Khin taken in stage as a "LOLZER" or use another word which you like.
1st Image Paths here need to pass through some ramps. Nelsona says: Here you don't really need Nodes in these short ramps or else you'll want to push them lower a bit.
What nodes can be a problem - by example ?
This PathNode7 from image below might need to be lowered as recommended by Mr. Garbage. Also Polge said that we don't need PathNodes near Inventories, Nelsona: and this might be going even worst when these are happening in a ramp. A Lulu ramp is below, similar spot... If you ask what exactly is the problem, the problem is Node reachable-unreachable - False reach calculation. Bot-Pawn cannot get into Location of PathNode and will retry. Sometimes will stay here all day long depending on which Bots are we using and how many, and how do they are engaged in combat.
Let's see a video-gif done at a lower resolution from this area. It should be relevant as aspect of pathing not exactly as an UBER video: Solutions then ?
Get rid of PathNode7, and get rid of ANY PathNode closer to an Inventory especially when this is placed on a ramp and that PathNode has no purpose in any way.

Back at basics - um.....

Today's story - CTFGame mapping - subject AlternatePath usage. Work category: easy-medium.

1st Note - Always Pawn is guided by Engine through the shortest road to the target if it's available. Due to this logic limitation, CTFGame uses an actor specific ONLY for THIS GAME-TYPE named AlternatePath and... sub-classes if exist any (community has done here some goofing no worries).

2nd - When Bot has an AlternatePath loaded (it's internal variable) it will look for (once again) the shortest road to this AlternatePath until it goes reachable - in that moment AlternatePath is discarded and pawn will look for desired Flag.

As result - we need these AlternatePaths dropped on longer roads for flags or else Bot will always roam through smallest route - it might be toggling routes only if PlayerStarts are placed away from shortest roads making it to follow another shortest route but returning with Flag goes through the same predictable shortest road.

Placing these at cross-roads it's not really helpful. I'll show you below a
BAD PLACEMENT sample Here Pawn will always find the way through central area because it doesn't have any deal other way.
In this case an advisable
GOOD PLACEMENT is below: Here we have shortest routes to and from AlternatePath always going Out of central area.
If you understand the logic of the SHORTEST road to the goal, all it goes easier.

Variables used by this actor
bTwoWay = Using this by a flag carrier - ignoring team byte.
bReturnOnly - Using this ONLY for return and not for attacking Enemy Flag.
These are based on PlayerStart logic placement for preventing a loop back in base during attack - CTF-Coret here is automatically hacked by Engine because they did wrong team settings.

EDIT:
Any ALTERNATEPATH is useless if map has no valid connected paths to FlagBase target. AlternatePath it's in account ONLY if a path can be found to a FlagBase target. Why FlagBase ? Because FlagBase is the nearest navigationpoint to the Flag. Why not adding A PathNode there ? Because if FlagBase is messed up, PathNode status located there will be the same - overcrowding points in area has no purpose - unless you have a special situation and you know well what is about (some flag corrections behind auto state stages, etc...)

Next problem: Jumpy Goat
This is not a subject for more talk. It is about using kickers - kickers are based on "kidnapping" they are supposed to adjust movement velocity in a sudden moment.
Pawn should have a destination set and then we don't need a Node inside Kicker because Bot will try to reach here doing constant jumping. It is advisable to add navigation combos or some fake navigation IN FRONT of kicker. Pawn starts running at target and hitting kicker later. We also might want to figure the way-back and then kicker should not have an insane collision. This a sample out of too much talk. For various failures we can complete other kickers dedicated at Bot Class only.

BAD LEDGES
Bumping ahead with learning some cheap solutions and not listening what Polge was talking about ledges and angles chapter. In certain angle with ledge Bot needs to jump instead of trying to find a better jumping angle - he simply can jump but Engine has another deal with Pawn's movement. Then it's time to apply a small tweak, we can call it "step lifting" - Pawn will lose contact with ground so it won't be blocked at ledge and... continuing to move.
Let's see first the bug: Pretty nasty but... in this case we do have a really simple trick not only creating other paths or other complex solutions. We can add a very small (adjusted blocker like BlockAll) making pawn to be lifted a bit from floor and avoid a contact with ledge. Actor can be placed immediately in path's line direction and it won't affect anything if is smaller as possible but Pawn will simply start Falling and heading to the goal (healthvial here)...