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

[Higor]

On a different story... check this sweet text received from my test server.
Possible to see what XC_Engine version the server uses and all the UTX files are sorted inversely at the end of the list.

Spoiler

DevNet: PendingLevel received: CHALLENGE VER=436 CHALLENGE=-492444459 STATS=0
DevNet: PendingLevel received: USES GUID=913DD41C464D031C0AD025AB0278316A PKG=CTF-(EoW)Kanjar FLAGS=1 SIZE=1183439 GEN=1 FNAME=CTF-(EoW)Kanjar.unr
DevNet: PendingLevel received: USES GUID=D18A7B9211D38F04100067B9F6F8975A PKG=Engine FLAGS=1 SIZE=1149858 GEN=17 FNAME=Engine.u
DevNet: PendingLevel received: USES GUID=4770B88411D38E3E100067B9F6F8975A PKG=Core FLAGS=1 SIZE=59233 GEN=10 FNAME=Core.u
DevNet: PendingLevel received: USES GUID=4770B88811D38E3E100067B9F6F8975A PKG=Fire FLAGS=1 SIZE=15248 GEN=10 FNAME=Fire.u
DevNet: PendingLevel received: USES GUID=4770B88C11D38E3E100067B9F6F8975A PKG=UnrealShare FLAGS=1 SIZE=22124694 GEN=1 FNAME=UnrealShare.u
DevNet: PendingLevel received: USES GUID=1C69657611D38F44100067B9F6F8975A PKG=Botpack FLAGS=1 SIZE=39016791 GEN=14 FNAME=Botpack.u
DevNet: PendingLevel received: USES GUID=4770B88D11D38E3E100067B9F6F8975A PKG=UnrealI FLAGS=1 SIZE=18549361 GEN=1 FNAME=UnrealI.u
DevNet: PendingLevel received: USES GUID=C073770F11D2D1A4E000278383161081 PKG=Foregone FLAGS=1 SIZE=1992753 GEN=1 FNAME=Foregone.umx
DevNet: PendingLevel received: USES GUID=550D78804B403D8CDE3739BD6CA79C0F PKG=FerBotz_cl_2 FLAGS=1 SIZE=35282 GEN=1 FNAME=FerBotz_cl_2.u
DevNet: PendingLevel received: USES GUID=508172E54194F42691B9479C4B9891EF PKG=XC_Spec_r7 FLAGS=1 SIZE=55905 GEN=1 FNAME=XC_Spec_r7.u
DevNet: PendingLevel received: USES GUID=94A4668C4F74E74E115F5294D52427C2 PKG=FV_Weapons FLAGS=1 SIZE=1126143 GEN=1 FNAME=FV_Weapons.u
DevNet: PendingLevel received: USES GUID=627DAB834FAC01EBC5E278B4CB181480 PKG=sgUMedia FLAGS=1 SIZE=11184062 GEN=1 FNAME=sgUMedia.u
DevNet: PendingLevel received: USES GUID=EC4F2D9943A301112FA47BB605E188CB PKG=SiegeIV_0025 FLAGS=1 SIZE=2987127 GEN=1 FNAME=SiegeIV_0025.u
DevNet: PendingLevel received: USES GUID=517A7E0411D6B1FEE00098A02FA07B7D PKG=sgMedia FLAGS=1 SIZE=1366827 GEN=1 FNAME=sgMedia.u
DevNet: PendingLevel received: USES GUID=84DC68E448DAC3E9D38C6F9AF2949CC1 PKG=sgMedia2 FLAGS=1 SIZE=267187 GEN=1 FNAME=sgMedia2.u
DevNet: PendingLevel received: USES GUID=A3B94EE411D1ED674544E58A00005453 PKG=AmbModern FLAGS=1 SIZE=6112404 GEN=1 FNAME=AmbModern.uax
DevNet: PendingLevel received: USES GUID=A3B94EE911D1ED674544E58A00005453 PKG=Extro FLAGS=1 SIZE=2871719 GEN=1 FNAME=Extro.uax
DevNet: PendingLevel received: USES GUID=9E4BDC8211D2B3904F007391ED2A004C PKG=DDay FLAGS=1 SIZE=1534753 GEN=1 FNAME=DDay.uax
DevNet: PendingLevel received: USES GUID=7B29417A495AE03C3F5BCB8B41942FA5 PKG=LCWeapons_0017 FLAGS=1 SIZE=454260 GEN=1 FNAME=LCWeapons_0017.u
DevNet: PendingLevel received: USES GUID=FB67D84E450A4D13FA1D14BCFAFCA2EE PKG=XC_Spec_r10 FLAGS=1 SIZE=67769 GEN=1 FNAME=XC_Spec_r10.u
DevNet: PendingLevel received: USES GUID=E10A72964718B5B1E08B409D4587C332 PKG=MVLA14UUb13C FLAGS=1 SIZE=99469 GEN=1 FNAME=MVLA14UUb13C.u
DevNet: PendingLevel received: USES GUID=6B89283B4B86C0DB9C57EEB0FA46361E PKG=FV_ColorShock FLAGS=1 SIZE=1709216 GEN=1 FNAME=FV_ColorShock.utx
DevNet: PendingLevel received: USES GUID=1E90ACC111D1ED664544279700005453 PKG=Palettes FLAGS=1 SIZE=421024 GEN=1 FNAME=Palettes.utx
DevNet: PendingLevel received: USES GUID=86A1D119408C6873A5F66CB4E2D5F703 PKG=SoldierSkins_XC_ FLAGS=1 SIZE=1814938 GEN=1 FNAME=SoldierSkins_XC_.utx
DevNet: PendingLevel received: USES GUID=24E5A72411D321104F006B8CDE9A0349 PKG=BossSkins FLAGS=1 SIZE=1867811 GEN=1 FNAME=BossSkins.utx
DevNet: PendingLevel received: USES GUID=D4F6ABE111D385CAE0006295BE341081 PKG=SGirlSkins FLAGS=1 SIZE=7226959 GEN=1 FNAME=SGirlSkins.utx
DevNet: PendingLevel received: USES GUID=B7B49CA611D38BCDE0006395BE341081 PKG=FCommandoSkins FLAGS=1 SIZE=5093279 GEN=1 FNAME=FCommandoSkins.utx
DevNet: PendingLevel received: USES GUID=E96BC96311D31D2F4F006B8CDE9A0349 PKG=CommandoSkins FLAGS=1 SIZE=4318050 GEN=1 FNAME=CommandoSkins.utx
DevNet: PendingLevel received: USES GUID=93CC0A8111D3888FE0006295BE341081 PKG=SoldierSkins FLAGS=1 SIZE=7184269 GEN=1 FNAME=SoldierSkins.utx
DevNet: PendingLevel received: USES GUID=561AD02011D38D0FC00084B50A1E604F PKG=SkyBox FLAGS=1 SIZE=930722 GEN=1 FNAME=SkyBox.utx
DevNet: PendingLevel received: USES GUID=C47BBD4011D38CFBC00084B50A1E604F PKG=DecayedS FLAGS=1 SIZE=11846698 GEN=1 FNAME=DecayedS.utx
DevNet: PendingLevel received: USES GUID=66FC62C111D389A2E0006BA2D2321081 PKG=RainFX FLAGS=1 SIZE=4672509 GEN=1 FNAME=RainFX.utx
DevNet: PendingLevel received: USES GUID=74547A4511D36EACE0005F95BE341081 PKG=Coret_FX FLAGS=1 SIZE=1024846 GEN=1 FNAME=Coret_FX.utx
DevNet: PendingLevel received: USES GUID=D84EFC3911D3627FE0005F95BE341081 PKG=CTF FLAGS=1 SIZE=3192693 GEN=1 FNAME=CTF.utx
DevNet: PendingLevel received: USES GUID=1E90ACAE11D1ED664544279700005453 PKG=genfluid FLAGS=1 SIZE=5510043 GEN=1 FNAME=genfluid.utx
DevNet: PendingLevel received: USES GUID=1E90ACAD11D1ED664544279700005453 PKG=GenEarth FLAGS=1 SIZE=6186030 GEN=1 FNAME=GenEarth.utx
DevNet: PendingLevel received: USES GUID=EA07DE4111D384A9E0006BA2D2321081 PKG=Xtortion FLAGS=1 SIZE=853804 GEN=1 FNAME=Xtortion.utx
DevNet: PendingLevel received: USES GUID=1E90ACA811D1ED664544279700005453 PKG=Detail FLAGS=1 SIZE=1729964 GEN=1 FNAME=Detail.utx
DevNet: PendingLevel received: USES GUID=2E3682A411D379A7E0006BA2D2321081 PKG=UTtech1 FLAGS=1 SIZE=11206345 GEN=1 FNAME=UTtech1.utx
DevNet: PendingLevel received: DLMGR CLASS=XC_Core.XC_ChannelDownload PARAMS=Enabled COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=Engine.ChannelDownload PARAMS=Enabled COMPRESSION=0
DevNet: PendingLevel received: XC_ENGINE VERSION=18
DevNet: PendingLevel received: WELCOME LEVEL=CTF-(EoW)Kanjar LONE=0

Also, I added fixed ActorChannel names to the connections, now they always range 1-1022 and memory usage never rises!
It's all going to require XC_Core version 6 though but after I get a whole beta build done I'll put a package up.

BTW i'm also trying to figure out what's causing linux's strings not sending chars >0x7F, this would fix player names with weird characters on linux servers.

[sektor2111]

I'll prepare that shared structure described on my machines. I'm really interested about this way.

[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

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.