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

[Barbie]

Critical: appError called:
Critical: Failed to find object 'Class XC_Engine.XC_GameEngine'

You need XC_Core

I just run into the same trap.
Probably it is a good idea to mention the dependency of XC_Core in the documentation.

Thanks for working on it anyway.
<EDIT>
The first two maps had run fine, but then "MH-Crescendo" was loaded and I could not connect to server anymore:

LoginTimeout.jpg (22.16 KiB) Viewed 5456 times

This behaviour is reproducible; it even happens if server is started up with this map. The server is running XC_Engine_17 and XC_Core_5.

servers log

[NSC-SYS] Nexgen Server Controller is active.
NotifyAcceptingConnection: Server MyLevel accept
Open MyLevel Mon Jun 13 03:40:35 2016 192.168.1.128:1043
NotifyAcceptingChannel Control 0 server Level MH-Crescendo.MyLevel: Accepted
Level server received: HELLO REVISION=0 MINVER=432 VER=436
Level server received: NETSPEED 10000
Client netspeed is 10000
Level server received: LOGIN RESPONSE=1520265788 URL=Index.unr?Name=Ken?Class=BotPack.TMale2?team=0?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?OverrideClass=?Voice=MultiMesh.SkaarjVoice
Client passed challenge
Login request: Index.unr?Name=Ken?Class=BotPack.TMale2?team=0?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?OverrideClass=?Voice=MultiMesh.SkaarjVoice
Level server received: HAVE GUID=D18A7B9211D38F04100067B9F6F8975A GEN=17
Level server received: HAVE GUID=4770B88411D38E3E100067B9F6F8975A GEN=10
Level server received: HAVE GUID=2DB53B0011D3E9001000D3B9F6F8975A GEN=8
Level server received: HAVE GUID=13F8255A11D3DBA01000CBB9F6F8975A GEN=4
Level server received: JOIN
Join request: Index.unr?Name=Ken?Class=BotPack.TMale2?team=0?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?OverrideClass=?Voice=MultiMesh.SkaarjVoice
Team 0
Login: Ken
Possessed PlayerPawn: TMale2 MH-Crescendo.TMale0
Join succeeded: Ken
CheckConnectionAttempt: Error while checking socket status.
[NSC-SYS] Login timeout for Ken
Connection timed out after 15.000000 seconds (15.029874)
Close TcpipConnection0 Mon Jun 13 03:41:10 2016
NotifyAcceptingConnection: Server MyLevel accept
Open MyLevel Mon Jun 13 03:41:21 2016 192.168.1.128:1043
Connection timed out after 120.000000 seconds (120.015048)
Close TcpipConnection1 Mon Jun 13 03:43:21 2016

I have left out Nexgen112, MapvoteLA13, SBMutatorFastWarShell-V3 and ServerAdds, but it keeps being odd: I can login then, move around, but can see the world geometry only, no HUD, no inventory items, no pawns, no teleporters.

Public server has now "GameEngine=Engine.GameEngine" again.
</EDIT>

[sektor2111]

Disable "NewRelevancy" and use an Uscript-ed one as in example from this section - else I'll put for it some full source-code and tool somewhere in forum. Watch out at that map...
New relevancy is not for 1600 Creatures. If you are loving those complex maths, tell me how do you want to update 1600 creatures through 1023 channels + map + nexgen + Mapvote +... NewRelevany is for common DM.

[Higor]

New Relevancy is bugged on linux due to a GCC 2.95 Compiler bug not properly aligning local data variables to 16 bytes.
It's a miracle the program doesn't crash during the 'new' relevancy checks.
Temporarily disable that setting until next release.

Login as administrator, use command: ADMIN TOGGLERELEVANCY until you get the desired result.


UPDATE:
Since the whole name management + linux bugs are important issues, I'm gonna make a maintenance release soon.
It's easier to replace channel creation on servers as it's done by the relevancy loop, but on clients that's another story.

One thing I can think of for clients is to reset the name counter to zero once it reaches a number.
Let's see... Client Connected to server: up to 1022 actor channels, Demo Recording: up to 1022 actor channels.
Then we have the name creator, which first runs an object scanner first to see if there's an object taking said name.
So, resetting when the number reaches 5000 is a way to avoid lockups for scanning multiple taken names, 5000 should properly spread the queries among 2044 possibly taken names, and allows taken names to be recovered before they're queried again.

