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 »

XC_Engine_hooktest_05.7z
(346.31 KiB) Downloaded 108 times
Disabled enhanced instruction set from build settings.
Relevancy loop is stable/working again.

Script Changes:
- PlayerPawn.ShowInventory hook moved to new system.
- PlayerPawn.ShowPath hook moved to new system.
- UT_EightBall.Firing.Tick hook moved to new system.
- Added GameInfo.ScoreKill edit > fix log spam.
- Added GameInfo.Killed edit > fix log spam.
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 »

Yay, I'm on it...
Edit: Nope, default NON XC client is crashing

Code: Select all

NetComeGo: Close TcpipConnection0 08/14/16 09:41:12
Critical: FMallocWindows::Free
Critical: FMallocWindows::Free
Critical: FMallocWindows::Realloc
Critical: 000001F6 0 FArray
Critical: FArray::Realloc
Critical: 0*1
Critical: FMallocWindows::Free
Critical: DestroyServerConnection
Critical: UNetDriver::Destroy
Critical: UObject::ConditionalDestroy
Critical: (TcpNetDriver Transient.TcpNetDriver0)
Critical: ULevelBase::Destroy
Critical: UObject::ConditionalDestroy
Critical: (NetPendingLevel Transient.NetPendingLevel0)
Critical: PendingFailed
Critical: TickPending
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UD3D9RenderDevice::ShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 08/14/16 09:41:17
Server XC 436 - Client Non XC 436.

LAN TEST using 436 VIA UT.EXE
Server.Log was this

Code: Select all

XC_Engine: Empty connection after 3.019000 seconds.
NetComeGo: Close XC_TcpipConnection5 08/14/16 09:35:44
DevNet: Connection timed out after 10.000000 seconds (10.023000)
NetComeGo: Close XC_TcpipConnection4 08/14/16 09:35:51
And during this time we have client crashed at Server-Travel - NON XC Client. So XCGE server cannot deal that much with Normal Player.
Edit2:
More testing
Server 436 Outside Disable all LevelHooks and collisions. Simple Player 436 entered and then crashed at Server-Travel after voting right before to enter the new Level.

Code: Select all

Exit: WinSock shut down
Log: 0.0ms Unloading: Package MH-Demons][
Log: 0.0ms Unloading: Package Addon1
Log: 0.0ms Unloading: Package Seeker
Log: 0.0ms Unloading: Package LavaFX
Log: 0.0ms Unloading: Package SpaceFX
Log: 0.0ms Unloading: Package Coret_FX
Critical: FMallocWindows::Free
Critical: FMallocWindows::Free
Critical: DeleteObject
Critical: (28355)
Critical: DeleteGarbage
Critical: (TcpipConnection0)
Critical: UObject::PurgeGarbage
Critical: UObject::CollectGarbage
Critical: Cleanup
Critical: UGameEngine::LoadMap
Critical: AttemptLoadPending
Critical: TickPending
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UD3D9RenderDevice::ShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 08/14/16 10:00:25
With Collisions enabled looks like server is crashing when even client XC wants to join for some PreNet:: bla bla like in a previous post.
Which Setup do you recommend ? Problems seems to happen even if I'm using classic structure or shared structure.

Server using DNS name and No collisions and Levels set Disabled seems to stay more alive.
Normal player without files will get them right from server directly. XC Player has opportunity for LZMA VIA Redirect. This way was perfect before <hook> versions. However, I was using Collisions disabled...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

This one was built using VC++6. See if the crashes persist. (I've been unable to reproduce them here)
Attachments
XC_Engine_hooktest_05dll.7z
(109.21 KiB) Downloaded 100 times
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 »

:mad2: :mad2: :mad2: :mad2: :mad2: :mad2:
I went to a reinstall of UT because the client clean was still blabbering. Fresh was working so I did a research in who is Evil crashing client travel. I have added one by one and testing patch 436, then d3d9, then Ipdrv - OOOPS. From 3 IpDrv.dll which I have there is one made EUT which do sucks in XCGE server (any ?). Holy mother, I spent a few hours trying to figure whatta heck is bugging things like that. You might wanna take a look at these. Probably a client using EUT will have the same problems (or I'm the only one brutalized ???).
[attachment=0]IpFiles.zip[/attachment]

And I have some IpDrv from 451 UTPG packages which I did not checked made 2003 and 2004.
Edit: EUT seems the same as file used in UTPG Patch 440 and file from UTPG451b does the same travel-crash. Probably 451 is the same - I'm not gonna waste time with those "patches" because they were patching my patience. Cough UTPG, Cough...
Edit: Other tests.
Server trial MH (MH, MH2, MA) version 440 (required only 3 dll changed) IpServer used by UTPG from 451b is omni usable universal. IpServer.u since 440 has added a "teaminfo" query and uses a While PawnList cycle, which in 451 is excepting Spectators using a default PawnList. Interesting, but I think spectators are consuming a bigger bandwidth that default player due to their "seeing features". All right, let me describe test.
In this Multi MH 440 server default non XC player can join using default IpDrv.dll or that official patched. Non of UTPG types are compatible with Server-travel - client is crashing. Updating client to 440 and using UTPG libs are driving to the same crash. If client has 440 but it uses Patched LIB by Epic, it won't crash. So UTPG releases are not recommended for players. Player with version 440 but using XC stuff properly configured it's not crashing.
----
On a self note toward 440 Server and 440 Client I was hitting F6 (StatNet or such) what I saw on screen is a result like randomly generated form a hat with numbers... This proves how obsolete is this Net Stuff doesn't matter how better seems to move player in 440. Values reported at PacketLoss are probably fake - 436 to 436 don't have any PacketLoss in the same Net-Provider Network, so 440 is bullshitting screen with presumptions and trash.
Attachments
IpFiles.zip
Contains Original IpDrv, a patched one officially and EUT which was crashing me at Server-Travel... Probably this one crashed XCGEhooktest server too ???
(219.4 KiB) Downloaded 89 times
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Figured out a few things...

Linux:
- XC_Core needs to use a different file manager due to being unable to call functions on the original file manager, same problem with DemoManager and ACE.
- So I realized that for some reason, the compiler decided to put the VTable at the end of the FArchive object instead of the beginning.
So the result is that when switching from version 436 to >440 in linux, calling any virtual functions in FArchive types results in a segmentation fault.
And I just found out how to fix this :loool:
- Also, the workaround used on these cases had Linux clients broken (being unable to write files to $HOME dir)

So XC_Core will be seeing an update first, and XC_Engine v19 will forcefully require XC_Core 7.


======
@anth!!!
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 »

I want to mention something.
If you can do some more enhanced tests under Linux then insist well with them. I can do some basic testing in a Win system using dual versions 436 440. I'm very interested to get them stable as a rock and then - with your iterators I think I'll setup a simple attached MonsterHunt and some DM, TDM. I intend to follow original stuff (not attaching things End, Etc.) but having functions rewritten and even tuning a bit content. A couple of replacements might be recommended but I prefer to fix them in run-time rather than calling 2 pages of script in CheckReplacement.
Aside If I'm doing this wrong I'll prepare new calls to other mutator for taking control and rejecting "original". I could see last time attempts to get rid of BaseMutator... oh well, if people want their own stuff then game controller will spawn another AlternateBaseMutator. If anyone else wants to participate at doing such things we can debate those in a desired thread.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Got rid of the additional file manager now that it's possible to use FArchive methods in v451.
This restores Home dir functionality for all XC_Core components: LZMA upload, XC Channel/HTTP download, BinarySerializer
Attachments
XCGE_Linuxtest.7z
Apply over Hooktest_05 build: https://ut99.org/download/file.php?id=6968
(189.34 KiB) Downloaded 68 times
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 »

Have you figured somehow evilized differences at those IpDrv files ? I would like to know if they can be used somehow or never...

Edit: I want to know which Actors are in account by Iterator <native(3553) final iterator function DynamicActors( class<actor> BaseClass, out actor Actor, optional name MatchTag );> Does it do a faster job than <AllActors> ?

Edit2: 440 Playing local - Exit testing game using IpDrv.dll originally from 440

Code: Select all

Critical: FMallocWindows::Free
Critical: FMallocWindows::Realloc
Critical: 4290F092 0 FArray
Critical: FArray::Realloc
Critical: 0*2
Critical: FMallocWindows::Free
Critical: UObject::ExitProperties
Critical: (StrProperty Botpack.TournamentPlayer.spreenote)
Critical: UObject::Destroy
Critical: (XanMk2 MH-Cliffs2_Rv2_2.XanMk0)
Critical: AActor::Destroy
Critical: UObject::ConditionalDestroy
Critical: (XanMk2 MH-Cliffs2_Rv2_2.XanMk0)
Critical: DispatchDestroy
Critical: (50999: XanMk2 MH-Cliffs2_Rv2_2.XanMk0)
Critical: DispatchDestroys
Critical: UObject::PurgeGarbage
Critical: UObject::StaticExit
Critical: appPreExit
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: Double fault in object ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Warning: glxStopOutput() failed: 6
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 08/20/16 00:17:53
Crash type exit...
Else I'm using this ShowPath "fix"
Spoiler

Code: Select all

class XC_PlayerPawn expands PlayerPawn abstract;

var float LastPathTime;
var bool bSaidPath;

exec function ShowPath()
{
	local Actor Node;
	local WayBeacon W, W1;
	local bool bHasBeacon;
/*
	if ( !bAdmin && (Level.NetMode != NM_Standalone) )
		return;
*/
	foreach ChildActors(class'WayBeacon',W)
	{
		W1 = W;
		bHasBeacon = True;
		break;
	}
	if ( LastPathTime + 7 > Level.TimeSeconds )
	{
		if ( !bSaidPath )
		{
			bSaidPath = True;
			if ( bHasBeacon )
			{
				W1.Disable('Touch');
			}
			ClientMessage("Spaming is not allowed... Retry after"@(LastPathTime+7)-Level.TimeSeconds@"seconds...");
		}
		GoTo DoNothing;
	}
	else
	{
		if ( bHasBeacon )
			W1.Enable('Touch');
		bSaidPath = False;
		LastPathTime = Level.TimeSeconds;
	}
KeepGoing:
		if ( PointReachable ( Destination ))
		{
			ClientMessage("Destination is Reachable, look around for Lamp-Beacon...");
			if ( bHasBeacon )
			{
				if ( W1.Location != Destination )
					W1.SetLocation(Destination);
			}
			else
				W1 = Spawn(class 'WayBeacon', self, '',Destination);
		}
		else
		{
			Node = FindPathTo(Destination);
			if ( Node != None )
			{
				log(GetHumanName()@"found path: "$Node.Name);
				if ( bHasBeacon )
				{
					if ( W1.Location != Node.Location )
						W1.SetLocation( Node.Location );
				}
				else
					W1 = Spawn(class 'WayBeacon',self,'',Node.location);
				if (W1 != None)
				{
					if ( Node.Base != None )
						W1.SetBase(Node.Base);
					ClientMessage("Path Found - Look For Lamp-Beacon");
				}
			}
			else
			{
				ClientMessage("Could not find a Path to Destination Spot.");
				log(GetHumanName()@"didn't find path.");
			}
		}
DoNothing:
}
As for WayBeacon

Code: Select all

class XC_WayBeacon expands WayBeacon abstract;
...
function Touch(actor other)
{
	local Actor Node;

	if ( Other == Owner )
	{
		LifeSpan = 6.00;
		if ( PlayerPawn(Owner) != None )
		{
			if ( PlayerPawn(Owner).PointReachable( PlayerPawn(Owner).Destination ) )
			{
				if ( Location != PlayerPawn(Owner).Destination )
				{
					PlayerPawn(Owner).ClientMessage("Destination Reachable at"@PlayerPawn(Owner).Destination@"!");
					SetLocation ( PlayerPawn(Owner).Destination );
				}
				else
				{
					PlayerPawn(Owner).ClientMessage("You have reached at Destination!");
					Destroy();
				}
			}
			else
			{
				Node = PlayerPawn(Owner).FindPathTo(PlayerPawn(Owner).Destination);
				if ( Node != None )
				{
					if ( Location != Node.Location )
						SetLocation( Node.Location );
				}
				else
				{
					PlayerPawn(Owner).ClientMessage("No Longer find a path to Destination!");
					Destroy();
				}
			}
		}
	}
}
Because Mutator uses:

Code: Select all

			class 'WayBeacon'.Default.RemoteRole = ROLE_DumbProxy;
			class 'WayBeacon'.Default.NetUpdateFrequency = 5.000000;
So Net Code and spamming went different this way...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

v440 - v451 have these nasty FMalloc/FArray issues.

Regarding DynamicActors, all bStatic actors are arranged first in the actor list.
Once that happens, iFirstDynamicActor is set to the index of the first non-bStatic actor that comes next.
This iterator works just like AllActors, but starts from that index instead.
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 »

I got it. The problem is that some "anticheats" might restrict players with lower UT versions 451--. I have found a dude in the past which was removing player using 436 and lower - bad move - 440 and 451 are not that good as supposed after all. Of course later nobody was playing there because of two reasons: 1) restricting common player 2) he changed some stock files and I never understood why so nobody could join for months and later stopping server because "nobody play UT anymore" LOL.

Changing gear...
I got a "present" today, a computer IBM PIV which was supposed operational (fake feeling). Else I get some parts from it placing them into my old rig Athlon 1800+. I have installed a 3COM Netcard and through a router (that 3COM seems to bug other Broadcom adapters connected to the same TP-Link Switch causing Lags - equipment sh!t soup), so I went through the router and using external Net address I did some tests using a simple client with nothing added (like in times before XCGE). I don't know what I messed or not... results were similar at a moment, pawns seems to warp a bit randomly (non MH game) and seems to happen in this hook-test 5 any of these 2 hookv5 used and clean player. Perhaps I must do some checks or server refresh but I'm not so convinced, things were good before. Else "ReplaceFunction" feature does an excellent work, I could play a couple of games with default stuff having 0 zero errors - HookTest until this moment is good if I discard those movement tiny issues.
As for people using 451 for playing on-line I'm sorry for them but UTPG did not finished their work. 451 updates were addressing servers (for changing crashes not that much fixing).
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

I just realized... XC_Engine is holding a cache of all replaced functions so they can be properly restored, yet we don't have a on-demand restore feature?
A RestoreFunction native should take care of that, good for temporary replacements.

I'm considering adding a function that pushes an actor's variable into the to-send list of the players' connections.
Good for forcing a variable update that for some reason isn't properly happening.
An example would be the translocator's location/velocity when it gets hit before it lands, or a player's location if it's possible he might be imagedropping.
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 »

I did more tests using this Athlon machine. I could figure that from these 2 HookTest v5 I can run as client (after adding XCGE) only last smaller version. It seems like this machine doesn't have SSE2, the rest of game-play looks normal with a tiny bit of delay at turning to target movement while XCGE is being used. Aside from non SSE2, other major problems did not happen, else machine being in clean state looks like everything starts faster, LOL. I might do a cleaning operation at the rest of machines but... Antivirus, Firewall, Web-Services... not sure if helps that much...

However restoring a function fixed into original messed one ? Is this necessary ? I see automated reverting all them at Server-Travel stage when a new game starts in a clean state - probably a sort of another game which doesn't need tweaks being "perfect", eh... But... I'll fire tests as needed reporting results...
Here is a normal log before to join "On-Line".
Spoiler

Code: Select all

Log: Log file open, 08/26/16 01:24:39
Init: Name subsystem initialized
Init: Detected: Microsoft Windows NT 5.1 (Build: 2600)
Init: Version: 436
Init: Compiled: Oct 24 2000 23:40:18
Init: Command line: 
Init: Base directory: F:\UT\System\
Init: Character set: Unicode
Log: Bound to Engine.dll
Log: Bound to Core.dll
Log: Bound to Window.dll
Init: Object subsystem initialized
Init: Computer: VIA1800
Init: User: Admin
Init: Memory total: Phys=2096696K Pagef=4039052K Virt=2097024K
Init: Working set: 32000 / 159000
Init: CPU Speed=1825.981119 MHz
Init: CPU Page size=4096, Processors=1
Init: CPU Detected: PentiumPro-class processor (AuthenticAMD)
Init: CPU Features: CMov FPU RDTSC PAE MMX KNI 3DNow!
Localization: No localization: Startup.IDDIALOG_WizardDialog.IDC_WizardDialog (int)
Log: Bound to XC_Engine.dll
Log: Bound to XC_Core.dll
Log: Bound to Fire.dll
Log: Bound to IpDrv.dll
Init: ========= XC_ENGINE - Test build 19 =========
Init: ================= By Higor ==================
Init: Unreal engine initialized
Log: Bound to WinDrv.dll
Init: Mouse info: 0 0 0
Init: Initializing DirectDraw
Log: DirectDraw drivers:
Log:    display (Primary Display Driver)
Init: DirectDraw initialized successfully
Init: Client initialized
Log: Bound to Render.dll
Init: Lighting subsystem initialized
Init: Rendering initialized
Log: XC_LoadMap: Entry
Log: Game class is 'UTIntro'
Log: Level is Level Entry.MyLevel
XC_Engine: Bringing Level Entry.MyLevel up for play (0)...
ScriptLog: InitGame: 
ScriptLog: Base Mutator is Entry.Mutator0
.....
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Function restoration can be an intended feature for mods that do heavy usage of XC_Engine code.

BTW XC_Core v7 is ready, but since it breaks all current XC_Engine due to removing the Linux-only file manager code that's no longer used (only release v19 will be able to run) I won't put it up yet.
The new/updated natives will be these:

Code: Select all

native /* (600)*/ static final function Object FindObject( string ObjectName, class ObjectClass, optional Object ObjOuter ); //ObjOuter param incompatible with 227!!!
native /*(2014)*/ static final function bool HasFunction(name FunctionName, optional Object ObjToSearch); //Defaults to caller (SDK, this one won't crash if called static without param2)
native /*(3558)*/ static final function name FixName( string InName, optional bool bCreate); //Fixes name case, optionally create if not there
FixName may look trivial, until you realize you can use it to fix native binding and package redirection, among other small things.
Having the extra 'ObjOuter' param allows you to find enum properties in a class, which then lets you use GetEnum properly.
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 »

Oh, man, please put me on tests, explain what <FixName> does (function, actor, object), I want these + a few tiny public lessons (or private if are... less cute)- <FindObject>... Can I find a deleted object for recovering it ? I intend to see if recovering a lost thing heading to crash is doable... or I might be wrong... :help:
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

This is a full build (XC_Core + XC_Engine), if you intend to revert to a stable build you'll have to revert both.

Changes:
- XC_Core: BinarySerializer can read ANSI text lines.
- XC_Core: BinarySerializer's WriteText can also append EOL chars.
- Moved SetEnemy, PreLogin, SetOrders hooks to new system.
** ScriptedPawn.SetEnemy will force monsters to attack enemies that are ScriptedPawn or have PlayerReplicationInfo.
** PreLogin should fix a string crash exploit (needs further testing).
** Bot.SetOrders is non-BotReplicationInfo friendly.
- Replaced PreBeginPlay on XC_Engine_Actor wtih XC_Init event, it's basically the only unrealscript function that gets called before GameInfo.InitGame
- Moved all Unreali/Botpack dependant hooks to a new package XC_Engine_UT99.
- Spawn and 'XC_Init' on XC_Engine_UT99.XC_Engine_UT99_Actor if Botpack package is detected.
- Spawn and 'XC_Init' on XC_Engine_TOs.XC_Engine_TOs_Actor if s_SWAT package is detected (future support for TacticalOps)
XC_Engine_hooktest_06.7z
(476.51 KiB) Downloaded 112 times
EDIT:
Now it would be a good time to get additional fixes to standard stuff.
Post Reply