So I’ve created a script where a rope constraint is created and attached between 2 players HumanoidRootPart’s that have 1 attachment in them, however, the player that has Attachment 1 Seems to lag or buffer behind while the other player experiences no lag. Player with attachment 1 also doesn’t seem to play any walk animations and pressing any movement key takes 500+ miliseconds before it actually moves and makes it very stuttery. I do not know if this has got to do with NetWorkOwnership or not but I can’t find any easy fix to this.
It does relate to network ownership. I think a possible way to fix this is to remove ropes, then instead prevent the player from moving further than a certain radius by adding a counteracting force to the player’s walking that grows linearly
this is a basic way to do it
local RS = game:GetService(“RunService”)
local Player = game.Players.LocalPlayer
local p2 = workspace.Dummy
task.wait(5)
RS.Stepped:Connect(function(deltaTime)
if Player.Character then
local HRP = Player.Character.HumanoidRootPart
local HN = Player.Character.Humanoid
local BDis = (HRP.Position - p2.HumanoidRootPart.Position).Magnitude
if BDis > 10 then
HRP.AssemblyLinearVelocity += (-HN.MoveDirection*HN.WalkSpeed - (BDis-10)) * deltaTime
end
end
end)
It has to be RopeConstraints though, In the picture you can see i have attached 2 players to a rope (spring constraint actually) and “Player 1” Stutters while walking while “Player 2” can walk and jump without problems. I might be missunderstanding your potential solution.
You cannot use any constraint without stuttering. Assemblies (any physically simulated bodies) are made from BaseParts attached by constraints. Stuttering is because one player gets power to simulate the other player’s movement, and it causes a lot of bugs
But there is a game called Altitorture that does this without the replication issues or lag on either player side, and I’m 99% sure they use springconstraints so there must be a way
what @theseformasentence is saying is 100% correct. We can’t use a rope or spring constraint due to it setting network ownership.
What you could do though, is have a clientsided, invisible, part for each player, that is cframed to each player’s HRP every frame, connect the rope constraint to that instead of the player themselves. Since the parts and the players are seperate, there won’t be any network ownership issues.
A solution similar to whats shown above though will not actually keep the players together. You need to do this in conjunction with the solution kjanahan has.
However there’s one main thing he didn’t explain with his answer above.
You need to do this on each client, they should be applying their force relative to the other player’s character position. If we do this on the server then we will get inconsistent results and the players will take a while to have the force applied due to lag.
hey sorry about this late question but could you elaborate how you would solve the issue with network ownership? which scripts are local and which are server sided?
Pretty much everything would be localscripted tho, the only server logic you would need is to actually notify the clients in some way who they are hooked to.
If a constraint connects two parts with different owners then their owners change.
How do we get around this?
One way is to make the parts being conjoined by constraint not be owned by anyone, or more specifically… create new parts that aren’t affected by network ownership.
The way I would opt to do this is by instancing an invisible, anchored, “RopePart” into each character on the client. (aka using a localscript) Then every frame, CFrame the RopePart onto their respective character. Instead of connecting the HRPs together, connect the invisible, clientside RopeParts together via a script!
However, since we are CFraming the rope parts every frame and not actually connecting the RopeParts with the client’s character the rope constraint will only be visual
Then you still need to figure out how to constrict the players with an actual rope. You could do this with a script simulating a rope
or you could probably get away with connecting an actual rope from the static RopePart of your client’s partner to your HRP.
I still have no idea if it would actually work well, since its completely untested but its an idea
