House of Fools

Audience:
Mappers willing to support Bot Play in RX games - future versions might be expected more improved. Solid Bot Pathing knowledge is required and what a reachSpec is.

Intro:
Initial prototype of RX09 with Bot Support has basics for making a Bot to initialize a flight to Enemy Base and bringing flag at Home Base using RX Jet from Inventory if available and ammo is suffice for launching Jet.
We can discuss about future DM games with jets - a sort of arena games. Is that plain Bot capable to navigate using such a path-net ? YES, not only CTFGame is subject for a flight between Bases.

Methods:
The original editor that UT'99 has does not help us much, we have XC_EditorAdds that develops airways but makes strange connections between the navigation points that we do not need.
The editor in UGold 227 or I think U227 also has the ability to create airways because the UT engine supports these features but never created them, enough nonsense to say so. We have an engine that we can use and we have brought to life what others thought were myths.
UGold227 offers us an Editor that also has many new features. We prefer not to use everything it has because the new classes that do not exist in UT make a useless map.

RX spawns some Jets and fuel around PathNodes from around Flags - configurable but... we have to take these in account.
In order to have access at flight we need items so these are not flight routes right nearby FLAGS unless we are using other NavigationPoint actors which can be in MyLevel or no one can get them if are too high. MyLevel has to be done and compiled in UT, points placed in map and... only paths building task will go in UGold227 - do not compile MyLevel stuff for UT in UGold227. I was using names like HighNode - having a bigger collision, AirNode, ect.

In plain Editor, such a map is like here. Explanations below image. By using MapGarbage we can figure What is the deal with those 3 lines - paths - which said HighNode has:
Mr Garbage said:

• Specs: HighNode58 - UpstreamPaths[0]=510 ->HighNode56 --->HighNode58 RFlags=Fly =2 Dist=817
  Connected: HighNode56 to HighNode58.
  Specs: ___________________________________________
  Specs: HighNode58 - Paths[0]=506 ->HighNode58 --->HighNode56 RFlags=Fly =2 Dist=817
  Connected: HighNode58 to HighNode56.
  Specs: ___________________________________________
  Specs: HighNode58 - UpstreamPaths[1]=350 ->PathNode16 --->HighNode58 RFlags=Fly =2 Dist=804
  Connected: PathNode16 to HighNode58.
  Specs: ___________________________________________
  Specs: HighNode58 - Paths[1]=508 ->HighNode58 --->PathNode16 RFlags=Jump Walk =9 Dist=804
  Connected: HighNode58 to PathNode16.
  Specs: ___________________________________________
  Specs: HighNode58 - UpstreamPaths[2]=435 ->PathNode7 --->HighNode58 RFlags=Fly =2 Dist=797
  Connected: PathNode7 to HighNode58.
  Specs: ___________________________________________
  Specs: HighNode58 - Paths[2]=507 ->HighNode58 --->PathNode7 RFlags=Jump Walk =9 Dist=797
  Connected: HighNode58 to PathNode7.

Which Means:
A Navigation Point has two main arrays according to navigation where reachspecs are referenced. Paths[0-15] - 16 pieces and upstreamPaths[0-15] also 16 pieces. This is another image - visible by advanced actor Editing in Editor.
And now, numbers which we can see OUT of that default "-1" are reachSpecs - aka Reaching Specifications - aka reaching Conditions - aka how you want to call them. By giving them a number Engine is identifying them, that number is like a name Mike, Andrew, George, but Engine doesn't use names, it uses numbers.
What do we must have and what do we must know ?
These structures at object Level are not like a decoration where we can put Skins and all that common Editing task, here Editor is using C++ for creating them and also for Using them in game. However we can handle creating these how we want - will talk about this later. They are having stored data, some of these can be captured with UScript interface function called DescribeSpec. It's why we can check what we have because... I'm not coding when I do these paths, I'm using already coded things and A mouse and A keyboard.
Aerial Paths means that these ReachSpecs heading to a Higher point and/or to another higher point must have a ReachFlag which Engine is recognizing as number 2 and human is recognizing as being R_Fly or R_FLY - aka requesting FLY capability for taking this way. Pawn not having these capabilities will be discarded from roaming map. In UT Editor you will never see this R_FLY aka 2. Don't ask me why, ask Sweney and Polge. It's why we need UG227 or U227.

