Author Topic: [DLL] Tick Rate Modding Experiment (updated)  (Read 421 times)

Yesterday I wanted to see if it was possible to patch Blockland and enable variable tick rates as would be allowed if you had the source. Here I am now with a working DLL! I've tested 62.5 tps and 125 tps so far, and I'm currently hosting a server for those interested in experimenting with me. You will need to run this on your client in order to play properly, although interestingly clients without the DLL can still join. Attached is the source for the DLL. If you want you can add me on my discord (in my profile) for a build.

This is a special DLL! It needs to run before engine classes are registered with the console. So it won't work with Port's BlocklandLoader. Use Stud_PE to open Blockland.exe, go to the functions tab, right click the list in the "Imported Functions" box and select the DLL and the export "hello." This will add it to Blockland's imports and cause it to load before the main thread gets a chance to do anything. Make sure the DLL is also in the same directory as the exe. You can also do this on Port's modified exe to retain DLLs you already have.

(also, if you want to revert/remove the DLL to play on other servers, you'll have to undo what you did in StudPE.. or recompile for regular ~32tps. Back up your exe!)

Update for version two:
- Fixed projectile lifetime/armingDelay/fadeDelay range limits
- Added patch for max packet rate clamp

Note: $Pref::Net::PacketRateTo* variables are clamped both in the engine and in the dsos. So you'll have to re-set these variables after your server or client is done executing default scripts!! Can't say I didn't warn ya!

Apparently the player collision issues aren't bugs, it's just a side effect of how higher tick rate collision calculation works. This version should be complete, then! Enjoy!
« Last Edit: May 14, 2019, 12:05:40 AM by CompMix »

could you outline the benefits of higher tick rate for those who dont know what this means? off the top of my head i can think of these as benefits:
  • faster and more accurate position updates for things like vehicles and players
  • slightly more accurate collision updates
  • for challenge servers, more accuracy and smaller spacing in recorded time values
  • can support more vehicles/bots in the update loop - ports/pahs superghost for bots but for everything.
  • as an extension of the above, ghosting is faster


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.

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
« Last Edit: May 12, 2019, 04:59:51 PM by PhantOS »

  • can support more vehicles/bots in the update loop - ports/pahs superghost for bots but for everything.
I want to know the specifics on this


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!):

Code: [Select]
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.
« Last Edit: May 13, 2019, 09:59:28 AM by CompMix »

does this also mean events can run at a faster rate?
what about schedule with lower than 33?

so i guess now i can make staticshapes move fluidly instead of teleporting every 33ms.

does this also mean events can run at a faster rate?
what about schedule with lower than 33?
events are simply function calls, so that doesnt necessarily happen any faster unless the tickrate also decreases the time it takes for the engine to do something. i kinda doubt that, but it might be the case since its known that timescale 2 == game engine literally runs at 2x speed. that might be a misconception though, but that's what ive heard.

definitely can do schedule lower than 33ms with this setup, probably only useful for logic gate/computer stuff. and even then there's better solutions (Redo's logic bricks that "outsource" the calculations/switching simulation into a lua engine which runs much faster than bl)

Source has been updated to fix a bug and add in the packet rate patch. Make sure to check that the packet rate variables are set properly because the default scripts like to clamp it on startup as well.

does this also mean events can run at a faster rate?
what about schedule with lower than 33?

events are simply function calls, so that doesnt necessarily happen any faster unless the tickrate also decreases the time it takes for the engine to do something. i kinda doubt that, but it might be the case since its known that timescale 2 == game engine literally runs at 2x speed. that might be a misconception though, but that's what ive heard.

definitely can do schedule lower than 33ms with this setup, probably only useful for logic gate/computer stuff. and even then there's better solutions (Redo's logic bricks that "outsource" the calculations/switching simulation into a lua engine which runs much faster than bl)

Schedules run as fast as the game can run its main loop, so sub-32ms has been a thing since forever. Timescale causes events to run faster because you're artificially scaling the elapsed time that happens between engine loops, which makes schedules execute sooner or later based on how much time has passed. So this DLL doesn't change how fast events execute.

The only difference you would see maybe is if your events or schedules caused ghost updates for things, because the engine will now both simulate objects and send updates to clients faster.

so i guess now i can make staticshapes move fluidly instead of teleporting every 33ms.

With a DLL you can cause vehicles to not have gravity on both the client and server, effectively making them interpolated shapes with rigid body physics. I made moving platforms (gears) for Heedicalking with this method and it's very smooth.

With a DLL you can cause vehicles to not have gravity on both the client and server, effectively making them interpolated shapes with rigid body physics. I made moving platforms (gears) for Heedicalking with this method and it's very smooth.
is it possible for a server sided dll to allow clients to see the objects interpolate or would the clients need their own dll for that since there's no prediction on shapes

Quote
patch(0x6D81BC, 9.81f * TickSec);

so im guessing the engine has its own arbitrary gravity math?
« Last Edit: May 14, 2019, 02:50:43 AM by PhantOS »

is it possible for a server sided dll to allow clients to see the objects interpolate or would the clients need their own dll for that since there's no prediction on shapes

That's what made it special. Client does prediction on all vehicles, even ones you're not driving, so it takes a few tricks to both get lack of gravity and disabled prediction.

o im guessing the engine has its own arbitrary gravity math?

x87 and SSE instructions only accept floats from memory locations, not immediate values. I use the word immediate in the code but that's basically meant for anything not in rdata and utilizing the stack (the IEEE representation is reused everywhere). Computing 9.81 times the tick rate is just an optimization.