Page 2 of 4

Re: Various XC Works Discussions

Posted: Sun Jan 13, 2019 1:17 pm
by sektor2111
Due to a small discussion/question in XC_Engine megathread toward some maps supposed to not work because of XC_Engine and they might be good without XC_Engine, I think it's time to explain a bit what is about - bad maps have nothing with XC_Engine and neither without it.
iSense wrote: With XC version 22 running on a server, classic maps like:
DM-1on1-flowX
DM-CItyzen

Are still having elevator issues. (Delays up and down)
Apparently map DM-Citizen has the perfect lift. In reality I don't like it and this lift is the same as without XC_Engine.
My thoughts:
- we don't need more than 500 distance between center and Exit - If Editor is causing ugly links just move sh!t ammo away - why do they need to be there ?;
- we don't need that lift timer + placement for LiftCenter - it's not needed in the middle of lift it can be just more Reachable as possible;
- we can set Lift ME_IgnoreWhenEncroach and - chapter is closed (not closet);
- we can add a node on ledge for making down route SHORTER instead of using lift for going down;
- we can use bOneWayPath for preventing taking that lift route on the down way;
- we can remove Node from ramp nearby Armor and adding other on ledge connected with armor and simple discarding RAMP from being used and making A.I. to jump and to use lift at moving up or pawn spawned there. Bots won't get stuck in ramp at this point because there are closer nodes to follow.
These LIFT problems are not generated by XC_Engine, but by mapper himself.
Map is very well designed - respect for that. The problem of Lift can be adjusted with a patch plugin but... why not having stuff correctly for everyone.
________________
Next: DM-1on1-flowX
Speaking about Lift Issues ? No speech... simple as that. That one has ZERO PATHS at lifts so we cannot speak about bugs but about ZERO SKILL in mapping lifts. If I'm posting a "screenshot" you'll figure what paths are those - such a mess won't sit in my grounds without patching or... remaking map. So far I will remove it because I find it useless. I think author was confusing PathNodes with Lights :loool: .

To summarize: you can stop blaming XC_Engine for your junk UNR files supposed to be maps.

Why discussion in XC thread ? Because XC_PathBuilder for UT Editor can help in controlling path links without adding extra routes bugging jumps around. Such a pathing task won't be done (without being a bit naughty) in default Editor's devs because Epic won't fix anything for UT'99 - they don't really care about it.
Asking for Editor improvements ? They are done - do USE them.

I suppose it's useless to ask mappers a question for personal curiosity:
Have you ever noticed that some ammo have at default properties PHYS_Falling ? Usually here comes that "fell out of world" thing. Can you stop happening this ? Because I can - it takes 10 seconds or 15 if I'm sleepy.
ConsoleCommand in Editor <set Ammo bSelected 1> right click then for all Ammo - defaultproperties - Movement - Physics -> PHYS_None - end of story.

Re: Various XC Works Discussions

Posted: Sun Jan 13, 2019 2:52 pm
by Barbie
sektor2111 wrote:I suppose it's useless to ask mappers a question for personal curiosity:
Have you ever noticed that some ammo have at default properties PHYS_Falling ? Usually here comes that "fell out of world" thing. Can you stop happening this ? Because I can - it takes 10 seconds or 15 if I'm sleepy.
ConsoleCommand in Editor <set Ammo bSelected 1> right click then for all Ammo - defaultproperties - Movement - Physics -> PHYS_None - end of story.
Have you tried this? When you select all Actors you don't have to change the default properties. This would be useful before starting spreading Ammo in the map. If you set the property PHYSICS to PHYS_None for all existing Actors, this will neither prevent Actors from "falling out of the world".
Instead the reason for this is that Actors' pivot point is already out of the world when starting the map. You can check this by inspecting Actor.Region.iLeaf what is negative (-1) in this case.

Re: Various XC Works Discussions

Posted: Sun Jan 13, 2019 10:07 pm
by sektor2111
Um... first move is firing builder. What does it do ? I will put actor on INT coordinates in 3D space Int(Location.X) etc Y etc Z. After this move engine will attempt to put them back if are not badly messed up. The rest of ammo things are... discovered by Mr. Scout. Else ammo and actors generally are not moved in void by engine, that's mapping goofing.
Before adding paths I'm changing properties but after closing Editor they are back in original, map is having PathNode in original because actor claimed a default property unchanged - I think class should stay in default and actor from map should be edited for causing "changes" which are in account in run-time else default is default and might mess with replication if actor doesn't look changed... I think... feel free to experiment with BioAmmo placed in air... Changing property before adding in map and after placing - I would be curious to see what's the deal.
If you check one of my recent maps or modified maps I changed PathNodes before placing them. Now if you open map you'll see them 50×46 at cylinder because I've added them as in default properties, if default properties were other ones with other values that's another story but they have original default properties according to engine used - a hacked engine will show other values accordingly... I think...
I'll go for a small test and I will report result later.

