Builders helpers for UT Editor

[Nelsona]

First Post
has been Updated/Edited. There is available another version updated with news of MapGarbage Editor AddOn.
Updates:
- miscellaneous code adjustments;
- Checking PlayerStart rotated at wall;
- creating linked Combos - strings definition more exactly - that need to be connected with paths;
- Places exchanging for two actors - Inventories needs a bit of attention;
- Re-connector InventorySpot-Inventory if was used place exchanging feature;
- Several Stock textures loader.
Extra-details are written in PDF document included.
It's time for fun... Until I'll notice other needs that can be speed-up using a builder instead of spending all life in Editor...

[Nelsona]

PathsLinker update released - first post has been updated.

Version for November doesn't include news but modifications in Operation Mode.
- After disconnecting path from Point N1 (whatever Navigation Point) to the Point N2 (another Navigation Point), builder will exchange these two nodes. When User wants a complete disconnection of N1 to N2 and N2 to N1 it will gain these nodes ONCE but they are disconnected by setting up bDisconnectN1toN2 twice to True without capturing them a second time, builder does swapping and checking if N2 has a connection back to N1 and/or they can have more than one reachSpec connected - lol, I found such case no worries - no names, no maps, defaming people it's Off-Topic and not nice.
- When we want to connect a Path From N1 to N2 which is connected already, builder won't only show reachSpec already connecting them but it will log Index Number and also will copy data to variable NSpec. This way applying a modification is doable faster without keeping numbers in memory, builder will memorize number for us. We are only putting bModifyReachSpec to True and reachspec with new data is adjusted. Here changing paths it's a bit more easy when situation is requesting such works. Variable is turned off after use for not working twice.
- after testing connectivity of two selected Nodes, feature is turned off - I think are not needed two tests for the same two nodes.
In future such ergonomic changes are expected as long as we don't need to waste time around logic stuff where builder might work automatically.

[Nelsona]

After adjusting a bit codes in MapGabage and making them a bit more simple I had a recall about some of my old friends which were solving a lot of problems: Teleporters. If MapGarbage does Combo links in seconds I don't see why not having Teleporters links. I was thinking at an ergonomic method of causing URL to Tag connection. Perhaps the quick solution which I did will remain as follows: Select a Teleporter which is Destination, select an option and Hit button for capturing it, select a teleporter Source and some option then hit button for getting linked to Destination - uni-directional in one step as long as Bi-Directional is not always needed but... is doable in the same way. No words written, no double editing, just using ENTER key and Mouse-Clicks.

TeleLinks.PNG (10.31 KiB) Viewed 9592 times

[Nelsona]

First Post contains now MapGarbage version November 2020.
Update notes:
- Support for adding triggers for Triggered Lift - explanations are in document;
- Support for deleting some PathNodes in overcharged areas - free range is configurable;
- Support for connecting teleporters - logic links are generated for making connections with future paths - these must be done before building paths. Task is doable in two steps without writing words.

[Nelsona]

The next update looks needed because UT has stock assets giving ideas in time... These ideas would need to be checked here and there and whatever automated tool for working it's welcomed for those interested in more than plain "static mapping".
Next Update of MapGarbage will have a report for PlayerStarts if are active/inactive and how many. Why ? Because even in CTF games and not only there we can have a spawn places toggling feature, triggered at random times by map itself.

Also here we can have a Dis-Connector from Navigation chain of certain Navigation Actor. Without rebuilding paths and ruining some hard manual work, whatever InventorySpot from void out of paths can be UnLinked from Navigation Chain and deleted later. Select borked point out of paths, set builder option to True, press build. Point is UnLinked and it can be deleted without to screw the rest of tweaks and mess with rebuilding chain in other way if this is not welcomed and not needed.

Next option is the reversal. Adding into Navigation Chain whatever point which doesn't need paths and rebuilding routes. Add a PlayerStart somewhere around Paths and higher placed, select this Start, put option to True and launch Builder. PlayerStart will get connected and working normally as it can be active/inactive and following spawn rules.

MG_02_21_Proposal.PNG (10.52 KiB) Viewed 9130 times

These are now in testing stage.

[Nelsona]

First post has been updated.
MapGarbage December 2020 - January 2021 it's out with a few adds:
- removing from navigation chain a Navigation Actor if has no path and no use, for being deleted without to alter remaining navigation chain;
- adding to navigation chain a new Navigation Actor more or less with paths. Usable when we want to add a PlayerStart without generating paths in order to make it functional as a default one following team rules and availability enabled/disabled;
- void buggers checker will have a subsequent option for removal of these - if map is well zoned: Lights Inventories Navigationpoint out of a custom tag and placed in void on purpose;
- tiny changes at PlayerStarts checks - reporting how many are active/inactive.

[Nelsona]

Moving ahead with update notes.

