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

[sektor2111]

I've been thinking more simple (I'm lazy at maths)

Spawn an actor at player trying logging. Actor lives a defined time. During this time in actor owned exists and player still try logging and is not admin a number of defined attempts then kick it, actor will be deleted automatically once owner vanished.

[Higor]

That exposes the server to an 'AllActors' loop for every adminlogin call.
As it is right now, it's almost the fastest UScript implementation possible.

It'd be the fastest if the loop started upside down, as we'd be doing the index checks using a predefined EX_IntZero opcode and no substraction of top index.
With a small tradeoff at calling Array_Length_LI one more time if this is the player's first time at typing AdminLogin.
Using a static array + a top index marker would be just as fast during checks, but this simplifies the code by a huge margin as there's no need to manually move entries to compact the array (so you don't check empty slots).

Globals:

Code: Select all

struct LoginInfo
{
	var() PlayerPawn Player;
	var() float DenyUntil;
	var() int BadLoginCount;
};
var array<LoginInfo> LInfos;

//Gain access to these XC_GameEngine opcodes
native(640) static final function int Array_Length_LI( out array<LoginInfo> Ar, optional int SetSize);
native(641) static final function bool Array_Insert_LI( out array<LoginInfo> Ar, int Offset, optional int Count );
native(642) static final function bool Array_Remove_LI( out array<LoginInfo> Ar, int Offset, optional int Count );

As it is now:

Code: Select all

	local int i, iP;
	
	iP = Array_Length_LI( LInfos);
	while ( i<iP )
	{
		if ( LInfos[i].Player == none || LInfos[i].Player.bDeleteMe )
		{
			Array_Remove_LI( LInfos, i);
			iP--;
			continue;
		}
		if ( LInfos[i].Player == P )
		{
			if ( LoginBeingSpammed )
			{
				if ( SpamLimitReached )
				{
					//Kick player here
					Array_Remove_LI( LInfos, i);
					iP--;
					return false;
				}
				LInfos[i].DenyUntil += IncreaseMultiSpamTime;
				return false;
			}
			iP = i;
			Goto POSITIVE_RETURN;
		}
		i++;
	}
	Array_Insert_LI( LInfos, iP);
	LInfos[iP].Player = P;

	POSITIVE_RETURN:
	LInfos[iP].DenyUntil = CurrentTime + SetSpamTime;
	return true;

As it could be:

Code: Select all

	local int i;
	
	i = Array_Length_LI( LInfos);
	while ( --i >= 0 )
	{
		if ( LInfos[i].Player == none || LInfos[i].Player.bDeleteMe )
			Array_Remove_LI( LInfos, i);
		else if ( LInfos[i].Player == P )
		{
			if ( LoginBeingSpammed )
			{
				if ( SpamLimitReached )
				{
					//Kick player here
					Array_Remove_LI( LInfos, i);
					return false;
				}
				LInfos[i].DenyUntil += IncreaseMultiSpamTime;
				return false;
			}
			Goto POSITIVE_RETURN;
		}
	}
	i = Array_Length_LI( LInfos);
	Array_Insert_LI( LInfos, i);
	LInfos[i].Player = P;

	POSITIVE_RETURN:
	LInfos[i].DenyUntil = CurrentTime + SetSpamTime;
	return true;

[sektor2111]

As facts noticed by me for this chapter, I'll keep your way as long as has a fast code. Alternate solution which I was thinking using UScript only is... custom child game with redefinition of "adminlogin" or using a custom player which will be more cute

[sektor2111]

I found something, might be useful for understanding AdjustHitLocation problem.
LOG says:

Code: Select all

