Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - CompMix

Pages: 1 2 3 4 [5]
61
Modification Help / Re: Moving Platform
« on: June 18, 2019, 12:33:22 AM »
We had moving platforms like this implemented with vehicles, selective ghost updates, and replicating the player movement surface walking function to detect whoever was on the vehicle. Through selective ghost updates we could make players warp while you observed the vehicle and force a teleleport when riding. This was needed because when riding, the vehicle object needed to appear rigidly updated as your player object does not get the nice interpolation other players get. I'm intrigued by using physical zones as a way around this but that sounds like a headache for nonlinear motion and could fall victim to whatever prediction would like to do instead, lest a gap in server updates occurs or similar.

To make vehicles float and interpolate smoothly, only a few flags need to be set to trick the client into doing so. The rest is collision testing, math, and ghosting the right data to the right people. With this we had some cool boat mechanics for a TDM although it was laggy as all hell as expected.

62
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.

63
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.

64
Modification Help / Re: [DLL] Tick Rate Modding Experiment
« on: May 12, 2019, 11:38:48 PM »
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.

65
Modification Help / [DLL] Tick Rate Modding Experiment (updated)
« on: May 11, 2019, 07:10:46 PM »
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!

66
Off Topic / Amends
« on: February 25, 2019, 12:18:57 PM »
Hey guys!

I'm working a 12 step program to recover from drug addiction and child abuse. It has done wonders for my mental and emotional health.

In it, I became aware of how my own selfish actions, through the behaviors I learned when I was abused and in active use, have affected others in the past. I have made many mistakes in the Blockland community, and I'm here to make amends for my wrongdoings. I'm here to focus on your issues, not mine.

I have enabled players to cheat through the use of hacks, and this has caused a lot of trouble on various types of servers, especially lava survival, TDM, and hide-and-seek gamemodes. I made BLHack and its derivatives to gain an unfair advantage on servers for myself. I then gave it to other people so I could feel better about myself and my work when they complimented me. Eventually, when the community voiced its disapproval, I felt self-rightous and egotistical, and continued to make more hacks to spite people.

I made a server crashing utility many years ago and had been silently taking down servers since 2014. This suddenly disrupts gameplay for those involved and ruins their fun. I did this because I wanted players to go into the servers I liked for my own benefit, or for a friend's benefit (these friends did not know this was happening), or simply to spite certain hosts or purposely ruin certain people's fun.

I made reverse engineering tools for Blockland in order to uncover code that Badspot did not want anyone seeing. I excused this as "helping the community" to feel better about my actions, and shared this code with others to feel better about myself. Revealing this code enabled people to abuse functions of the game which allowed impersonation, auth bypassing, and piracy. The angry responses from the community again made me feel self-rightous and egotistical.

I made many aggressive, harmful, and egotistical posts in my previous accounts. I did this to downplay others so I could feel better about myself, my accomplishments, or excuse bad behavior to make it sound good, feel in control of others, or sound like I knew everything about anything. This lead to frustrating and stressful conversations for others here.

This post serves as my attempt to make amends to those I don't know I've affected. Those who I do know I've wronged will get their own message from me as soon as I can. If you feel like a victim of my behaviors, here is the place to discuss it and how I can repair the damage for you. You can PM me, or make a post, and we can figure out something together.

I appreciate your cooperation in this. These behaviors are unacceptable, and moving on they will not be repeated.

Pages: 1 2 3 4 [5]