Hey! That’s a really good idea! I assume that there will be an event or something. Perhaps this information will be passed to any connected events?
I don’t quite agree with this. For me the JointInstance | Roblox Creator Documentation and JointInstance | Roblox Creator Documentation properties of the weld are really useful, as I can move entire welded assemblies just be editing the joint offset on a single weld.
I understand that the WeldConstraint | Roblox Creator Documentation was meant to replace the Weld | Roblox Creator Documentation, and I do use it. However, whenever there’s an instance when I need to move a connected instance and all the parts connected to it, it’s easier to use the C1 property of a weld. This isn’t to say that the weld constraint is useless or inferior by comparison. Quite the opposite in fact! However, the C1 provides information about the joint offset automatically so I don’t have to calculate it manually.
While this is quite the long tirade, my point is that I wish that the WeldConstraint had these properties or some implementation of them. It’s already using some offset internally, so why don’t we have access to it? It would be a lot easier if we did.
I hate WeldConstraint with a passion. It has some weird inscrutible internal state that gets corrupted randomly and misaligns parts for no reason. There are horror stories of entire builds being lost because I connected things with WeldConstraint in Studio. I tried to move the build and everything got misaligned by the WeldConstraints, even though the game wasn’t running. Then, because they kept their weird internal state, even after I pressed undo, they continued to corrupt the build every single time I tried to do ANYTHING to it.
I don’t remember if I was ever able to recover it.
Wow, this has never happened to be, but I can confirm that I would be very irked to have something like this happen.
How long ago was this? Has anything like this happened recently? If so, then I hope that the RigidConstraint won’t use a similar internal state. Otherwise this very same thing could happen as well.
Instant fan! Threw a non-skinned accessory on my skinned mesh and added a RigidConstraint, and boom!
6 Likes
This is not strictly the case. WeldConstraint is meant to replace Weld for manually created joints, however Welds are not deprecated. They’re still fully supported, and it does make sense to use them in the case where you want to script the offset between objects.
Unfortunately WeldConstraint did have a rocky past, and didn’t have the level of polish it should have when initially released. At this point it should be fully stable however, if you have experienced issues with WeldConstraint within the last year we’d be interested to hear more.
3 Likes
i dont even know what weldcontraint mean and im a scripter i feel so ashamed
TL;DR: WeldConstraint is like a weld but it joins things together at the offset they had right before you created it rather than you having to manually enter a C0 / C1.
1 Like
thank you very much for the explanation!
Just to be sure RigidConstraint is like a Weld with C0, C1, equal to the respective Attachments ObjectSpace in relation to their BasePart Parent right?
I feel it would be less efficient with tons of them due to the two attachments, or even in the acute sense against a WeldConstraint for a hat or adornment, just one instance.
WeldConstraint’s low barrier to usage confuses me as to why this was made like is it something else?
I think an better way to conceptualize it is that RigidConstraint is the simplest constraint: It’s a constraint with zero degrees of freedom, exactly snapping the two Attachments together.
It’s not intended that you will be using a “ton of” RigidConstraints. The idea behind RigidConstraints is rather to snap together high-level objects at pre-defined locations, for instance attaching accessories to your character or attaching together large prefab sections of your level. Those aren’t use cases where you’ll be needing that many of them.
1 Like
Apologies if this has already been raised but is there any ideas or plans to add this force based snapping feature to WeldConstraints?
The systems in my game revolve around building & this feature would be very useful to have for more dynamic creations however to use Attachments doesn’t play as well with my systems as using WeldConstraints where I can just set the two parts.
I understand this would be expensive to compute so having it as a toggle property might be possible?
Sorry again if this has been raised already, just looking for clarification that this is not planned to ever come to WeldConstraints.
Thank you!
1 Like
Waiting for the day when Roblox gets reduced-coordinate multibodies and this actually becomes true…
(assemblies are a form of this for welds)
Destructible brick walls.
3 Likes
usefull for vr grabbing, still got this error though
RunService:fireRenderStepEarlyFunctions unexpected error while invoking callback: builtin_MoveDragger.rbxm.MoveDragger.Packages.DraggerFramework.Utility.PartMover:374: invalid argument #2 (Vector3 expected, got nil)
3 Likes
I can confirm things like that do happen, mostly when messing around with various plugins, especially ones that do not handle undo/redo in Studio properly
1 Like
Is there an ETA for the force limits for this joint yet?
2 Likes
7 months later and nothing. There’s just too many updates that get abandoned or left in the dark.
1 Like
The amount of great features in recent years that have been announced, half completed and left unfinished is disappointing and seems like a result of rushed crowded quarterly timelines.
Without destruction this joint is only useful as a WeldConstraint that allows an offset, in my opinion that doesn’t constitute a new constraint and should be added to the WeldConstraint. It seemed the initial primary purpose of this joint was initially intended for destruction, I remember it being showcased at a previous RDC.
1 Like
It seemed the initial primary purpose of this joint was initially intended for destruction, I remember it being showcased at a previous RDC.
It’s an interesting story – A rigid weld for Attachments was planned long before destruction, and came directly from community feedback. We even considered adding Attachment welding to WeldConstraint rather than a new class, but decided against that for ease of use - WeldConstraint would need a UseAttachments mode that would behave completely differently from how WeldConstraint normally behaves.
The final forcing function that made us add RigidConstraint was that it was impossible to rigidly attach parts to Bones. We also wanted to release joint destruction, but this wasn’t fully decided on.
Is there an ETA for the force limits for this joint yet?
RigidConstraint and breakable constraints are different features with different timelines and, in this case, different teams. We’re always going to choose shipping a complete, well-designed feature over delivering something that’s partially finished.
In this case, the team working on breakable constraints took a longer view and decided that we need a more general form of breaking that’s not specific to just RigidConstraint. I strongly think that’s the right call – breaking is much more useful without being tied to a single joint type.
We’re still working on breaking, but we still can’t promise a timeline yet due to other important projects. We really want it too, trust me.
seems like a result of rushed crowded quarterly timelines
It’s disappointing that this is the reason that you came up with. Posting constructive feature requests is the best way to help us prioritize.
6 Likes
As you are adding this rigid constraint, And It may feature the joint destruction, Will you compute the weight on top? Like for example a two part connected with a rigid constraint and on the end side hinged to anchored part, Will some weight on the joint area be able to break it?
2 Likes