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.
- TAir_0.png (916.62 KiB) Viewed 8584 times
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.
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.
- TAir_1.png (13.71 KiB) Viewed 8583 times
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.
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 ?
- TAir_2.png (1.12 MiB) Viewed 8583 times
- TAir_3.PNG (1.23 MiB) Viewed 8583 times
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...
- TAir_4.PNG (12.59 KiB) Viewed 8583 times
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.
- TAir_5.PNG (780.15 KiB) Viewed 8583 times
