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

[Chamberly]

Sent a PM.

That won't help the others, if they too would like some info on setting this up ... care to share?

Because my document on setting it up is outdated :L I just wanted him to try it out and see if it work well so it won't be just 1 person who have officially completed it.

I'll write up another soon. But for now I'll just let him send me a feedback so I know what I should get it understandable as a tutorialist. lol.

If you want one I'll send it to you too.

[sektor2111]

MY options as follows:
A) Server:
- XC_Engine, XC_Core, XC_IpDrv;
- declared INI-s config as described.

B) MY Client
- XC_Engine, XC_Core, XC_IpDrv;
- Stuff was previously declared in INI but I see... not necessary.

How works:
This client with normal INI but XC files loaded will "understand" that server is able to use LZMA and will get files from... whatever location redirect or directly sent. When client have files location info will download/decompress them properly triggered by server.
For client is veeeery simple, only copying XC files in system - advanced users might declare stuff in INI but it's not The No. 1 Factor.

Fix me, Higor, if I'm wrong.

[Wises]

Thanks Guys and Girls

wondering if this mod conflicts with ;

XserverQuery IP.Drv (will XC_GE conflict with this? if so is there a way around it?)
MapVoteX Actor / Package Loader (as it rebuilds ServerPackages && ServerActors if utilized)

Ty

[Chamberly]

Thanks Guys and Girls

wondering if this mod conflicts with ;

XserverQuery IP.Drv (will XC_GE conflict with this? if so is there a way around it?)
MapVoteX Actor / Package Loader (as it rebuilds ServerPackages && ServerActors if utilized)

Ty

It doesn't have any problem with that xserverquery as I been playing with it on my server and so.
CMV does the same thing as a dynamic loader with XC_GE, so you could configure the XCGE and try it with MVX. (Tbh, I haven't been able to set up MVX since the complicated set up or something lol. I'm sure it'll work unless there is some kind of actor conflict within the codes.)

[sektor2111]

As I could figure from client log. Server is sending file info in response for connection, client get those things compression (even type) also if true false + redirect address. Mainly is trying to use XC_IpDrv which will deal with the rest of libs involved in downloading decompressing. So technically using default IpDrv but having XC loaded, XC will run when it feels called. Assuming another wild lib is not very restrictive and allows other DLLs to run perhaps will work, more exactly task is hooked by XC_IpDrv.

Xc stuff as mentioned being Beta I have sorted files needed which for me were flawless last time as follows:
- XC_Engine - > v16 (even UWindowList version)
- XC_Core3
- XC_IpDrv > released January 13 with checksum described in this thread.

These files will go in client too (declared or undeclared).
If you are curious you can see me on Skype where I can point you to some server (which it is used for testing) configured as described above and you can do a direct check not based on stories. Later you can examine client logs, test redirects with different tools, etc. Then you'll get how are these things supposed to work.

Simple default client will download files only from server VIA XC_Engine and without UZ (UZ won't be used anymore by me).

[Higor]

So after various games of smooth play I crashed 3 times on the same map, all different stuff.
I'm using a BAT file to rotate logs on my client, just like any decent server.

============================================================================
Oh ho! I found something interesting in this log... thanks to one of my mods.

Code: Select all

Critical: ULevel::CheckEncroachment
Critical: ULevel::FarMoveActor
Critical: UGameEngine::Draw
Critical: UWindowsViewport::Repaint
Critical: UWindowsClient::Tick
Critical: ClientTick
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: ACE8421
Critical: EnforceTickRate
Critical: MainLoop

One of those nasty CheckEncroachment checks happeing in the rendering process, then I realized that the only thing moving actors in that stage is LCWeapons (position advancer).
LCWeapons removes actors from the hash/octree using a SetCollision(false) call, so I checked CheckEncroachment and found something interesting...

Code: Select all

	guard(ULevel::CheckEncroachment);
	check(Actor);

	// If this actor doesn't need encroachment checking, allow the move.
	if( !Actor->bCollideActors && !Actor->bBlockActors && !Actor->bBlockPlayers && !Actor->IsMovingBrush() )
		return 0;

This doesn't care if the actor isn't supposed to collide anymore!!
Looks like a bug to me but I'll happily test a branch where all encroachment checks return NULL if the actor doesn't have bCollideActors=True.


============================================================================
Same old stuff, I have to figure out what's up here.
One interesting thing is that this part of the code only does stuff if there's movers in the way.
If there are no movers then this does nothing (almost).
BTW, the game mode uses brushless movers as platforms, I'll have to start there...

Code: Select all

Critical: CheckWithActors
Critical: ULevel::MultiLineCheck
Critical: ULevel::MoveActor
Critical: AActor::moveSmooth
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=3)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: ACE8421
Critical: EnforceTickRate
Critical: MainLoop

============================================================================
Ouch, this code is inside XC_Engine.

Code: Select all

Critical: ActorLoop
Critical: FCollisionOctree::FastLineQuery
Critical: FCollisionCacus::ActorLineCheck
Critical: CheckWithActors
Critical: ULevel::MultiLineCheck
Critical: ULevel::Trace
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=3)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: ACE8421
Critical: EnforceTickRate
Critical: MainLoop

Alright, let's take a look.