Edit: A big NOPE.
If you want your ammo with Physics NONE you have to change them AFTER placing in map and NOT Before, else if default properties are changed and used, ammo will have "defaultproperties" - like they have in BotPack, LOL, and still falling in run-time...
Let's check some ammo changed Before and After.
Properties changed for ammo in map

Code: Select all

Begin Map
Begin Actor Class=BioAmmo Name=BioAmmo2
    bDynamicLight=True
    Physics=PHYS_None
    Level=LevelInfo'MyLevel.LevelInfo0'
    Tag=BioAmmo
    Region=(Zone=LevelInfo'MyLevel.LevelInfo0',iLeaf=9,ZoneNumber=1)
    Location=(X=328.000000,Y=-264.000000,Z=-96.000000)
    OldLocation=(X=328.000000,Y=-264.000000,Z=-248.000000)
    bSelected=True
    Name=BioAmmo2
End Actor
End Map
And ammo changed BEFORE adding.

Code: Select all

Begin Map
Begin Actor Class=BioAmmo Name=BioAmmo2
    bDynamicLight=True
    Level=LevelInfo'MyLevel.LevelInfo0'
    Tag=BioAmmo
    Region=(Zone=LevelInfo'MyLevel.LevelInfo0',iLeaf=9,ZoneNumber=1)
    Location=(X=224.000000,Y=-321.000000,Z=-83.000000)
    OldLocation=(X=224.000000,Y=-320.000000,Z=-248.000000)
    bSelected=True
    Name=BioAmmo2
End Actor
End Map
Can you see the difference ? In first case property is in account, in second case it's not because it's a default thing, and will be a default in run-time according to original property disregarding your newer defaulted.

Re: Various XC Works Discussions

Posted: Mon Jan 21, 2019 6:33 am
by sektor2111
I will have to figure out how I can turn a two-way path into a one-way one. This could help in some maps of MonsterHunt where Bots walk without purpose in the areas already visited without being a little more determined to move forward. It will not be necessary to completely disconnect the navigation point, just one of the Start End paths, the one that connects with the area already visited.
Virtual snippet :???:

Code: Select all

function DisconnectPath(NavigationPoint P1, NavigationPoint P2)
{
	local ReachSpec R;
	local int i, RI;

	if (P1 == None || P2 == None)
		warn("Disconnecting path requires TWO points, check the script and retry.");
	else
	{
		ForEach AllReachSpecs( R, RI)
		{
			if ( R.Start == P1 && R.End == P2 )
			{
				R.Start = None;
				R.End = None;
				R.bPruned = 0;
				R.Distance = 0;
				R.CollisionHeight = 0;
				R.CollisionRadius = 0;
				SetReachSpec( R, RI);
				CompactPathList(P1);
				CompactPathList(P2);
				break; // stop here or keep running ?
			}
		}
	}
}
Also now I have to think if I need to put it in a module declared as XC_Actor or to be a separate part used by NavAdder plugins.

Re: Various XC Works Discussions

Posted: Mon Jan 21, 2019 12:36 pm
by Barbie
sektor2111 wrote:Edit: A big NOPE.
So this leads to the conclusion that not only in T3D format but in binary format also (the map in this case) only Actor properties are stored that are different from the default value.

Re: Various XC Works Discussions

Posted: Mon Jan 21, 2019 4:44 pm
by sektor2111
After working on some modules for NavAdder I could see what happens when these default properties are different from server to client. The server says "default property" for Actor A. The client may have other default properties for Actor A, if we have a rebel code executed in the client changing these, and then we have two different things even if they are both defaults. If that value is declared in replication and the server knows it is not the default one, it will be passed to the client as it is causing an actor change. It has happened to me, but I do not correct anything because I want ... an educational memory about "how not to do". If client has problems with the garbage collector, in the next map will notice changes, it will have different default properties.

The editor is not that different about these default properties. I can change them but ... remain default properties which, depending on the properties of the machine that they are running, behave as they are. In this case, about 6 types of ammo fall (TournamentAmmo here), that's their physical property - default one: BioAmmo, BulletBox, EClip, RifleShell, RocketPack, ShockCore, SuperShockCore (useless one).

