Testing/Debugging Hacks & Tips

[sektor2111]

Another subject.
MH-LandsOfNapali is not only a Map with an Insane number of paths, but I think I got a Hint around some of those looping spots, where Bot is skating between to closer points and... Engine will not deal with paths created by itself - I doubt for other methods used. After setting up stuff for extra "editing eye" if I can use this term, take a look at these two:

[attachment=1]IsThisNormal.PNG[/attachment]

I did random checks around and I did not see two other points to have the same previous path. Probably this explains why Bot is skating there, MBot_G in testing stage do seems to randomly get over that crap. Another spot where Bots were going nasty at random is the start where I could figure another surprise:

[attachment=0]IsThisNormal_01.PNG[/attachment]

Let me guess... Some Editor does need a bit of Love I'm guessing...

Anyway... new Paths Network running with only 762 NavigationPoint Actors works better so far.

[sektor2111]

Bumping ball. Subject: Mapping heavy routes or lifts using XC_Engine.
Snippet below belongs to functions called for spreading navigation points toward lifts and false lifts routes for getting various "geronimo" jumps from A.I. - original map had nothing here, it was messed up. Functions are wrapped without "GoTo" (I haven't got any damage accordingly but... nvm) and without any "return", that simple.

Code: Select all

final function SetLiftExit(LiftExit AnExit, name LiftTag, optional name LiftTrigger)
{
	local bool bInvalidPoint;

	bInvalidPoint = ( AnExit == None || AnExit.bDeleteMe || !AnExit.IsA('LiftExit') || LiftTag == '' );

	if ( !bInvalidPoint )
	{
		AnExit.LiftTag = LiftTag;
		if ( LiftTrigger != '' )
			AnExit.LiftTrigger = LiftTrigger;
		AnExit.PostBeginPlay(); //restart it in order to gain properties correctly
		log(AnExit.Name@has been added at@AnExit.Location);
	}
	else
		Warn("LiftExit or LiftTag undefined. A.I. for this Lift won't work properly.");
	bInvalidPoint = False;
}

final function SetLiftCenter(LiftCenter ACenter, name LiftTag, optional name LiftTrigger, optional float MaxZDiffAdd)
{
	local bool bInvalidPoint;

	bInvalidPoint = ( ACenter == None || ACenter.bDeleteMe || !ACenter.IsA('LiftCenter') || LiftTag == '' );

	if ( !bInvalidPoint )
	{
		ACenter.LiftTag = LiftTag;
		if ( LiftTrigger != '' )
			ACenter.LiftTrigger = LiftTrigger;
		if ( MaxZDiffAdd != 0 )
			ACenter.MaxZDiffAdd = MaxZDiffAdd;
		ACenter.PostBeginPlay();
		log(ACenter.Name@has been added at@ACenter.Location@having as Lift@ACenter.Base@.);
	}
	else
		Warn("LiftCenter or LiftTag undefined. A.I. for this Lift won't work properly.");
	bInvalidPoint = False;
}

Stages for these are delayed with about 0.3 seconds; during this time Movers/Doors are moved to hell for releasing space and making reachable the rest of routes tested by Mr. Scout. When Mr. Scout will finish tests and connections, movers are moved back into the original place and additional points are depleted for connecting any possible lift, this map is not having lifts but some funky door set as a ramp which will need another deal because it has to be navigable AFTER opening. Original Network being too loaded will be completely removed else code will be very long writing stuff for each bad point and wasting time writing connections. Reconfiguration of a new Network is a better option. LiftCenter and LiftExit types used are not bStatic in order to spawn properly. In about 1-2 seconds map will have a new Navigation Network with Points having BOT collision type not Skaarj collision type as Editor does. Less priority tasks are done later as long as are not an emergency, eg: toggling routes using some actors for this task and their triggers more or less connected with map's mechanics depending on situation.
The rest of adds are going to be tested multiple times before other debates.

[sektor2111]

Mr. LoathSome has pointed something about "Do" "Until" coding solutions. I think I have to be grateful for this reminder, I totally forgot them. My NavigationPoint actors are a bit visible by default for editing/coding task. In game this is not that nice to stay visible all time - speaking about Off-Line games. On-Line these are not visible because all pathing stuff is not for client, more than that, not for default client. In order to figure presence of nodes in game if everything is loaded properly, I wrote something simple for fading them (addressing STY_Translucent) after a short time.
After connecting to the network (or creating network more exactly) the are going into a less disturbing visible format as follows:

Code: Select all

.....
Begin:
	ConnectToNetwork();
	Sleep(0.3);
	if ( Level.NetMode == NM_StandAlone )
	{
		do
		{
			ScaleGlow -= 0.02;
			Sleep(0.2);
		}
		until (ScaleGlow <= 0.100000 );
	}
	GoToState('');

Beautiful ! Thank you, Mr. Loathsome, you are The Man.

[MrLoathsome]

@sektor2111

Thanks for the kind words.

Do you happen to remember where you got that tiny bit of code from?

It looks familiar, but I just am not remembering exactly where I used it.

I am thinking it was something I modified from a bit of code in a default effect or animated deco or
something that I found somewhere while staring at random code, but can not remember exactly
what it was actually used in.

If that is actually all mine, then aren't I the clever fellow.

I do like your use of it there with the NavigationPoints as a debugging tool.

And you got the thread back on topic.

Spoiler

This thread continues to deliver, on or off topic.

[sektor2111]

Um, you remembered me about them in a recent mutator related to ScriptedPawn Tweak, I used these in other way for another purpose, indeed I can rewrite some decoration code - I used placards fading from time to time and looping in a state code but definitely won't hurt using <do until>, excepting other <if> testing and I think code goes smaller, of course that is addressing client as long as those things are visuals addressing client, because server won't appreciate "nice" decos looping there for no purpose saving CPU usage from server and letting client to decorate Level using his own client-engine. If I'm thinking well, I believe I can write a permanent state with these breaking iterations constantly and smoothly tracking whatever activity.

[MrLoathsome]

Derp. No wonder I didn't recall it offhand.

The only <do until> in that code is the bit I copied from the wiki quick-sort example.
I just poked at it a bit to support my little structure.