Various XC Works Discussions

[sektor2111]

For local debugging and examinations I wrote a reachSpec listing tool which is an XC_Engine_Actor usable in XC_Engine.ini. Here is about ALL DATA from a reachSpec structure - I have already posted such a log fragment but I think there might be people interested about resources for such a game-test-tool.
It's simple and dependencies are Core, Engine, XC_Engine U packages and XC_Engine version is v24, works probably with v25 too.

Code: Select all

class XC_ReachSpecs expands XC_Engine_Actor;

event XC_Init()
{
	local ReachSpec R;
	local int RI, i;
	local NavigationPoint N;
	local Actor Start, End;
	local int distance, reachFlags;
	local string MapFile;

	MapFile = string(Outer.Name);
	if ( Instr(MapFile,"UT-Logo-Map") != -1 || Level.NavigationPointList == None )
	{
		log ("The current environment is not suitable for reporting navigation routes.",'NotNeeded');
		return;
	}
	log ("ReachSpecs reporting Actor.",'MapSpecs');
	foreach AllReachSpecs(R,RI)
	{
		i++;
		log (RI@": Start ="@R.Start.Name@"End ="@R.End.Name@"ColRadius ="@R.CollisionRadius@"ColHeight ="@R.CollisionHeight@"ReachFlag ="@R.ReachFlags@"Dist ="@R.distance@"Pruned ="@R.bPruned$".",'ReachSpec');
	}
	log ("Detected"@i@"reachSpecs.",'XC_ReachSpecsDescriptor');
}

defaultproperties
{
	RemoteRole=ROLE_None
	bGameRelevant=True
}

If I missed something, source code is this one:

XC_ReachSpecs.7z

(879 Bytes) Downloaded 19 times

Then it can be set in XC_Engine.ini as follows:

Code: Select all

...
LastVersion=24
XCGE_Actors=XC_ReachSpecs.XC_ReachSpecs
...

Package already compiled is here for people which want it usable directly out of source-code:

XC_ReachSpecs_Actor.7z

(1.3 KiB) Downloaded 23 times

If it crashes certain maps... you will need to check them other way not with this actor, lol.
This actor is loaded and executed by XC_Engine BEFORE GameInfo's InitGame, so to speak before everything... future changes in navigation might take place if are applied after this tool, this will report mainly original map's content.

[sektor2111]

Buzzing around...

I think at least in local games - perhaps in server too - I'll completely get rid of PrunedPaths. Except processing for nothing I don't have any use of these... either way all "stock" reachSpecs 70 × 70 will have 117 × 112, simple as that. Bot won't have issues but maybe a few monsters will be more active...