What is the deal over there ? This is what UGold Shows and what UT won't show - see differences: one line in UT vs Two Lines in Gold because we have 2 connections between such two points which UT won't bother to show. How can we identify directions ? Take upper from lower like coming downhill. Enforced explained: And why not using UGold for all ? Because UGold has new data not recognized by UT and some of these are making a mess in UT.
We can take a look at default PathNode what does it have added as properties - some of them being helpful but not all of them... We have two new arrays assigned creating reachSpecs in certain conditions:
ProscribedPaths - here all Names/Tag used won't get any connection with these tag points or such names.
ForcedPaths - a blind connection is done forced with tagged node or named node without too many flags - I'm not sure if this one helps out of a RX Jet loaded before - this is not what I want.
Why I'm not using these ? Because if these default values are changed, will be saved in map. We have to ReSave final map later from UT in order to get rid of foreign bytes... This is not a problem but I prefer to remove a reachspec or to cause creating a new one in this environment because NavigationPoint in UGold227 is coming with new natives allowing you to play with these. I created an Interface - simple but good enough for fine tuning - In Next posting you'll have all toys.
Without too much talk we can have two routes where ground paths can be whatever type added in MyLevel, and Air paths might be Another type. We can select All AirNodes and put as Proscribed paths GroundNodes leaving only heads to be connected natively with normal PathNodes. The same for ground nodes we can put proscribed paths those AirNodes ( all are having a TAG ) and connected with PathNodes at beginning.
Will result a double pathed map - Ground route and Air route.

Here is a sample in causing UGold227 Editor to do complete separate paths: It's why ground is not connected with air and neither reversal.
In RX mapping we might want Air paths more straight/short so to speak. They are primary paths - shorter - if Pawn has A rocket. If not we might want it to get it from elsewhere as GROUND pawn. At entry into Air node we must have a relevant height for starting flight. When Pawn has RX item will have a new power. Engine will point Pawn on another route. If pawn is on ground will navigate normally until is closer to first HighNode - doesn't matter the name, it has to be higher from ground. Pawn is tracing this Node if could be reachable by default, if it's higher enough will start Jet following paths to Enemy - and back if is alive.
Technically pawn losing Jet won't have a deal with air paths until has an usable Jet loaded. It's why an alternate navigation network might help him if there is a Jet/WarheadLauncher. Even if is on the ground with a new jet, if Air Paths make a shorter road Pawn might start flying if wants.

These properties are gone for good in UT, it's why a Path-Network after testing can be filtered with UT Editor. I prefer to remove what UT is not using... by any matter, a copy of map out of UT with said "new" properties can be stored elsewhere for future editing in case of bugs, and for recovery...
Air ReachSpecs created by UGold227 are recognized without issues in UT, creatures in a MonsterHunt map can follow those paths if are intended too - A.I. triggering knowledge is required here...
As a self note: I would like to see someone writing some C++ thing for Editor, storing these bytes in files using the same name as map but with another extension and attaching them only in Editor without to add anything in map and leaving it clean for UT, perhaps functions too... including vertex editing using some numbering stuff as well in order to correct the crap which Editor does with geometry - ANY of them.

Adjusting and... connecting paths can be done with another Builder "PathsLinker" which I wrote using functions from UGold227 which UT don't have but UT can recognize results. Initially this was intended for UT but... I got no help for doing something which an advanced mapper would need.
This one will be posted after writing a small document with features: As result of Manual Adjusting Paths-Network we can have this: Nice air-paths passing only through special nodes causing Bot to switch to his best weapon - our RX is rated here just because we WANT it USED.

Bump: Ditto
We do have the tool helper in paths handling - doable since 2012 but I was... utter N00B and I think... Ignorant.
Because Unreal at doing flying paths might do extra connections or it's missing some wanted connections we can adjust/create/remove paths using...
PATHSLINKER
Here it is: In origins it was aiming UT... but we do have more reachSpecs handling support in Unreal227 ("h" it's my update).
This is NOT WORKING in UT Editor because it calls native functions which only Unreal227 has at this moment - Yeah, UT...

However, maps using stock textures and simple stuff done in UT, can be adjusted/edited here with ZERO problems.

Methods summary:
- All Navigation Points are linked in some array known as NavigationPointlist;
- we can connect, disconnect/edit these with needed reachSpecs/Paths/Lines shown in Editor;
- we can add New PathNodes, but they are useful only if are linked in said list - MapGarbage does disconnecting and reconnecting this network with new points;
- we are doing, as advice, one operation per session, creating reachSpecs, another session will remove unwanted ones, and other session for modifying reachSpecs - I don't think I can explain why I prefer such methods - you might figure this;
- we re-open map in UT after tweaking, and re-saving it from UT - purpose is getting rid of New Unreal bytes and leaving it full usable for plain UT;
- common reachSpecs done by Unreal are recognized in UT - if map won't work it's your fault or map is badly messed up.