House of Fools

PathsLinker has been updated. A few notes:
- hovering mouse over builder's button will show name and version (month - year);
- all tweaking requiring a recount of reachSpecs in navigation Network are taking in account PrunedPaths (generated by original Devs, not generated by XCGEv24);
- icon is also changed for showing version.
Usage and working with such a builder needs a bit of experience with paths and not experience in "guess-mapping". Here we do not do navigation assumptions, we are deleting evil or useless data creating what we want and how we want remaining to study what Bot does when our paths are recommending something which Editor won't do with automated scripts. At questions if this is working or not, there are a few maps posted around forum having a suffix "rSxxx" in which xxx is a number showing the number of reachSpecs which map has and all of them mapped inside navigation network. Some of these links have been created by this Builder and not by Editor and of course re-linking NavigationPointlist. Any doubt can be checked by rebuilding Paths in these maps and compare what edited map had VS what Editor does.

Edit: The Point to know
If we work on a network which was created in years 2000+ using Plain UT Editor, there are some data which won't match other internal links added - increasing paths processing cycles... These bytes/variables are: visitedWeight, nextOrdered, previousPath, prevOrdered. They can be removed with MapGarbage using option bRemoveNoReachPaths from builder's menu. By removing these extra-bytes, some routines processing internal paths list won't take place and then certain old Unreal maps are not having these and they work without problems. Actually we don't need any other load because if we are doing changes, technically we need to remap these as Editor is doing which means extra-processing without actually to be a must have for map's run-time stage. UT is having a few add-ons at these devs but... logs are demonstrating that are just NOT READY and not far from a BETA stage poorly tested and rushed, and then, we can get rid of them. If we are getting rid even of OldLocation data hosted in actors, map file goes a bit smaller as a direct result of deleting these spam bytes.
You can do all time an experiment in a stock map saving a copy with extension "_test" and compare these map files - you will get evidence about what I'm trying to say.

Next things which are done so far for Next MapGarbage update:
- bHlpAddActor - is helpful for adding something nearby other thing, eg: Kicker at a Teleporter, A SpecialEvent at a Trigger, a PathsToggler over a PathNode, A TouchSwitcher over a MonsterWaypoint, etc. using a defined height because new actor will use the same X Y coordinates. I used this for adding easily extra navigation triggers needed in some radius for not wasting time with "pixel-ing" locations because I'm quickly getting tired to setup details which can be easily automated with just.. a perfect alignment during a few seconds...
- bAddInvSpot - means that a selected Inventory will have (with the same optional height definition) an InventorySpot connected - custom classes can be used here. Of course, new navigationpoint has to be linked and reachSpecs added (using PathsLinker) if we want it as a navigation goal for Bots else adding it it's useless.

Perhaps I have to try to setup a Blocking Spot detector if Engine iterations will allow some stunts.
What is the deal ? Scanning all Paths from map if exist certain nodes having only 4 reachSpecs 2 In-Out from a node A and 2 In-Out from another Node B these being intermediate ones and logging these names. Purpose ? Such PathNodes can be special ones delegated with Locking/Unlocking some routes and being recommended in case of such needs or... for adding a triggered PathToggler over the Node as long as there are no shortcuts over it causing Blocker to not work as intended and such node can be made more smarter. To clarify what kind of Nodes I'm talking about I'll show you some picture: This spotted PathNode can be delegated with a flexible ExtraCost using an external nearby Actor in range. Node will Block Ramp or unblock this ramp making A.I. to follow various other paths. If map is a bit complex we need to examine a lot of places for figuring which node is suitable for a dynamic operation. In that such case Builder will print a list with PathNodes that can be blockers.
That's in theory, practically we have to iterate around and testing possible closer connections passing over this node even if node has the only two required neighbors. If other paths are a shortcut over this Node, blocking it makes no sense - perhaps this detection works more accurate using human EYES...