So, we limit the amount of memory actor channel names take by controlling the naming on servers with 1022 choices, and by cycling between 5000 choices on clients.
This paired with the dual garbage collection on level switch, we wouldn't really need another garbage collector to be manually ran ever.

===
BTW, there's an undocumented feature introduced in v17 (my bad here):
When loading a map, a gametype is always selected no matter what, all according to the following criteria:

GameInfo class present in URL(?Game, can be remembered from past maps) >>> Attempt to load said class.
GameInfo class not present in URL >>> Load the LevelInfo's DefaultGameType field.

Then if no class has been loaded >>> Load "Engine.Engine.DefaultServerGame"
Then if no class has been loaded >>> Use GameInfo generic class.
The game will never crash if you misspell the gameinfo class in ?Game or if the default game fields are empty.

[sektor2111]

I did not have issues with those game declarations. I had Old issues with that sounding order... Very late I have figured some of troubles where are from. It's simple, more Server-Actors using timer were doing crap. I have changed all of them with State type time control and... suddenly XC_Engine v17 works like a charm. No more Timers from now on... ServerAdds, NoD3DCrash, Relevancers, OsRelics and the rest of garbage. I morphed them in state related modules - unbelievable how well do works this way.
The rest, you might wanna light me a bit about that Httpclient used by IpToCountry and "Addon" which stops working after some MH firsts kills. Doesn't matter what I tried, in MH it stops working. Aside those "cute" Scoreboards looks like they trigger a http query rather than checking local INI if some player can be found there "IPToCountry.IPData". Aside, I see no reason to spawn a "http" thing if no player is connected right in PostBeginPlay - perhaps some people will want to participate at some remake and a few info about that "http" funky thing should be given. You might do a check there and explain me a few http details because I believe that IpToCountry sometimes goes in troubles itself. Addon spawned is not friendly in high loads or http instance should be removed after returning the result before to get rammed by some unidentified problem.

[Higor]

I have fixed the Linux player name replication with a VTable replacement on the PlayerReplicationInfo.PlayerName property.
Took me like 25 slow compilations on the Ubuntu machine until I remembered all the FArchive bugs in the Linux ports, so as long as it's Engine.so serializing the data and not XC_Engine.so we're fine.
So I'm forwarding individual character serialization to the PlayerReplicationInfo.Team property, it was a wild hack but it worked!

Code: Select all

class UXC_StrProperty : public UStrProperty
{
public:
	UXC_StrProperty()
	{}
	UXC_StrProperty( ECppProperty, INT InOffset, const TCHAR* InCategory, DWORD InFlags )
	:	UStrProperty( EC_CppProperty, InOffset, InCategory, InFlags )
	{}
#ifdef __LINUX_X86__

	//
	// Net serialization.-- Linux fix
	// Context, Linux only sends data without special characters
	// TCHAR in this OS is 8-bit ANSICHAR aka BYTE
	//
	UBOOL NetSerializeItem( FArchive& Ar, UPackageMap* Map, void* Data ) const
	{
		//Receiving? Use old code
		if ( Ar.IsLoading() )
			return UStrProperty::NetSerializeItem( Ar, Map, Data);

		//Sending data? Hack it!
		TArray<BYTE>* A = (TArray<BYTE>*)Data;
		INT SaveNum = A->Num();
		Ar << AR_INDEX(SaveNum);
		//FArchive::Serialize is grossly broken in Loki/UTPG ports, so we can't use it
		static UProperty* Team = FindScriptVariable( APlayerReplicationInfo::StaticClass(), TEXT("Team"), NULL);
			for( INT i=0; i<SaveNum; i++ )
			{
				BYTE Character = (*A)(i);
//				Ar << Character;
				//Instead we use another BYTE property to do the character serializing for us (var byte Team)
				Team->NetSerializeItem( Ar, Map, &Character);
			}
		return 1;
	}
#endif
};

[Higor]

Beta XCGE 18 linux build (new relevancy still broken, disable it)

Highlights:
- XC_IpDrv.XC_TCPNetDriver fully functional in all versions.
- Player names replicated without bad characters.
- Package sorting so that UTX files go last, should prevent sliding players for ST3C clients.

[Higor]

XC_Core version 6 update.

UnXC_Math.h:
- Enhanced both DoublePlaneDot implementations.
- Linux: Fixed DoublePlaneDot and FLinePlaneIntersectDist.
** (These are used in the relevancy traces)

Created abstract XC_NetConnectionHack class:
- Moved common v436-v440 compatibility macros and functions of XC_Engine and XC_IpDrv into this class.