Code: Select all

	foreach AllReachSpecs(R,RI)
	{
		if ( R.bPruned == 1)
		{
			i++;
			for (j = 0; j < 16; j++)
			{
				if ( NavigationPoint(R.Start).PrunedPaths[j] > -1 )
					NavigationPoint(R.Start).PrunedPaths[j] = -1;
			}
//			DefragPrunedPaths(NavigationPoint(R.Start)); //Nah, it won't be anything for wrapping
			R.Start = None;
			R.End = None;
			R.CollisionRadius = 0;
			R.CollisionHeight = 0;
			R.ReachFlags = 0;
			R.Distance = 0;
			R.bPruned = 0;
			SetReachSpec(R,RI);
			log ( "Nulling pruned path"@RI$".",'PrunedAdjust');
			continue;
		}
		if ( R.Start != None && R.End != None && R.CollisionRadius == 70 && R.CollisionHeight == 70 )
		{
			i++;
			R.Start = R.Start;
			R.End = R.End;
			R.CollisionRadius = 117;
			R.CollisionHeight = 112;
			R.ReachFlags = R.ReachFlags;
			R.Distance = R.Distance;
			R.bPruned = R.bPruned;
			SetReachSpec(R,RI);
			log(RI@":Start ="@R.Start.Name@"End ="@R.End.Name@"CollisionRadius ="@R.CollisionRadius@"CollisionHeight ="@R.CollisionHeight@"reachFlags ="@R.reachFlags@"distance ="@R.distance$".",'EnlargedSpec');
			continue;
		}
...
...

The true fact as base used here is... Teleporter. These are using 150 × 150 mainly all the time, then I'm not sure if changing 70 will do a hazardous damage at all.

Cons: I cannot purge garbage in this stage - it's too fast and garbage is not completely unreferenced - for removing all trash data before initializing game...
By example: A map with 1222 reachSpecs will work in run-time using only 808 specs without any issue - except issues properly added by mapper.

In other hand those UTDM whatever crapped modified pawns will have more interest about hunting in open areas... Another problem has been solved then...

[sektor2111]

A bump Note with some data regarding to reducing paths creation at minimal requirements when XC_EditorAdds is being used, XCv21 and XCv25b

If you ask me: Whatta heck is this all about ? - I will need to tell you something.
When these assets are creating paths they are using a MaxScanRange aka MaxDistance for creating paths around Nodes doing some calculations.
If we have Node 1 closer to Node 2 at 200 UU distance and Node 3 closer to Node 2 at 450 UU distance, we don't need 1000 or 2000 range for checking paths creation options. We have the minimal requirement recommended 451-452, we are preventing extra-links from Node 3 to Node 1 as long as they are already connected point to point through Node 2. So we need to find the best value for preventing Devs from creating long not needed paths and reducing processing.
If we talk about finding this optimal value using your/my eyes, then I will leave discussion... and the room...
In future version of MapGarbage (after doing all sort of tests) it will be a feature for XC enthusiasts with regard to calculation of this minimal needed distance for covering any navigating interval between any random two closer nodes from a map.
Example:
Value recommended for map AS-HighSpeed ( after deleting useless LiftCenter3 - lol EPIC ) can be 603 UU MaxScanRange/MaxDistance instead of stock range 1000/2000 UU. For such a case XCv21 will create 1580 reachSpecs (with all prunedpaths included) instead of 1885 reachSpecs and other useless data having a navigation network operational like in stock map... and a better optimization, reduced as reachSpecs number.
I was wondering if such a feature written in C++ for recommending the best MaxDistance would hurt mapper's brain... (mapper not cubes drawer...).

Edit: Logging the scan process for finding those two nodes which can be... adjusted or whatever ? Eh... let me think a bit... I have to admit that in certain cases on Z axis it might be needed extra special paths but we can still have less loaded areas...
Edit2:Cough, fantasies from other maps and these devs are not always supporting my first strategy so I went to spy reachSpecs length and reporting log ranges allowing user (me at this moment) to figure with Human eye said spot, if that long path it's not very needed, choosing another lower value if is connected with a nearby closer node... This is a bit difficult to do but I won't quit that easy...

[sektor2111]

Bumpy - Wizard entered the stage leaving me with mouth open.

I went to work on sorting paths lengths for various ranges based on reachSpecs data. Now I'm wondering what exactly was the problem with these people - stock maps and nothing else...
Here I found strange reachSpecs claiming water paths at 1938 UU when physical distance between those nodes in reality was under plain 1000 UU -> AS-Frigate.

Code: Select all

Specs: ___________________________________________
Specs: PathNode187 - UpstreamPaths[0]=1756 ->PathNode192 --->PathNode187 RFlags=Swim =4 Dist=1938 //You have to be kidding me...
Connected: PathNode192 to PathNode187.
Specs: ___________________________________________
Specs: PathNode187 - Paths[0]=1732 ->PathNode187 --->PathNode192 RFlags=Swim =4 Dist=1938
Connected: PathNode187 to PathNode192.

Computing best range option in this case must be done after a full rebuild of network as long as Epic were the best at doing such a garbage - we cannot gain accurate data based on reachSpecs if they did things this way...

Right now I'm realizing that such maps in order to work normally these elements have to be fixed and... UScript has nothing because Epic decided to keep such lousy data untouched, a script for checking reachSpecs looks more mandatory than optional...

[sektor2111]

I was trying to figure what can I do at geometry with regard to fixes/corrections... Not too much... I'm not aware how to put in my favor XC iterator AllObjects. Because I failed at geometry scan and corrections, I fired a final attempt to bring Editing/Creating User-Made Paths in UT - not only in 227. I'm saying Editing because Removing is not exactly possible as I could see and it might be damaging as well. But... some questions from forum about "how to connect two nodes over boxes" or another issues, are having an answer here. I'll think about releasing this stuff (it looks like it works in 469b too...) in the wild because I think it will cause more damage than help in wrong hands...

Yes, it's no longer a brush scanner but it does things which automated scripts are not doing... in UT and using two recent XC extensions. Zooming at builder...

DevTool.PNG (9.51 KiB) Viewed 1085 times

Mapper/Editor can prevent loading spam data by using a limited range depending on map's geometry. If there are nodes not connected due to distance required, map can be opened later using XC24 XC25b and... creating missing data/connections. By testing empty spot in advance, builder recommends collisions based on a Scout bigger than original as long as paths can be mapped/adjusted for Titans and all sort of "Big-Ones", stock pawns can be happy now... and "reachFlags" can be defined too - aerial R_Fly included and operational (as tested already last year...). I'll send builder at people interested as long as I don't have a restricted plan for keeping this very private. Either way in my environment this worked - it was pretty challenging to compile it because... some rules which I don't get were bugging me up to 2:20 AM...

[sektor2111]

New toy was capable to do even some UScript-ed paths-net - known as "Paths Define" command. I didn't like those very much. Probing Scout was intended to setup giant paths, this making invalid routes for clumsy small Bot and then I abandoned this thing as long as I need to figure some 3D traces and rotations which in Editor are... different than in map's Run-Time. These were aiming a clean network and less specs pruning routes into the same direction - it's heavy for my tiny brain... But... for chapter "Box-Jump" which Editor doesn't do even if it's possible, I think I can connect with valid navigation routes these jumpy things without issues - automated. I believe a jump at 280 UU ahead is doable even in "Classic" game settings, so... Why would not have paths connecting these and only these not other jerky impossible paths ?

[sektor2111]

Mmm, I would like to know more about how to figure points oriented in the same direction in Editor in whatever angle but, eh, I'm dumb... This is only what I've got so far:

Code: Select all

...
UScriptDevPath: Scout did not fit for HealthVial7.
UScriptDevPath: Scout did not fit for HealthVial8.
UScriptDevPath: Scout did not fit for HealthVial9.
UScriptDevPath: Scout did not fit for MedBox13.
UScriptDevPath: Scout did not fit for MedBox14.
InventoryPaths: Created InventorySpot Points.
LinkedNavigationList: Linked 366 NavigationPoint actors as Navigation chain.
XCInitialization: Preparing Paths Creator - Sending Range Data.
SpecInit: Creating ReachSpec with Radius 115 Height 110 and Flags 1.
NewSpec: Created ReachSpec 0:
Data: 	- Start	= FlagBase0;
Data: 	- End	= PathNode49;
Data: 	- CollisionRadius = 115;
Data: 	- CollisionHeight = 110;
Data: 	- ReachFlags = 1;
Data: 	- Distance = 196.
Data: ---------------------------
SpecInit: Creating ReachSpec with Radius 92 Height 108 and Flags 9.
NewSpec: Created ReachSpec 1:
Data: 	- Start	= FlagBase0;
Data: 	- End	= PathNode53;
Data: 	- CollisionRadius = 92;
Data: 	- CollisionHeight = 108;
Data: 	- ReachFlags = 9;
Data: 	- Distance = 212.
Data: ---------------------------
....
TheNode: Done with InventorySpot98
UScriptDevPath: Created 833 ReachSpecs.

Fascinating is that I could log from UScript when "Scout did not fit" and WHERE concerning ONLY X and Y because Z it's different in the most of cases, Epic in C++ could not do this... it's like they were paying gold for typing ... What ? No, it's not 469.

[sektor2111]

A more recent work...

Ugly decisions:
- won't map bOneWayPath points - these are doable later - due to fascinating rotation assets from Editor which I could not manage to understand what they do at random;
- won't map Warp-Zones - allowing setting up private WarpZoneMarkers non-crushers;
- won't map bHiddenEd Inventories for preventing spam paths.

Working...

[sektor2111]

Current stage I think will make me to forget original pathing a la Goblin...

Original_Vs_XC_Options.7z

(3.17 MiB) Downloaded 17 times

I've packed the reduced movie captured into a 7z archive since "flv" format it's not accepted as attachment with a direct preview... This XC based builder and helper will go public in next month (if something else won't be needed to be completed).

[sektor2111]

After that discussion about "Memory corruptions" with regard to what function DescribeSpec should do and not other discussions about programing and useless phrases and a so called "ScriptWarning" which 227 and 436 won't spread but it was added in 469 instead of doing things wrapped, let me show you some DESCRIBESPEC executed in UScript using XC assets (yeah, Higor) WITHOUT stories about corruptions if everything has sanity checks and it's being written normally, and in C++ options for wrapping these are more .

Code: Select all

function XCDescribeSpec( int rIdx, Out Actor Start, Out Actor End, Out int Radius, Out int Height, Out int reachFlags, Out int Distance, Out byte bPruned )
{
	local ReachSpec R;
	local Actor tmpStart, tmpEnd;
	local int tmpRadius, tmpHeight, tmpreachFlags, tmpDistance, MaxSpec;
	local byte tmpbPruned;

	MaxSpec = ReachSpecCount();
/*
Setup None cases first here ? Maybe not needed in UScript... and not even temp variables...
*/
	if ( rIdx > -1 && rIdx < MaxSpec ) // NO ACCESS OVER RANGE
	{
		GetReachSpec(R,rIdx);
		tmpStart = R.Start;
		tmpEnd = R.End;
		tmpRadius = R.CollisionRadius;
		tmpHeight = R.CollisionHeight;
		tmpreachFlags = R.reachFlags;
		tmpDistance = R.Distance;
		tmpbPruned = R.bPruned;
	}
	else
	{
		log ("ReachSpecs are ending at "$MaxSpec$".",'NoReachSpec');
	}
	Start = tmpStart; //Capture ALL results including MR. NONE and ZERO-s
	End = tmpEnd;
	Radius = tmpRadius;
	Height = tmpHeight;
	reachFlags = tmpReachFlags;
	Distance = tmpDistance;
	bPruned = tmpbPruned;
}

Well ? The report needs some sanity checker when funky Specs are having Start = None End = None (Your doing not Polge's) as long as calling Start.Name for a None means Accessed None... End of corruptions stories and Script Warnings because I don't need any warnings... and I think it can be more simple than that but... it's not like it hurts something.

[sektor2111]

Evolving chapter it's turned on for XC_PathsWorker. Probably I have now all needs for cleaning and making things normal.
Last option which will be available in next release is moving a ReachSpec without hunting data and wasting too much time.
Options are going to be re-wrapped a bit...

EditMoveCDToAB.PNG (10.36 KiB) Viewed 908 times

Path going from point C to Point D can be moved elsewhere between point A and B. Some data is copied into TempReachSpec if a future editing is needed (such as moving flag or collision) and index of moved path is printed for visual ergonomics.

[sektor2111]

In XC context can be another stuff (those sending me PMs about various A.I. assets might be interested). Talking about XC pathing tools in C++ by Higor or XC_PathsWorker there can be mapped simplified paths without shortcuts, multiple routes through the same door. When Paths are simple, certain Node can cause a better A.I. reaction when it comes to Timed Doors not those which can be triggered directly (MH-SG1 as example). Pawn can be educated to not run in door based or a reach test which usually has a negative response in run-time when a Mover/Door is blocking creature.
I called this Navigationpoint - DoorNode.

Code: Select all

//=============================================================================
// DoorNode.
//=============================================================================
class DoorNode expands NavigationPoint;

event Actor SpecialHandling(Pawn Other)
{
	if ( !Other.bCanOpenDoors )
		return None;

	if ( Other.PointReachable(Location) )
		return Self;

	return None;
}

In stage are required two of them for both directions - coming IN, going OUT. Sample

There a a few chances to fail at random due to movement timing - A.I. vs Door but... in big parts pawn it's more nice than brutalizing a door which cannot be controlled from a nearby trigger or a nearby button.
Edit:Note -> DoorNode is not very helpful when Pawn is "Hunting" - I mean when Pawn has "bHunting=True". In this case nearby (next) node is Reachable even if in plain navigation is being denied.

If map is overcrowded in spot, Pawn might see another way discarding any Smarter Node directive due to alternate options. This is why overcrowding paths it's useless in the process of adjusting A.I. movement for being more smarter. The other node is a temporary locker for spreading "hunters" and slowing down monster insanity. After passing through Node this is locked for a defined time causing A.I. to sort another way during this time.

Code: Select all

class TouchNode expands PathNode;

var bool bTouched;
var() float BlockTime;

event PostBeginPlay()
{
	SetCollision(True,False,False); //Made sure about enabling touch
	RemoteRole = ROLE_None;
}

function Touch(Actor Other)
{
	if ( !Other.bIsPawn )
		UnTouch(Other);
	if ( Other.bIsPawn && !bTouched )
	{
		if ( Playerpawn(Other) == None )
			bTouched = True;
		GoToState('BlockTouching','Touched');
	}
}

state BlockTouching
{
	Goto('Begin');
Touched:
	Disable('Touch');
	if ( bTouched )
		ExtraCost=100000000;
	else
		ExtraCost=0;
//	log(Self.Name$" >> Extracost="$ExtraCost);
	Sleep(BlockTime);
	bTouched = False;
	Enable('Touch');
	if ( Touching[0] != None )
		log( Self.Name@"Touch #1 ="@Touching[0].Name );
	if ( Touching[1] != None )
		log( Self.Name@"Touch #2 ="@Touching[1].Name );
	if ( Touching[2] != None )
		log( Self.Name@"Touch #3 ="@Touching[2].Name );
	if ( Touching[3] != None )
		log( Self.Name@"Touch #4 ="@Touching[3].Name );
Begin:
	ExtraCost=0;
//	log(Self.Name$" >> Extracost="$ExtraCost);
	GoToState('');
}

This can be used in various spots for CTF MH Assault or other suitable situations.

[sektor2111]

Next update concerning prior XC assets will operate in UT up to 459b - which are somehow operational for me, the rest is not for my inventory.
It will be ALL about Love. A very Loved map executed in versions post 469b can be cleaned up by newer spam bytes added due to "improvements" (duplicated/reversal paths - flight paths over ground paths - Pawn is not DENIED anyway due to moving flags and collisions). I did not see newer product, but I see what it does and then I need to have tools for getting rid of logic-less data that was added. These XC assets will work guaranteed in UT versions up to 469b but I have no warranty for next ones as long as each UT version seems to have its own XC stuff due to X changes done in these natives.

I won't show more images in topics of said maps because nobody will do anything than posting some useless answer instead of tackling the problem.
I think option from builder will get called bNoFlightGnd or bNoGndFlight or whatever bNoLousyFly or... something a bit self-explanatory.

I wish everyone a nice day so far !

[sektor2111]

I'm getting something concerning a bit of tweaking for debris... duplicated Specs with different collision data between the same two nodes... such as:

Code: Select all

...
ReachSpec: 909 : Start = PathNode154 End = PathNode1779 ColRadius = 70 ColHeight = 70 ReachFlag = WALK Dist = 627 Pruned = 1.
...
ReachSpec: 11206 : Start = PathNode154 End = PathNode1779 ColRadius = 70 ColHeight = 50 ReachFlag = FLY Dist = 626 Pruned = 0.
...

Initial stage with useless Ground Flight...

And after applying grounding process...

Code: Select all

...
NoFlightNeed: Already connected in reverse InventorySpot5834 to PathNode43 with Walking flag, which means that flight is not Needed.
DuplicatedFlight: Already Connected PathNode154 to PathNode1779.
...

Several paths looks gone but they are NOT. These are just hidden because are shortcuts aka PrunedPaths in Lists. And then...
I think two Temporary options bShowPruned and bHidePruned would be welcomed letting user to know how much charge is in reality loaded inside Level...
Showing Pruned paths will be applied as a stupid hack and map should not be left in this stage, then it comes to reverting them in original (hidden from users).
Solution would be turning them into normal Paths (that are drawn) and storing them in dummy specs added from outside (not from builder). Hiding them will be based on these dummies "saved" ones. This is needed because some maps have more than 1000 junks that are nowhere in the lists but inside maps and nobody can see them - so we need to know which ones were originally hidden. Either way these can be a bit nullified and wrapped with previous version - July 2022.

[sektor2111]

Yep... future version will be able to show (temporary purpose recommended) ALL Paths which a map is hosting - it will reveal PrunedPaths by making them normal and then option for putting them back is automatically switched active, ready for pressing BUILD button again.
And... if original show it's poorly drawn...

If we want to see them (probably a lousy view), they will be like this...

These two options will not alter data from navigation chain - it will only adjust reachspecs in order to fool Editor to draw them by making them normal specs. Reversal option it's just turning them back into pruned specs.

CaveAt: Data for these Paths is stored/saved in some keypoints. It will be recommended cleaning map with XC_EditorAdds because Actors list is grown. Perhaps only examining map without saving it it's recommended in order to plan future optimizations.

That's all so far.