As you can see here, the cough ‘Instruction Payloads’ do get stuck to the android, but if the player moves away fast enough, they tend to just float midair. How to combat them?
Suspected chunk of code:
local new = Needle:Clone()
local tos = new.Touchie.CFrame:toObjectSpace(hit.CFrame)
new.Inside.MoveWeld:Destroy()
new.Parent = hit
local we = Instance.new("Weld",new.Inside)
we.Part0 = new.Inside
we.Part1 = hit
we.C1 = tos:inverse()
Additionally, how screwed am I if I make a game such as Ro-Chanics or Ro-Bio?
just sounds like the average client-server lag.
the server welds things where it thinks they are at the moment, in the server’s “server”. this is kind of how it works, time-wise, and why server-client communication can be a bit of a nuisance:
you click, and your tool sends a request to the server to create an “Instruction Payload” at the android.
a little bit of time passes. client-server communication has a delay, so the request wasn’t received yet. its still in travel.
the player/android starts moving, which probably reaches the server at a different time, most likely before the “Payload” is received. if it’s an android moving in the server, the server gets that movement instantly, no delay, because the server is moving it.
the server finally receives the request to create an “Instruction Payload”.
the server looks at the position of your player and the android player. little does the client know, but the position of the android and the player is actually different to what the server sees. the client probably has not received the movement of the android yet, and the server has not received the actual location of the player yet (vice versa). the server notes down only the location its aware of in the moment.
the server finishes the code like its supposed to, which creates … a bit of an odd result. the server only did what it was asked to, but since the humanoids were not 100% synced up in position, there’s going to be some offset to what the client originally intended.
heres a workaround i could think of, to make sure the server knows exactly where the needle was placed when the client completed it:
you click, and the tool takes note of the position/rotation of the “Payload” compared to the android’s location on the client side. the tool takes this information and sends it to the server.
time passes. players/humanoids move.
the server receives the request. the request says that the client, just a moment before, sent the “Payload” at this position and rotation compared to the android’s root (or any other object listed).
just in case there’s nothing finicky going on (like an intense lag hiccup), the server makes sure the player is at least somewhat close to the android. then we know for sure the “Payload” was shot in at some point, and the player didn’t lag their way over while everyone was still to inject it from far away (because that would be cheating! insert the “Payload” the proper way, player!).
the server finishes the code, and puts a clone of the needle relative to the androids root, with the given position/rotation. it doesn’t need to know the current locations of the player/android—only that it definitely happened at some point because they were close to each other.
hope it helps!
and ermmm idk about that last question tho ermmmm sorry bro
