XC_Engine [20] - XC_Core [7b] - XC_IpDrv

User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

BTW about traces, visuals and such stuff. You have posted previously a Test map using PlayerCanSeeMe(). Because I have a curiosity like rats I was interested to see what's going on with the most of UScript visual related features:
- LineOfSight
- FastTrace
- CanSee

Results.... hmm... :? I have added an ON-Screen broadcast. Conclusion It was a good move of mine to change at pawns CanSee with LineofSight. Why ? Feel free to see how is acting CanSee at closer ranges... I think is a piece of crap too and maybe it needs more accuracy. It's just changing frequency to True/False with each tick or ???? WTF ????. I cannot tell distance with precision but... What should I expect then from some ScriptedPawn code:

Code: Select all

if ( (aPawn.IsA('PlayerPawn') || aPawn.IsA('ScriptedPawn')) //again bullshiting checks - Thanks for this awesomeness
					&& (VSize(Location - aPawn.Location) < 500)
					&& CanSee(aPawn) ) //YES IF... IF CAN SEE, because I have certain doubts
				{
					if ( SetEnemy(aPawn) )
					{
						GotoState('Attacking');
						return;
					}
				}
Exactly under this 500 range it might be skating to false a lot of times. Is this fixed in UTPG's works ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Evaluate the tracer's bLOSflag.
It has a LOT to do with how CanSee and LineOfSightTo behave...
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

I'm just wondering if you can debate a bit situation related to Inventories. It was amazing to see dumb stuff added for mapping contest. Some people cannot deal with bRotatingPickup and they like to mess up with bStatic set for weapons in purpose to stay, troubles start when humans wants some of them. Anyone checked logs? If cannot be done then I have to recode game-types used in order to properly ruin these brain-farts, and those were only half or troubles. For mapping contest that one has also Bot Pathing somehow messed, eh... Editor shown blues/reds, but in game NONE.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Fix the map if it has an issue.
If you licensed the engine, it's the licensee's responsibility to properly use the engine's capabilities.
A similar logic can be applied to mapping.

On a second note, I've managed to port the InvSqrt and Reciprocal methods to Linux using SSE ASM, the octree speed gain was absurd but some other change of mine has made it unstable on v436 Linux, also the v451 garbage collector no longer crashes the game if called manually, but still crashes during mapswitch.
I'm gonna have to change the structure of a lot of things...
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

Okay I'll share a solution if you are agree (it works at this moment but maybe you want to do a revision...)

Code: Select all

event InitGame( string Options, out string Error )
{
	local string InOpt;
....
....
	SolveWepsy();
....
....

function SolveWepsy()
{
	local Inventory I;
	local string Sc;

	foreach AllActors(class'Inventory',I)
	{
		if ( I != None )
		{
			if (I.bStatic)
			{
				log(I@"is wrong set bStatic...");
				Sc = Caps(I.Class);
				Sc = "set"@Sc@"bStatic 0";
				ConsoleCommand(Sc);
				I.bRotatingPickup=False;
				log (I@"has now bStatic ="@I.bStatic);
				Sc = "";
			}
			if (I.bNoDelete)
			{
				log(I@"is wrong set bNoDelete...");
				Sc = Caps(I.Class);
				Sc = "set"@Sc@"bNoDelete 0";
				ConsoleCommand(Sc);
				I.bRotatingPickup=False;
				log (I@"has now bNoDelete ="@I.bNoDelete);
				Sc = "";
			}
		}
	}
}
....
Else I'm agree with you, such maps have issues anyway...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Frome one bad to other in Linux...
I finally fix the v451 garbage collector crash... only to find out that servers will crash when a package load operation fails to find a file, on both v436... and this must have been dragged down from the very first Linux build.
Can't catch a goddamn break.

EDIT:
In the meantime, I'm rewriting most of the XCGE's sub elements into global variables, this (and a few other changes) will allow XC_GameEngine actually be inserted into the game at any time instead of just startup, probably that will fix Linux UT's in the future.
This time's victim: the Time Manager which is now a derivate of FExec, allowing it to parse console commands the classic way:
Attachments
TimeConsole.PNG
TimeConsole.PNG (8.41 KiB) Viewed 1866 times
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Chamberly »

lel intel laptop ftw.
Attachments
chamtimeconsole.png
chamtimeconsole.png (13.84 KiB) Viewed 1857 times
Image
Image
Image Edit: Why does my sig not work anymore?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 12]

Post by Higor »

Build 12 update

NOTE: There's a critical bug in Linux where failed loading operations crash the game instead of printing a 'file not found' warning.
It's been there for ages and will take a while to figure out what's going on, sorry about that.

