What exactly does this mean, this feels like it could be a breaking change if Roblox missed something, and the message is really vague about what actually happened here
If all else fails the services are still creatable by calling game:GetService("SomeService") in the command bar as a workaround. Though I wouldn’t worry about it either way, there’s very few services with actual props that a developer would want to access so it’s unlikely that any were missed.
Wait, “Robux emoji”?! Did I miss something???
You did indeed: Release Notes for 541 - #5 by Tiffblocks (TL;DR: There’s a custom Robux emoji included in the Roblox fonts)
Fix Robux emoji not working in certain fonts like Inter.
Yay!
These will be very helpful!
I remember seeing people ask for these, so thanks for listening to the community!
Especially with that camera function. The amount of math that goes into positioning the camera to perfectly fit a bounding box is super annoying. Mainly, this will be useful for ViewportFrames and showcasing items you can obtain ingame!
Also about the ScaleTo function. How will this work? Or is this too good to be true…?
It’s just what it says on the tin, PivotTo but for resizing stuff instead. The implementation still needs a fair bit of work, there will be a comprehensive announcement post once it’s actually ready. There will also be a beta feature, so if you’re worried about the exact behavior there will be time to give feedback on aspects of it once it’s in beta.
”Add an engine level scale API Model:ScaleTo and update associated systems like packages, draggers, and properties pane to take advantage of it.”
@tnavarts is possible to explain further about this new API? Because once reading fully, it seems to be quite a sort of :PivotTo() but specialised for scaling models and/or objects in an overall view… Although it is just my perspective and I can be wrong.
Will it support adjusting JointInstance offsets or SpecialMesh scale properties? And could it support scaling based on “OriginalSize” Vector3 values? The OriginalSize portion is super handy for scaling parts multiple times with a static baseline
I’ve got some custom code for handling Model based player equipment and viewmodel scaling .
Here is the code:
Utilities.ScaleModel = function(model, xScale, yScale, zScale)
local origin = model.PrimaryPart.Position
local scale = Vector3.new(xScale, yScale, zScale)
for _, obj in pairs(model:GetDescendants()) do
local HasOriginalSize = obj:FindFirstChild("OriginalSize")
if obj:IsA("BasePart") then
if obj:GetAttribute('DontScale') ~= true then
if HasOriginalSize then
local newSize = HasOriginalSize.Value * scale
obj.Size = newSize
else
obj.Size *= scale
end
end
local distance = (obj.Position - origin)
local rotation = (obj.CFrame - obj.Position)
obj.CFrame = (CFrame.new(origin + distance*scale) * rotation)
elseif obj:IsA("JointInstance") then
local c0NewPos = obj.C0.p*scale
local c0RotX, c0RotY, c0RotZ = obj.C0:ToEulerAnglesXYZ()
local c1NewPos = obj.C1.p*scale
local c1RotX, c1RotY, c1RotZ = obj.C1:ToEulerAnglesXYZ()
obj.C0 = CFrame.new(c0NewPos)*CFrame.Angles(c0RotX, c0RotY, c0RotZ)
obj.C1 = CFrame.new(c1NewPos)*CFrame.Angles(c1RotX, c1RotY, c1RotZ)
elseif obj:IsA("SpecialMesh") then
if HasOriginalSize then
local newScale = HasOriginalSize.Value * scale
obj.Scale = newScale
else
obj.Scale *= scale
end
end
end
return model
end
And some examples of how/where it’s used
-- For scaling equipment to player (iterating over equipment parts)
bodypart.PrimaryPart = middlePart
if bodypart.Name == "Head" then
Utilities.ScaleModel(bodypart, HeadScale, HeadScale, HeadScale)
else
Utilities.ScaleModel(bodypart, BodyWidthScale, BodyHeightScale, BodyDepthScale)
end
bodypart:PivotTo(Character[bodypart.Name].CFrame)
-- For scaling player viewmodel scaling (iterating over player char clone or humanoid based viewmodel)
if string.match(Limb.Name, "UpperArm") or string.match(Limb.Name, "LowerArm") or string.match(Limb.Name, "Hand") then
if gameRules.ScaleViewModelArms then
Limb.Size = Vector3.new(Limb.OriginalSize.Value.X * ArmScale,Limb.OriginalSize.Value.Y, Limb.OriginalSize.Value.Z * ArmScale)
end
for _, Child in pairs(Limb:GetDescendants()) do
if Child:IsA("Attachment") or Child:IsA("Vector3Value") or Child:IsA("Weld") or Child:IsA("WeldConstraint") or Child:IsA("BasePart") then continue end
if Child:IsA("Model") then
if gameRules.ScaleViewModelArms then
Util.ScaleModel(Child, ArmScale, 1, ArmScale)
end
Child:PivotTo(Limb.CFrame)
continue
end
if Child:IsA("Motor6D") then
Child.Enabled = true
continue
end
Child:Destroy()
end
Limb.Parent = armModel
continue
end
TL;DR: It supports… everything, or at least all properties that have a remotely sensible scaling behavior. There’s going to be a beta feature for it so there will be time to give feedback before the exact behavior is locked in.
at least you can use keyboards for explorer purposes now 
Yeah seems extremely counter-intuitive… “To make it more useful, we’ve removed some of the things it can do!”… like what?
Oh boy! It’s always a good day on roblox when you can replace custom work with engine level features
Will it be able to scale models nonuniformly (like stretching it)?
No such luck.
Maybe one day but it’s not feasible to get non-uniform scale into the engine at this time. The crux of the problem is that rotated descendants of a thing you’re scaling non-uniformly may become skewed / sheared as a result of the scale and the engine doesn’t have a reasonable path to cleanly representing that for arbitrary Instances (we could make it work for Unions specifically but doing it for arbitrary Instances is much harder)
The tradeoff that other engines tend to make in the same scenario is to just throw up their hands and have weird unfortunate behaviors in that case but we’re not interested in permanently locking in a decision like that.
The best we could include is an affordance in the package system letting you non-uniformly scale packages and not have them count as modified as long as those packages only have a single part in them. That at least lets you have simple reusable geometry that can be scaled nonuniformly.
Ooh! Does this mean that tools could be scaled by using this upcoming method on its handle part? If so, this could be useful for games with different “character sizes”, so smaller kid characters don’t hold full-size items in their hands.
This will naturally combine with the Tool-inherits-Model change coming out next week. Tools won’t automatically change size when you reparent them to a scaled character but you should be able to make a simple call like tool:ScaleTo(character:GetScale()) to do the adjustment now.
I wanted to ask, and I have always wondered this, but what is AnimationFromVideoCreatorService? I feel like it shouldn’t be in the insert service menu if all functions are locked to RBXScriptSecuritty.
It does what the name suggests, creates an animation from a video, probably for motion capture.
Why there’s a StudioService clone of it? Who knows, the Roblox API is a mysterious web