Builders helpers for UT Editor

[Nelsona]

First post has been updated with an initial release of Builder called PathsChecker that can be used in stock UT. Exactly, it doesn't use anything than Engine, Core and Editor packages, but it does checks which I think they should be available directly from factory not in 2022... Better later than never ?
Shortly...
Builder has one single option to be activated before pressing BUILD button. This bCheckItemsRoutes option will process navigation network from current loaded map inside Editor for finding if there are logical connected ReachSpecs creating routes from all PlayerStart actors to possible targets:
- Inventories;
- FlagBases;
- AlternatePaths;
- AmbushPoints;
- ControlPoints;
- MonsterWaypoints;
- MonsterEnd(s).
To do ?
Reacting for debugging purpose by probing routes from each PlayerStart to a selected Actor ?
Asking because there is already a builder for debugging a "SOLO" route called PathsDebug written by Buggie which I loved a bit for my needs.

[Nelsona]

First post contains now August updates:
#1 MapGarbage - added one option for showing content of a group, some maps were hosting empty groups for no reason.

#2 XC_PathsWorker based on XC_Engine v24+ - quoting modifications:
- it has a total paths deletion option using Command Paths Undefine but nulling ReachSpecs from Level's references as first measure before triggering Engine to delete objects with references inside - I'm not sure if this is helping but... I have it;
- options for showing/hiding PrunedPaths that usually are not shown - I don't know if other future UT patches will have more options and/or more bugs...
Showing these PrunedPaths will reveal the true story of map in terms of "Paths"/ReachSpecs. A hidden thing doesn't means that it doesn't exists.

[Nelsona]

PathsChecker from first post will be updated soon.
There will be some code modifications and a "CleanUp" behind processing done in UScript as long as some natives are still leaving useless debris data.
Internal cleaner "Pawn.ClearPaths()" doesn't do a full cleaning. If C++ can alter data exposed to UScript then UScript might have an entry as well ignoring lousy ucc "compiler", using some "statics" in order to gain some speed as I was reading elsewhere...
(Spoiler doesn't work properly in forum's script based on latest updates Script vs PHP engine)

Code: Select all

static final function CleanNode(NavigationPoint N)
{
	N.bestPathWeight = N.class.default.bestPathWeight;
	N.visitedWeight = N.class.default.visitedWeight;
	N.prevOrdered = N.class.default.prevOrdered;
	N.nextOrdered = N.class.default.nextOrdered;
	N.startPath = N.class.default.startPath;
	N.previousPath = N.class.default.previousPath;
	N.routeCache = N.class.default.routeCache;
	N.taken = N.class.default.taken;
	N.bAutoBuilt = N.class.default.bAutoBuilt;
}

static final function CleanCache(Pawn Scout)
{
	local int i;

	for ( i = 0; i < 16; i++ )
		Scout.RouteCache[i] = Scout.class.default.RouteCache[i];
}

In fact ALL builder concerning these assets will get updated... Autumn's crops...

Memory recall: Reasons for this builder
I did it because:
- some times I wasn't aware about all items placed around maps so I failed to see missing paths - I failed some paths at this point recently;
- by using a "Single-Path" test will require a lot of time for manually probing spots.

[Nelsona]

Hi, everyone...
Bumping topic for some information. Let's say that we can delete certain path in Unreal227 whatever, UT having no way to do this. However... XC_PathsWorker for next month will have some feature for a mass destruction of null ReachSpecs (aka Paths) which can be in map-files.
We are cleaning nodes and nulling these paths for preventing any evil stuff to get them back. After nulling them and reindexing them at the end of array we can simply get rid of them using both XC_Engine and... Engine itself.

Technically we are creating some copies of "volatile" nodes and remapping paths, then we are backing up only normal paths. After backup, we simply destroy all Paths. Lost nodes are going to have new copies (even similar custom classes) and then only valid saved ReachSpecs are going to be added. Even if they are customized or in original, all good content is recovered.

[Nelsona]

Imaging a bit future release.

XC_Pw0.PNG (9.84 KiB) Viewed 4290 times

bRemovePaths does a "Paths Undefine" command but not before nulling all data referenced to Nodes from map. These Garbage Specs won't get vanished before de-referencing Nodes from them - purpose is to gain more clean assets as possible - perhaps helpful;
bDisablePruned - Previous feature showing PrunedPaths was pointing me other misery which I did not even implemented in Paths Constructor from builder. I don't need them, Bots don't need them, nobody needs them. This feature is nulling them for good - no recovery. Yes, Goblin, I'm right behind you...
Next...

XC_Pw1.PNG (10.45 KiB) Viewed 4290 times

