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.
A while still.
First round of fixes are going out this week. Final round of fixes could go out on the 29th if we’re lucky and people only find minor issues in this week’s release and we don’t decide to change any of the behaviors (we’re still watching the feedback), but we’ll still want to do an out-out period for a couple of weeks due to the scale tool behavior changes, so April 12th is the soonest you might see it live on production.
Updates to the beta on March 16th
Animation Clip Editor now works on rigs with a scale other than 1 (the animation will be saved at scale = 1 so that when played back on the scaled rig it will look like it did as you were editing it)
Scaled characters now have the correct offset from ladders while climbing (the climbing animation still plays at the wrong speed, this will be fixed too)
Calling ScaleTo(inf) or ScaleTo(NaN) will no longer put the model in an unrecoverable bad state. Instead the calls will be ignored and Studio will warn you that you have a math error in your code.
PrismaticConstraint will now scale correctly, enjoy scaling your constraint based vehicles!
Torque/Force scaling would also be nice. When a part’s mass changes, a LinearVelocity or any other mover constraint will not have adjusted torque for the new scale. However, I don’t think it’s necessary for the feature, I’m just putting a thought out there.
Where was this when I needed it the most? Also love that TF2 nope.avi reference lol.
Great update! Excited to use it in a new character creator system!
Any idea when it might go live?
I think if there’s a feature for the Scale tool like a list of objects which’s hound be scaled, with some already on others off (parts = on/proximityPrompts = off)
Are we gonna be able to use the Scale tool while making animations? Such as Move, Rotate, Scale.
Looking forward to it! Any updates on the release date?
Sweet feature! We tried using it to animate layered clothing rigs but ran into an issue.
Trying to animate the ScaleTo property causes some serious delays and visual artifacts. It appears like Layered Clothing is completely recalculating every time ScaleTo is run. Would it be possible to just reuse the cached value for layered clothes data but scale it uniformly?
This is great! When is this planned to go live? I’d love to start using this in my experiences.
Would be really nice if there is a scale function for terrain as well
There are engineers working on making it much easier to do bulk operations on terrain like that right now, be on the lookout for that stuff when it comes out.
Hello!
I have stumpled upon an issue in the production of our animations within Prior Extinction.
(It should be noted that I don’t even have this Beta enabled, but it’s still effecting me.)
Whenever we export our models from Blender, we usually do 1.0 scale, as it’s easier to scale the model to the desired size we want from there.
In this case, we have scaled down Spinosaurus to be ~20x smaller than import size at 0.051 scale, which also is the scale of the animation that is imported. These two Spinosaurus’ models are the exact same physical size, but handle the very same animation very differently.
I believe the issue stems from the different set ups between the models.
The one where the Foot IK hardly moves :
The one where the Foot IK works perfectly :
From what I have read, each “Model” has its own scale. Perhaps, using these different set ups, is what is causing the problem.
The first model (The one that doesn’t work) hasn’t received any edits to work ingame, so it uses the same “Model” group it was given from it was imported.
The second one, doesn’t use the original “Model” group, as the mesh has been placed inside an already-existing “Model” group, that is made to work with all our scripts and features.
This issue only started occuring a few weeks ago, so I am 300% sure it is related to this scale feature.
(Last time we imported animations, was ~4 weeks ago (27th of March), when it worked just fine.)
The only solution I currently see, is that we instead start setting up all our animations, on the model which has already been set up with our scripts and features, instead of the freshly imported one.
Thank you,
That likely isn’t related to the scale feature but rather the numerous issues with animations and Motor6D that they keep experimenting on.
It seems that the AnimationSpeed of animations are changed based on the HipHeight property under the Humanoid. How does that system and the new animation scaling for the scale property work together?
I don’t have a use case to change the HipHeight of my custom characters, nor do I feel as though the scaling system interrupts my workflow as of right now. I am curious. I view the scaling of AnimationSpeed via the HipHeight to generally be a good thing, changing how it works would probably break a ton of games on Roblox. Anyhow, interested to hear what you have to say.
Would love to be using this but it’s still disabled.
Any ETA for when this will ship?
Sorry for the long delay! I kept ending up getting occupied with other work which pulled me away from getting this to production (but not for long enough for it to be worth handing off the remaining work to someone else).
The last bits which we needed to get in for this to go live are completed and on their way to production now. We’ll have to wait for a mobile force update to flip the final switch. Expect this go live by June 7th (or possibly May 31st if things line up right).
Well spotted.
TL;DR: yes there is some code to make the scale applied by this interact correctly with that existing HipHeight based hack.
Long story:
