Since it won’t let me post in engine reports I’ll post here.
There is no documentation that this is intended so I’ll assume it’s a bug.
When you create a weld constraint and weld parts not in workspace, it’ll determine which of the parts should be the root part and set the CFrame of non-root part to the root part. It should not change the CFrame at all.
The weld Script is in ServerScriptService. For those not wanting to download the place:
Script
print("Hello World!")
--Simple way of changing the RootPart of all models
local CollectionService = game:GetService("CollectionService")
for _,model in ipairs(CollectionService:GetTagged("TestModels")) do
for _,modelDes in ipairs(model:GetDescendants()) do
if modelDes.Name == "Cylinder" then
--modelDes.RootPriority = 127 --(un)comment line to see change
end
end
end
--does the welding
local function weldModel(model)
local p0 = model.PrimaryPart or model.Part
for _,p1 in ipairs(model:GetDescendants()) do
if not p1:IsA("BasePart") then continue end
local weldCon = Instance.new("WeldConstraint")
weldCon.Part0 = p0
weldCon.Part1 = p1
weldCon.Parent = p1
end
end
--welds and clones models into workspace
local redwork = game.Workspace.RedWork
weldModel(redwork)
local greenrep = game.ReplicatedStorage.GreenRep
weldModel(greenrep)
greenrep:Clone().Parent = game.Workspace
local yellowscript = script.YellowScript
weldModel(yellowscript)
yellowscript:Clone().Parent = game.Workspace
local purpserv = game.ServerStorage.PurpServ
weldModel(purpserv)
purpserv:Clone().Parent = game.Workspace
To recreate on your own:
Make model and put parts in it
Copy model, move it over a little, and put anywhere but Workspace.
Weld everything together using script or by hand while model is not in workspace.
I’m having a very similar issue with WeldConstraints. Changing the position of the part with the WeldConstraint, with Part0 being set to the parent of the constraint, results in the position being ‘snapped’ to the center of the part it is welded to. As such, the example script in the documentation is broken. This is a very inconvenient issue and I can only assume this is related to the issue you are experiencing.
One of my game mechanics broke in my game since the weldconstraints got updated, i tried to re-add the mechanic, but it was impossible to do so since there was no way to offset the weld constraint without it teleporting to the middle of the part.
Right now, i have done it via a hacky way by manually welding it and moving c0 and then enabling the weldconstraint, but if this issue did not exist, i would definitely have moved the position instead.
Easier steps to repro:
Launch a test server with 0 players and unanchored welded parts.
Hey all, thanks for the bug reports. With respect to the replies, the change has been reverted, and the server-client issue should be back to normal.
To OP: From my understanding of the repo, the intended behavior should be such that all the models look like the Start Model (redwork) you have shown above, correct? In some sort of dramatic irony, it seems the very change intended to fix OP’s issue has caused some other bugs to pop up. WeldConstraints were not properly handling non-World initializations, so we’ve been working on fixes. Looks like it’s causing some replication issues, though, so we’ll let everyone know as soon as they are addressed.
Hey all, especially to @DrWhoInTARDIS, we’ve pushed a recent change that should fix the non-Workspace initialization, as well as avoiding the client - server bugs reported above. Let me know if any outstanding issues occur, however, and we’ll investigate. Thanks everyone!
Some players in my game are reporting to have this issue again. Our doors work based on Weld Constraints and as such, they appear to break often now. This was not an issue when the change was reverted so I’d say it’s safe to assume it’s related to the recent change.
I haven’t exactly managed to get exact repro steps, but I’ve managed to reproduce it myself both in-game and in a demo place.
By using device emulation, StreamingEnabled on and a local server with more than 3 players, I was able to experience doors becoming stuck and doors appearing in completely random places that don’t really make sense with how they’re scripted / set.
Posting this quickly for visibility, this post will be updated as more info comes out from our investigation: I’ve tested locally, and I’m assuming the problem is the following image (the overlapping doors)?
The issue seems to be unrelated to the latest change. I’ve repro-ed on the reverted version, and the behavior in the picture persists. We’ll continue to investigate to see if there might be an actual bug or not. Thanks for the report!
That’s odd. I have no idea what is happening to have that happen; the doors work most of the time, but in some cases they bug out. If the behaviour still occurs on the reverted version then I’m at a loss; this has only started happening again after the new changes were announced / made public so I assumed it’d come from there. (If it’s not then this might still be a bug although unrelated - or, some very rare edge case in how the doors are handled)
Here are some of the things our players have been sending us:
Wanted to round the discussion out a little bit for sake of transparency, so here’s my findings so far:
After looking through your code, I’m curious as to why the parts need to be re-welded? I presume there’s a reason you don’t want to statically weld these parts together. At any rate, however, for the purposes of testing, it doesn’t look like the weldConstraints affect the issue in any way- completely removing the weld and leaving only the animated door frame still results in inconsistent animations. You may want to test for yourself just to confirm, that the movement issue is independent of the welding process, even when there’s no runtime streaming weirdness that can happen to the welds themselves.
Reverting a couple of likely changes this week hasn’t changed anything, either.
Doesn’t mean this isn’t a bug, though. You can try and isolate the problem further, and it might be worthwhile to make a separate post entirely for visibility. Definitely feels like a streaming / animation related problem, if at all. At any rate, if you do happen to find bug dependencies on the WeldConstraints themselves / constraint-related issues, feel free to continue the discussion in this thread. I’ve pinged teams that might know better than I about animations, but regardless it’ll probably be helpful to make a separate, animation/streaming specific report.
I can confirm that WeldConstraint bug has resurfaced in my game. I am not allowed to post my own bug reports, so I will just reply here. As far as I can tell, this issue occurrence is directly connected to this change being pushed and pulled back
I was unable to replicate, but it seems that visual artefacts are visible to specific clients only. When I joined the game everything looked fine to me.
I am welding (via WeldConstraints) non-collidable steps, to the anchored, invisible “ramp”. On the screenshot you can see some steps dropping, even though the ramp has not moved during that time.
It seems that Network ownership is at play, since steps start to drop as soon as player walks on them.
There are also other visual bugs, namely meshes being welded far away from root parts. I am using WeldConstraints for that too. It only happens sometimes and to only some of the clients.
i Can Also Confirm That This Bug Has Resurfaced And Its Really Slowing Down My Work Flow.
In My Screenshot I’m Welding The Steering Wheel And Camera To The Engine But It Has Recalculated This Weird Offset And I Can’t Do Nothing To Prevent This Apart From Making My Own Welding Plugin.
If it’s happening consistently please try to isolate the important parts post a script/repo as it’ll be really helpful for them to fix the issue.
I did some testing and the fix they implemented still seems to work for me. I even tried a local script version of my repo and all is well.
Hey all, especially @DrWhoInTARDIS , wanted to give a heads up that we’ve encountered some TeamCreate issues with the latest patch, and will have to revert the fix for the original bug posted here regarding out-of-world weldConstraints.
There’s already a fix to the TeamCreate problem in place, and normally, we’d be able to release that fix - but due to holiday scheduling, this fix probably won’t get in until after the holidays. Sorry about that, this is on us, especially to @DrWhoInTARDIS
Until the fix to both TeamCreate and the non-world initialization is ready to be flipped, I’d suggest a workaround to the above, by trying to avoid having disabled weldConstraints saved or created outside of world / workspace. Only store weldConstraints outside of workspace after having positioned the parts to your liking and enabled.
Thanks again everyone, we’re refactoring quite a bit of legacy code to make the engine more correct and reliable. I appreciate your patience with us as we work through that. We’ll update once all the fixes have been addressed.
UPDATE: The issue should now be resolved. Thanks for waiting, everyone! Let us know if any future issues occur.