bFindFreeSpec - after nulling some of these Specs, they will stay in Level. If we need something to be connected we can re-cycle one of these junks for our new need. It shows the first free reachSpecs available which we can edit using previous features;
bCleanNullSpecs - this has a purpose deleting empty ReachSpecs resulted from nulling some paths and/or new UT patches that are only disabling paths not deleting them. This time we are not going to host NULL data at all - I think Monsters are not loving such Specs... Solution used here could be better and more suitable in C++ rather than solution applied at UScript level. At least in Editor we can have a "CleanUp" closer to 227 assets...

The rest means a bit of code polishing. Highly loaded Levels will require "-norunaway" command switch for allowing Builder to do its job.

Testing Environment:
Builder in normal maps is capable to perform a Cleanup/Editing task under a second using a slow machine Pentium HT at 1400 MHz. In another faster machine the same task takes around an eye blink. I believe in very new machines all goes faster than that.
Building Paths-Net in exchange is a slower process - in the most of time working still faster than Editor's DevPath due to simplified methods and accepting any future corrections.

[Nelsona]

Back in stage... Builders chapter... Pre-release information
MapGarbage will have a bit of ergonomic revision at de-referencing a path - last time I used that thing for preparing tweaking stage operated later with XC_PathsWorker. Something a bit clumsy for "LevelValidate" cloned command will have some "report" with regard to a permanent copy-paste dumb practice around skybox with asteroids which nobody can see ON-Line and nothing is done in every single map with those stupid rocks.

Code: Select all

LEVELVALIDATE: Level Validation:
PlayerStart: Checking PlayerStart1
PlayerStart: Checking PlayerStart2
PlayerStart: Checking PlayerStart5
PlayerStart: Checking PlayerStart6
PlayerStart: Checking PlayerStart7
PlayerStart: Checking PlayerStart4
PlayerStart: Checking PlayerStart12
PlayerStart: Checking PlayerStart13
PlayerStart: Checking PlayerStart15
PlayerStart: Checking PlayerStart16
PlayerStart: Checking PlayerStart17
PlayerStart: Checking PlayerStart18
PlayerStart: Checking PlayerStart19
PlayerStart: Checking PlayerStart20
PlayerStart: Checking PlayerStart21
RecommendedCheck: Actor boulder22 looks placed in SkyZone and it might be invisible On-Line or not animating.
RecommendedCheck: Actor boulder23 looks placed in SkyZone and it might be invisible On-Line or not animating.
RecommendedCheck: Actor boulder24 looks placed in SkyZone and it might be invisible On-Line or not animating.
RecommendedCheck: Actor boulder25 looks placed in SkyZone and it might be invisible On-Line or not animating.
RecommendedCheck: Actor boulder26 looks placed in SkyZone and it might be invisible On-Line or not animating.
LEVELVALIDATE: Validation done...

Here is only a report, each dude might want his own method in solving problem, perhaps several recommendations are going to be printed without touching anything... I don't understand why map should be loaded with these if nobody can see them ?

XC_PathsWorker
Here will be something added during paths building process... Previously I went to update Viewport from time to time in order to see if builder it's still working or... it went stuck. However, I used recently a slow rig machine and here Building Paths was a slow process not only because machine worked slow but because these updates were losing a speed of 20-25 ReachSpecs/Second. Display speed will be tested and if machine works slow due to display, map's charge, whatever factors, updating is reduced for getting more performance in processing data rather than painting ViewPort.

[Nelsona]

Time Up.
First post has been updated with September versions as follows:
- MapGarbage - several tiny changes and checks;
- XC_PathsWorker - some other new for UT options;
- PathsChecker - cleaning debris left behind pathing and routing calculations.

[Nelsona]

The other notes concerning Goblin known as UT Editor - some things unchanged even in new patches or "improved".
When I worked recently for eliminating duplicated ReachSpecs, I went to some deal - opening a separate ViewPort with settings for showing Paths. Somehow works, and somehow it's an incomplete deal. Viewport is created but not given a NAME since Goblin looks capable to ignore its own commands...

UnNamedPort_436.PNG (376.48 KiB) Viewed 4163 times

As result you cannot close new ViewPort from UScript until you are closing all ViewPorts ruining user settings. In 469b this external ViewPort has a funky rendering...
It doesn't only take ages for hiding back PrunedPaths but after said task UnNamed ViewPort created goes into HOMS...

UnNamedPort_469b.PNG (274.47 KiB) Viewed 4163 times

Of course any of external Viewports can be closed by user any time, to me it seems a bit helpful, I'm not interested in making these advanced since developers are not interested to make new versions to work in my system and to do further investigations.

Next... Someone very "smart" ruined map Tundra into "Tundra][". Paths are there, nodes are there but are somehow in a deletion process. I could see even their locations and ObjectFlags. In 469b I did not even see any ObjectFlags neither doing anything else. Why I deducted that "deleted" data it's still there ? Because ReachSpecs are drawn based on Start End and their locations (paths are drawn) - yes, I could see locations but I cannot bring them back - the only way is creating copies in t3d editing and importing them after a "CleanUp". To me it doesn't worth too many efforts at this point, perhaps a builder might deliver some data that is read from ReachSpecs and generating a t3d import in log.

