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

Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by Higor »

All unrealscript functions add a generic, non-typed EX_Return opcode at the end, and the equivalent to Zero is always the default return value.
The unrealscript 'stack' is an allocated object that points to the owner, node, compiled script and locals.
UObject::ProcessInternal processes the script opcodes until a EX_Return opcode is found, no overflow check is done, EX_Return ALWAYS has to end a function.

C++ compilers automatically do what you do with the code when there's multiple returns with the same value, in that case, the compiled code will automatically contain various jumps to the same return directive (as many jumps as returns you add).
As Torvalds not-so-kindly told one of the Linux devs, don't do compiler masturbation (unless there's no choice).


EDIT:
Regarding bot replication, have you see anything weird with bots or monsters running being badly updated on clients? Someone running a linux server told me he literally saw monsters and bots 'sliding' and 'teleporting' but it may have been a case of bad networking, i've not been able to reproduce this.

Also, I'm considering reducing the amount of forced position updates the server does on the player owner, as everyone knows, increasing server tickrate increases the amount of 'PlayerAdjustPosition' (i think that was the name) calls the server sends to the player, and that can increase per-player bandwidth by 2 kb/s if tickrate goes from 30 to 65 for example.
Forcing it to a solid 30 (even if TR goes to 100) is a good thing imo.
And since the amount of calls is in the PlayerPawn class, it's nothing ReplaceFunction cannot handle :rock:


========
Gonna try this formula (finally found a use for InvSqrt native)
Then, the error will get an additional amount if:
- Player is likely to imagedropping (standing on an edge) = Force update
- Player has non-static colliding actor nearby: +0.1
-- Actor blocks players: +0.1
-- Actor is PHYS_Walking/PHYS_Swimming/SimulatedProxy: +0.1
--- Said actor is 10 units away from touching player: +0.8

An error of 3 forces the position correction from the server to the client (positional error between client and server), this way the server will smartly send data if the simulation is likely to be altered by a pawn and will do so at saner intervals.
It's completely likely to see much lower bandwidths in solo-player conditions (coop, MH, 1v1)

Code: Select all

	//LanSpeed 80000 = Check 28 times a second
	//NetSpeed 20000 = Check 20 times a second
	//NetSpeed 5000  = Check 7 times a second
	if ( Level.TimeSeconds-LastUpdateTime > 10*InvSqrt(Player.CurrentNetSpeed) ) 
	{
		LocDiff = Location - ClientLoc;
		ClientErr = (LocDiff Dot LocDiff) + AddedPosError();
	}
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by sektor2111 »

Higor wrote: Regarding bot replication, have you see anything weird with bots or monsters running being badly updated on clients? Someone running a linux server told me he literally saw monsters and bots 'sliding' and 'teleporting'
I don't want to write assumptions but when textures in server are bad some "effects" are happening. I don't have place-holders to mess me.
Else Speaking about movement which Nobody is posting nothing (probably trash is loved as usual), I suggest ScriptedPawn:
#1
If you take a map with geometry like CTF-Face, and monster in the middle is attacking down-hill it won't move straight like Bot, it is doing a sort of Z like is coming from an invisible stair (In Net Play) happening on Z Axis. If ramp is finishing at a moment monster looks like is levitating in air being seen in a FALSE Z location. After getting some hit, monster is relocated properly on ground.
#2
At tickrate 20, 2 guys might be firing minigun against a bigger monster for stucking it in location. Okay, and then ? Then it looks like the monster is pushed by fire but the only pushed thing is the mesh, monster stays getting damage. This effect looks retarded and some player intend to track mesh losing aiming at creature. As effect anyone with those "tutorial" recommendations with server tickrate 20 can wipe his as with them - probably he/she never did a MH/Coop/Etc server in his life - Minigun and PulseGun overpowered ? So what ? (+ Still some stupid codes when minigun leaves the world and firing - gotta do some try around). The option which seems to not develop this "unmeshy" effect is minimum of 30 tickrate + getting smaller intervals between ticks (aprox. 36 milliseconds in theory) and server response is faster because it will respond after a smaller interval.
Higor wrote: - Player is likely to imagedropping (standing on an edge) = Force update
YES, please fix this (for all Pawns). A Bot killed me at this point, I though it felt but then... it killed me.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by Higor »