Next stage:
Capability to add common stuff useful in mapping but... for being added MyLevel. Builder might generate a Script for Blockers or for certain decorations which are static but we don't need them static because they mess up clients in servers, ect...
By example we can copy HuntNode directly from log into Scripting Window and compiling it: We don't need to search for scripts and maps having this Actor, we can have it on demand, like other simple things for MyLevel.

Bumping with another little tech for Nelsona.
As I could figure so far, in plain pathed maps or XC pathed maps all NavigationPoints are connected in chain. This chain has a last Navigation Point as tail.
Nelsona: Yeah, so what ?
Me: So What ?... THIS tail which I studied a bit doesn't use an ExtraCost value, it can be a common thing: PathNode, Playerstart ect but this will have a Cost, not a cost like ExtraCost in BlockedPath actors but... a Cost of a million = 1,000,000. I think this way DevPath is informed that Navigation chain ends here helping it to stop processing in that moment as long as there is not a need to continue in any way. I'm not sure if this is a must be but I could see it done like that by pathing devs.
Nelsona: Ooops. I think if last point is moved because of a future chain completion, then old point stays with that Cost and there can be created a hard route.
Me: Well... Disconnecting chain should reset that last point, and reconnecting chain should have the last one with Cost=1,000,000. LOL
Nelsona: Good... MapGarbage will be rewritten for a full reset of all navigation actors when are disconnected, and the last in the reconnected chain will be adjusted to Cost=1,000,000 as automated devs are doing. So far in old versions of MapGarbage this can be modified manually as long as chain checker explains which actor is the last one. Not a big problem, but if it's done automatically we can avoid wasting time.

