Range limiter constraint, prevents parts from going past a certain range

[rickje139]

The range limiter, a new constraint type which sets a max distance allowed between attachment1 and attachment2.

This constraint could be useful for a lot of situations, here are some examples of what it could be used for:

Preventing players from leaving a specific area while still being able to walk around without any side effect.

Preventing objects which are affected by physics from leaving the area it is meant to stay in, like if you have an orbit system, and someone is somehow causing the planets to go faster than expected so that it leaves the orbit area, the constraint can prevent the planet from leaving the area and force it back in instantly.

This can also solve the flinging issues with rope constraints:

Without this constraint, you would need to use a lot more items per ropeconstraint.

If this constraint were to get added, it would allow me to prevent physics mechanism and parts from flinging themselves into the void by pure luck.

[tnavarts]

A “constraint type which sets a max distance allowed between attachment1 and attachment2” is by definition exactly a RopeConstraint with Restitution = 0, there would be no difference between the two. RopeConstraints don’t have mass or inertia of any sort, hard-limiting the distance between the Attachments is exactly what they already do when Restitution = 0.

Is what you’re really asking for here “fix RopeConstraint” or am I missing something?

Also, whoa… is that scan UI thing in the second GIF made using RopeConstraints?? There is a much better way to do that, using LineHandleAdornments / CylinderHandleAdornments.

[rickje139]

Its something i could use to prevent any physics parts from flinging into space.

like as an example, somehow a player manages to glitch through a basepart or causes it to fling by pure luck, i could slap the constraint on there and next time it flings by pure luck, the constraint forces it back no matter what, causing it to stay inside of the area it has to be in.

Ropeconstraints are very broken and useless in a lot of situations.

Automatic Physics replication / constraints properties replication button

As of now constraint property replication is very hard to do and creates a lot of lag. A “Enable physics constraints replication” button would help me out so much as i wouldn’t have to make my own custom physics replication then, which would use 3 times more replication updates and slow down the game by a lot. To make RopeConstraints not fling other players, i have to send a remote event for every change to the server and make the server update the property value’s and then i hav…

Rope owned by player does not replicate length changes to the server

Whenever you change the length of the rope that is networkowned by the player, the change does not replicate to the server and causes a lot of issues. These issues are game breaking, as it causes other players who stand ontop of the part attached to the rope to get flung with an extreme speed and also causes buggy behaviour like this : RopeBug Demo.rbxl (21.4 KB) Steps to replicate this issue : Launch a test server with 2 players. Get player2 to stand ontop of the …

Parachute attached via ropeconstraint doesn't slow down plane?

I have been trying to make a parachute as an ingame item but somehow it doesnt slow down the plane it just shakes the rope instead. I tried adding the same bodyvelocity to one of the parts which is welded to the plane and that prevented the plane from moving completely. But somehow if the same bodyvelocity is inside a part which is connected to the plane via a Ropeconstraint it wont slow down the plane. With bodyvelocity in plane : With bodyvelocity in parachute : I…

[rickje139]

The second gif is called a “ropestorm” its something people create in my game to mess up the gameplay experience for other players.

They place a bunch of ropes and place trail blocks ontop of them, once its all in place they rotate the ropes in a circle and boom!, there is a ropestorm which flings everything in every single direction because the ropeconstraints exceed their length and anyone which is 400/600 studs near the ropestorm will get flung instantly.