It's self-update though.
The update of other pawn's locations goes according to normal replication rules and detecting imagedropping is a very expensive thing to do in replication.
A small serveractor can handle it, but it's not ideal (sgPlayerData class in SiegeIV does this).
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by sektor2111 »

Then it might be the time to some of my garbage engineering toward a monster which has an enemy (or an old enemy) to get updated Via something Owned, almost similar to MRele relevance tool, but for a different purpose: Z Axis crap.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by sektor2111 »

24 H Bump
If I'm wrong I'm asking apology in advance. I don't know how much is fixed in collision octree but I can see something in default, probably a hard chapter involving a lot of dependent stuff HitWall automated calls.

I did a research at MBot in how to properly solve those nasty corners VIA HitWall. Looks like is not the best option, this would need some DOT, Traces, and all that nasty math which I don't like. Aside HitWall seems to have a problem, IT DOESN'T get called if surface is not perfect Vertical which is a problem. As long as that trash cannot hold a Pawn as a Base due to angle, IT SHOULD BE listed as WALL. Because HitWall is not called in such cases we have crap with A.I. (MH-Canyon and similar) Then... I have traced some navigation instances developing a jump for getting over buggy obstructions. Related to HitWall I don't entirely like original Bot Code, In order to prevent full default code and computing unexpected brushes I have demanded a temporary sort of kicker in non-water zones setting up a randomized Z velocity around in purpose to get over crappy wall somehow. Pretty good but HitWall I think has to be called for any surface which cannot hold Pawns non-fliers.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by Higor »

Will be updating XC_Core soon, with the GXFileManager symbol back so older XCGE builds can load it (Win32 only), at least for this build to make transition smoother.

BTW, I found out why appSeconds, Clock, Unclock natives don't properly work during rendering (PostRender, PreRender, etc).
Render.dll switches the floating point math to low precision mode during this process, this is why timing doesn't work in rendering and why the old collision is so damn unstable if you perform traces during this process (my collision grid uses SSE math so it never crashed at this point).
I'm gonna investigate if it's possible to use SSE instructions to perform the Cycles->Time conversion so UnClock doesn't simply return '0'.

In the meantime I added a 'AppCycles' native that gives the user the low part of the cycle counter (QueryPerformanceCounter in Win32, gettimeofday microseconds in Linux)
The cycle counter doesn't use floating point math so it can be used to perform timing during rendering.
Basically this is what it does:

Code: Select all

function Something()
{
    local int Cycles;
    Cycles = AppCycles();
    ... heavy code here
    Cycles = AppCycles() - Cycles;
    if ( Cycles != 0 )
        Log("Cycle counter for this function: "$Cycles);
}
You can wrap it around if you're making HUDs and only need to debug locally without crashing online clients:

Code: Select all

final function int AppCycles(); //Return nothing if client, non-xcge

function Init_XCGE()
{
    if ( bDebugMode && (int(ConsoleCommand("get ini:engine.engine.gameengine xc_version")) >= 19) )
        ReplaceFunction( class, class'XC_CoreStatics', 'AppCycles', 'AppCycles'); //Enables native opcode, makes it return something other than zero
}
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv

Post by sektor2111 »

This trick looks beautiful, never been more wise. Perhaps something simple is doable toward that speed-hack thing... hmm.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

XC_Core version 7 update.

Added more up to date timers based on:
- QueryPerformanceCounter for Windows
- gettimeofday for Linux
Created XC_Core.XC_Server commandlet that uses these timers to enforce server tickrate.
** ucc xc_server (params)

Fixed Linux file manager handling, home dir functionality finally available in all XC_Core components.
Removed GXFileManager global object in Linux builds.
**All XC_Engine versions prior to 19 will fail to load!!