RULE: ALL time last navigation point in chained list will have Cost=1,000,000 - not my rule... This is a good to know if we are adjusting/tweaking manually paths into a map.
See this: Even stock map DM-Deck16][ has this Cost and also it doesn't look filled with some of those Extra-Bytes used later... And then... cleaning them doesn't hurt.
Lesson for Nelsona ends for now...

BumpTimer
Because we were reading about Triggers as helpers for pawns where they might have jumping issues, we can use Jumper class. A problem comes because this is limited at Monsters aka ScriptedPawn and it doesn't have anything with Bot, and this needs oriented in jumping direction.

What is doable for Bot ?
A bit of modifications but... not taking actor in account about rotation as Jumper does. Actor for Bots can be called Bot_Jumper and it's a subclass of Triggers a bit educated for Bot according to a very needed jump. Script can be used in MyLevel even without scripting anything because in next version we will have the script generated in log, ready for COPY-PASTE and compile new sub-class of Triggers.
There is a small tiny problem here. Script is longer and overrides logging boundaries. As result Script is split in two having an innocent Label as a border. It will compile with or without Border-Label, simple is the best - Border-label can be deleted from Scripting Window. This way we can have permanent scripts available on demand if some situation needs extra-tweaking (those angled walls buggers). Bot touching this trigger will react in next 50-80 milliseconds with a configured jumpZ value. Default 325 might not help in all game situations, it might need a bit more for cloning human's jump.
Why delay ? We allow Bot to call PickDestination for next Path. Trigger can be used immediately after current Path, right before jumping target point.
Can we see an usage sample ? Yes ! It won't take in account Pawns already jumping or flying - they should not get screwed. If you have extra bytes to add in Script feel free to add them as you want.

I added also PathSwitcher script generator reacting as a BlockedPath but it can be locked too, or toggled like the one in the map sampled in the back posting.

The known Cave:
No Script will be compiled if Editor has loaded original MonsterHunt package or similar ones altered against compiling. You need to compile and adding these actors BEFORE using any altered packages.

Another MapGarbage extra-note: Un-Linking and Re-Linking Navigation Network will take in account last Node in chain for having that 1,000,000 cost. Old node from previous network will be back to 0 - or I think I'll return it at default class Cost, and if a new node will be the last, it goes to said increased Cost. It will happen in next update.

Bump During Working stage
MapGarbage which will have another update for helping the work in Editor, it has small changes and adds:
- Level Validate - zero and fake command, known as bLevelValidateMap option will check TrapSpringers if they exist and the bad setup making them to get vanished in run-time - the rest of Tags must be done properly because MapGarbage doesn't have human eyes, next extra-check will report if map has "DistanceLightning" actor which in network games is a flickering junk and not a real Lightning clone. This can be replaced and is easy to find such useless and bad actors in a blink during a general Level check;
- An Importer available.

What does it do Importer function ?
We are intended to write some command (which I forget myself if I'm not using it intensive) for importing a package dedicated to MyLevel.
What will be the deal here ?
We are setting up a bool value bLoadAMyLevel to True, we are writing package name and extension (u utx umx ...) and then we press build button. In next seconds if we are inspecting assets in browsers (clicking on ToggleDockStatus is recommended for refreshing GUI and loads), we can find a MyLevel ready to use. No stories written, nothing specified, just the name, the bool value and build button does the importing command for you, very useful for multiple packages dedicated to MyLevel.
Requesting package at builder: And then after refreshing browsers we have MyLevel... Why these options here ? Because in these private packages we can host smarter Navigation Points and all sort of things needed for a more or less special map.

Added another helper in detecting bugs with regard to Navigation points.
If we are talking about a CTF map full filled with Paths but not having too much Bot activity with Flags, this might be due missing paths heading to one of FlagBases or both FlagBases are messed up. Even in middle of a route such a Node breaks entire road if there are no other alternatives. Such a Node usually doesn't make any sense. Of course, a SpawnPoint in MonsterHunt might have such configuration, here is not always a problem but it might be (no map-name this time) if node is inteded for navigation to a goal - those placed in air for various creatures, they are still hosting a path moving pawn away but are not having any incoming path. A PlayerStart isolated in a spot might be like this, but isn't good when this node has a roaming purpose.
In CTF games such a node should never be listed as a FlagBase - this is showing a borked CTF map due to FlagBase placement.
Instead of checking manually nodes in heavy loaded maps, we are using builder and focusing only on logged nodes. We don't need always details about reachSpecs, we might want to know if a FlagBase has availability or not from DevPath, or an Important PathNode on the way is not a break point.
Option will be called bCheckNoPasses in builder menu.
If this node has such missing things, we can figure that UpstreamPaths[x] array has only elements -1 - default ones. If we want to see these properties and we don't have an XC_EditorAdds builder loaded we can use MapGarbage starting from next update with option bAdvActorEdit Set to True with our checked Actor selected. With this option we have access to Advanced Actor Editing and we can see things which usually are not seen by inspecting plain default properties.

I'll think if I need more extra help easily to be added in Editor and making this poor UT Editor not only to build maps but even for helping in checking them.

Edit: Scripting Considerations
So far I could even create new classes in Editor which can be found when browsers are getting a refresh but I don't have any clue yet how to open scripting window automatically and neither to execute a script-copy in there. I think I'll allow user to create MyLevel even if this can be done using almighty commands:
CLASS NEW PARENT=Engine.Triggers PACKAGE=MyLevel NAME=Bot_Jumper
I don't know how many are commands that can be automated and how much is C++ with mouse and keyboard, lol.
I would like to create these automatically but... I think solution is mixing user's action with Editor.Log.

Back to the subject manual paths handling
PathsLinker will have for creating a reachSpec the user option for distance even in cases of Combos, Teleporters, Warps. If value is zero, default is taken, if user says another one, it will be mapped. Also a small bug with regard to N1 N2 variables in some combo case has been fixed. It wasn't anything critical but... I don't accept any wrong thing here.
PathsLinker August 2020
MapGarbage also was touched today. It will have an option for Movers. If whatever map is badly messed up and Movers are plain default ones, if we want them pathed, there is not a need for more creativity regarding to tag used, MapGarbage will generate a Tag for all Movers having nothing, or those with default tag applied by Editor. After that, each of these names can be copied easily in their future combos as LiftTag value. Credits for idea ? Some lousy map having only a guess-work, the genius used PathNodes on every single mover - useless. They don't even bother to search for tutorials - and this is the road to a guaranteed failure.
MapGarbage August 2020 Version has explanations about all adds and old features.

Bump Time
I've been looking at old features which I wrote in this builder, like the feature designed for doing a basic fix at paths.
It's about not following Epic rules by Epic themselves when Polge recommended Not adding PathNodes nearby inventories and other paths and keeping a minimum 50 UU distance between Nodes (any).
Technically builder was testing PathNodes placed around other sort of Nodes (any) in a radius of 61 UU - hardcoded.
I think this testing/fixing feature can be a little bit smarter but this won't be recommended for being used in maps with paths worked/created manually because it will rebuild them and... ruining all modifications. I suppose maps with bad spots are similar to stock and nothing executed manually when this feature is being used.

What is changed in terms of flexibility. That "small" range is configurable, we can test nodes in a desired radius, not 61, maybe 70, 50, or such distance bugger.
Also in this range is done a FastTrace check in order to not remove nodes which are needed so close - I doubt about such needs because PathNode needs a bit of experience for mapping paths with them in narrow spots. And next test for closer Nodes is checking links. If node closer to others also has more than 6 reachspecs which means it's connected to and from 3 directions perhaps these connections vs presence around other nodes it's a nonsense and node is removed. As you have guessed, removing node from network will return a new paths building task. It's why manual tweaks are entirely gone for good. As result this feature is one of primary checks BEFORE working at paths manually, if anybody is doing this...
Sample: When I was tracking Nodes closer to others at 60 range in DM-Deck16][, 23 PathNodes have been deleted and map was working flawless. In similar maps or other with an insane charge, it might be welcomed another range check - 100-110 or even more. Reconstructing all network is more time consuming than deleting a few of them and rebuilding paths for a basic examination. Final build can be done as last editing move in a cleaned map.

Future version will have this modification and perhaps I will adjust other features as well...

Okay, A Hint with regard to builders used in Editor.
Builders can be placed elsewhere if you want a common repository for multiple Editors, you don't need 3-5 copies for each Editor - if you are using this way.
Let's see that I'm not bother to copy all time a MapGarbage package updated file in UT469. Why ? Because it looks like UT can use things out of "sand-box". See this definition from UnrealTournament.ini: By defining full paths outside of main system path we can have builders. However, I think Icons used by these things must be in editorres folder or else you won't have a face for their buttons.

Another extra-option used in 512k mapping contest was doing connections between two spots using a sort of teleporters acting like PathNodes and forcing Editor to do some stunt. If these are wisely used they can do connections making pawns to have other reactions than plain reaction. By using a wise placement these are doing a good job combined with kickers. And then ?
Then it's about having these in MyLevel. We will have next MapGarbage version capable to log the script for you right in Editor, all need is copying script and compiling a subclass of Teleporter.

We can edit an UT map inside UGold227 whatever. A problem in opening map outside of UT can be various UT actors calling Classes/Variables which don't exist in Gold. How can be edited such a map ? If we are aware of specific UT actors on purpose, we can Cut-Paste them in notepad (even if are Items/Inventories) and then we can operate pathing changes with PathsLinker - saving them as t3d file.

And... we can re-import back all Items saved from t3d file in current working map. If by chance InventorySpots have lost their linked references at these inventories this is not that good. However, items are still having the variable pointing at which InventorySpots were previously connected. And ?
Future version of MapGarbage will have adjusted that feature bXCPostNavHck for checking some lost references between InventorySpot<->Inventory. Not only InventorySpots will check linked Inventories but also Inventories containing a link to an empty one, will try to adjust referenced InventorySpot back to connected Inventory - so to speak this check is now bidirectional not unidirectional as it was before.

During a latest work at paths, I needed to restore more than 50 ammo with their InventorySpot and preventing any Paths Rebuild as long as network had corrections executed manually with purpose to have a normal deal with Inventories. Too much time consuming, builder can do this under one second.
These cute tweaks are doable, we only need good tools in order to gain speed toward doing settings or else we can spend days for simple operations.