It would inevitably become a plugin tool eventually, and that’s fine. I just think when this is released, it will be disruptive in normal use. I think including a toggle for a perfectly reasonable alternative implementation of the resize function (probably) wouldn’t be too heavy a maintenance cost + would be tremendously more convenient being directly integrated with the draggers than a separate plugin would be.
E.g. I could reimplement my own dragger just to have plane handles, but it will be a pain to use because I would have to switch between the dragger and my plugin often, and my plugin button would not live in the same place as the dragger buttons. In the same way, nobody wants a separate scaling plugin just so they can resize a model without messing up e.g. fine tuned visual effects, light ranges, or textures that should stay consistent throughout the world, when this was previously how the built in dragger worked. Both methods of scaling have strong use cases and arguments for being the default way the scale tool should work. Scaling this way is already inherently opinionated.
In a nutshell, it would be fine as a plugin, but it would not be convenient to use with the way Studio currently shows plugins to the user, even with the quick access toolbar (extremely small button, or else a hotkey to memorize).
Deciding whether or not to have some sort of modality in the API was actually the most difficult part of building it. Having the modality is actually a very expensive choice.
The dragger UX gets quite tricky, mostly around knowing what mode you’re in. It’s not as simple as having a mode because a lot of the potential changes that the “scale everything” mode can be making aren’t visual changes, or aren’t that obvious even if they are (E.g.: Constraint limits). That means it’s really easy to scale something in the wrong mode and not immediately notice it, and especially if you scaled it further in the other mode later, unwinding from the situation can be basically impossible without manually fixing up each Instance.
Packages present friction with having two modes as well. Only having a single mode makes the UX and mechanics of how scale interacts with packages considerably simpler. Otherwise packages effectively have to have some sort of additional modality of what scaling behavior they’re using. That or have packages just count as modified with one of the modes, which is an unfortunate outcome.
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?
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.
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.
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.
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.
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!
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.
