Hello friends. I am currently working on making a rope/tether system for a game I am working on, the rope right now is pretty much just a long chain of circle parts all bound together to the next one with rope constraints. I have the rope in it’s own collision group so it will not collide with itself. The idea is to be able to hook the player up to the immobile anchor point via the tether, and having the tether or rope being able to stretch out, or retract which would let the player either move further out, or pull them back in. I accomplish this currently by just adding new sections of the rope or deleting them, and attaching the player with another rope constraint to the last rope section. The rope MUST be able to collide with game objects so it can wrap around the game world, so I can’t just use 1 rope constraint since it doesn’t have collision
The issue that I am having is that honestly it is super wonky, at a short distance it works fine, but long range(which is a priority for what I want) it starts breaking up, and performance-wise it crashes my studio once the length gets to a certain point. I am open to redoing the entire system, it just has to be able to retract and elongate, or if you have any clue on how to fix what I currently have.
I have tried using different part shapes, and using rod constraints instead and they both have the same issues as above. The only thing that sort of works is making the parts much larger in size than I would like to( This just makes makes the break up problem happen at a later time). I have been looking around for solutions online and have come up dry.
The only thing I’d be able to think of, off the top of my head would be using Verlet Integration. Here’s a basic defenition for what I mean if it’s needed.
Verlet integration is a technique used for simulating flexible objects like ropes. It involves maintaining a list of points (verlets) that are connected by constraints. The constraints can be used to enforce the desired behavior of the rope. This approach might require more complex scripting, but it can provide realistic and stable results.
If there’s further information you can give I’d be able to give a more detailed answer but as of this moment it’d seem this would work best.
Firstly, the instability you’re seeing with long chains of constraints is a known limitation of the current Roblox physics engine. As you found, it doesn’t matter if you use ropes, hinges, ball sockets, rods, etc… if you make too many of them, things get shaky. You can’t fix this limittion, you have to work around it.
There certainly is a way to do this that uses Verlet Integration methods, and FABRIK IK would also be applicable, but this approach amounts to writing your own rope physics simulation from scratch, and integrating it with Roblox physics collisions or writing your own collision detection as well. No small task!
Now, I don’t know exactly how long or how serpentine you expect things to get, but my first inclination would be to see if you can subdivide the rope to use as few constraints as possible. Like if the rope is always tensioned taut, and isn’t wrapped around anything, it could be a single RopeConstraint. If it doesn’t automatically retract when the player moves towards the anchor, that would make simulating this a much harder problem.
Assuming the rope can always be considered to be pulled tight, then when the rope wraps around obstacles, you only really need a “live” rope constraint between the player and the last obstacle-rope contact point closest to the player. All the rope up to that point is effectively static. When either the player moves and unwinds the last contact point, or forced retraction of the tether pulls the player back past that point, you pop that point from the stack and retether the player to the previous one.
When I was thinking about this a little more, you don’t necessarily need to visually represent the tether as a taut rope, there are other ways to cheat your way around having to deal with having to realistically simulate slack rope at the end near the player.
For example, your tether could be depicted as a heavy chain. It would be natural for this to hang from the player and hit the ground a short distance behind them. All the chain leading up to this short length that is off the ground would be on the ground, motionless most of the time. Even if you need the chain to be able to double back (i.e. it’s NOT constantly being tensioned), you still don’t need all of the links to have live flexible constraints active between them: On any given frame, links on the ground that aren’t moving can be set to Anchored = true, disabling all constraints between them. Likewise, long straight sections being pulled in the direction they’re already aligned to could have rigid welds enabled between them on the fly, each frame, removing their constraint simulation burden. You only need active rod/rope/ballsockets where the chain is suspended or currently changing curvature.
Stability of the physics simulation only fails when you have too many live constraints in a chain, all with forces pulling on them. If you’re careful about only having as many constraints active as you actually need on any given frame, you could definitely cheat the system to make a very long chain! Generally, heavy parts on the ground will be less likely to vibrate apart then parts suspended in the air by RopeConstraints and always subject to gravity. The ground friction and lack of gravity pull will both help stabilize things.
Thank you so much for all of your help I have been moving along well now.
This last heavy chain solution is the one I am pursuing as of now. There is one big problem I am having though. I am able to detect when the part has low velocity in order to anchor it. Once I get the part anchored, I am checking for a velocity to determine when the part should be unanchored, but since it is anchored, it can’t ever have a velocity for me to check when to unanchor it. Do you know what I should do?
There are a couple of ways you could do this. Your idea of a velocity threshold for sleeping the parts is sound. But for an already anchored parts, it’s probably simplest for the last anchored part in the chain to be monitoring the next link; the first unanchored one, for movement, and unanchor itself in anticipation of moving. If it does move, this then next one back unanchors, and so on.
