Short answer: Scaling is always going to be a one-shot action.
Long answer:
The Roblox engine fundamentally has a very direct “What you see is what you get” style. If you have an Instance, it isn’t going to move or change size, or otherwise change appearance unless you explicitly tell it to do so, which is always eventually done though changing its properties (though possibly through an intermediary API call like this one)
As such scaling currently (and likely always will) takes the form of a one-shot action which scales the subject Instances by modifying their properties, rather than being a continuously applied scale transform that applies to whatever happens to be under the scaled hierarchy.
So I know that we need to scale tools manually, but how do animations work in that case?
Say I have a tool that has some parts rigged with Motor6Ds, the character holding the tool has its scale set to 2, and the tool has not been scaled at all. What happens? Does the animation on the rigged tool parts also get scaled? Or do they remain the same?
The beta feature has just been rolled out to 100% of Studio users and I’ll be enabling the API on production this Wednesday the 7th if no unexpected crashes come up.
Model:ScaleTo and Model:GetScale are now live on production, enjoy!
The beta will remain active in Studio at 100% rollout for a while longer in case anyone runs into tooling issues and needs to opt out to work around them.
Will I run into performance issues with tweening ScaleTo? (Or if tweening isn’t possible, running it many times per second to give the effect of it tweening)
Yes and no, but mostly yes, you’ll see performance issues.
You can use it to tween scale of simple objects, and probably even get away with tweening scale of a Character in real-time if you do it on the client, but the API is designed for consistency / ease of use purposes, not for efficiency.
If you couldn’t scale something efficiently enough before with raw property sets ScaleTo will not be significantly more efficient than that was, because ScaleTo is still setting the same properties underneath, just avoiding some of the overhead that came from the Lua reflection.
What you definitely can’t do is tween scale of something significantly complex on the server because that will spam the network with way too many property replications causing network lag.
One day the API may be upgraded to do better network replication and efficiency wise but for now it still does the same property sets as anything else underneath.
Will we see a feature to remove certain instances or properties that are affected by :ScaleTo? It’s especially annoying that it changes the WalkSpeed and JumpPower of humanoids.
In my game, setting a character’s scale to anything other than 1 results in AssemblyLinearVelocity to not work as effectively as it should, however manually changing the size of the player without changing scale doesn’t do this at all.
The player characters in my game have everything set to massless except the HumanoidRootPart.
Came here to comment the same thing, was working fine yesterday on mobile but appears to be not working today. Was it temporarily disabled? I feel less confident using the feature for my live game if I can’t be certain it will always be enabled
There was a bad, tricky to understand regression on iOS which caused Roblox to revert all flags up to a few weeks back for some iOS users in order to help diagnose the issue, and unfortunately ScaleTo was caught up in that window.
The flags should be back to normal sometime today, I’ll keep you updated.
Perils of using recently enabled features . Usually you would be completely safe more than a week after a feature being enabled, this is an exceptionally unusual case, I can’t think of any other time a feature has come out of beta and been reverted more than a day later.
It appears that, when using :ScaleTo or using the built-in scale tool to size up the default R15 blocky avatar, the edit mode view does not represent the in-game view. Updating any of the ScaleNumberValues under the Humanoid will result in the rig snapping to a thinner version with a smaller head.
This was pretty confusing for me as the animations I had made just seconds earlier resulting in their models clipping through walls, even though I made sure that they weren’t in the Animation Editor.
In my opinion, their proportions shouldn’t be changing like this. When I scale up a model, I expect to scale uniformly, not for certain parts to end up smaller or larger than they should be.
I’m not sure whether a place file would help here, because it changes when running you likely will see it in edit mode as I see it in Run Mode because the scaling will be re-applied then and there, but here it is anyway:
I’m having an issue with this feature trying to scale a character whilst it is moving. If a player is walking while ScaleTo() is called on their character, the character is killed and “flung” far away.
To reproduce this issue, paste the following in the server console and start walking:
task.wait(5) workspace.[PLAYER NAME]:ScaleTo(4)
This doesn’t seem to produce the issue 100% of the time, but seems to occur fairly reliably for me on a completely blank baseplate. When my character is not moving, the scaling works just fine.
This is one of the best changes I’ve seen so far, I randomly saw it when resizing something in my lobby, audibly gasped at the Scale property and came here to see its 10x better than what I thought. Thank you Roblox.
I created a test project based on the Racing template project, it seems that the ScaleTo() function has a problem with character collisions robloxapp-20230623-1442085.wmv (1.1 MB) TestScaleTo.rbxl (596.5 KB)
. Usually you would be completely safe more than a week after a feature being enabled, this is an exceptionally unusual case, I can’t think of any other time a feature has come out of beta and been reverted more than a day later.
