SLBotBrain.uc - Class for bots using jets.

[SC]-[WARTZ_{HoF}]

That is a popular map played by the DM fight night guys. Be great to test this Thursday evening.

[Nelsona]

Here is some ChronicZen whatever.

Ch_Zen.PNG (1.3 MiB) Viewed 9985 times

My note:
Here would be needed some XC_Engine and/or smarty Bots as longs these clowns were separating bases with Movers which in plain UT make Bots to attack each-other crushing and doing nothing or map has to be modified with normal WALLS because we can have players visible through a "glass", we don't need mooing with stupid Movers...

All right, I have to do (maybe tomorrow, now it's late here) some testing of these aerial paths and I'll pack the sample for A.I. working lab. Now It's up on you how you trigger Bot in using jet, I can only have a few recommendations toward tracing ground of a MoveTarget. If goes lower Jump, if goes higher, start flying.

[Nelsona]

And I was very curious about whatever content and doing miscellaneous checks in fresh "aerial map" which I named CTF-Chronic_Zen-v2020.unr.
I got bad news and good news.
Good news: Aerial support was available, I found path to enemy (other) flag - now it's up on coding A.I. and Jets for these. Common Bot uses Impacthammer as a sample of a relation between Inventory and A.I. pawn.

Bad news: For some reason which I couldn't get - I was about to spit coffee all over the place this morning before going to work - I could find some funky reachSpecs, hilarious abominations if I can define those things in words describing Polygons, Models, having insane reachFlags with no use. 30+ such reachspecs were added in map. I don 't know how much are damaging these because they weren't in Navigation Points but in Array and which factor caused their appearance. I could solve problem in UGold Editor 227 - the fact is if some map uses more assets from UT unexistent in UGold, making an aerial pathed map won't really work.

Plain maps using stock things and similar ones can be successfully pathed for aerial support in U227 without borks...

Previous map which I called CTF-RB_SpaceStation][FIX][_FL.unr was build properly - I don't get why this one was good and the other one went utter trash with regard to aerial navigation.

[evilgrins]

Jets as in planes or jets as in jet-packs?

[Nelsona]

Jets means here those "Weapons" aka planes aka whatever "aerial" movement which... it's not pawn's native feature - unless you have some smarty ones...

Okay people RX "brainzors", We do have right now 2 maps with aerial support only. No AlternatePath so far because that is not a number 1 priority here, priority is to see Bot doing something like RX CTF in first stage. Maps are reduced in size as much as possible - Every single UE1 based Editor is adding InventorySpots at items in void - without pathing data - but having NO SINGLE purpose - including Gold U227. I did not do a super duper Tags cleaning but other data without any use Like OldLocation NoReachPathsX and so on, are removed or defaulted to zero, reducing map with other bytes (my habits).

We do have full aerial navigation out of XC_Engine or with XC_Engine.

CTF-Chronic_Zen-v2020.7z

(2.36 MiB) Downloaded 432 times

- Base "glass" Movers replaced with a single SemiSolid Brush.

CTF-RB_SpaceStation][FIX][_FL.7z

(1.63 MiB) Downloaded 416 times

- having Movers "glass".

TESTING NOTES:
Ground pawn which doesn't fly in any way won't see the route to enemy Base - we have reachSpecs linking Bases with R_Fly flag - no kidding, no joking, I warn you.
Tester can figure this by placing a RememberSpot in other base and sending command ShowPath from his base - my CTFGame has capability to setup this spot directly to a flag location: Enemy or Friendly Flag, and then, testing maps goes easier.
To do for finding paths:
Console Commands:
set playerpawn bCanFly 1 - adding new capability for Engine's paths processing.
fly - if you don't fly you can only see paths but you need this Physics for getting into target point, else Engine won't help you because you need to reach at point using physics required in reachFlags. It's crazy to find that EPIC did this aerial navigation capability but NOTHING for adding these flags in maps - plonkers - you did a monster flier but no paths for it even if that jackass is able to deal with an AlarmPoint placed where mapper wants...
If you are using normal physics and a translocator Engine will return you to the previous ground node attempting to give you a retry - R_Fly needs "PHYS_Flying" as a MUST, NOT OPTIONAL.

If these A.I. navigation codes/features are properly added - later we might discuss about AlternatePaths and other stuff - but for now I want to see Bots taking Enemy Flag as Stage 1. And... I think I can set later 100-200 aerial maps in certain time interval.

And now I'm wondering if I can drop a MyLevel actor capable to remap navigation network without useless InventorySpots - those previously in void - because I believe they can even be deleted as not being in any navigation reference but in "Navigationpointlist" from Level. Compiling with constants for me it's not a barrier so I might want to minimize as much as possible CPU processing for DevPath. DevPath is processing routes based on NavigationPointList as first thing so if the size of this array is smaller, Engine's processing cycles are reduced and we can gain a faster execution speed. I remapped this array in patch files which I Previously did for NavAdder - exactly, that "paranoia" worked for real disregarding what others were saying and demonstrating their lack of knowledge about DevPath - no names needed here, they demonstrated their "skillz" in what they did.

Good... And now there is my first Lab test Map for R_Fly flags - other "paranoia" working for real - paths done in U227 in that time. See this if map posted was inconclusive.

MH_NativeFly_Test.mp4

(11.59 MiB) Downloaded 412 times

Here plain default CaveManta monster demonstrated that can find human enemy using this navigation network unavailable for plain Bot which won't fly in normal instances.

[Nelsona]

All right, I don't even know if these RX things regarding to A.I. navigation will ever come into reality, perhaps people are not understanding AT ALL what is about with these air paths because NO MAP HAS them in UT even if Engine can deal with these - but they are doable using U227 and/or XC_EditorAdds. I see Diego talking about testing. I cannot test any VOID. Those are blind PathNodes without data - just loaded without purpose.
However, a bit later, after work I'll write a little document and releasing something which UT don't have - a more like lab tool - a CTFFlagTracker mutator capable to work with Paths Network for human player as Bot does - no AlternatePath support is being implemented yet, it is for orientation, map debugging. Like other similar toys which I did it uses command mutate mebot. Route Beacons are spawned if player can use paths for navigating to enemy base and BACK if has enemy flag. It stays latent if paths are not found and it goes active if paths are navigable or they have been found.
Mutator is a generic paths finder so it will work with these aerial paths as well if player uses required console commands. Today I used it a bit and I got a full confirmation in what I was talking before. You can see paths if you can move to a nearby node. Really pathed Aerial maps are guiding you if you have movement properties. I hope this one will be helpful in a better understanding of these devs.
I'll be back later...

[Nelsona]

Here are two tools that can be used in maps which I modified with flying paths.

Fly_Test_Muts.PNG (13 KiB) Viewed 9946 times

First one works in other CTF maps with paths as well. It responds at command mutate mebot. Can be used only this one for testing map without Bots and using Fly + bCanFly 1 for player.
By using it with The Second one you won't need extra commands but you can see paths with mutate command above. This Second mutator will debate Bot physics making them to move in said aerial maps - see what they do with/without mutator. If translocator is messing up with them, you can disable it from menu - we fly anyway.

PathsTestTools.7z

(15.75 KiB) Downloaded 393 times

These being mutators will go to System Folder and you can have access at them from menu. In two above maps, paths being simple without game crushers they won't hurt anything. XC_Engine it's not needed.

PS: Apology for sharing two tools because I was talking about one tool...
The third tool NOT POSTED it's a mutator mapping aerial paths for VisNoReachPaths[x] internals - it requires XC_Engine so that it's not under discussion here, it is addressing plain paths mapping without air connections mutator adding new reachSpecs in run-time.

[Nelsona]

Bumping with notes toward aerial notes - no wories, ZERO tutorials have explanations here because 20 Years UT never used its own features...

Warning - these are without XC_Engine support in game play - not in editing map.
ActorReachable is more powerful for a fly unit compared with a ground unit - it's engine not me - confirmed with CTFFlagTracker mutator.
Whatever higher located actor not reachable for a ground pawn might be a navigation goal for flier pawn - human included.

Consequences:
Because ActorReachable it's... more reachable from air, paths processing is also accelerated as in bHunting case. A fly unit actually has mainly the same search capability as Bot does in XC_MonsterHunt and it might be even stronger. Technically if you fly you can have more freedom to move - it's logic and engine do seems to have this logic.

Rules for being engaged into aerial Paths-Net.
Movement for start can be as a ground unit with bool bCanFly=True. When Next Node it's in a HIGH Spot you need to change physics accordingly. If you have other physics, engine might return you back to the previous ground node in a "perfect" LOOP.

Next things to do: Doing more testing for figuring if some less logic bug is left in engine toward flying and paths seeking because this chapter is pretty much new for UT - probably not for U227 whatever...

Mod hint.
If you check well CTFFlagTracker mutator, it has two pieces: Server-Side and Client-Side. And here it comes discussion for protecting mods against stealing - DO NOT SEND AT PLAYER WHAT PLAYER DOESN'T NEED. Audio-Visuals and guiding stuff can be package, the rest of A.I. stuff should not go in client, I don't see any single reason for that, just SPLIT mod in two as should, and forget Suppressing errors - they have to be fixed not masked.