could you outline the benefits of higher tick rate for those who dont know what this means?
You're right about simulation being keener in general. The game will tick faster (a tick will last 16 or 8ms compared to 32ms) while also moving objects at smaller increments. Input will be sampled more often and makes the game feel smoother. A friend and I crashed a bunch of vehicles into buildings on a 125 tps setting, and we both agreed it felt more "solid" as we couldn't manage to penetrate bricks. Although, no formal measurements were done so this could just be placebo (Additionally this should only be slightly different than just increasing the .integration field in the datablock). The same applies for projectiles and players-- fast moving targets should have a higher likelihood of being hit.
I'm not sure about challenge servers yet because we experienced a few odd bugs related to climbing up stairs and more generally player collision with bricks. It might be that there's an extra patch that needs to be done to fix up collision calculations every tick or it could be something else. Not quite sure yet.
"Superghost but for everything" is accurate. That specific DLL/patch just makes the server flood the client with packets (it's not even specific to bots either-- ghost updates of any kind) until the window is full (ie there's a 30 packet lead from last sent to last acked) but a higher tick rate is fairly comparable, the engine will check if it needs to send packets more often. Although (rather lamely) this is limited by the range of the packet send and receive rates like $Pref::Net::PacketRateToClient as they don't go above 32 packets per second. I'll say more about that below.
Ghosting should be faster but the game will automatically flood clients with packets whenever large amounts of anything are ghosting. That DLL you mentioned patches the function that does this to just always say things are ghosting, completely ignoring the $Pref::Net::PacketRateTo* settings.
also i suspect the reason that normal clients can still join is that ts is able to run on various packet input rates. port described the situation with ts being "it'll update as fast as it receives packets" even though it only normally sends at 30 packets/sec. its how superghost for bots works - it just ups the packet rate on the server so that everyone can get updates for more than 50 bots/players that are moving, at the cost of increased bandwidth usage from the server.
Yeah, so this is kind of like increasing the timescale but with additional patches all over the engine to 1. Decrease movement distance per tick and 2. Slow down timers of things in various simulation functions. I know about unlimited/flexible packet rates and had a hunch regular clients would still be able to play but thought it was naive to feel certain since this is a lot more than just increasing tick rate. They would be running essentially completely different engines simulation wise.
Wait so does this also raise the packet send/receive rate so that the tick rate's data can all be sent? Or do people need another dll for that
I forgot to add a patch for this. Whenever a NetConnection is instantiated it checks the $Pref::Net::PacketRateTo* variables and clamps them so they don't go over 32 packets per second. This is also done when you do %connection.checkMaxRate(). Obviously this needs to be higher for the net code to take full advantage of the rest of the engine changes. I used a hacky TS solution to trick the clamp function to allow me to go up to 128 packets per second (if it thinks you're running a LAN server it quadruples the rate). Here's that (this would work on any vanilla server too and increase packet rates to clients, so think of it like that ghost update limit DLL but in TS!):
function NetConnection::setMaxPacketRate(%t)
{
%c = $pref::Net::PacketRateToClient;
%s = $pref::Net::PacketRateToServer;
%l = $Server::LAN;
%d = doesAllowConnections();
$Server::LAN = 1;
setAllowConnections(0);
%t.checkMaxRate();
setAllowConnections(%d);
$Server::LAN = %l;
$pref::Net::PacketRateToClient = %c;
$pref::Net::PacketRateToServer = %s;
}
package SetMaxPacketRate
{
function GameConnection::startLoad(%t)
{
%t.setMaxPacketRate();
return Parent::startLoad(%t);
}
};
activatePackage(SetMaxPacketRate);
I'll see if I can fix the bugs I saw with collision and add in those patches for the packet rates tomorrow. You'd have to manually set the variables though.