Botpathing request thread

Tutorials and discussions about Mapping - Introduce your own ones!
a9902957@nepwk.com
Novice
Posts: 22
Joined: Thu Nov 03, 2011 5:12 am

Re: Botpathing request thread

Post by a9902957@nepwk.com » Fri Sep 03, 2021 6:43 pm

Awesome! Kind of speechless you did most of LostValley by hand (placing like each node manually?) and yet got it fully pathed so quickly.
Only thing I noticed so far was on LostValley they have troubles with the lift which has a chain at the center (a green to yellow portal is close by at the top).
These definitely give me more reason to try to improve the FerBotz plugin for BRUT further.
Nothing like the last bot pulling a telefrag kill on you and then taunting you with "Too easy!" ^_^

EDIT: Damn it is hard if you are not Steve Polge, Higor or you Sektor. ;)
Heh, look what is says here: https://wiki.beyondunreal.com/Legacy:Na ... Point_(UT)
"NavigationPoint VisNoReachPaths[16]
Paths that are visible but not directly reachable."
Sounds like such an edge case like with the stairs might also get handled with that array property.

I am having a hard time figuring out how to check if a certain destination will have a FerBotz (version 20 native or now more so 18 UScript) take a path(detour) through Pathnodes that I consider (and could identify) as "bad". It seems I would have to do the whole path finding and moving-along on it myself when I want to check for this before "sending" the bots there in some way.
And I fear that will cost me most of what the Botz code offers quite fast if I would not tread very carefully and slowly. Seems like a big herculean task when one would hope for an easy way to do it instead.
The native variant might have ConnectedDests iterator function which might serve for this purpose but even if, then that would mean dropping support for v469b.

User avatar
sektor2111
Godlike
Posts: 5513
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Botpathing request thread

Post by sektor2111 » Fri Sep 03, 2021 11:15 pm

The short story is: Always nodes must be placed manually. What Editor does with Paths Build command is a full mess. That thing works against their own rules being capable to deploy two PathNodes in the same place out of reasons.
What is the problem in overcrowding nodes ?
Well, my deduction is that Dev is testing traceable nodes each-other and add ReachSpecs. You can imagine combinations number in 1000 UU range. When testing movement reports positive results ReachSpec is updated with Start and End. A random node X might be pointed as Start or End in let's say 43 ReachSpecs. Internal lists are using only 16 - enough because the shortest route is taken. Dev does a large amount of paths which have no place. Image of paths-lines in Editor lies reality from game but... there can be somehow usable paths if Dev won't fail in some instance.
Bots are a bit more aggressive when map has more nodes but this is against limitations and will trigger more processing. In this case another builder having a configurable range will cause a less load but enough connections. Also limiting paths lists will allow future run-time adds (if some dude wants more links). The rest is how PointReachable responds in Editor.
XC_PathsBuilder works based on iterators from XC_Engine but I have added certain things for preventing overcharging nodes out of their hosting capacity.
Stages:
1 - Adding InventorySpots excepting Items hidden in Editor (by Group or by hand).
2 - Scanning bunches of items and deciding a Master of this bunch which will be candidate for external connections - bunch area is configurable.
3 - Generating NavigationPointList hosted in LevelInfo based on "Foreach AllActors".
4 - Mapping paths through bunches considering Masters as priority - Ordering Items will generate more combinations for the same items placement;
5 - Paths starts to be mapped in order of "foreach AllActors" aka NavigationPointList - testing Bot size which has the last word in painting a path or not. If Bot is compatible next tests are concerning Big Size pawns. If a bigger one returns PointReachable ReachSpec data will be set accordingly. This way future Path will be compatible with all sort of creatures. Maximum size is 115 × 110 (Titan more exactly).
6 - If paths Lists are reaching to configured value Builder will deal with next Node.
7 - Task is closed reporting total ReachSpecs/Paths created.
Builder won't mess with WarpZones or bOneWayPath and bHiddenEd nodes - my decision. Facility with bHiddenEd will help another way. By toggling groups visible or hidden builder can do some separate paths in the same room without combining them allowing paths to be build in multiple steps and unlocking more options.

Whatever is not connected it can be done later post-pathing. Also an auto-connector for simple areas will do extra-links calculating itself the path-size recommended for that spot. A Path can be also moved elsewhere if it does damage in current location and anything else must be connected elsewhere. Paths are getting screwed this way, but we do have a fix function and/or ReachSpecs defragmenting. This way Paths are remapped according to ReachSpec data. Builder won't mess with Prunedpaths - invisible, and VisNoReachPaths for me are not aiming a ground pawn so that data for me makes no sense in CTF matches. They are only extra-bytes without purpose like Tags used by Brushes - nothing is triggering a Brush if it's not a Mover, tagging brushes is useless like tags added for actors which won't respond at Events.

In this DM map I went to use nodes at 400 500 UU distances. That limited ScanRange will not process anything out of this distance and connections are simple and fewer even if this way map has more nodes. Lift is supporting LiftCenter to be adjusted a bit post-pathing if current location is not what Bot wants.
Pathing Process took a few seconds and... I added a few paths in next minutes - for Invisibility. New Nodes are thrown in Navigation Chain using MapGarbage. All Nodes concerning navigation it is advisable to be in chain.

I would like to have these toys for Editor a few years ago...

How to check Pawn's route ? - Idea for a future mutator is something like my testing mutators for MH and CTF but having RouteCache points visible/marked for everyone. Pawn roaming will have shown next nodes and tester can see where pawn wants to go. You might even see in a 1on1 DM if Bot is hunting you.

User avatar
TankBeef
Adept
Posts: 290
Joined: Tue Apr 13, 2021 12:56 am

Re: Botpathing request thread

Post by TankBeef » Sat Sep 04, 2021 2:29 am

Whoa!!! What a great map that Lost Valley!!! :rock: Feels epic. Thanks for suggesting and pathing that one. :tu:

User avatar
JimmyCognitti
Skilled
Posts: 176
Joined: Sat Mar 29, 2014 11:48 pm

Re: Botpathing request thread

Post by JimmyCognitti » Sat Sep 04, 2021 7:05 am

Sorry for being an annoyance, but where do I find the files required to play "DM-RealCity" and "DM-DoCdOoM_LosT-VaLLeY" (.UTX, .UMX, etc...)?
Image

User avatar
sektor2111
Godlike
Posts: 5513
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Botpathing request thread

Post by sektor2111 » Sat Sep 04, 2021 8:17 am

At UnrealArchive where I downloaded maps - links are added into requesting post.

Resuming:
"Azcanize v2" map I think it's ready. "Jumpers" of type teleporter will have a protection against "fixing" Teleporters by TeleporterFix..whatever. If that thing is messing mindless with any Teleporter then it's time to deal with these and trashing them out.
Let's read the stage:

Code: Select all

ScriptLog: Add mutator TeleporterFix103.TeleporterFix
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink0...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink1...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink2...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink3...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink4...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink5...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink6...
ScriptLog: Fixing teleporter CTF-Azcanize_2_rS688.MyLink7...
And after a few seconds, "MyLink" which is having enough patience, will attack any nearby intruder :lol2:

Code: Select all

MyLink: MyLink0: Tracking Initialized...
WCFlush: MyLink0 - Disabling nearby trash.
MyLink: MyLink1: Tracking Initialized...
WCFlush: MyLink1 - Disabling nearby trash.
MyLink: MyLink2: Tracking Initialized...
WCFlush: MyLink2 - Disabling nearby trash.
MyLink: MyLink3: Tracking Initialized...
WCFlush: MyLink3 - Disabling nearby trash.
MyLink: MyLink4: Tracking Initialized...
WCFlush: MyLink4 - Disabling nearby trash.
MyLink: MyLink5: Tracking Initialized...
WCFlush: MyLink5 - Disabling nearby trash.
MyLink: MyLink6: Tracking Initialized...
WCFlush: MyLink6 - Disabling nearby trash.
MyLink: MyLink7: Tracking Initialized...
WCFlush: MyLink7 - Disabling nearby trash.
Anything added out of paths and out of NavigationPointList will be deactivated and scheduled for removal.

Automatically merged

Let me know if anything else is needed...
CTF-Azcanize_2_rS740.7z
Extra-Notes:
Map seems to run perfectly with plain D3D render and all things are going normally.
It's a good work here, when mapper is not trying to reinvent the warm water the result it's always High Quality. RESPECT for mappers team !
If you don't like how Bot Support does work here feel free to improve it.
You do not have the required permissions to view the files attached to this post.