Edit: I think I forgot something in above blabbering post iterator.

Code: Select all

R = None; //...

Re: Various XC Works Discussions

Posted: Mon Jan 28, 2019 12:45 am
by sektor2111
I went into a problem for compiling this One-Way stuff - removing path between Point1 and Point2, iterator returning a mismatch thing toward that ReachSpec.....
Plan B entered the game.

Code: Select all

function DisconnectPath(NavigationPoint P1, NavigationPoint P2)
{
	local Actor Start, End;
	local int distance, reachFlags, i, j;

	if (P1 == None || P2 == None)
		warn("Disconnecting path requires TWO points, check the script and retry.");
	else
	{
		for ( i=0; i<16; i++ )
		{
			if ( P1.UpstreamPaths[i] != -1 )
			{
				P1.DescribeSpec( P1.UpstreamPaths[i], Start, End, reachFlags, distance );
				if ( End == P2 )
				{
					P1.UpstreamPaths[i] = -1;
					G.CompactPathList(P1); //Mr. G is a child of XC_Engine_Actor
					break;
				}
			}
		}
	}
}
This one can be compiled... but I want to test if strategy is helpful.
If Not, there is a Plan C inside my neuronal network so far.
What I want here ?
In certain maps a la MH-ICERedone..blabla, after connecting everything properly and remapping MonsterWayPoints, when teleporters are locked temporary, Bots having no goal are trying to roam around and they want to move away. Because I want them restricted from being idiots, I'm willing to lock routes back to main Spawn Area as long as all that blabbering it's a waste of time.
2 routes are disconnected here according to 2 lifts LiftCenter with first entrance point LiftExit - Editor won't make such paths as I could see. If any mapper needs such things they have to be added in map as auto-editing actors operating changes in run-time else dumb things are still inside.
The only need I think would be "CompactPathList(NavigationPoint N)" to be written in UScript for such a tactical move. If that function does what I'm thinking, it shouldn't be hard writing it.
A small actor for MyLevel might be doable for such special situations but I don't think such a release is helpful for someone. Last time people proved that have no trails of any clue about lifts (regarding to tutorials and stock samples) - oops, Doors - those are not lifts, btw...

Edit: Jumping ahead.
Hmm ... this method is too complex, we need to take into account the other point that still has a similar path - both of them must be checked, too many iterations.
We get drunk and jump over Plan C directly to Plan D, which is simple but particular to each navigationpoint and it's kind of like this:

Code: Select all

		foreach NavigationActors(class'PathNode',Pa,30,vect(-1123,-2784,-726)) //Using XC quick iterator in spot
		{
			if (string(Pa.Name) ~= "PathNode21")
			{
				Pa.Paths[0] = -1; //useless path is reported by smarty builder - removing it from node's list
				G.CompactPathList(Pa); //assuming it helps
				break;
			}
		}
		Pa = None;
		foreach NavigationActors(class'PathNode',Pa,30,vect(-1073,-1806,-729))
		{
			if (string(Pa.Name) ~= "PathNode18")
			{
				Pa.UpstreamPaths[0] = -1;
				G.CompactPathList(Pa);
				break;
			}
		}
		Pa = None;
/* Route back to spawn location is now blocked - only advancing is possible - DONE, Tested, working, Lifts are a charm and everyone is getting loaded in secondary spawn location without leaving zone.
*/
Post Note: Now I think I can use in mapping a particular add-on in MyLevel for self-editing when borks are encountered and Goblin is getting mad - I know some stock maps with isolated problems - It's time for loving them.
Greetings at Higor.

Re: Various XC Works Discussions

Posted: Wed Jan 30, 2019 2:00 pm
by sektor2111
January 30 2019.
Today I learned how to manually create one-way paths when the Editor does not help us. The strategy is simple but requires some tools, unwanted paths are not destroyed, just removed from the lists and we have what we want. I would have liked to deduce other tricks related to geometry ...
In the past, I have worked hard to gain what is really simple. I'm curious if a tutorial will ever describe some of the editing tricks that can be done without creating any problems in the final result. I do not have the language and hardware resources to do a video tutorial so I expect someone else to do it. I can only provide a minimum of information that can be taken as the basis for explanations.

Re: Various XC Works Discussions

