Builders helpers for UT Editor

[Nelsona]

Bump ahead.
MapGarbage in current state it needs whatever testing time due to newer feature added - it was my desire to optimize navigation as much as possible by listing several paths ranges dimensions.
What is about ?
In maps with smaller spots and more nodes, desired 1000 UU Paths making range used by Original Editor can be decreased in certain XC builders. By finding a proper value the task will except time wasted with tests for various values.
This function tested in some stock maps has demonstrated that it needs extra fine tuning and adds as long as certain stock map seem trashed right from factory. However reducing Scan Range is delivering less useless data improving navigation performance in similar maps.
Builder is excepting from calculations Teleporters and LiftCenters and corresponding lengths (warps) as long as these are not exactly like in reality having hard-coded data in all cases. I don't think this is the final stage of a report:

CTF_Coret_Paths.PNG (186.87 KiB) Viewed 10479 times

Situations are a lot - not very predictable or common , Range uses even bigger values over 1000 UU because we might want to know it these long paths worth to be used and not working at a lower level... If some reachSpecs are fake like in AS-Frigate, these are calculated based on real distance...

AS_Frigate_Paths.PNG (330.34 KiB) Viewed 10479 times

User might have a clue if map has too many small paths that can be covered with less paths but longer intervals, reducing processing cycles even using plain builder working at 1000 UU Scan Range.

[Nelsona]

Still moving here for helping during editing.
Basically I wrote a texture importer - not package loader, but texture maker from source PCX and BMP files... or whatever will be supported...
Function need at least a file name / path for generating Texture. If package target is not specified MyLevel is used.
All textures should follow plain importing rules power of two and nothing else - UT doesn't need to reinvent wheel otherwise it's crashing...

More_Help.PNG (176.03 KiB) Viewed 10466 times

Mainly builder is constructing textures having a default formula as it is shown in log. However if user wants another LODSET or Flags these are going in importing directives too. It loads files even outside of UT truncating names at Max 8 characters lenght - we don't need stories written as names .
In other hand if you have plans for SPACE used in files names it's YOUR problem if all it's crashing and your work goes useless.

[Nelsona]

Topic's HeartBeat
It looks like it won't hurt support for loading major Stock Sounds - good for movers and more.

Code: Select all

	MyMap.ConsoleCommand("obj load file=VRikers.uax");
	MyMap.ConsoleCommand("obj load file=Extro.uax");
	MyMap.ConsoleCommand("obj load file=DoorsAnc.uax");
	MyMap.ConsoleCommand("obj load file=DoorsMod.uax");
	MyMap.ConsoleCommand("obj load file=AmbOutside.uax");
	MyMap.ConsoleCommand("obj load file=DMatch.uax");
	MyMap.ConsoleCommand("obj load file=AmbModern.uax");
	MyMap.ConsoleCommand("obj load file=AmbAncient.uax");
	MyMap.ConsoleCommand("obj load file=Activates.uax");
	MyMap.ConsoleCommand("obj load file=Pan1.uax");
	MyMap.ConsoleCommand("obj load file=rain.uax");
	MyMap.ConsoleCommand("obj load file=openingwave.uax");
	MyMap.ConsoleCommand("obj load file=noxxsnd.uax");
	MyMap.ConsoleCommand("obj load file=LadderSounds.uax");
	MyMap.ConsoleCommand("obj load file=DDay.uax");
	MyMap.ConsoleCommand("obj load file=AmbCity.uax");
	MyMap.ConsoleCommand("obj load file=Addon1.uax");

Faster than loading everything one by one.

Note: Related to map MH-TrainCommando there is a sound in Pan1.uax if I well recall which could be used as a mission directive - I did not know that sound in that time... it would be priceless... It's not too late, these can be injected with run-time patch plugins... another time, maybe...

[Nelsona]

First post has been Edited/Updated.
MAPGARBAGE April 2021 is out with content:
- bGetMinScanRange - aiming a reachSpecs/Paths length statistic for optimizing ScanRange for mapping paths through builders from XCv21 XCv25b - advanced experience is required here not cube drawing only;
- bLowerMovers bUpperMovers - MoverLocateZ - if movers need to be elsewhere during building process for preventing creating shadows - might not be a daily need but... we do have this capability for testing various builds;
- bImportTexture - a texture importer/creator supporting various flags not only plain import;
- bLoadStockSnds - Stock sounds are loaded for use - except voices - Mover stuff, Ambient Sounds, etc.

Here went a few code completions regarding to old features such as checking and fixing CreatureFactory type goofs - Added because even in 2021 we do have "editor users" doing UNR files in a bad state and sharing them as maps. The bigger is the map, the harder is to track details and more bugged is the result.

[Nelsona]

In certain maps player feels lags. Some of these lags are caused by colliding actors which are using a Huuge cylinder. Due to some reasons which I cannot explain I totally forgot about these things and these checks might be useful in maps. There are maps having useless big triggers for firing various effects when these are doable by using a TimedTrigger for One-Time action. Definitely MA - MonsterHuntArena maps are pointed here as long as they are using a default big trigger for ending map - speaking about normal maps not those junks without end floating through community.

BigOnesDetection.PNG (873.93 KiB) Viewed 10316 times

Maps which have big triggers or such big ones actors - mainly colliding are a game slow-down. In next version we can have a report of these enlarged ones and even calculating all volume taken in UU - Unreal Units. We don't forget certain BlockAll actors needed for preventing lousy access in the wild. If these are not having insane cylinders they are not reported but if are having a big radius and a huge height these are pointed. Nothing is changed, adjusted or deleted, but only reported for the guy checker if is about decisions to add map on server or playground and wants quality things loaded.

Initial function was provided by Barbie (credits and Best Regards) showing this problem which it's definitely important - capturing my attention privately. I adapted function in MapGarbage, reporting mainly very big cylinders and not everything. A BlockAll having CollisionHeight 40 and CollisionRadius 2000 it's not in account in my opinion... it might be needed as it is for preventing unwanted access or mapped pawn actors going to nowhere.

[Nelsona]

Okay...
And I was working for some messed up surface which I changed at proper values. Then I rebuild map. Suddenly an invisible barrier was showing up from nowhere in a spot. Barrier was in line with a solid cube having a funky PrePivot... Ooops... I think I have access at actor's PrePivot in Uscript, this giving me the reason for discarding floating numbers and rounding PrePivot to the nearest integer - yes, we talk about negative values too not only positives.
Indeed some brushes have a prepivot modified but STILL NOT HAVING reasons to be floating numbers.
After rounding number to a ZERO integer because it was snapped elsewhere - a stupid plain cube messed up - barrier has been vanished.
And then... we have a bit of fixing - possible more or less helpful but better than nothing...

Code: Select all

	local Brush B;
	local int numBugs;

	foreach MyMap.AllActors(class'Brush',B)
	{
		if ( B.Prepivot.X != int(B.PrePivot.X) || B.Prepivot.Z != int(B.PrePivot.Z) || B.Prepivot.Z != int(B.PrePivot.Z))
		{
			log ("Brush"@B.Name@"has PrePivot"@B.Prepivot,'BuggingBSP');
			if ( B.PrePivot.X > 0 )
			{
				if ( B.PrePivot.X - int(B.PrePivot.X) < 0.5 )
					B.PrePivot.X = int(B.PrePivot.X);
				else
					B.PrePivot.X = int(B.PrePivot.X) + 1;
			}
			if ( B.PrePivot.X < 0 )
			{
				if ( int(B.PrePivot.X) + ABS(B.PrePivot.X) < 0.5 )
					B.PrePivot.X = int(B.PrePivot.X);
				else
					B.PrePivot.X = int(B.PrePivot.X) - 1;
			}

			if ( B.PrePivot.Y > 0 )
			{
				if ( B.PrePivot.Y - int(B.PrePivot.Y) < 0.5 )
					B.PrePivot.Y = int(B.PrePivot.Y);
				else
					B.PrePivot.Y = int(B.PrePivot.Y) + 1;
			}
			if ( B.PrePivot.Y < 0 )
			{
				if ( int(B.PrePivot.Y) + ABS(B.PrePivot.Y) < 0.5 )
					B.PrePivot.Y = int(B.PrePivot.Y);
				else
					B.PrePivot.Y = int(B.PrePivot.Y) - 1;
			}
			if ( B.PrePivot.Z > 0 )
			{
				if ( B.PrePivot.Z - int(B.PrePivot.Z) < 0.5 )
					B.PrePivot.Z = int(B.PrePivot.Z);
				else
					B.PrePivot.Z = int(B.PrePivot.Z) + 1;
			}
			if ( B.PrePivot.Z < 0 )
			{
				if ( int(B.PrePivot.Z) + ABS(B.PrePivot.Z) < 0.5 )
					B.PrePivot.Z = int(B.PrePivot.Z);
				else
					B.PrePivot.Z = int(B.PrePivot.Z) - 1;
			}
			B.bSelected = True; //Yes, I can do this no worries...
			numBugs++;
		}
	}

