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.
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:
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.
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.
Major dummy alert yeah you nailed it with the values, I for some reason despite you saying it too, completely missed that I was adding numbers in the X argument. Totally my bad. Thank you
I’m sorry to hear that. This tutorial is intended for developers of all levels and is meant to be novice friendly into the matter as well, while exploring some needed terminology to understand the meaning behind what we’re doing. I’m confident that I got to the main point right from the get-go considering it doesn’t take very long to find the beginning of starting model tweens.
The first two sections are very brief before delving into the main content:
Understanding what a tween is
Understanding what it means to “tween a model”
Could you perhaps explain a little more why you think this tutorial is only “okayish”, what you believe the main point of the tutorial is and how far you had to search to get to said main point? I value feedback that’s able to better develop this tutorial. While it’s something I wrote two years ago, I’m always open to make changes if that means keeping it relevant and good for information and learning.
I would appreciate more critical feedback to know where the drop off points are and where I can improve, otherwise I’m not too sure what displeases you!
Hello, I was wondering how I would go about tweening a model’s position, rather than CFrame. Currently I’m successfully able to tween the models position on the client-side, but on the server side only the primary part ends up getting tweened and the primary part then gets separated from the model. The main reason that I want to tween position rather than CFrame is to allow me to turn the model towards it’s goal at the beginning of the tween and allow it to then move it’s position to the goal. So really I’m running an orientation and position tween at the same time. Let me know if you have a fix for this! Thanks! @colbert2677
CFrames are comprised of a positional and rotational component, so really it’s just a matter of getting the right values in. If you’re only using position and orientation because of this factor, it’d be worth looking up angled CFrames. Position is better coupled with physics-based systems, not tweens.
As for the problem you’re asking of, there’s a lack of context or repro steps so I can’t help you. If you encounter problems, it’s important you to provide extensive context towards the person you’re asking so they don’t have to guess anything about your current setup.
I just had to get a little bit creative with how I use CFrames, thanks for the response though it was helpful, I’ll avoid tweening position in the future.
This was a great tutorial and was very helpful into understanding how welds and tweens work. I have never been fond of object oriented programming due to its complexity towards my mind but, this tutorial made it simple and easy to understand.
Hey developers! Coming by with an important update.
First, let's start with the cool thing.
…I’ve finally gotten around to adding a table of contents, woohoo! It’s right at the top of the thread before the introduction so now you can jump to parts of the tutorial rather than having to scale the entire thing to find a point or to get right to the good parts. This was a long time overdue.
I still do recommend that newer developers read up until Section 5 to fully understand what we’re doing and how to do it. The rest of the thread is more relevant to developers familiar with SetPrimaryPartCFrame versions of tweening models since it tackles the problems around it. If you’re only just learning how to tween (models), don’t worry too much about the rest.
Next: time to clear up physics exploits.
(I think I already addressed this well in the original post that they’re still okay but you need specific implementations to combat exploiters and therefore I wouldn’t do a writeup on it. This is just double clarification in that regard.)
Previously, I marked a post I created explaining that you should avoid physics (constraints specifically) as an alternative to welding and tweening a root part. That post is available as post 14: if you need a quick reference to the post in question, look no further:
I am happy to tell you all that you do not actually need to avoid constraints and there are ways to combat these exploits.
I admit that initially I did not have sufficient knowledge on physics and their relation to exploiting so I made a “reasonable” explanation as to why I would avoid writing on constraints. After delving further into the matter and discussing it with another developer, physics are actually safe to use as an alternative for tweening if you want player force to influence the movement of a door. For example, a wild west type game where saloon doors can fling open when the player runs through them.
Roblox supports a lot of physics control. While indeed the issue in the video was a result of a network ownership exploit, the reason it was possible was because the game was badly architectured. If you don’t know what you’re doing it can be a problem but it’s not too hard to resolve either. As parts network owned by a client replicate physics, the server is able to act as a point of truth.
Generally, the method to combat this exploit is as such:
Check reasonably frequently, maybe in Stepped (assuming automatic network ownership transfers ownership after physics are simulated), between a set of doors actively being interacted with where they are in the Workspace. You may need to define a space that identifies where the door should be (e.g. a small, invisible, non-collidable part in the middle of the threshold).
How far are the doors away from this threshold? If they are unreasonably far or outgo any other defined boundaries, check who the current network owner is and kick them or flag them down as a potential bad actor and kick them if more doors are unreasonably displaced by the same network owner (~3 times, batch all checks - don’t flag them per door, rather per physics step).
Have the server reset the position of the doors and claim network ownership briefly. As the server is authoritative of all actions and can override the client, the doors will be appropriately placed back in the locations they should have been in and it’ll update for everyone else.
Knowing this, you can still use constraints to manage door physics and developers in fact still do in games with large traffic. That being said, the sad part, I will still not be revisiting the section describing how you can opt to use constraints for a door system. As this is meant to be an all-purpose tutorial for tweening models, physics would be out of the scope of this tutorial.
tl;dr Constraints are okay to use for doors, but the reason I will not be writing up a section on constraints has changed from “exploiter problems” to “out of the scope of this tutorial”.
I followed this exact way, except for one problem: welded parts don’t follow the primary part on the server.
On the client, it works perfectly fine, but on the server, it doesn’t. For any new players who join the game while the tween is moving, the welds get messed up and welded objects get misplaced.
I will need far more details if you’re looking for help resolving this. I can’t offer help based solely on a video and your word that you’re following the tutorial because this otherwise should not be an issue.
Well it wasn’t exactly your way but the same concept, the main mover part is anchored and everything else is unanchored, welded to the main mover part. I made a post for support but it hasn’t been solved yet.
For elevators I typically recommend using constraints. That is, you can still rig your elevator the same way I have but make use of PrismaticConstraints instead. Ideally this also means that your root part will be unanchored and network ownership needs to be given to the server.
If you’re following this tutorial directly, then your tweens would be along the Y-axis.