User avatar
TankBeef
Adept
Posts: 290
Joined: Tue Apr 13, 2021 12:56 am

Re: Botpathing request thread

Post by TankBeef » Sat Sep 04, 2021 12:27 pm

Wonderful, better than expected!!! Thanks a lot, Sektor. :gj:
sektor2111 wrote:
Sat Sep 04, 2021 12:08 pm
Let me know if anything else is needed...
So far so good. :tu: Don't know what others think, but it more than works for me. Bots are doing great. 8)

User avatar
sektor2111
Godlike
Posts: 5513
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Botpathing request thread

Post by sektor2111 » Sun Sep 05, 2021 12:38 am

Until next one will show up I'll get busy with a few add-ons before releasing some toys - perhaps with a few features not done yet for UT Editor or... UnReleased.
What is about is described here:
https://hofgamingclan.com/forums/viewto ... 4377#p4376
Also there are a few small adds and code changes for XC_PathsWorker which will help me with these pathing requests. Probably someone else will want to try my toys as well so I'm not going to keep anything hidden.

User avatar
sektor2111
Godlike
Posts: 5513
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Botpathing request thread

Post by sektor2111 » Mon Sep 06, 2021 5:30 pm

In mean-time, for those getting used to play MonsterHunt in "soft" mode - not rushing in maps, here is a sample with Bot Support according to what MonsterHunt help file is saying, with MonsterWayPoint actors. Smarter MH versions won't break "attacking" like original does when they are touched in other order than required. Paths are helpful in coverage if attack goes rammed. It's simplified, and has... 399 ReachSpecs, not 3459.
You can open it in Editor and look at things in "RealTime Preview" ViewPort setup.
MH-AMC-Diminutive_3_rS399.7z
All map has Hand-Made paths, nothing automated.
You do not have the required permissions to view the files attached to this post.

User avatar
sektor2111
Godlike
Posts: 5513
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Botpathing request thread

Post by sektor2111 » Sat Sep 11, 2021 6:30 pm

Okay...
Entitled AwesomeMappingContest-MorpheusUnbounded converted to MonsterHunt but.. Eh... plain MonsterHunt has its problems it was touched a bit because...

Code: Select all

Total ReachSpecs found = 17543
VisNoReachPaths = 17583 - useless data
4135 actors having OldLocation vector saved.
2973 navigation debris variables
748 actors with bad zoning data
...
LostData: ReachSpecs missing from PrunedPaths[0-15] 	= 223.
FixedWithSuccess: ReachSpecs successfully attached 	= 0.
FixFailures: ReachSpecs attaching failures - probably no place = 223.
1153 NavigationPoints
probably this is not a very entertaining map for original MH users developing errors and having messed up RazorJack replacement plus monsters slaughtering each-other and ruining the fun for hunting them.

In time MonsterHunt was improved and... not everywhere... Due to these factors we do have:
#1 Map for MonsterHunt controllers without flaws a la RazorJack and so on:
MH-AMC-MorpheusUnbounded_rS806.7z
Where nothing is needed as a fix.

#2 Map for original MonsterHunt which has some problematic behavior and maps are getting screwed up. Probably this one will get over these in a different way.
MH-AMC-MorpheusUnbounded_rS806_sa.7z
One single actor adjusted will manage to setup initial charge for weapons (ANY) as it was done by Buggie which in UT436 and MonsterHunt was not seen at all.
Null replacements done by integrated MonsterBase mutator from MonsterHunt will get solved.
Spirits are not slaughtering each-other in seconds being more interested in combat.
MonsterWaypoints are present as MH objectives and HuntNodes will discard Bot rushing map like with hair burning.
This if it's played Off-Line waiting around 2-3 seconds before to start map, you'll have monsters set normally, SkaarjOfficer types armed, and all of them might held their weapon normally.

In these two maps paths are the same, we have 562 NavigationPoints with 806 ReachSpecs in Lists and no lost debris ReachSpecs. Teleporters savers are reduced because 454 Teleporters don't make any sense... seriously... :?
Other extra UT stuff has been removed as long as I could see HUD issues in a normal client game.
If you don't like them you can remove them and convert said map as you like.
You do not have the required permissions to view the files attached to this post.