The deal is as follows:
If Brush Actor has been PrePivot-ed being found screwed up this will be selected. Why selected ? We are looking at our brush if is badly altered and it's no longer valid as it is, whatever ground stuff looks very altered and it doesn't look original at all - a rebuild done this way will change geometry and it might do damage. And then we won't save map but closing Editor and reopening map, trying another sort of fixes out of scripted fixes. Here usually before attempting this fix I'm saving a copy with suffix "_1" and operating that thing leaving original as backup in case of failures.

[Nelsona]

The next check which would be good right at beginning ages of this MapGarbage would be a check when some "editing-dude" does weapons replacements without linking them correctly into network resulting InventorySpots without "markedItem" and generating null data in Bot's navigation.
Builder is not guessing which spot was assigned to which item - we can have multiple items in spot, but it will report these "replacements".
MapGarbage can do such replacements in seconds but nobody cares to use it and how. Debugging technician should have the helping hand for figuring these "edits" and recovering data. When map has hard-core pathing works and paths should not be rebuild automatically, replacing weapon in clumsy way is generating these gaps with no purpose.
Feature called Reporting Lost InventorySpots can be activated/used under bool variable which probably will stay called bRepLostInvSpots.

[Nelsona]

First post has been updated with a new builder concerning a Texture Alignment Calculator for pillars intended for a quick and precise workaround executed at whatever pillar.

[Nelsona]

First post has now a version of MapGarbage for May - a bit late right now but... I don't think this is a problem.
Let me know if there are ugly issues caused by builder (not by user...).

Next versions are postponed until I'll consider any other updates really needed for being public.

Right now I have to polish my other builder which is executing pathing works in UT using older XC24 assets and whatever stuff which will be out when I'll consider it good for a public release.

[Nelsona]

XC_BrushScanner as a name of a Paths Worker tool doesn't look suitable at all. From now on I named it XC_PathsWorker. This is less important point...
Another thing which see in maps full of debris data is incomplete referenced ReachSpecs so to speak, when paths are rebuild without cleaning up they are going referenced incomplete. Considering Point A and B connected, we do have added Paths in point A, but spec is missing from UpStreamPaths in Point B. This way is not really taken so this spec index is pointless as the spec itself. Results: Some of those Paths Lines which are shown in Editor are just Useless Myths happily generated by multiple builds of a trashed network.
This builder does a check if Specs are hosted properly and/or moved elsewhere as long as it supports editing paths manually. If Spec A to B is modified from C to D, it will be moved accordingly if this final check is applied. Also here missing references are added back in Paths lists if are valid.
This is demonstrating me that CLEANING map before a new network build is a very good idea and a good practice or else you will never know why Bot doesn't move using certain path which Editor is showing - happens because Editor is not cleaning and wrapping things correctly when Paths are Re-Build over and over generating more such useless "Lines"/paths which are not even used.

A recent map with a fake name "...._rS632" - in reality has 2124 reachpecs, it's including such False routes as long as upStreamPaths are mandatory for computing routes
Log was talking the story:

Code: Select all

SpecTest: Testing 78 :: PlayerStart15 :: PathNode112 .
OK: Spec with index 78 has been found inside PlayerStart15 at Paths[0].
SpecMissing: Spec with index 78 could not be found inside PathNode112 . Trying to attach ReachSpec.
SpecAttached: Spec 78 has been attached to PathNode112 at position upStreamPaths[6].

Map has additional paths around that spot but here the best route is not taken due the "re-build" operation. Thanks to the Karma God, Editor is happily painting such ReachSpecs/Paths but which are not used...
I suspect that such a spec was a PrunedPath before and after rebuild it was turned into a Normal Path out of upStreamPaths reference.
How do I know that are not used ? I did a test a few time ago, I removed all upStreamPaths from all Navigation Points from a map. Bots were wandering out of target moving slowly from time to time - all was broken even if Editor was full of lines linking nodes in FAKE routes, simple as that.
If we want our maps in a good state, it is advisable to work clean and organized, it's not like Any UNR file it's an UT map... you might be victim of counterfeiting.

XC_PathsWorker.flv

(3.83 MiB) Downloaded 832 times