Included XC_Networking.cpp in sources.
- Contains all the XC_ChannelDownload and XC_NetConnectionHack code.

XC_Engine version 18 update.

XC_Engine:
- Requires XC_Core version 6
- AdminLoginHook actor locked via bNoDelete to prevent crashes upon actor destruction
- Major code cleanup and binary size reduction.
- Removed some useless status properties in XC_GameEngine class.

Server:
- Package list sorted so that .UTX files are placed last, this should prevent sliding players issues.
- [Linux] Player names with weird characters properly replicated.

Client:
- ActorChannel names limited to ~5000, counter goes back to zero once number is reached.

New Relevancy Loop:
- ActorChannel names use the Connection as Outer and their slot as name number (ex: TCPIpConnection2.ActorChannel87).
** No longer creates millions of names, level switch on very crowded servers now immediate.
- [Linux] Fixed relevancy traces.

XC_IpDrv update:

XC_TCPNetDriver functional in Linux.
Moved v440 compatibility code to XC_Core.

[Barbie]

Login as administrator, use command: ADMIN TOGGLERELEVANCY

I see that it is still needed in version XC_Engine_18 for Linux. Can this command also be done by code somewhere? Has it to be run once on a server start or once for each map load?

[Higor]

Login as administrator, use command: ADMIN TOGGLERELEVANCY

I see that it is still needed in version XC_Engine_18 for Linux. Can this command also be done by code somewhere? Has it to be run once on a server start or once for each map load?

Why is that? I fixed the bug (GET THE VERSION IN THE MAIN POST).
The command saves the config, unless you're actually using a read-only config file.
Keep it enabled at all times and report bugs instead.

The enhanced relevancy should get rid of channel overflow problems causing Nexgen failures (it's proven it works on Win32 servers) and I pretty much got Linux build to run almost the exact same SSE implementations succesfully.
Also, it's required so that the server doesn't create millions of names when there's too many players.
If possible, post names of maps that cause the problems.

[Barbie]

ADMIN TOGGLERELEVANCY
...
The command saves the config

By inspecting the new keys in UnrealTournament.ini I guess that this setting can also be done by the following INI setting, right?

Code: Select all

[XC_Engine.XC_GameEngine]
bUseNewRelevancy=True|False

GET THE VERSION IN THE MAIN POST

I'm using »XC_Core_6« and »XC_Engine_18« linked in the first post, yes.

Keep it [bUseNewRelevancy] enabled at all times and report bugs instead.

I again run the map MH-Crescendo (3378 Actors) and noticed no difference to XC_Engine_17; same strange behaviour as I described here. If I set bUseNewRelevancy=False, map runs normal.

FYI the new sections of linux server's UnrealTournament.ini (v451):

Spoiler

Code: Select all

[XC_Engine.XC_GameEngine]
bAutoCompressLZMA=False
bAutoTravelManager=False
bCacheConvertAtJoin=False
bCollisionHashHook=True
bDisableBrushTracker=False
bDisableTimingFix=False
bEnableDebugLogs=False
bFasterUpload=True
bForceLevelHook=False
bScriptDebug=False
bSortMaplistByFolder=False
bSortMaplistGlobal=False
bUseLevelHook=True
bUseNewRelevancy=True
bUseSetEnemyHook=True
CacheSizeMegs=4
MinClientVersion=432
UseSound=True

; its a private test server, so don't use uplinks:
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=unreal.epicgames.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master0.gamespy.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.mplayer.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.333networks.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.oldunreal.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.errorist.tk MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.qtracker.com MasterServerPort=27900
;ServerActors=UWeb.WebServer
ServerActors=IpDrv.UdpBeacon
ServerActors=IpServer.UdpServerQuery
ServerActors=IpToCountry.LinkActor
ServerActors=Nexgen112.NexgenActor
ServerActors=ServerAdds.ServerAdds

ServerPackages=BotPack
ServerPackages=multimesh
ServerPackages=Soldierskins
ServerPackages=CommandoSkins
ServerPackages=FCommandoSkins
ServerPackages=SGirlSkins
ServerPackages=BossSkins
ServerPackages=EpicCustomModels
ServerPackages=TSkMSkins
ServerPackages=TNaliMeshSkins
ServerPackages=TCowMeshSkins
; For Epic Bonus Pack 4, you also need the single line "ServerPackages=SkeletalChars".
ServerPackages=SkeletalChars
ServerPackages=CountryFlags2
ServerPackages=Arumi
ServerPackages=ArumiSkins
ServerPackages=Squirrel
ServerPackages=SquirrelSkins
ServerPackages=Sabb
ServerPackages=SabbSkins
ServerPackages=marvinskins
ServerPackages=marvin
ServerPackages=MapvoteLA13
ServerPackages=Barbie
ServerPackages=SBMutatorFastWarShell-V3
ServerPackages=BarbiesWorld
ServerPackages=NexgenCC
ServerPackages=Nexgen112
ServerPackages=SBCannonFix
ServerPackages=SBIncomingSnds
ServerPackages=SLV2Fonts

[XC_IpDrv.XC_TcpNetDriver]
ConnectionLimit=128
LogPortUnreach=False
AllowPlayerPortUnreach=False
DownloadManagers=XC_IpDrv.XC_HTTPDownload
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=XC_Core.XC_ChannelDownload
MaxDownloadSize=0
AllowDownloads=True
LanServerMaxTickRate=50
NetServerMaxTickRate=30
MaxClientRate=25000
ServerTravelPause=4.000000
SpawnPrioritySeconds=1.000000
RelevantTimeout=6.000000
KeepAliveTime=0.000000
InitialConnectTimeout=25.000000
ConnectionTimeout=10.000000

[Higor]

Send me the map, gonna see what's up with it (it's probably affecting the win32 build too).