Fixed a GRegisterNatives bug registering a bad opcode number (could have resulted in crashes).
Added FixNameCase c++ global function.
Optimized SortStrings c++ global function.

Expanded XC_CoreStatics.FindObject native, now it's possible to find objects within a specified outer.
Optimized XC_CoreStatics' Clock and UnClock natives, take less cycles now.
Added XC_CoreStatics.HasFunction native.
Added XC_CoreStatics.FixName native.
Added XC_CoreStatics.AppCycles native.
** All timing natives now use the new timers.

BinarySerializer can read lines from text files.


======
Timer globals:
- appCyclesXC()
->-> appCycles equivalent of the new timers.
- appSecondsXC()
->-> appSeconds equivalent of the new timers.
- appCyclesSqXC()
->-> Returns the whole 8 byte part of the cycle counter (not just the low 4 as appCycles)
- GXSecondsPerCycle
->-> Multiplier used to turn cycles into seconds.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

How can be used timer globals ? Might they being get called into UScript or they are support for other natives ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

Timer globals are for native code usage.
They can be used to time non-tick actions (renderer timers, net driver resolve timers, etc), accurately time/sleep a thread (XC_Server commandlet) or clock stats safely (relevancy loop stats in XCGE).
The XC_CoreStatics clock/timing functions use these globals for exposure to unrealscript mods.


=========
EDIT:

Check this summon command, it's awesome.
class XC_Engine_TournamentPlayer expands TournamentPlayer
abstract;

Code: Select all

//***************************** << - Returns B if A doesn't exist
native (3555) static final operator(22) Object | (Object A, skip Object B);

Code: Select all

final function string PkgN( Object Other)
{
	return Left( String(Other), InStr( String(Other), ".")+1);
}

Code: Select all

final function SummonInternal( string ClassName)
{
	local class<Actor> NewClass;
	local Actor NewActor;
	local string Params;
	local int i;
	local BoolProperty bP;
	local class PPClass;
	

	While ( Asc(ClassName) == 32 || Asc(ClassName) == 46 ) //Space or Dot
		ClassName = Mid(ClassName,1);

	if ( ClassName == "" )
	{
		ClientMessage("XC_Engine enhanced Summon command, formatted as follows:");
		ClientMessage("SUMMON CLASSNAME prop=value prop=value boolprop...etc");
		ClientMessage("If no package is specified for CLASSNAME it'll attempt to load from known/common packages");
		ClientMessage("Naming a boolean property is enough to set it to True when spawning the new actor");
		return;
	}
		
	i = InStr(ClassName," ");
	if ( i > 0 )
	{
		Params = Mid( ClassName, i+1);
		ClassName = Left(ClassName,i);
	}
		
	if ( InStr(ClassName,".") != -1 )
		NewClass = class<actor>( DynamicLoadObject( ClassName, class'Class' ) );
	else
		NewClass = class<Actor>(	DynamicLoadObject( "Botpack."		$ ClassName, class'Class', true) |
									DynamicLoadObject( "UnrealI."		$ ClassName, class'Class', true) |
									DynamicLoadObject( "Engine."		$ ClassName, class'Class', true) |
									DynamicLoadObject( PkgN(Level.Game)	$ ClassName, class'Class', true) |
									DynamicLoadObject( PkgN(Self)		$ ClassName, class'Class', true) |
									DynamicLoadObject( PkgN(Class)		$ ClassName, class'Class', true) );
	if( NewClass != None )
		NewActor = Spawn( NewClass,,,Location + (72 + NewClass.Default.CollisionRadius*0.2) * Vector(ViewRotation) + vect(0,0,1) * 15 );

	if ( PlayerReplicationInfo != None )
	{
		if ( NewActor != None )
			log( "Fabricate" @ ClassName @ "by" @ PlayerReplicationInfo.PlayerName $ ": SUCCESS ("$PkgN(NewClass)$")" );
		else
			log( "Fabricate" @ ClassName @ "by" @ PlayerReplicationInfo.PlayerName $ ": FAILURE");
	}
	
	if ( NewActor != None )
	{
NEXT_PARAM:
		While ( Asc(Params) == 32 ) //Get rid of spaces
			Params = Mid(Params,1);
		if ( Len(Params) > 0 )
		{
			i = InStr(Params," ");
			if ( i == -1 )
			{
				ClassName = Params;
				Params = "";
			}
			else
			{
				ClassName = Left(Params,i);
				Params = Mid(Params,i+1);
			}
			i = InStr(ClassName,"=");
			if ( i > 0 )
				NewActor.SetPropertyText(Left(ClassName,i),Mid(ClassName,i+1));
			else
			{
				For ( PPClass=Newclass ; PPClass!=None ; PPClass=class'XC_CoreStatics'.static.GetParentClass(PPClass) )
					if ( class'XC_CoreStatics'.static.FindObject(ClassName, class'BoolProperty', PPClass) != None )
					{
						NewActor.SetPropertyText(ClassName,"1");
						break;
					}
			}
			goto NEXT_PARAM;
		}
	}
}