Posted: Wed Feb 13, 2019 8:51 pm
by sektor2111
Off-topic or On-topic? - this is the question.
Not once I witnessed the incredible effect of EAdjustJump() - it's native if I'm not mistaking ...
Two or three Bots were playing a map without any fire and any kill for a while. Why ? Because all 3 morons were busy: 1st to jump through holes or from a ledge never landing down due to jump directive and landing exactly on the same floor, 2nd busy at Hitwall vs Ledge looping nearby RocketLauncher, 3rd waiting in some ambushpoint a virtual enemy which is way to idiot for navigating map properly, not MBot case that much, but... still having this "jump-through-hole" problem...
These happens at random in DM-Grit-Tourney and others having similar spots: Path from InventorySpot98 to PathNode14 requires a jump through a hole which usually it's a failure...
[attachment=0]GT_LoopSpot.PNG[/attachment]

And now toward first question: If this EAdjustJump() or whatever crapped ledge deal can be solved in native movement code, it would be a hard fix without screwing other spots requiring this jump with any mater ? A trace from head to Actor target reducing jump strength if trace is not clean or too far, etc. - under a boolean of course for being disabled in case of problems.
Assuming 0 people are interested because no one asked this before, I've done something for such known borked spots and even in advance:

Code: Select all

NavAdder: Found module, attempt loading...
ScriptLog: Tagging with Grit-TOURNEY
GRIT-TOURNEY: PathsMapper0 Patching Level.
GRIT-TOURNEY: Attempting to screw up Evil NavigationPoint actors...
GRIT-TOURNEY: Hacking PathNode24.
GRIT-TOURNEY: Hacking PlayerStart11.
GRIT-TOURNEY: Hacking LiftExit1.
GRIT-TOURNEY: Hacking LiftExit10.
GRIT-TOURNEY: Hacking InventorySpot107.
GRIT-TOURNEY: Hacking InventorySpot98.
GRIT-TOURNEY: Evil NavigationPoint actors have been screwed up...
GRIT-TOURNEY: PreBeginPlay Completed...
NavAdder: Module has been started...
Alternate patch method:
Spawning an Invisible actor blocker (not player blocker) and causing a deliberated jump-failure in such spots when moron jumper is hitting this blocker during flight and causing a fall through the hole (I've done this somewhere in a MH map), and a blocker can be spawned even later in game, I think...

Re: Various XC Works Discussions

Posted: Thu Feb 14, 2019 9:01 pm
by sektor2111
Here (I can still manage to not throw up) will be debated subject "AND" as follows:

We have maps and a server 451 and XC_Engine and... duplicated actors - this usually is not a big problem but maybe it was in prior versions like v21, and the crash:
CrashLog_versionXwhatever wrote: Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel51
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel52
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel53
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel54
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel55
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel56
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel57
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel58
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel59
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel60
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel61
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel62
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel47
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel63
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel43
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel44
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel49
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel50
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel48
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel45
Log: Undeleted TarydiumBarrel DM-!DSF!-Harbour-Nights-v3-Rm.TarydiumBarrel46
Critical: appError called:
Critical: Assertion failed: FieldCache [File:R:\Projects\nacput\Utpg\Engine\Src\UnChan.cpp] [Line: 1092]
Exit: Executing UObject::StaticShutdownAfterError
Critical: ReplicateThem
Critical: UActorChannel::ReplicateActor
Critical: (Actor UT_LightWallHitEffect0)
Critical: UpdateRelevant
Critical: ULevel::ServerTickClient
Critical: ULevel::TickNetServer
Critical: UXC_Level::TickNetServer
Critical: UpdateNetServer
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Exiting.
Uninitialized: Name subsystem shut down
If anybody have that drive R: containing UnChan.cpp file I would like to drop an eye over it... :ironic: Let me see, the wizard engine 451 was trying to replicate an actor deleted by itself which went NONE ? Keep working with None then... :lol2:
And then... this
Crashlog_anotherversion wrote: ScriptLog: Couldn't spawn player at DM-{MM}-1-Funnel-6v2-RM1.PlayerStart21
ScriptLog: Failed to spawn bot.
...
...
Critical: appError called:
Critical: DeathMatchPlus DM-{MM}-1-Funnel-6v2-RM1.DeathMatchPlus0 (Function Botpack.DeathMatchPlus.FindPlayerStart:0484) Runaway loop detected (over 10000000 iterations)
Exit: Executing UObject::StaticShutdownAfterError
Critical: FFrame::Serialize
Critical: AXC_Engine_Actor::execPawnActors
Critical: ScriptDebugV
Critical: DeathMatchPlus0.FindPlayerStart
Critical: ScriptDebugV
Critical: DeathMatchPlus0.SpawnBot
Critical: ScriptDebugV
Critical: DeathMatchPlus0.AddBot
Critical: UObject::ProcessEvent
Critical: (DeathMatchPlus DM-{MM}-1-Funnel-6v2-RM1.DeathMatchPlus0, Function Botpack.DeathMatchPlus.Timer)
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Exiting.
Uninitialized: Name subsystem shut down
You don't wanna see where was this "StartOfPlayer" stuff... :loool:
And this problem has been debated here:
A_Log wrote: ScriptLog: Check prelogins... DM-[SHX]Playground-Rm.XC_Engine_Actor5
SpawnFixer: XC_SpawnFixer0 in state SpawnTesting is testing PlayerStart actors.
SpawnFixer: Probing spawn on PlayerStart63 failed, taking action...
....
....
ScriptLog: Check prelogins... DM-{BK}-Laundry-V2-Rm.XC_Engine_Actor22
SpawnFixer: XC_SpawnFixer0 in state SpawnTesting is testing PlayerStart actors.
SpawnFixer: Probing spawn on PlayerStart28 failed, taking action...
...
...
DevNet: NotifyAcceptingChannel Control 0 server Level DM-Evil's-SymmetryRMX.MyLevel: Accepted
DevNet: Level server received: HELLO REVISION=0 MINVER=400 VER=436
SpawnFixer: XC_SpawnFixer0 in state SpawnTesting is testing PlayerStart actors.
SpawnFixer: Probing spawn on PlayerStart43 failed, taking action...
XC_Engine: Set XC_ServerActor DM-Evil's-SymmetryRMX.XC_ServerActor26 as AdminLoginHook
....
....
DevNet: NotifyAcceptingChannel Control 0 server Level DM-((POT-RedeemerSNIPER-Heaven)).MyLevel: Accepted
DevNet: Level server received: HELLO REVISION=0 MINVER=400 VER=436
SpawnFixer: XC_SpawnFixer0 in state SpawnTesting is testing PlayerStart actors.
SpawnFixer: Probing spawn on PlayerStart0 failed, taking action...
SpawnFixer: Probing spawn on PlayerStart2 failed, taking action...
SpawnFixer: Probing spawn on PlayerStart3 failed, taking action...
SpawnFixer: Probing spawn on PlayerStart8 failed, taking action...
And after those, crashes have been ruined, but I think these will never end, they are based on a continuous trash supply task called "fancy mapping" with 25 MB or 40 MB of umx files used, and which some players are turning OFF in order to HEAR ENEMY and to figure a suitable tactical solution instead of shaking heads legs hands and whatever floppy stuff which they have during some music which in some cases has nothing in common with map - it's just trash to download.

Re: Various XC Works Discussions

Posted: Thu Apr 04, 2019 10:29 pm
by sektor2111
For a higher quality of some sort of Server-Tool-Mutator used to load some weapons - including for Bots without errors (actually I did not see any Bot loading weapon errors here) containing a sort of SkaarjCode but loved a bit, I did some changes to previous things done. The deal is using those mystic dynamic arrays which have some... good usage in company of XC_Engine. If predecessors were working error-free by setting up INI file properly, this one doesn't need empty positions for capping array checks, it uses XC_Engine for getting array length. These arrays containing Weapons and Ammo are like default known Arrays ServerPackages and ServerActors but... they do have weaponry content and a dynamic load - 3 weapons or 5 weapons or 12 weapons... Mutator works fine in XC_Engine v21 (other versions don't work in this cute old machine of mine). Out of XC_Engine mutator won't do anything, probably even crashing game...
The Thing:

Code: Select all

class LoadWeapon expands Mutator config (LoadWeapon);

var() config array<string> AWeapon;
var() config array<string> AnAmmo;
var() config float AmmoScale;
var bool bEnabled, bInitialized;
var int i, k;

const version="1.01";

//XC_Engine in here
native(640) static final function int Array_Length_Str( out array<string> Ar, optional int SetSize); //This was what I needed
native(641) static final function bool Array_Insert_Str( out array<string> Ar, int Offset, optional int Count ); //Leaving these because don't hurt
native(642) static final function bool Array_Remove_Str( out array<string> Ar, int Offset, optional int Count );

event PostBeginPlay()
{
	if ( !bInitialized )
	{
		log ("LoadWeapon version"@version@attempt initialization process...,'LoadWeapon');
		if ( int(ConsoleCommand("GET INI:ENGINE.ENGINE.GAMEENGINE XC_VERSION")) < 20 )
		{
			Log ("Could not find a suitable XC_Engine version for Dynamic Arrays.",'LoadWeapon');
			Log ("Please refrain from doing dumb things, it's not helpful.",'LoadWeapon');
			Goto DONE;
		}
		i = 0;
		if ( AmmoScale <= 0.2)
			AmmoScale = 0.2;
		DoInit();
Done:
		if ( bEnabled )
			log (Self.Name@has been Initialized.,'LoadWeapon');
		else
			log (Self.Name@has encountered a bad configuration, it will not load anything...,'LoadWeapon');
		bInitialized = True;
	}
}

