they recently did an update that made tools inherit from the model class as well. so the answer to your question is yes it also works for tools 
I remember reading about that change but I didn’t know that tools would also get all of the same functions as models.
Does this support all “welding” types? (not sure what the right word for it is but stuff like motor6d, manuelwield, wield, etc…)
Yes, Weld, WeldConstraint, and RigidConstraint should all work.
1 Like
The new Scale API is so useful. I’ve managed to make a cool item spawning system, where it animates it growing and dropping. This took use of using Tween Service, but due to it not supporting tween service for scaling, had to make my own work-around. Would be very useful for my new upcoming game.
However, this brings up the question; What is the E.T.A release date for this API to the public for live experience use?
1 Like
Could easily be a couple of months, because first we have to fix all the bugs and then we’re also going to include an opt-out period given the workflow changes with the scale tool.
3 Likes
I’ve experienced some issues with this in our game. We use vehicle models inside ViewportFrames and for whatever reason this has caused parts of the vehicle to have incorrect positioning when the model is scaled to anything besides the original import scale (1).
It works perfectly fine in studio but whenever in a live server this issue occurs.
As soon as I set the models scale property back to 1 everything is back to normal.
Also, it only seems to occur when using the :Clone() method on the specific model that is scaled up. Otherwise, it works fine if you’re just putting the model in the ViewportFrame manually even if it’s scaled differently.
Only way I found around this is to select only the parts and scale it that way.
There might be an easier way but this is what I found to work for a quick patch for our game.
Edit: ScaleTo(1) would’ve worked but obviously its not enabled in live servers yet.
Maybe try using a WorldModel in the ViewportFrame? Joints dont work in normal ViewportFrames
Could you try to make a minimal repro which you can share so I can debug?
I don’t have any guess as to what’s going wrong there, since the only ingame impact of this change so far should be animation scaling (the rest of the changes are only under the beta feature which isn’t live), and I don’t imagine you’re playing AnimationController based animations on your vehicles.
Okay, that “Nope” example was pretty funny. I did NOT expect that!
Jokes aside, this is SUCH an amazing feature. The ability to not just scale models but also particles, and possibly player models, and so much more is just so, SO exciting. This can bring SO MANY possibilities onto the table that previously weren’t possible.
Props to the team who helped make this! This is such an amazing step forward.
We finally don’t have to rely on a plentiful of calculations and other stuff to just scale down a character rig. FINALLY.
I think this has already been hinted at in this thread, but hitting upper/lower limits with part sizes can be a pain.
e.g. if I set the Scale property (or use ScaleTo()) to something really small or big (something that exceeds a child’s part size min/max), then set Scale back to 1, it’s all wonky. My general thought is that this should restore to the original size of the model.
I’m not sure what the solution would be. Maybe limiting the scale to not cause these properties to exceed limits? At least an option to have that constraint?
A use-case might be tweening in a model from a 0-scale up to 1-scale.
2 Likes
We’re actually considering changing this so that at least within a DataModel session if you x = GetScale(), ScaleTo(y), ScaleTo(x) you always get back where you started.
The tradeoff is that it’s a little bit less efficient that way, because the API has to ask the engine what the scaled property values are an additional time so that in the future it can tell the difference between a value that was limited by value limits (which should be ignored) and a value that was deliberately changed by the user (which should be taken into account), vs currently it just treats those two the same way which is why you see the “wonky” result.
Edit: Implemented this change, will update when it releases.
1 Like
That would be cool! I guess in the time being it wouldn’t be too hard for us to write our own constraints for this. Thanks for working on this feature btw, super cool!
This is nice! I’ve recently had some issues while scaling characters, let’s see if this fixes it.
Hey, sure no problem.
Here’s a place file with a minimal repro:
ModelScaleBugRepro.rbxl (244.6 KB)
Seems after further investigation that Model.Scale has conflict with PivotTo()
when parenting to a ViewportFrame.
1 Like
Thanks for the great repro file, here’s what I found:
The issue will happen locally too but only when the beta is turned off, when the beta is on everything is fine. This is because half the PivotTo code is acting as though scale is already enabled on production but the other half isn’t so things explode.
Prepared a fix for this, to go out in the March 22nd release, though since you’re running this code on the client it’ll be about a month before all mobile devices are updated and you can safely proceed with non-1 scale.
1 Like
This is so COOL!!! I don’t know when exactly I’ll use the API, but I love that the option is there!!
Gonna piggyback on this for a suggestion for ways to improve this feature: Optional extra properties for whether or not to also scale certain things such as ProximityPrompts or GUIs attached to the model’s parts. Would cover use cases like this pretty well, I think.
I can imagine a few uses for this myself already, having to make separate giant versions of NPCs in my games tends to be a pain, but this may turn it into a single line of code in a script, which is quite nice.
This API is really the most practical API I have ever seen, so please go online as soon as possible. It’s still beta now. I can’t wait. Please go online as soon as possible
Any ETA for the public release? Been using the functions on my new project so would be nice to know.