House of Fools

Preparing future needs - I forgot them but they have to be solved.
DevPath depending on people's opinion might have funny bugs or... for A.I. lovers might be really dumb, a not very salty joke.

Teleporter in UT has an incomplete code and it's not like DevPath takes this in account. Teleporter disabled heads pawn through this route until pawn is closer. Next move is stopping it by routing MoveTarget to None because it's disabled. If Pawn needs to move more behind Teleporter this is a Blocker. If Teleporter is active but is only a Source and not a Destination in the same time, it will Teleport or throw Pawn (swJumpad) into destination even if Pawn wants other things. I can create scenario for completing understanding but I think it's a waste of time only for demonstrating clearly what I'm trying to explain. In a recent pathing work I did paths manually but it's not like automated script should not be more smart. If plain DevPath is messing up the stage probably my clumsy builder will have another deal.

XC_PathsWorker it looks like has Teleporters problem solved but I think Editing a path is doable easier without tracking an Index of Path needed to be modified. In order to make things more easy and fast there it will be another bAutoMoveCDtoAB option capable for simple routing a ReachSpec. We don't need a Path from PathNode0 to PathNode12, we want a Path from PathNode0 to PathNode8. All we need is to complete Nodes names as C and D as original Path and writing new Names for future path as A and B. Of course if anything else needs to be corrected, ReachSpec Index which was moved is printed in log and then any future touch for this path is doable later (changing moving flags). When capturing nodes names is done automatically, Node A and B as Target nodes are captured too in TempReachSpec for making things more handy.
By activating required option and pressing build button, ReachSpec is moved and Nodes Lists updated - if nodes are not overcrowded or else ReachSpec is edited but not used. This movement of a Path will copy Collision data and moving flags automatically so it's advisable to have future moved path in a similar place format but in another spot where path is usable. This way is easy to get rid of a path that we don't need, by making it useful elsewhere.
At end of the task, an inspection concerning a fix option or reachSpecs defragmenting doesn't hurt.

Self messaging: Nelsona, I think you have all the necessary endowment to work on navigation paths and execute them correctly to be processed without errors from UE1 and not loading bytes without use only to ensure that navigation is usable by A.I.

After wrapping a bit variables from interface for a better handling I've recorded a small sequence about how does it happen paths moving task. HealthVial more far from PathNode has been disconnected - both paths have been relocated between PathNode and the closest HealthVial. There is no need to know Spec data and complex things unless we want another sort of modifications...

First post has been updated with XC_PathsWorker for October having small adds and a few code changes.
Adds:
- Moving paths from a node C to D into A to B - even if one of them is the same it will route ReachSpec to new paths list and deleting it from old place;
- Teleporters which are Source-Only won't have outgoing connections - if some of these are needed they can be Auto-Connected later on demand;
- Double working mode, using first a half of required range and full range if Node's paths list load is not reached yet - attempting to connect with priority closer nodes and far away ones later if are needed. This is a work around for what it does original RadiusActors used for probing nodes in required ScanRange.

For next Month (or this Month) I will add something for advanced mapping. Chapter is concerning custom Warp-Zones or plain warps if are used and... here is needed a completion, what WarpZoneMarker needs to be used because original one might crash game during testing stage. A new Marker in MyLevel will allow user to deploy markers in spot (where WarpZoneInfo is located) and mapping plain paths, then launching option for connecting WarpZones post-pathing - purpose is to have them in navigation chain. I don't think I'm interested too much about this chapter but... let it be usable if some day rules are going to get changed...

For MapGarbage I've added an option to solve TranslatorEvent "stuff", never seen in plain MonsterHunt into a common trigger and "SpecialEvent" (probably I'll do it more simple in future), I'm currently thinking if I have failed/forgot anything important, code for checking "collisions" is changed - credit goes again at dumb mapping - monster specific fixes are changed (something is removed as it doesn't really work as I wanted). Maybe an update is expected this month or next month for this builder aka UT Editor plugin aiming those interested about solving more map editing/fixing problems in less time wasted.

First Post has been updated with XC_PathsWorker version November 2021.
Here is about creating Paths through WarpZones but having the option for a custom WarpZoneMarker - a navigation actor responsible for making A.I. to crawl through Warp Zones. If original stock one might do some damage, here we can use any other sub-class loaded in Map as WarpZoneMarker. Original stock actor is not shown in Editor (exactly like InventorySpot) but it is added by plain DevPath automatically without any option and it has questioning codes right from factory but no options for being replaced...
Pathing method in maps with Warp Zones is doable in three stages:
#1 Adding our own WarpZoneMarkers or plain stock one;
#2 Mapping paths as usual using builder;
#3 Creating paths concerning Warps post-pathing with builder. We have to do this as final stage in order to have navigation chain already linked and not adding warps later connected without to be mapped in chain.

Builder will add WarpZoneMarkers defined type nearby WarpZoneInfo actors and these need to be properly linked with their strings, so it is advisable to have these placed normally on the ground and not on the walls or ceilings. Such actors are defaulted to be visible for having a clue about their locations and if they could be added in spot.

MapGarbage for November 2021 has been added in first post.
Changes and Adds:
- code for checking monsters is changed
- code for scaled collisions is changed - all Pawns screwed up are reverted (using this before adding customized FortStandards);
- added option for cleaning Tag from brushes - nothing/nobody needs that;
- mapping TranslatorEvent for "converted" MH maps as Trigger and SpecialEvent stuff for being readable in plain MH games where F2 key-hint is a myth.

Movement Bump:
One of maps which I checked last time had some errors in paths being a crusher. The thing is that XC_PathsWorker and MapGarbage can be used for fixing problem without to rebuild anything. Of course, bugged paths needed some detailed report - which will be available soon. Also I touched a bit interface... Sooner or later I will need to setup a separate thread as a sort of tutorial about this tool and what is capable to do and to not do. Probably several dudes will have curiosity for making something special and paths handling in UT's Editor at this moment is hard to manage with plain stock Scripting solutions - which are not fully logic in all cases.
This tool is capable to help in debugging paths concerning Coop SinglePlayer maps where some creatures will need to perform actions (patrols, alarms, retreats, etc). When a creature doesn't do what has to do we can have data about stage due to detailed paths report. Subject cannot be explained in 3 sentences, it needs images and explanations about methods.

Bump: Other December plans for XC_PathsWorker
- LiftCombos I think they will have all Maximum Specs Size because are "Special" and even if a lift is small, brainless big ones won't use them due to flags declaration, either way they can support editing after all;
- Small code changes - won't be welcomed in XCv21 which has borked things anyway making some of functions useless...
The changes went different - if old code has build 554 specs with an average of 3.97 seconds, the new code has build 554 specs with an average of 3.93 seconds. Of course it depends on ViewPort settings - how much render works during building process - more work with lights returns slower speed in processing because here are involved screen updates.
- Solved a small error - it was about logging stuff, nothing critical - but I hate errors...