Goblin also has embedded some keys for operating assets which I'm not going to explain - I don't know if are even documented somewhere through fake docs collections, other keys to me are useless. Such a key might operate something not selected - more exactly a NULL thing and... reaction is accordingly . When Editor is suddenly crashing, you might want to pay attention at your fingers and what is being selected or... NOT selected. This is the most bugged application which I could see since I'm living on this planet. Honestly I'm not sure how much can be fixed... and how long does it takes to do this.

[Nelsona]

Finally I managed to do some settings regarding to creating a ViewPort in both UT versions (old 436 and new 469b) without HOMS - still don't know if ViewPort has a NAME for being closed later... Eh... Window created has X anyway in top position...
Now it would be awesome implementing resolution for this ViewPort depending on user's desire. Default size for me looks suitable at 1080 × 640... either way Window created supports to be adjusted other way, perhaps it doesn't need anything else.

Tech Explanations from internals.
We are grateful for ConsoleCommands... such as:

Code: Select all

CAMERA OPEN NAME="PathsWorker" X=32 Y=16 XR=1080 YR=640 FLAGS=32732 REN=5 GROUP=PathsWorker

Legend:
- X means Screen coordinate on X axis where window starts being painted;
- Y means Screen coordinate on Y axis where window starts being painted;
- XR - resolution width;
- YR - resolution height;
- Flags - means what sort of deals are in Viewport;

Code: Select all

enum EViewportShowFlags
{
	SHOW_Frame     		= 0x00000001, 	// Show world bounding cube.
	SHOW_ActorRadii		= 0x00000002, 	// Show actor collision radii.
	SHOW_Backdrop  		= 0x00000004, 	// Show background scene.
	SHOW_Actors    		= 0x00000008,	// Show actors.
	SHOW_Coords    		= 0x00000010,	// Show brush/actor coords.
	SHOW_ActorIcons		= 0x00000020,	// Show actors as icons.
	SHOW_Brush			= 0x00000040,	// Show the active brush.
	SHOW_StandardView	= 0x00000080,	// Viewport is a standard view.
	SHOW_Menu			= 0x00000100,	// Show menu on viewport.
	SHOW_ChildWindow	= 0x00000200,	// Show as true child window.
	SHOW_MovingBrushes	= 0x00000400,	// Show moving brushes.
	SHOW_PlayerCtrl		= 0x00000800,	// Player controls are on.
	SHOW_Paths          = 0x00001000,   // Show paths.
	SHOW_NoButtons		= 0x00002000,	// No menu/view buttons.
	SHOW_RealTime		= 0x00004000,	// Update window in realtime.
};

- Ren - Means Render type.

Code: Select all

enum ERenderType
{
	REN_None			= 0,	// Hide completely.
	REN_Wire			= 1,	// Wireframe of EdPolys.
	REN_Zones			= 2,	// Show zones and zone portals.
	REN_Polys			= 3,	// Flat-shaded Bsp.
	REN_PolyCuts		= 4,	// Flat-shaded Bsp with normals displayed.
	REN_DynLight		= 5,	// Illuminated texture mapping.
	REN_PlainTex		= 6,	// Plain texture mapping.
	REN_OrthXY			= 13,	// Orthogonal overhead (XY) view.
	REN_OrthXZ			= 14,	// Orthogonal XZ view.
	REN_OrthYZ			= 15,	// Orthogonal YZ view.
	REN_TexView			= 16,	// Viewing a texture (no actor).
	REN_TexBrowser		= 17,	// Viewing a texture browser (no actor).
	REN_MeshView		= 18,	// Viewing a mesh.
	REN_MAX				= 20
};

Credits...
I'm grateful to my mouse because it helps me to close the Window successfully without describing which ViewPort is closed but only reporting that something is closed - no warning, just a Log Line. I think is enough at painting chapter...

[Nelsona]

The next update work is regarding to MapGarbage.
Happens because a bunch of maps are having issues with Nodes placement and maybe we really want them to be more compatible with Bot specific size - even Monsters can use them without problems.
Perhaps something in testing state will stay added:
- bTryFixHighNodes - a sub-option for that which was initially only for reporting Nodes which are impossible to be visited by Bots but having paths;
- bBotifyMyNodes - will do some repositioning of Plain PathNodes more closer to Bot specific Size.
Maybe another option (only an idea so far) would be to check jumping spots where JumpSpot it's in a wrong location - it could be useful for doing fixes easy and not surfing maps for minutes in order to find lousy combos done based on guessing.

- Textures toggling concerning a test for PlayerStart actors now will take in account 4 teams.