Added _Reciprocal SSE method as ASM and ASMLINUX, speeds up trace code.
(Linux) Ported _appInvsqrt SSE method to ASMLINUX
(Linux) Removed linking to __Context::Env symbol, works on all v436 builds now.

FCollisionCacus review:
- Unified AddActor code for movers and normal actors.
- Nodes won't create child nodes if it has less than 3 actors.
- Encroachment checks are faster
- Fixed integer rounding issue causing actors to be placed in incorrect nodes (inreasing depth).
- Fixed AddActor code adding Movers to incorrect nodes.
- Added OctreeDebug command.
-- OctreeDebug Name=ActorName
-- Prints relevant info regarding an actor in the octree.

Fixed CollidingActors iterator.
Announcer, Credits packages won't cause mismatches when attempting to play a demo.
Boss mesh now has audible footsteps on Strafe and Backrun animations.
Removed PackageMap command.
XC_ServerActor: Nexgen administrators don't need an admin password when doing "AdminLogin" (default=enabled)

Rewritten XC_TravelManager
- No longer accessible as an Object.
- Item info continues to be held for all (present and non-present) player for as long as the coop chain isn't broken.
- Fixed v451 Linux garbage collector crash.
- Can receive 'TravelUpdate' console commands, forces a global travel list update manually.

Rewritten XC_TimeManager
- Is now a separate object, referenced global variable.
- Can receive 'TimeFactor' console command if timing fix is enabled, displays the current time factor in level update.
- Better behaviour after map switch.


I want to thank {HoF} clan for providing betatesting and bearing with me :mrgreen: .
Also, a couple of things that might useful for someone... somewhere.

ASM Reciprocal using Intel and Extended GNU Assembler syntaxes, this crap builds on GCC 2.95 lol.

Code: Select all

inline FLOAT _Reciprocal( FLOAT F)
{
#if ASM
	FLOAT z;
	__asm
	{
		rcpss    xmm0, F           // x0: z ~= 1/x
		movss    xmm2, F           // x2: x
		movss    xmm1, xmm0        // x1: z ~= 1/x
		addss    xmm0, xmm0        // x0: 2z
		mulss    xmm1, xmm1        // x1: z^2
		mulss    xmm1, xmm2        // x1: xz^2
		subss    xmm0, xmm1        // x0: z' ~= 1/x to 0.000012%
		movss    z, xmm0          
    }
    return z;
#elif ASMLINUX
	//Higor: finally got this working on GCC 2.95
	FLOAT z;
	__asm__ __volatile__("rcpss    %0,%%xmm0\n"
			"movss    %0,%%xmm2\n"
			"movss    %%xmm0,%%xmm1\n"
			"addss    %%xmm0,%%xmm0\n"
			"mulss    %%xmm1,%%xmm1\n"
			"mulss    %%xmm2,%%xmm1\n"
			"subss    %%xmm1,%%xmm0\n" : : "m" (F) );
	__asm__ __volatile__("movss    %%xmm0,%0\n" : "=m" (z) );
	return z;
#else
	return 1.f/F; //ALL ABOARD THE SLOW TRAIN
#endif
}
And the InvQrt from Unreal Engine adapted to Extended GNU Assembler as well.

Code: Select all

inline FLOAT _appInvSqrt( FLOAT F )
{
#if ASM
	const FLOAT fThree = 3.0f;
	const FLOAT fOneHalf = 0.5f;
	FLOAT temp;

	__asm
	{
		movss	xmm1,[F]
		rsqrtss	xmm0,xmm1			// 1/sqrt estimate (12 bits)

		// Newton-Raphson iteration (X1 = 0.5*X0*(3-(Y*X0)*X0))
		movss	xmm3,[fThree]
		movss	xmm2,xmm0
		mulss	xmm0,xmm1			// Y*X0
		mulss	xmm0,xmm2			// Y*X0*X0
		mulss	xmm2,[fOneHalf]		// 0.5*X0
		subss	xmm3,xmm0			// 3-Y*X0*X0
		mulss	xmm3,xmm2			// 0.5*X0*(3-Y*X0*X0)
		movss	[temp],xmm3
	}
	return temp;
#elif ASMLINUX
	//Higor: finally got this working on GCC 2.95
	const FLOAT fThree = 3.0f;
	const FLOAT fOneHalf = 0.5f;
	FLOAT temp;

	__asm__ __volatile__("movss    %0,%%xmm1\n"
			"rsqrtss    %%xmm1,%%xmm0\n"
			"movss    %1,%%xmm3\n"
			"movss    %%xmm0,%%xmm2\n"
			"mulss    %%xmm1,%%xmm0\n"
			"mulss    %%xmm2,%%xmm0\n"
			"mulss    %2,%%xmm2\n"
			"subss    %%xmm0,%%xmm3\n"
			"mulss    %%xmm2,%%xmm3\n" : : "m" (F), "m" (fThree), "m" (fOneHalf) );
	__asm__ __volatile__("movss    %%xmm3,%0\n" : "=m" (temp) );
	return temp;
#else
	return 1.0f / appSqrt( F);
#endif
}
SC]-[WARTZ_{HoF}
Adept
Posts: 426
Joined: Tue Feb 21, 2012 7:29 pm

Re: XC_GameEngine [build 12]

Post by SC]-[WARTZ_{HoF} »

Higor wrote:Build 12 update
I want to thank {HoF} clan for providing betatesting and bearing with me :mrgreen: .
Your welcome and bearing with you is no problem at all. XCGEv12 is working well.
Image
Image
Image
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 12]

