I must be agree here... all time I tried to point people at TESTING these. UT has internal functions for this task, all need is dropping them into a mutator.
I witnessed a tick-rate configured at 60, but in presence of 16 players all went to 18-20 due to fascinating long chain arrays computing stats and other arrays which majority of players did not care about - it's a 4 CPU Cores win based machine. What Core.dll is reporting that it's the reality from machine at UE1 Level - the rest is OS, Uscript might be different - even LOWER at this point... I did not see said report in Linux yet...
Server tick rate
- sektor2111
- Godlike
- Posts: 6417
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Server tick rate
No one mention if your servers run under Linux or windows and witch windows, I think that plays a big part to.
- sektor2111
- Godlike
- Posts: 6417
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Server tick rate
Linux or Windows these must be tested with C++ natives, Uscript is not that relevant if it's based on tick. By example at NfoServers that "win" machine (it's a VDS) has tick-rate reported by natives a bit faster than tick-rate reported by UScript for reasons which I cannot explain.
I have to admit that strong machines hosting 1 on 1 games might be better in all the way capable for real high tick-rates.
And now the techs - which I tested so far.
There is a command that can be sent from UScript and log captured as string called MEMSTAT.
This is showing amount of memory taken by UT compared with the rest - we have to take in account maximum amount which UT can handle...All status can be re-logged not only a fragment of interest.
Then in the same function... GETMAXTICKRATE GETCURRENTTICKRATE
What was reported in a high load moment was pretty closer to reality, players could feel the loss of performance without to be experts trained at Oxford.
Report can be done in a slow state code not each tick, just from time to time - a configurable time. Of course, strategy can be coded different, assigned to a mutate command, etc. Injecting userflags also shows if server it's under-resourced and admin is hypocrite pointing finger at player when his machine used it's an overloaded wreck unable to sustain a constant tick-rate or physically won't ever reach at 70-80.
I have to admit that strong machines hosting 1 on 1 games might be better in all the way capable for real high tick-rates.
And now the techs - which I tested so far.
There is a command that can be sent from UScript and log captured as string called MEMSTAT.
This is showing amount of memory taken by UT compared with the rest - we have to take in account maximum amount which UT can handle...
Code: Select all
local string Status, CrTick, CfTick;
// log ("Triggerring");
status=Level.ConsoleCommand("MEMSTAT");
if ( bLog )
log("Load ="$Right(Status,4)$" at "$Level.Game.NumPlayers$" Players.",'MemoryStatus');
Then in the same function... GETMAXTICKRATE GETCURRENTTICKRATE
Code: Select all
CrTick = Level.ConsoleCommand("GETCURRENTTICKRATE");
CfTick = Level.ConsoleCommand("GETMAXTICKRATE");
Status="Current Tick-Rate = "$CrTick$", Max Tick-Rate = "$CfTick;
if ( bLog )
log(Status,'TickState');
if ( bBroadCast )
MyBroadCastMessage("Tick-Rate Actual/Config = "$int(CrTick)$"/"$int(CfTick)$" ticks per second.");
Report can be done in a slow state code not each tick, just from time to time - a configurable time. Of course, strategy can be coded different, assigned to a mutate command, etc. Injecting userflags also shows if server it's under-resourced and admin is hypocrite pointing finger at player when his machine used it's an overloaded wreck unable to sustain a constant tick-rate or physically won't ever reach at 70-80.