During whatever pathing sessions where "teleporting and filtering" through 227 assets are doing more damage than helping, mapping paths using original assets might not go very entertaining at reachSpecs charge. As a sample, a random "sniperammo" apparently innocent and connected with other two ammo actors around VIA their InventorySpots in reality had a bunch of PrunedPaths - 13 more reachspecs which means paths that aren't shown by Editor. Because these are not shown or even if are shown might be heavy to figure all such spots in order to do changes (removing them temporary for reducing the load), I operated a sort of Nodes examination, so to speak a charge measurement of Nodes. We are using a percent said 60 (%), and launching a testing option. All nodes are checked according to a simple math formula if whatever Paths[x] corresponding to Percent requested has valid paths data and then has a high load that might be reduced using various methods (deleting these it's included and useful in the most of cases).
Percent has a simple deal - if 16 Paths means 100% how many [ i ] means 50% or whatever 60 % ? Here value calculated [ i ] Paths upStreamPaths and PrunedPaths are tested if their data is not default "-1". In this case node contains reachSpecs and then, PrunedPaths[12] if it has some index, this means that it has 13 invisible Extra-Paths heading to nearby Points and not seen by user - it's time to get rid of this spammer loading processing cycles.

First time I was thinking that such a feature is not really helping but as long as I could reduce the load in some spots going around 2000 reachSpecs in a medium-big map I think it's useful somehow...

Percent_Charge.PNG (263.88 KiB) Viewed 9060 times

In this image InventorySpot656 is not very helpful in processing Navigation and neither other "friends" of him... Also there is visible even a PathNode which can be removed as long as Editor will create enough connections for this area without it, that load has no use and then such things can be detected by builder.

[Nelsona]

Nearby previous described feature, MapGarbage will have another sort of duplicated actors detector - bCheckMultipleActors - those which are having different names but are the same class in the same place with the same rotation etc. These are copies (not brushes !!) of whatever Items/Nodes causing crowded spots. They are removed when option is launched - there is no reason for keeping these multiple copies. All information it's documented in release note PDF file coming with MapGarbage version February 2021. All these are possible because FIRST POST HAS BEEN UPDATED. Builder will log if a NavigationPoint/Light has been removed because such things usually need a map rebuilding task.

[Nelsona]

First Post is being updated with MapGarbage version February 2021 but in next version we might have some features for Original UT Editor. We can see those Blue and Red Paths in different colors - we are picking what we want - planned for March 2021.

PimpMyPaths.PNG (1.1 MiB) Viewed 9002 times

In newer assets XC and 469 these colors are changed - let me see, ViewPort won't react at newer colors only original Editor and older XC assets version 21 - those having Range option for creating paths...

[Nelsona]

Bump timer - Update Timer
First Post is Updated with MapGarbage version March 2021.
Previous feature with colors is now available for Stock Editor 436 440 (even 451b... if you can do something there) but also there are a few small adds and code changes. Quoting adds:
- bFindTrapPoints - feature will find navigation points having incoming paths but nothing for going out. These are not welcomed in routes to goals as long as we need Two-Way paths for heading at something and back, not 50%;
- bChangePathsColors - Explained above, colors are active mainly instantly, ViewPort must have checked flags for "Show Paths", at this moment I could not find a solution for setting this automatically, it needs more than UScript for this option;
- bRedFlagIsRed - This option makes "RedFlag" for Team 0 - in Editor it's FlagBase not really a flag - exactly as it looks in game and not a Blue one;
- bFixScaledCollisions - This option does an examination at colliding Decorations and Pawns. Pawns screwed up by n00bs are reverted back, Pawn is adjusting collision cylinder automatically in run-time and it's advisable to be left alone. Decorations with a bigger drawscale will collide as in original if they are not adjusted having a lousy colliding cylinder - here cylinder is automatically calculated based on DrawScale, by example a NaliStatue with DrawScale 2 will collide as it should and not like is having DrawScale 1.

Little note:
Hunting all reachSpecs from map requires a test done by incrementing numbers until results found are: None, None, 0, 0. Any number out of array should do these results and then I know when array is ended without any warning as long as 227 doesn't do any warning but giving what user has asked for.
UT469 which has a "fix" claims a ScriptWarning perhaps because DescribeSpec from UT469 it's not in XXI century yet :/ ...
Answer was something funny: We don't have in UT solutions for getting reachSpecs. When Nelsona is finding a solution we are going to setup some "fix" for bugging him. And then, Nelsona won't change anything at code just for 469 when in other versions of UE1 all it's operational, to not forget that when you want to complete some fields from a list with actors, Editor might crash like an a$$ in this newer 469 because that "NEW" feature is NOT very TESTED. When I need to work with those features (adding/replacing actors with builder) I'm using old Editor which doesn't include any stupid buggy list and D3D driver in that old Editor it's working. In end shortly: It's possible if you want to adjust whatever map to get used to work with two Editors because certain crashes have been fixed in Newer Editor and new ones were brought in stage...

Selecting_TheCrash.PNG (9.52 KiB) Viewed 8887 times

causing function from builder to be useless based on a feature which I don't know who asked it and why. Previous "feature" is here since 469a and it's unchanged.
Do you think that I will remove my function because Editor has a new bad list ? Nope, I'd rather prefer to remove newer Editor.
As example, if you want to use another PathNode in the same spot and you want to add a newer actor in the same place, it is advisable to know its name and typing class-name directly and not by using newer browsing method through available classes because that list it's screwed up - and a waste of time scrolling less visible classes - a fake new feature, entirely useless for this builder.

Old_Method.PNG (1.09 MiB) Viewed 8883 times

Either way I'm curious what any other feature has no use in newer context... I'll study what it's about in future.