final function DoInit()
{
	local bool bKeepGoing;
	local class<Weapon> W;
	local class<Ammo> A;
	local int NumWep, NumAmmo;

	NumWep = Array_Length_Str(AWeapon);
	NumAmmo = Array_Length_Str(AnAmmo);
	if ( NumWep != NumAmmo )
	{
		log ("Bork >> Number of Weapon Types is different from Number of Ammo Types configured",'LoadWeaponErrConfig');
		log ("The Mutator Rule Is: Giving Weapon and Ammo accordingly. We have"@NumWep@weapon types and@NumAmmo@ammo types.,'LoadWeaponErrConfig');
		ConsoleCommand("QUIT");
		return;
	}
	else
		log ("Array scanning task has detected configured"@NumWep@weapon types and@NumAmmo@ammo types.,'LoadWeaponConfig');
	for ( i=0 ; i<NumWep ; i++ )
	{
		if ( AWeapon[i] != "" )
			W = class<Weapon>( DynamicLoadObject(AWeapon[i], class'Class', True) );
		if ( W == None )
		{
			log ("Unable to load"@AWeapon[i]@it's probably some bullshit fake class. Breaking deal...,'LoadWeapon');
			bKeepGoing = False;
			break;
		}
		else
			bKeepGoing = True;
		if ( AnAmmo[i] != "" )
			A = class<Ammo>( DynamicLoadObject(AnAmmo[i], class'Class', True) );
		if ( A == None )
		{
			log ("Unable to load"@AWeapon[i]@it's probably some bullshit fake class. Breaking deal...,'LoadWeapon');
			bKeepGoing=False;
			break;
		}
		else
			bKeepGoing = True;
	}
	if ( bKeepGoing )
	{
		W = None;
		A = None;
		bEnabled = True;
	}
	else
		GoTo Initialized;
	k = NumWep;
Initialized:
}

function ModifyPlayer (Pawn Other)
{
	local class<Ammo> Am;
	local class<Weapon> Wp;
	local Ammo A;
	local Weapon W;

	if ( Other.PlayerReplicationInfo == None && Other.bIsPlayer )
		GoTo FagitronSet;
	if ( bEnabled )
	{
		for ( i=0; i<k; i++ )
		if ( !Other.bHidden )
		{
			Am = class<Ammo>( DynamicLoadObject(AnAmmo[i], class'Class', True) );
			if ( Am != None )
			{
				A = Spawn (Am,,,Other.Location,Other.Rotation);
				if ( A != None )
				{
					A.SetPhysics(PHYS_None);
					A.Enable('Touch');
					A.Enable('UnTouch');
					A.RespawnTime = 0.00;
					A.AmmoAmount *= AmmoScale;
					A.Touch(Other);
				}
			}
			Wp = class<Weapon>( DynamicLoadObject(AWeapon[i], class'Class', True) );
			if ( Wp != None )
			{
				W = Spawn(Wp,,,Other.Location,Other.Rotation);
				if ( W != None )
				{
					W.SetPhysics(PHYS_None);
					W.Enable('Touch');
					W.Enable('UnTouch');
					W.RespawnTime = 0.00;
					W.Touch(Other);
				}
			}
			Am = None; A = None; Wp = None; W = None;
		}
	}
	Super.ModifyPlayer(Other);
FagitronSet:
//Ruin chain for shite
}

defaultproperties
{
	AmmoScale=2.000000
}
The INT:

Code: Select all

[Public]
Object=(Name=LoadWeaponM.LoadWeapon,Class=Class,MetaClass=Engine.Mutator,Description="Load These Weapons - DynArray - V1.01")
Preferences=(Caption="Load These Weapons V1.01",Parent="Mutators",Class=LoadWeaponM.LoadWeapon,Immediate=True)
The INI:

Code: Select all

[LoadWeaponM.LoadWeapon]
AWeapon=BotPack.PulseGun
AWeapon=BotPack.UT_Eightball
AWeapon=BotPack.UT_FlakCannon
AWeapon=BotPack.ShockRifle
AnAmmo=BotPack.PAmmo
AnAmmo=BotPack.RocketPack
AnAmmo=BotPack.FlakAmmo
AnAmmo=BotPack.ShockCore
AmmoScale=20.000000
And tomorrow I'll go to the doctor for removing wires from my mouth...
To not forget Umake.ini

Code: Select all

; Generated by UMake

[Engine.Engine]
EditorEngine=Editor.EditorEngine

[Editor.EditorEngine]
CacheSizeMegs=32
EditPackages=Core
EditPackages=Engine
EditPackages=XC_Engine
EditPackages=LoadWeaponM

[Core.System]
Paths=*.u
Paths=../Maps/*.unr
Paths=../Textures/*.utx
Paths=../Sounds/*.uax
Paths=../Music/*.umx
And then I'll change the cousin mutator which I was using for loading a RANDOM weapon from such an array...

Re: Various XC Works Discussions

Posted: Sat Dec 07, 2019 11:07 pm
by sektor2111
Leaving aside the problems with the collision I think it's time (related to the Editor) to see what else would help us to know when these maps are ruined in the navigation chapter, respectively when we have more than 3000 ReachSpecs. Given the constant in the engine, I tend to believe that DevPath stops when this limit is exceeded. I don't know if version 436 has a higher value, but ... we can find out the number of reachspecs using regular Uscript - it probably doesn't have high accuracy but it can help us to make the navigation network simpler and easier. The XC_Engine iterators didn't help me with the Editor's editing environment and then I used stock methods.
What prompted me to write such a function in MapGarbage? The last mapping sessions and posted "works" were not as convincing as the mapper knows how to configure. Because what I saw was kind of crazy, I was curious how many navigation specifications were created and if this stupid mapping method helps.
Maybe in the future we will have something like this in XC_EditorAdds...
Report Sample:

Code: Select all

NumReachSpecs: This map has 3535 ReachSpecs.
And then I think that explains why Bots are confused here and there and have strange reactions, we simply skip over what the engine has as normal capabilities and foolishly useless trying vainly to go beyond the limits defined by the engine.
One more ugly phase is that in this map we have these specifications taken from the navigation network. When we delete the navigation network using the Editor it logs exactly how much garbage is actually on the map, even if the data is not visible in the navigation points:

Code: Select all

...
DevPath: Remove 21983 old reachspecs
Log: Collecting garbage
Log: Purging garbage
Log: Garbage: objects: 45144->44963; refs: 797933
... and then I need to correct the logging from the console (from reconstructed map):

Code: Select all

NumReachSpecs: This map has 592 ReachSpecs shown in Navigation Network.
Since they are built with XC_EditorAdds, there seem to be no garbage specifications anymore. When deleting the network using the Editor it seems we have only the specifications set out in the navigation and nothing else:

Code: Select all

DevPath: Remove 592 old reachspecs
Log: Collecting garbage
Log: Purging garbage
Log: Garbage: objects: 45040->44968; refs: 796313
Now I realize how clean XC_EditorAdds works without leaving any junk behind.
Edit:
I'm gonna count Shortcuts aka PrunedPaths as well...

Re: Various XC Works Discussions

Posted: Thu Jan 30, 2020 6:31 pm
by sektor2111
I was working to a function from MapGarbage intended to drop away paths heading from a teleporter to a node - usually teleporters are throwing pawn away when are touched. Paths out of destination URL for me are wrong because I'm not sure if pawn can follow them - except teleporters without URL. By writing a raw solution that can be used even out of XC_EditorAdds but... XC is helpful for images, I wrote something like "CompactPathsList" from XC aka Defragmenting these using UScript because I don't know that native, I did not see it. Outside of XC_Engine or combined with it, right during map editing I can use with builder such thing - of course for UpstreamPaths is similar.
Instead of having 10 -1 233 301 -1 ect, we will have 10 233 301 -1 -1 ect. -1 values being in tail of array as Editor does in original with meaning no reachSpec is linked there.

Code: Select all

function DefragPaths(NavigationPoint N)
{
	local bool bInvalid;
	local int i, np, cnt;
	local int wrap[16];

	bInvalid = ( N == None || N.bDeleteMe );

	if ( !bInvalid )
	{
		for ( i = 0; i < 16; i++ )
		{
			wrap[i] = N.Paths[i];
			N.Paths[i] = -1;
		}
		cnt = 0;
		for ( np = 0; np < 16; np++ )
		{
			if ( wrap[np] != -1 )
			{
				N.Paths[cnt] = wrap[np];
				cnt++;
			}
		}
	}
	else
		log("Borked - DefragPaths Entry ( NavigationPoint == None )",'PathsListDefragmenter');
}
Huh ?

Re: Various XC Works Discussions

Posted: Sun Oct 11, 2020 10:21 am
by sektor2111
The other thing is... if 469 + XCv25+ will have that "feature" in DevPath to switch to Translocator when enemy it's in front of me then I'll revert it to default DevPath, seriously these changes have never been asked by anybody, it makes me to die when enemy is closer and I cannot fire because weapon was switched automatically and the delay created by switching weapon was helpful for enemy. If Bot(/s) used is(are) a smarter one(s) than those stock losers, he/she will switch weapon in a suitable situation and not brute-forcing everyone for no reason.
And then... What does it do default Translocator ? Let me see... if Bot wants to use it and fails for some reason (usually crapped up combo paths) TranslocatorTarget projectile falls on the ground. Moron at random starts shooting its own Translocator thing... plain retarded. Not a single time I witnessed this "facility" and it's why I'm using another sub-class of said "Translocator".

Like I said already, ANY of these "news" must be controlled by a boolean variable for being disabled when are damaging - including "sub-features".

Re: Various XC Works Discussions

Posted: Sat Nov 07, 2020 4:57 pm
by sektor2111
Ahem... I was thinking right now at something which I think I find... confusing a bit...

Personal Notes:
Editor Goblin was making thousands of paths through lifts and teleporters having reachFlag 32. I'm not sure if this is fair. Coop SP map where monster is a main character in game should not have these locks as long as poorly brained creatures can still use AlarmPoints, PatrolPoints, and the rest of attacking capabilities.
R_Special will block all of them even if a lift can held a monster and a teleporter can teleport monsters too...

I think... for XC_Engine V24 or whatever I might be willing to setup a True DeathMatch. Lousy reachSpecs R_Special might be edited in run-time before to initialize game and switched to R_Walk + R_Jump - of course, not all of them. TranslocStart and TranslocDest are not the best option when it comes to monsters, if reachFlag is properly set, SpecialHadling from these Bot-Things is not going to do more damage, but a LiftCenter and LiftExit are not having troubles and neither teleporters. If these are modified properly, I think the DeathMatch with Monsters will have another Level.

I don't know how many UT users are aware of what I'm talking about here...

Edit: I don't think I'm alone at this thinking - XC_Engine has something, I don't think is a bug (okay, teleporters are having... no distance):

Code: Select all

	if ( !bConnected )
	{
		R.Start = Start;
		R.End = End;
		R.ReachFlags = R_WALK | R_JUMP;
		if ( Start.Region.Zone.bWaterZone || End.Region.Zone.bWaterZone )
			R.ReachFlags = R.ReachFlags | R_SWIM;
		if ( Start.IsA('LiftCenter') || End.IsA('LiftCenter') )			R.Distance = VSize( Start.Location - End.Location) * 0.2;
		else if ( Start.IsA('Teleporter') && End.IsA('Teleporter') )	R.Distance = 0;
		else															R.Distance = VSize( Start.Location - End.Location);
		R.CollisionHeight = 50 * Scale;
		R.CollisionRadius = 25 * Scale;
		AddReachSpec( R, true); //Auto-register in path
	}
EDIT2:
There is nothing more frustrating than a short time happiness... XCv24 stage. Testing mod outside in Win7.

Code: Select all

Critical: appError called:
Critical: XC_PawnLift UT-Logo-Map.XC_PawnLift1 (Function XC_PawnLift.XC_PawnLift.XC_Init:0038) Unknown code token 09
Critical: FFrame::Serialize
Critical: XC_PawnLift1.XC_Init
Critical: GeneralConfig.Setup
Critical: UObject::ProcessEvent
Critical: (XC_Engine_Actor UT-Logo-Map.XC_Engine_Actor0, Function XC_Engine.XC_Engine_Actor.XC_Init)
Critical: BeginPlay
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: UGameEngine::Init
Critical: UXC_GameEngine::Init
Critical: UXC_ServerCommandlet::Main
Unknown token code for its own function V24 - excuse me but I cannot work this way. In primary WinXP environment it worked properly...
XC_Init is called for XC_Engine_Actor types by XC_Engine itself - now it says unknown code after compiling actor successful in the same environment. Pretty "Entertaining".
Edit2:
Solved - maps not intended for game-play are excepted from... "run-time editing" - yeah, I don't need to process anything for no purpose - now I do have paths.
UT Paradox: The more poorly are reachFlags the more extended is navigation... Geez !