Post by sektor2111 »

I still have to disable collision fixes

Code: Select all

XC_Engine: GameInfo.PreLogin hook success
XC_Engine: PlayerPawn.AdminLogin hook success
XC_Engine: ScriptedPawn's SetEnemy hook success
XC_Engine: UT_Eightball.NormalFire.Tick hook success
XC_Engine: Bot's bSetOrders hook success
XC_Engine: PlayerPawn.ShowPath hook success
XC_Engine: PlayerPawn.ShowInventory hook success
XC_Engine: Setting up collision octree for MA-RocketArena
Critical: FCollisionCacus::AddActor
Critical: AddActors
Critical: UXC_GameEngine::SetupCollisionCacus
Critical: UXC_EngineHook
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: TryTick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 05/01/15 19:17:50
Seems a random crash because sometimes works, sometimes not. First time I forgot to update U file and though I was totally wrong, but now happened again.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 12]

Post by Higor »

This is the logic I intended to use for fast grid/node selection, the example is for 3 max subdivisions (instead of 6)
OctreeGriding.PNG
OctreeGriding.PNG (11.04 KiB) Viewed 1731 times
This is the code in v12:

Code: Select all

inline INT GridIdx( FLOAT Line, const FLOAT& Total)
{
	return Clamp( appFloor( Line / Total )*TWO_EXP_OGA, 0, TWO_EXP_OGA-1);
}
What I should have used:

Code: Select all

inline INT GridIdx( FLOAT Line, const FLOAT& Total)
{
	return OctreeGridAssignment[Clamp( appFloor( Line * (FLOAT)TWO_EXP_OGA * _Reciprocal(Total) ), 0, TWO_EXP_OGA-1)];
}
Basically, the old code was returning either 0 or 63 (2^6 - 1).
Due to misplaced integer rounding and not accessing the Grid assignment array.

MH-RocketArena contains an actor that's bigger than the map's octree so it was returning 63, which is way bigger than the Grid array's top index (6) lol.
I'll embed a couple more stuff and re-release as v13 later this week.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 12]

Post by Higor »

Win32 Hotfix to octree code.
Attachments
XC_Engine_v12_fix.7z
Contains additional exception handling macros.
(68.21 KiB) Downloaded 75 times
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 12]

Post by sektor2111 »

Higor wrote:MH-RocketArena contains an actor that's bigger than the map's octree so it was returning 63....
:idea: Cough, it's MonsterArenaEnd trigger having a default 15000 × 15000 size which is supposed to end game properly ?
BTW I think I'll try to move this in a PathNode Location+vect(0,0,-2) to gain Bot Support right in PostBeginPlay (or later ? - I don't want timers... or ticks in here). But will stay in original Size (I guess it's centered into Universe nearby Sun, LOL). And I believe that function "Touch" is already called in spam style into such game-type... and, eh, I'm not sure how goes Touch happening inside another Touch... :???:
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 12]

Post by sektor2111 »

Hi, today...
For a future update I think will be cool to see a revision of something named "FindBestInventoryPath" resident in Pawn as a native thing.
It was fascinating to see Bot interested about ScubaGear placed far away in water not about a ripper + ammo placed truly nearby and more handy than anything. I really cannot understand criteria of sorting "BESTINVENTORY" from a far away place (even other zone) rather than something closer and more combat related item. I saw that a lot of times and I screwed respawntime of items from water to remove that stupidity for a while.
I was thinking at a replacement in UScript but it will be called a lot and exist chances to burn CPU.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 12]

Post by Higor »

The complexity of FindBestInventoryPath is stupid high, if you were to take a look at leaked code...
The update is taking a while because various anti DDoS experiments are being done with it.

UnrealKillers servers have been target of an undocumented TCPNetDriver lag exploit (present in most UnrealEngine versions).
And we've been doing various live updates to mitigate those.
Post Reply