Code: Select all

			FVector4 HitLocation; //TODO: use FVector4!!!
			FVector4 HitNormal;
			guard(ActorLoop);
			for ( INT i=0 ; i<ActorCount ; i++ )
			{
				AActor* Actor = CacusNodes[CurRef]->Actors(i).Actor;
				if ( !ValidCollidingActor(Actor) )
					continue;
				if ( !Ray.HitsGCylActor( Actor, &HitLocation, &HitNormal, Primitive) )
					continue;
				/* ... crash doesn't occur here ... */
			}
			unguard;

I see these options:
- Invalid pointer (Actor)
- Unstable math in HitsGCylActor (3 different trace methods, I should add exception handlers here)

============================================================================

[sektor2111]

Interesting... (or I think it's interesting).

Code: Select all

guard(ULevel::CheckEncroachment);
   check(Actor);

   // If this actor doesn't need encroachment checking, allow the move.
   if( !Actor->bCollideActors && !Actor->bBlockActors && !Actor->bBlockPlayers && !Actor->IsMovingBrush() )
      return 0;

I see only a... primitive raw code, specific to something like rushing for reaching at sugar and breaking legs in next 2 seconds.
Physics ? Zone ? and "bCollideWorld", or pending removal, etc. bIsPawn - presuming EncroachedBy gets called somehow ? Whatever type of actor having base or such. Am I wrong ?

[Higor]

XC_Core version 5 update.


Fixed crash bug after sending/receiving file using XC_ChannelDownload in Windows builds.
XC_CoreStatics.XC_Core_Version now properly indicates build version.

FindScriptVariable(): can be called with [NULL] 'Found' pointer.

[Higor]

Grid test 4.
More exception handlers (may slow down grid by a small %).
Client, Server, Demo working.
Version reporting fixed.

BTW check the version indicator when you launch the game

[sektor2111]

Nope...

Code: Select all

NetComeGo: Close TcpipConnection2 03/22/16 19:36:06
Critical: UObject::ProcessEvent
Critical: (NsTFemale1 DM-Pressure_Rv.NsTFemale0, Function Engine.PlayerPawn.Destroyed)
Critical: ProcessDestroyed
Critical: ULevel::DestroyActor
Critical: (NsTFemale1 DM-Pressure_Rv.NsTFemale0)
Critical: UPlayer::Destroy
Critical: UNetConnection::Destroy
Critical: XC_IpDrv::~UTcpipConnection
Critical: UObject::ConditionalDestroy
Critical: (TcpipConnection Transient.TcpipConnection2)
Critical: DestroyClientConnections
Critical: UNetDriver::Destroy
Critical: UObject::ConditionalDestroy
Critical: (XC_TcpNetDriver Transient.XC_TcpNetDriver1)
Critical: ExitLevel
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down

Happening when game has ended, post voting, at travel time... I stay with v16.

[Higor]

Did you edit the event Destroyed() on those pawns?
Because so far I haven't been able to crash the v436 server on level switch (with players on it).

EDIT:
Also, i'd suggest enabling this option on the server:

Code: Select all

[XC_Engine.XC_GameEngine]
bScriptDebug=True

[sektor2111]

That is true (as always). This crash has random behavior it's not usual - sometimes crash, sometimes not - it's unstable. A single time I saw something like "Critical ScriptV..." if I well recall - a not very relevant line to looks like a function crash and the rest was like above. Other crashes were similar - No other ScriptV or such things. Whatever you've done at player in state "game ended" it needs a revision. I don't know what is going on in any other instances/games or not, but definitely in v16 this crash has never existed.

[Higor]

I'd like to see the event in particular.
When the server is switching maps it'll destroy the player pawns, even if destruction event isn't needed due to mapswitch.

[sektor2111]

... even if destruction event isn't needed due to mapswitch.

I believe I want to eliminate that (if I'm not mistaking), because if player quits during "servertravelpause" by pressing F10 or demanding "exit" with a key bound, I don't need to keep that connection in Next Level if Player went to bed, right ? Perhaps we want to sanitize stuff, destroy if exist something for destruction or whatever relevant things not NULL things.
Perhaps Prelogin might need a revision - I see many times a second connection being closed unused after a couple of seconds - player is already in game and playing using 1 connection and number 2 is closed (why did open if we have player on the first ?).

[Higor]

There may be a chance that collision hash mangling is the problem... a chance though.

Changes:
- Map loader now will either create FCollisionCacus or FCollisionHash depending on settings, never both. (*1)
- Fixed bug in FCollisionCacus destructor that caused segmentation fault, removed UXC_GameEngine::DeleteCollisionCacus (*2)
- Added XC_GameEngine.bForceLevelHook (def=False), this forces Level hook in Client games (DON'T USE ON ACEv09 SERVERS).
- Added more exception handlers. (*3)

XC_Engine_gridtest5.7z

*1 - FCollisionCacus can be created via the level hook or the engine hook (if level hook not possible: clients for example).
*2 - The level's SetActorCollision(false) method now promptly destructs both collision systems without problems.
*3 - Level hook modifies 'MoveActor' function to add better error tracing, if you get a crash of the sort UXC_Level::MoveActor, inform me.

Known bugs:
Reconnecting into the same map (mostly as spectator) may cause the skyboxes to not be linked, I suspect the level isn't being fully cleaned up when reloading itself.