I have an issue in my game where people build so called “rope storms”, these rope storms fill up the entire map with tons of stretched ropeconstraints which block your view and fling anyone in the area.
They acomplish this by forcing an extreme amount of force on a ropeconstraint or making themselves lag like crazy.
I was wondering if there is a way to prevent the ropeconstraints from exceeding the max allowed length.
To the best of my understanding, any force that will allow a RopeConstraint with a Restitution of 0 to exceed its length will need to be handled by code.
A Heartbeat event handler that monitors the length between the anchor and the part that moves the part “back into range” if it exceeds the rope length could do the trick, but you may need to add logic to neuter the force that caused the rope to exceed the length in the first place or else the results will still be pretty unstable.
If you want to choose approach that only neuters forces, running that from Stepped may yield better results than Heartbeat.
I have tried doing this and my solution is somehow causing the part to spin everytime it gets teleported back causing extreme rotation velocity which results in this issue still happening due to the rotation velocity instead this time.
At extreme forces like 10000, the issue is looking like its still the exact same.
What should the logic be for preventing this?
I currently have this:
Part.CFrame = (Part.CFrame - Part.CFrame.Position) + (workspace.RopeConstraint.Attachment1.WorldPosition + CFrame.new(workspace.RopeConstraint.Attachment1.WorldPosition,workspace.RopeConstraint.Attachment0.WorldPosition).LookVector * workspace.RopeConstraint.Length)
^ this is ran on a .stepped:connect() function
This is the code I’ve used to clamp the position, which seems to be working and respects the Position value of the Attachment. In my setup, Attachment0 is the anchor and Attachment1 is the part.
local part = workspace.Part
local rc = workspace.RopeConstraint
local rc0 = rc.Attachment0
local rc1 = rc.Attachment1
local V3_000 = Vector3.new(0,0,0)
game:GetService("RunService").Heartbeat:Connect(function()
if (rc0.WorldPosition - rc1.WorldPosition).Magnitude > rc.Length then
part.Position = rc0.WorldPosition + --Starts at anchor's point.
(CFrame.lookAt(V3_000,rc1.WorldPosition-rc0.WorldPosition).LookVector * rc.Length) + --Moves in the direction of the rope until length maxes.
(part.Position - (part.CFrame * rc1.Position)) --Offsets by the part's attachment's position.
end
end)
One thing I have found is that it may be worth only correcting the position if it exceeds, say, a few percentages of the length or more, since the RopeConstraint itself seems fairly good at correcting small deviances, and running the correctional logic less often will help with performance, although this code isn’t optimized as-is anyway.
As for the rotational velocity, I see what you’re saying. I rescind my initial suggestion of clamping the linear/rotational velocities in Stepped, because I’ve found that even if I set the values for both to a zero vector in both Stepped and Heartbeat, the rig still flips around, albeit at the correct distance. I’m not sure how to tame that part via code.
Perhaps focus should be changed then into looking at how players are creating these messes in the first place and preventing it at that step. Do you know how users create rope storms?
It can be caused by anything, even by having a potato machine this can be created.
The code is not working sadly with massive forces sadly
How large of a force are we talking? I’m getting it to stay “stable” (read: within the length of the rope but still spinning like crazy) with these specs:
The code is also holding the part in place at higher forces, but after some time the part somehow ends up falling below the FallingPartsDestroyHeight, presumably due to reactionary force applied to the part by the RopeConstraint.
I guess what I’m trying to get at with the whole “how are players doing this” aspect is that our environments are very contrived. We are using body movers with immense strength to simulate this effect. Is this how players do this in-game, or are there other mechanics in-play?
If the effect is impulse-based, then you might see better results clamping the velocities in Stepped and running this in Heartbeat than what I saw with my own testing, since the force wouldn’t be constant, although I’m not sure the reactionary force of the RopeConstraint can be overridden.
any possible force, i want to prevent it as much as possible.
What about making the 2 rope parts pull towards eachother by changing the velocity?
I think it might be possible to acomplish this by pulling both parts towards eachother with something like ApplyImpulseAtPosition.
But how would i create something like that?
I dont know what force i should set it to or what to depend on.
Is the situation you are suggesting something players could create in the game? I did hop in to try and figure out how to create one of these rope storms. While I was unable to create something as intense as your clip, I did find something that I think is exacerbating the issue: allowing the players to change ropes’ Restitution.
The whole point of setting the Restitution of a RopeConstraint to 0 is to tell the constraint that the rope’s defined length is the absolute limit, and any circumstance that results in that not being the case should be corrected by a force that will achieve that goal immediately, which works fairly well in lower-force environments. When the Restitution is set to anything else, you’re adding elasticity to the equation and effectively telling the constraint that the length is the goal but not the upper limit. How any of this is implemented is beyond me in terms of both the engine construction and the physics principles at play, but I digress. All-in-all, it means that the constraints are not actively enforcing length at nonzero Restitution values.
Clamping the length via code achieves the results of Restitution = 0, particularly at higher forces, but it won’t do anything to mitigate the forces of different Restitution values. I found with my builds that Restitution = 1 vehicles produced much less stable assemblies (ropes curling and bouncing around) versus Restitution = 0 assemblies, which were stable for the most part albeit overwhelmed by the centripetal force of the swinging ropes.
Disabling this feature will give you as the developer more control over the environment, but this does move the issue from less of a technical one into more of a design one: is the freedom to change a RopeConstraint’s Restitution worth the impact it has?
Even if you don’t choose to change this feature, you could still add coded clamps in, but they’ll need to be a little more forgiving, otherwise you’ve effectively disabled the feature anyway.
Also, looking at the construction in game, you’d likely need to implement the system in a way where every Stepped event, you limit each rope assembly’s angular and linear velocities, and every Heartbeat you clamp the positions, and both of these processes start with assemblies closest to the main assembly and move their way outwards. I think you may be able to get results by applying reactionary impulses at rope attachment points, and you would likely need to transform all your calculations to be relative to the main assembly’s velocities, but we’re probably well over my head at this point, to be honest.
