They’re the same as regular remote events, but I’ve heard that they send data in an unorganized way making them faster (Correct me if I’m wrong)
Yeah like that. It’s super hacky, and it might be worse. You’d really want to use a position buffer approach. This velocity approach might invert your problem and cause the hitbox to be ahead in time, because the humanoid root part’s position had to be replicated from the client as well.
The f5 studio test is not a good place to be testing this btw. A studio Team Test will better network delay, but in a live server is better.
Yeah it made it worse 
. I’ve tried it in test place as well, and same results
RemoteEvents are raknet, which is TCP over UDP. They will ensure packets arrive in order, and that any corrupt data due to packet loss is resent. UnreliableRemoteEvents are just raw UDP, but also the engine can decide to just not send them at all if other stuff is using too much of the network or CPU.
1 Like
Is there a way for me to do this on the client side, and not worry about the exploiters?
Maybe you can try this
Rip. position buffer is the best option then. Here’s some info on how that works in the Source engine.
Tl;dr, store a short record (like 4-5 seconds max) of each player’s HRP position, along with the timestamp (workspace:GetServerTimeNow()) of that position. When the hit command comes in, use that GetNetworkPing() method to go back in time and create the hitbox based on that position instead of the current one. Would do the same thing for the attacker, so you’re comparing both of them at that point in time on their screens. Isn’t great on it’s own, would help to have input prediction, but it’s better than nothing.
Here’s an amazing GDC talk from one of the engineers on Rocket League on how they solved this same problem https://youtu.be/ueEmiDM94IE?t=1438
1 Like
Nope it didn’t change anything.
Wdym “go back in time”. It’s late, and I’m sick, so I don’t really understand what you’re saying
That wiki link and/or the video will probably explain it better. A position buffer is a record of the past few seconds of character positions, so you can check the hitbox from where they were at back then, instead of right now. This would sync the server sided hitboxes for both the attacker and the victim.
Is this some how exploitable? I’m watching the video rn, and I’ll finish the Position Buffer section of it, just wondering.
It’s no less exploitable than anyone with an android being able to teleport their character to anywhere they’d like. It doesn’t open up any new vectors that don’t already exist in the engine.
Would I store the position on the client or server?
Could I just give the RemoteEvent the CFrame of the HumanoidRootPart? Then on the server do sanity checks, to make sure the CFrame isn’t wrong?
This position buffer is the reason Roblox’ replication system is so delayed. I highly recommend the approach where the client forwards their cframe data at 20hz to the server for much more accurate hitboxes. This surpasses the replication buffer delay caused by roblox. Then your server uses these given values instead of doing a character.HumanoidRootPart.CFrame (@fangamerproinpro )
You do NOT need BetterReplication for this, as this is just an extra thing to also minimize this delay across clients as well (not only accurate hitboxes for the server)
NetworkPing is incorrect advice… the position buffer exists to account for packet LOSS not any DELAY
20hz? As in every 20 frames right?
yes. BetterReplication has the set-up for that that the other guy linked to. But beware that it also includes stuff that you should not use in your game. You’ll have to use UptodatePositionHandler script
I’m not going to use BetterReplication as I don’t even really get it, and so I won’t be able to change/update the code if it starts messing with my code
How would the server know which Position to look at from the Character? Also where would I store the Positions? Lastly would I remove some of the positions after a while?