Code: Select all

exec function Summon( string ClassName )
{
	local class<actor> NewClass;
	if( !bCheatsEnabled )
		return;
	if( !bAdmin && (Level.Netmode != NM_Standalone) )
		return;
	if ( Len(ClassName) > 1024 ) //Safeguard
		return;
	SummonInternal( ClassName);
}
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

Me... coughing a few times...
Indeed I'm using your commandlet, engine, Core, Ipdrv and similar stuff + new launcher in client - I think I play UT finally after 16+ years - good job...

2nd) - I see exec calling other function, exactly what I did with "ShowPath" but things were not that cute, By adding those in your XC_whatever actor, I got a crash because that new function doesn't exist in PlayerPawn - kaput game. By using external NsUTw things were working (suddenly exist a function which seems called) as supposed but traveling between Levels returned crap during garbage collector process.

Exist a major hint toward calling one (or more) new function(s) from a simple exec which will work properly with no crash ? First time I was interested about such things but later I started to retreat. I made something against abusing so I'm allow ON-Line path seeking because... at a moment advanced player might use it - me, personally I'm using intensive that stuff, debugging, hunting... etc.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

Lemme take a look at the abstract player class (or at least function and globals).
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

Ok... then I have implemented that Summon, using it after path seeking (after a few seconds) looks like Nali Spawned got frozen, me too, and... I forced an UT end. That player thing seems to screw something. Another thing... I went to seek path through Pathnode-TLocStart-TLocDest-LiftExit-PathNode... Well... only Bot can use this combo - or I did wrong handling or vector seeking is limited at players or... heck knows. I modified codes to automated switch T-Loc for player seeker - switching do works but it returns None after next point whatever, LOL. IDK might be "FindPathTo" VS "FindPathToward". I used intensive such spots in that CTF-DarkVSLight map for lower area, M_Bot Alys covered me properly and went to attack from that area, but... I didn't see way out... hm... probably those things do screw player... I'm lost now because I don't have any suspect on list.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

Works here, the player class...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

Beta changes:
- Anti-speedhack on default netcode.
- FPS limiter using command 'FPS x'
** x=0: unlimited
** x can be anything between 0 and 200
- Slightly faster relevancy loop.
- Summon command revamped (type 'summon' without parameters to get a guide).

Implemented simple ReachSpec/Path editor functions.
* See XC_Engine.XC_Engine_Actor for functions.
* See XC_Engine_UT99.XC_Engine_UT99_Actor for usage examples.
* Nowhere near as mainstream as FerBotz's, but can be used to fix certain stock maps (Play Deck16 on this build and you'll see)
XC_Engine_hooktest_08.7z
Use XC_Core v7.
XC_IpDrv not included.
(280.09 KiB) Downloaded 100 times
Post Reply