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.
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.
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=510 ->HighNode56 --->HighNode58 RFlags=Fly =2 Dist=817
Connected: HighNode56 to HighNode58.
Specs: HighNode58 - Paths=506 ->HighNode58 --->HighNode56 RFlags=Fly =2 Dist=817
Connected: HighNode58 to HighNode56.
Specs: HighNode58 - UpstreamPaths=350 ->PathNode16 --->HighNode58 RFlags=Fly =2 Dist=804
Connected: PathNode16 to HighNode58.
Specs: HighNode58 - Paths=508 ->HighNode58 --->PathNode16 RFlags=Jump Walk =9 Dist=804
Connected: HighNode58 to PathNode16.
Specs: HighNode58 - UpstreamPaths=435 ->PathNode7 --->HighNode58 RFlags=Fly =2 Dist=797
Connected: PathNode7 to HighNode58.
Specs: HighNode58 - Paths=507 ->HighNode58 --->PathNode7 RFlags=Jump Walk =9 Dist=797
Connected: HighNode58 to PathNode7.
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.
Code: Select all
native(519) final function describeSpec(int iSpec, out Actor Start, out Actor End, out int ReachFlags, out int Distance);
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.