ScriptWarning: Titan DM-ZepTepi][.Titan0 (Function Engine.Pawn.AdjustHitLocation:003A) GetAnimGroup: Sequence 'Fighter' not found in Mesh 'Titan1'
ScriptWarning: Titan DM-ZepTepi][.Titan0 (Function Engine.Pawn.AdjustHitLocation:003A) GetAnimGroup: Sequence 'Fighter' not found in Mesh 'Titan1'

After making almost complete Bot Support (except Udamage path) a clown stands up there messing up Level, which seems a cute one.

Action: Loading any DM game with Translocator and even playing alone you can score 1 point (anyone can do this) - yes, score for nothing successfully delivered by telefragging a Statue-Pawn mooing an invalid 0 animation.
I'm feel sorry for these people which were wasting their time to do trash.

dm-zeptepi][.zip

(646.51 KiB) Downloaded 63 times

See here...

[Higor]

I'm seriously considering dropping my efforts on the Linux port, dealing with the compiler alone is a problem, and not mentioning these weird assertions all over the linux's memory handler.

Flipping the page, planned stuff in the long term:
- XC_IpDrv
Reimplement the TCPNetDriver from scratch.
Fix some bugs, add extra channel types for internal game modules communication (voice? AC?) and add a LZMA decompressor so we no longer use the obsolete UZ formats (LZMA is the 7zip specification).
PackageMap updates in realtime.
- Default Properties reloader.
You join a server, and most packages defaults get reloaded.
- Input reimplementation.
Turbo binds, maybe extra mouse buttons.
Protect specific keys from being rebound.

[sektor2111]

and add a LZMA decompressor so we no longer use the obsolete UZ formats (LZMA is the 7zip specification).

Wheew... and will work with a normal clean client this "other" compression format ? If you have solution a bunch of HDD space will be saved...

[Higor]

Normal clients will not be able to gain access to these features.
Ideally if a XC_GE client joins a server, some few extra parameters will appear on the login:
- PlayerName?class=PlayerClass?skin=PlayerSkin?face=PlayerFace?voice=PlayerVoice?xc_version=13?xc_ip=2

A normal server should ignore those, a XC_GE server will set appropiate flags on its side for that client.
So we client downloader would then:
- Receive the server's response, if the response contains a 'lzma' keyword, then enable 7z queries.
- [lzma] Open thread, query the redirect for 7z.
- [lzma] Wait 0.5 second.
- Query query the redirect for UZ if there's no 7z channel.
- If the 7z channel receives a positive ack, close UZ channel.
- Wait for the 7z/UZ timeout, start normal Channel download if there's no file channel open.
- File finishes downloading, open UZ/7z decompressor thread.
- Query next file if present, or wait till decompressor thread finishes if no files in queue.

[Chamberly]

Does the client have to have 7z program installed to use this? O.o

[sektor2111]

Hm, I'm doubt to see player dealing with this if won't be an EXE patch doing the job. Some of them are too ignorant for reading forums... I'm wonder if number of users will pass 25 players able to deal with a MANUAL (see Servers section and try to understand what I mean). If a tool/mod/mutator will be full of options very few will read document but the most of them are going to ask craps in forums with manual opened in front of them. If a tool/mod/mutator is too simple, again complains because that is not configurable, that should be modified, etc.

It will be extremely useful a solid engine for Servers and I cannot be sure what's the deal with players.

[Higor]

Working on the milestones stated above will require lots of stuff done first.
You can take a quick peek here:

XC_Core_alpha1.7z

(10.1 KiB) Downloaded 66 times

What it has:
- XC_CoreStatics: some static UScript functions (opcodes not set, XC_Engine will do that) from XC_Engine and FerBotz.
- StripSourceCommandlet
- DeobfuscateNamesCommandlet

StripSource is what you can find in newer UnrealEngine games.
DeobfuscateNames will grab a horribly obfuscated package and create a version that UTPT or UEExplorer can easily decompile, you may hex edit the names later on the U file as well.

[sektor2111]

I'm not sure if this does compile

Code: Select all

native /* (643)*/ static final function float AppSeconds();

But for sure this works:

Code: Select all

native (643) static final function float AppSeconds();

Aside note as a response for new stuff:

Code: Select all

ScriptLog: Time required for InventoryPath Seeking: 0.000122
ScriptLog: Time required for InventoryPath Seeking: 0.000244
ScriptLog: Time required for InventoryPath Seeking: 0.000244
ScriptLog: Time required for InventoryPath Seeking: 0.000366
ScriptLog: Time required for InventoryPath Seeking: 0.000366
ScriptLog: Time required for InventoryPath Seeking: 0.000366
ScriptLog: Time required for InventoryPath Seeking: 0.000244

Lines involving 366 happened on a stair in a ramp. Good to know for me...

I would appreciate some examples about usage of Core - maybe a complete replacement...

Edit: DeobfuscateNamesCommandlet, something is not cute:

Code: Select all

Critical: appError called:
Critical: Assertion failed: Removed!=0 [File:C:\UTDev\Core\Src\UnObj.cpp] [Line: 3166]
Exit: Executing UObject::StaticShutdownAfterError
Critical: UObject::UnhashObject
Critical: UObject::~UObject
Critical: DeleteObject
Critical: (279)
Critical: DeleteGarbage
Critical: (RemappedName0)
Critical: UObject::PurgeGarbage
Critical: UObject::StaticExit
Critical: appPreExit
Exit: Exiting.

It generates something, UTPT shows nasty things and as usual cannot deal with "jump destination..." etc.

[Higor]

That crash is expected.
Renaming objects isn't a safe task in Unreal, either way the purpose of recovering a package that was beyond f***ed up into something decompilable already happens without a problem.
Sure, I may implement the ability to add a small text buffer with minimal class and variable declarations in the future.

Edit2:
I may implement a 'clock' feature that keeps the original 'double float' timers to make more precise measurements.

[Higor]

A quick peek of next XC_Core alpha...

Code: Select all

Log: Log file open, 06/24/15 04:58:02
Init: Name subsystem initialized
Init: Detected: Microsoft Windows NT 5.2 (Build: 3790)
Init: Version: 436
Init: Compiled: Oct 24 2000 23:40:18
Init: Command line: Botpack.u2.lzma
Init: Base directory: F:\ut src\System\
Init: Character set: Unicode
Log: Bound to Core.dll
Init: Object subsystem initialized
Init: Computer: FERNANDO
Init: User: Administrator
Init: Memory total: Phys=2096268K Pagef=4194303K Virt=2097024K
Init: Working set: 32000 / 159000
Init: CPU Speed=1994.997542 MHz
Init: CPU Page size=4096, Processors=2
Init: CPU Detected: PentiumPro-class processor (GenuineIntel)
Init: CPU Features: CMov FPU RDTSC PAE MMX KNI
Log: Bound to XC_Core.dll
Log: Bound to Engine.dll
Log: Executing Class XC_Core.LZMADecompressCommandlet
Log: LZMA header indicates an unpacked size of 39016791
Log: === Serializing 65536 bytes...
Log: === Serializing 65536 bytes...

... some more lines later...

Code: Select all

Log: === Serializing 65536 bytes...
Log: === Serializing 31389 bytes...
Log: === Serializing 65536 bytes...
Log: === Serializing 20006 bytes...
Log: Decompressed Botpack.u2.lzma -> Botpack.u2
Exit: Preparing to exit.
Log: Purging garbage
Log: Unbound to Core.dll
Log: Unbound to XC_Core.dll
Log: 0.0ms Unloading: Package XC_Core
Log: 0.0ms Unloading: Package Core
Log: Unbound to Engine.dll
Log: 0.0ms Unloading: Package Engine
Log: Garbage: objects: 208->0; refs: 0
Exit: Object subsystem successfully closed.
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Allocation checking disabled
Uninitialized: Log file closed, 06/24/15 04:58:06

[sektor2111]

I WANT to try this - ( and strategy explanations ?)

[Higor]

Second alpha build.

XC_Core_alpha2.7z

(34.64 KiB) Downloaded 59 times

The compressor is running, although the LZMA sdk was a bit too complex on that so I couldn't use Unreal's file, thread and allocators there (big question mark if I try to build this on linux).
On the other side, I did manage to port the LZMA decompressor to use Unreal's GMalloc and GFileManager so it's portable and theoretically could run in the Linux platform.

Example log of the LZMACommandlet

Code: Select all

F:\ut src\System>ucc lzmacompress *.dll
Compressed CAC.dll -> CAC.dll.lzma (11%)
Compressed CacusTeamBalancer.dll -> CacusTeamBalancer.dll.lzma
Compressed CAC_0001.dll -> CAC_0001.dll.lzma (11%)
Compressed Core.dll -> Core.dll.lzma (23%)
Compressed Editor.dll -> Editor.dll.lzma (24%)
Compressed Engine.dll -> Engine.dll.lzma (23%)
Compressed FerBotz.dll -> FerBotz.dll.lzma (20%)
Compressed Fire.dll -> Fire.dll.lzma (28%)
Compressed FV_ACEv08h.dll -> FV_ACEv08h.dll.lzma (11%)
Compressed FV_InputHandler.dll -> FV_InputHandler.dll.lzma (12%
Compressed IpDrv.dll -> IpDrv.dll.lzma (25%)
Compressed MoverFactory.dll -> MoverFactory.dll.lzma (11%)
Compressed Obfuscator.dll -> Obfuscator.dll.lzma (14%)
Compressed TextureAddon.dll -> TextureAddon.dll.lzma (14%)
Compressed UBinary.dll -> UBinary.dll.lzma (13%)
Compressed udemo.dll -> udemo.dll.lzma (21%)
Compressed UWeb.dll -> UWeb.dll.lzma (28%)
Compressed Window.dll -> Window.dll.lzma (21%)
Compressed WinDrv.dll -> WinDrv.dll.lzma (28%)
Compressed XC_Core.dll -> XC_Core.dll.lzma (27%)
Compressed XC_Engine.dll -> XC_Engine.dll.lzma (25%)
Compressed XC_IpDrv.dll -> XC_IpDrv.dll.lzma (24%)

^About that last DLL... news will come later.

Extra script features:
- Some silly float/vector natives that use XC_Engine's UnXC_Math.h SSE functions.
- Real Clock/Unclock functions that operate on double floats (you need specific float F[2] types here).

Code: Select all

//Ultra precise clocking, for checking small pieces of code
//This measurement is way more expensive than AppSeconds, don't keep it on final builds
native /*(3556)*/ static final function Clock( out float C[2]);
native /*(3557)*/ static final function float UnClock( out float C[2]);

native /*(3570)*/ static final function vector HNormal( vector A);
native /*(3571)*/ static final function float HSize( vector A);
native /*(3572)*/ static final function float InvSqrt( float C);

And how it's used (example actor):

Code: Select all

event PostBeginPlay()
{
	local float F[2], Time;
	class'XC_CoreStatics'.static.Clock( F);
	//Do something here
	Time = class'XC_CoreStatics'.static.UnClock( F);
	Log("Actor script initialization took: "$Time);
}