EDIT: NVM leeched it from a server.

EDIT2: It's even happening on the Win32 build, so it's a different bug.

EDIT3: So I play the map and brainstorm a bit.
First, there's way too many solid brushes with translucent surfaces touching walls and ground, that completely messes up some of the BSP nodes' flags and occlusion.
Second, when the netspeed is TOO high, the actor channel list fills faster than some of the higher priority actors update... so I'd need something to hold off the low priority actors while the high priority ones are being sent.
Third, could add a special case where low priority actors' channels are manually closed if the channel count exceeds 900 (so that new actors take their place... especially those nearest the player).

BTW, in this specific map I detected some BSP nodes with non-transparent surfaces marked as 'NF_NotVisBlocking', removing said flags caused some (around 5%) of the monsters to not be replicated, but it was still not enough.

[RocketJedi]

Hi There seems to be a latency problem with flag grabs. This happens only sometimes, but in a full server it happens a lot.

With XC engine off when you grab the flag normally by running across it or in our case flying with RX the flag is taken near instantly

with XC engine on there is a 2-5 second delay after the flag has been grabbed / returned etc it also seems to be affected byt the amount of players in game as well.

On our test server I simply grabbed the flag (walk/running) using behind view 1. I had the flag and the flag was also still showing on its flag stand.

Even with some flag returns there is a 1-2 sec delay before the flag shows back up at the base.

This was not a problem in the older XC engine versions 3.x for isntance

Using all the latest XC components

any thoughts?

[sektor2111]

I could figure some "a bit lazy" pickups at a moment but not that disturbing, probably in a server under-resourced (as mine) with 5 players might be happening more intensive (or not ??)... the rest of my CTFGame does run with "AssaultTheBase" with v18 doesn't matter what I tried. But... it didn't crash.

[Chamberly]

Hi There seems to be a latency problem with flag grabs. This happens only sometimes, but in a full server it happens a lot.

With XC engine off when you grab the flag normally by running across it or in our case flying with RX the flag is taken near instantly

with XC engine on there is a 2-5 second delay after the flag has been grabbed / returned etc it also seems to be affected byt the amount of players in game as well.

On our test server I simply grabbed the flag (walk/running) using behind view 1. I had the flag and the flag was also still showing on its flag stand.

Even with some flag returns there is a 1-2 sec delay before the flag shows back up at the base.

This was not a problem in the older XC engine versions 3.x for isntance

Using all the latest XC components

any thoughts?

Hey, at least it's not like RB's RX as it didn't pick up the flag at all!
So it kept happening after 3.x updates?

[Higor]

Run two tests in near identical settings (XC=off and XC=on)

Load the map/mods where this problem occurs
Hit F6 and write down the channel count and bandwidth usage.
Type INJECT USERFLAG 1 (disable with INJECT USERFLAG 0) and write down all the info being printed.

Then, load the same map/mods but on Standalone mode, is everything working as intended?

If something is broken in standalone mode, then it's the collision octree.
If it's not, then it's the relevancy loop.

EDIT:
Also I need to know:
- XC_Engine version
- UT version
- Win32 or Linux?
- XC_GameEngine settings from INI (no need for ServerActors/ServerPackages)