Post
by Higor » Fri Mar 13, 2015 9:47 am
These are facts, not myths:
1 - Player connections are limited to 1023 channels.
2 - If you connect into a zone where there's >1023 relevant actors, your player pawn will fail to be replicated, resulting in your client sitting in "Connecting...", while server spawns your actor and attempts to replicate it (failure).
3 - Channels for actors whose variables don't change don't transmit data.
NPLoader has a bug where NPLReplicationInfo actors don't self-destruct when the owner player disconnects, a populated server with long games like uk Siege will have between 30-150 of these actor channels doing nothing until the map changes, I already reported this bug to anth over 9000 years ago, I may have to design a ServerActor of my own to kill these annoying channel-hoggers.
4 - The local player constantly sends ServerMove functions so that the internal ServerTickClient doesn't interrupt the connection, this occurs because if (Driver->Time - NetConnection->LastReceiveTime) is greater than 1.5 second, the ServerTickClient will always return 0 and interrupt/delay any replication from server.
This can explain certain behaviours, like non-bNetTemporary projectiles failing to disappear on clients after a huge lag spike (never seen a shock ball stuck into a wall?).
5 - Relevancy traces going through translucent surfaces is now default behaviour in Unreal 227, a game with a vastly superior engine than UT.
6 - Replication checks consume CPU resources using a formula of this sort: [Summatory of (update frequency * variable count * player count) for each relevant actor ]
The only loser in increasing the amount of replicated actors, server TickRate or making highly net-unoptimized mods is the Server, the client never sees any performance impact.
Earlier NewNet versions would not be able to go over 12 players due to excessive CPU usage on 100 tickrate servers, for example.
I also devised a tool myself that reduces the PlayerPawn's NetUpdateFrequency dynamically depending on player count, from a configurable table, you can make your Server's client channels never reach the 20k bytes per second mark if you want to, which as a result also decreases CPU usage on replication checks.
7 - Inventory actors do not replicate their Inventory based variables to non-owner players, no matter how much you try messing with the replication checks.
8 - Inventory actors always update at a frequency of 2hz on dedicated servers, no matter what NetUpdateFrequency value you set.
9 - Actors that fail relevancy checks after being relevant will continue to be relevant for a IpDrv.TcpNetDriver.RelevantTimeout (default=5.000000).
10 - Relevancy traces hit the actor in their (0,0,0) spot, this means that a camper on a high position can snipe ppl without becoming relevant to other players, randomizing the Trace End into any point of their box each frame will solve this behaviour.
This also solves such behaviour with huge monsters/non-static decorations.
Also, by the previous rule, actors partially visible won't disappear because said timer will ensure than a new random position becomes visible before it hits zero.
11 - The only things replicated behind walls are actors where:
- Your pawn owns in it's Owner hierarchy (this even works: Actor->Owner->Owner = you)
- Your pawn is the actor's Instigator
- You are within AmbientSound radius (25.0 * SoundRadius i believe?)
- Actor has bAlwaysRelevant=True
- Actors whose relevancy timeout hasn't reached zero.
(I'm certain i'm missing another condition here...)
That's not something I intended to change, I simply want to change what 'visibility blocking wall' means.
Basically by letting traces have the NF_NotCsg + NF_NotVisBlocking flags (they currently stop at anything that blocks them, which is bad for visibility based conditions).
12 - The variable 'NetTag' in an actor determines each replication polling done to it, you can easily measure how many relevancy checks were done to it in a period of time by simply saving 'NetTag' and comparing it again one second later.
Regarding the other hacks, if there's a technical problem with those I fix them. They're there to prevent crashes, speedup the code or keep your log window from spamming.
For example, MonsterHunt servers (at least the old versions) can be greatly speed up if MH gets to know when to forcibly set a monster's Enemy to a Bot, or when not to do it (XC_GE server) because you wouldn't need to loop the pawn list on every AI polling.
The other reason for changing the behaviour of actors instead of the actors themselves is precisely to avoid sending more stuff to the clients, replacing more actors via mutators, etc.
Some things are best handled at UScript level, yes. But you can't derive everything to it, there's a point where it becomes slower, impractical and annoying to clients.
I'll have a 10.5 release for the recently fixed bug in TravelManager and a v436 Linux build, because these are indeed critical things.
, i'll just figure out something.