It shouldn’t be teleporting around even if you have a large amount of parts involved. I’ll try and have a look at this behaviour whenever I’m able to do so, but providing me with a repro file would help me narrow down the issue even better because I can work with problem code and see where things aren’t adding up.
Thanks for letting me know. I really hope it isn’t my code that’s broken.
(small update, i think it actually said “PrimaryPart is not part of MainPart” since i chose the mainpart, i’ve reopened studio. i’ve probably done something wrong)
ct1.rbxl (48.0 KB)
Sorry for the late reply.
I have not been able to locate any issues within this repro, everything’s done right here. I find that it would be odd if the PrimaryPart can’t be detected. Is this relatively the same code you’re working with in your actual place? You may be referencing the wrong parent.
I’m now noticing that the error you mentioned makes me think that you were using script.Parent, which would mean that the group the code is looking at is the MainPart. PrimaryPart would neither be a property or child of MainPart.
You may want to review your code and try again to make sure that it references the right things.
There is one big weakness with this method.
You wouldn’t be able to safely have explosions in your game without the risk of destroying your models.
It’s only a weakness if you make it one, meaning that you rely on the default behaviour of explosions (which, on activation, will break joints and apply a force to parts in range).
First and foremost, please do keep in mind that this thread is only meant to be an introduction to tweening models, not an all-purpose guide. It’s chief purpose is to lay the foundations down behind attempting to tween a model and address an old method which is bad.
From what I do know, there are a dwindling amount of games that arbitrarily allow explosion objects to use their natural effect when they are instanced. This is in favour of creating custom explosions and likewise explosion handlers. such that the explosion object is either used as a visual or not used at all.
If you need the natural explosion behaviour (which is most likely a dubious claim) and you use this method, then it will become an issue which then you need to look into changing either your explosion or method of model movement. Changing the explosion can be done by making raycast explosions (which are honestly probably better to use) or making use of an explosion’s hit event. Door movement would involve revisiting the Using SetPrimaryPartCFrame header in the tutorial and manually calculating an offset for all your parts to a certain root part to avoid the issue of models tearing apart.
Revisiting this tutorial after a long time for an important notice with regards to the bottom: specifically, where I note that you can also use other constraints for moving models and that a potential tutorial may be written up on that later (assuming I had the time to do so).
In short: it’s not happening.
I currently follow this tutorial myself for two of my group’s games and respectively each of them have had a glaring problem with regards to exploits based on network ownership. As a little recap, network ownership refers to the entity (the server or a client) responsible for handling the physics simulation of an unanchored assembly. My game uses constraints to move models, and it does not end well.
Please observe the following example, reported by one of said developers:
What’s going on here is: since we are using constraints, that means that we have to fully unanchor the doors and network ownership will get passed around to the nearest client meaning they’re in charge of physics simulation. With that in mind, an exploiter holding ownership can do something like this.
The obvious solution here would be to give ownership to the server and that would completely stop this exploit but at a very resource intensive cost, since clients can better simulate physics than the server can (or so that’s what I know). Other options include flagging suspicious movements on the server’s end, logging the network owner via GetNetworkOwner, kicking them and then rubberbanding the door or just making the doors client-side only. Anything where an exploiter can’t influence how doors look to others without the server’s intervention at some step of the way.
As such, due to the above concerns, I feel it’s not appropriate to write a constraints tutorial that doesn’t address exploitation and I don’t have the time to do that. Apologies. At least you’ll have this information on hand though and possibly be prepared to take measures, regardless of what you choose.
I’ll be removing the “Constraints in General” section as of this post and include a reworded version that includes an exploit advisory warning with a link to this post at a later point in time.
Cheers. Stay safe all, happy developing and good luck fighting against silly exploiters. 
Sorry so to clarify, as long as you have one anchored part in the model and everything else that is welded to it is unanchored, it won’t have physics ran on it right? The exploit vulnerability only happens when you use other constraints?
That is correct. To be able to use constraints with this tween method, all of your parts need to be anchored (including the root which you tween). Any unanchored part opens the door for physics exploits, which is what is being seen in the video.
Now on the other hand, if you follow the tutorial as shown in the original post, you should be fine. When at least one part is anchored and becomes the root of your model, network ownership doesn’t apply and thus physics exploits are mostly moot (not sure if they can detach welds and it’ll work, though from my experience this doesn’t seem to be the case). Any part welded to an anchored one will also behave as an anchored part.
So yes, you are correct. If you have at least one anchored part, physics don’t apply to the model and all parts are treated as if they’re anchored. Network ownership also isn’t applicable to anchored parts so exploiters can still fling around models but it won’t replicate. This exploit is only possible if you decide to use this tween method with constraints and unanchor everything in the model.
*Note though: WeldConstraints are the only acceptable constraints to continue to use with this method, as they are just welds that hold models together in relative space. Other constraints like PrismaticConstraint (the one used for the flinging doors in the video) are no good otherwise.
Can you make a model for the door?
@HDAdminUnofficial Hey there, sorry for the reply. I actually do not have this model on hand, but I can upload a model that is tween-compatible for reference later if that helps.
@Planet_Dad Typically in, because the proxy part is becoming your model’s root not just for tweening but it can be the root for pretty much anything else that needs to know what the main part of a model is.
It’s generally much easier to work with that way as well. If you have some kind of wild system where a root outside works best for your use case, go for it. The welds are the key to making this work; hierarchy is irrelevant, but good to be wary of for the sake of organisation.
This doesnt work with very large models, it lags out studio. Any solutions?
I need far more details than “this doesn’t work” to be able to help you with any questions you may have about using this method. If I don’t have a detailed scenario, then I can’t really help you much here or give pointers as to how you can improve your circumstances.
That being said, there is a section in the thread regarding SetPrimaryPartCFrame and an alternative that you can use instead. If you prefer, you can update the offsets of all the parts or a group of them manually relative to a root and that can serve as an alternative. I don’t work with huge or complex models when I’m tweening them; if I do, then I always have some other kind of solution handy, up to using a complex MeshPart instead of several parts.
Nevermind I literally just got it to work lol, sorry about that. I forgot to unachor certain parts.
Is it possible to control which direction the model turns when you tween its orientation? Like, in the first tween you created (the swinging door), it first rotates left 180 then right 180 to go back to its original position, but then it rotates right 180 then left 180 to go back to its original position. So, I’m wondering if it’s possible to control that or at least make it consistent?
Yes. The values I use in the thread’s code as well as how the tweens appear are purely for the sake of demonstration; you can input any values or math you’d like to get the desired effect you’re looking for. In the video, I was modifying the degree value via the command bar but I do not have the command bar recorded so it doesn’t show that I’m changing anything to make the door move differently.
EDIT: Every gif I upload is coming through as jpeg so I drew arrows.
So i’m having a little problem here, and I can’t make any sense out of it? Basically copy and pasted code, I checked that the Y axis is pointing straight up, which it is. I have two tweens, an open and a close which work after the first time using it. On the first move, it goes way farther and in a totally different direction than it is supposed to?
Here is the code for the open with a gif of what happens:
local DoorOpen = TweenService:Create(Model.PrimaryPart, PanelSlideInfo, {
CFrame = Model.PrimaryPart.CFrame * CFrame.new(Model.PrimaryPart.Size.Y + 0, 1, 0)
})
That is what im calling the “Big Move” where it throws itself diagonally backwards? I am assuming its some sort of physics issue but there shouldn’t be that as I have everything unanchored but welded to the main part.
Here is it closes, and me trying to open it again which works as intended. I can’t figure out why it screws the first open.
local DoorClose = TweenService:Create(Model.PrimaryPart, PanelSlideInfo, {
CFrame = Model.PrimaryPart.CFrame * CFrame.new(Model.PrimaryPart.Size.Y + 0, -1, 0)
})
Any idea why its acting so weird? I have nothing else moving the door at all, there shouldn’t be any reason for this to happen that I can see so i’m a bit stumped.
The media in your post is actually a JPG, not a GIF. I won’t be able to see what’s happening in your case, so if you could update that media that’d be helpful and great.
Media aside, I don’t know if this will instantly solve your problem or not but there’s a problem I notice with the CFrame goals you’re setting and it’s that you’re using the Y value in the X argument of the CFrame constructor - this this intentional or no?
If you check the code I posted for the slide tweens in the OP, I want to move the panel across the X axis. that’s why the CFrame goals only have non-zero values in the X slots. Remember that CFrames are constructed with X, Y and Z. I wanted to move my panel along the X axis so anything I’ve inputted always only uses the X values of CFrames.
Confusion about which axis you should be using and what numbers you should put there is probably also what’s causing the problems you’re having. You’re using the PrimaryPart’s Y-size as a reference for an offset in the X-axis and for some reason you’re also adding zero to it. The Y-axis has hard set values of 1 and -1 for the open and close tweens respectively.
Looks like you’ve got everything in order except the values you’re using in your CFrame goals. Try playing around with those numbers using the sample in the tutorial as a reference point.
I should have noted I am trying to get it to move up and down rather than left and right.
Well my issue is that it only breaks for the first move. After the initial slide, which is diagonal and backwards(not intended), it begins working properly. Slides up and down on open and close like it should. It’s just completely out of place now as the first time moving it and only the first, it goes completely the wrong direction and distance. So it’s lead me to believe that it may be something else affecting the door?
I will need a proper GIF to fully understand and visualise what you’re seeing. A repro file might also help if you’re able to create one that demonstrates the same problem that your door is having. I can’t exactly give any help on abstract problems without something direct to work off of.
As I did mention, it could simply be a misunderstanding on how CFrames and axis operates and inputting incorrect values where they shouldn’t be. This is a symptom representative of incorrect value placement wherein only the first movement of the door causes displacement.