Release Notes for 423

Notes for Release 423


Client Difference Log

API Changes

Added Property string Player.PlatformName {RobloxScriptSecurity}
Added Property bool UIGradient.Enabled

Added Function void Animator:ApplyJointVelocities(Variant motors)
Added Function string ThirdPartyUserService:GetUserPlatformName() {RobloxScriptSecurity}

Changed the parameters of Function StudioService:PublishAs 
	from: (int64 universeId, int64 placeId)
	  to: (int64 universeId, int64 placeId, int64 groupId)

Changed the parameters of Function VirtualInputManager:SendMouseButtonEvent 
	from: (int x, int y, int mouseButton, bool isDown, Instance pluginGui)
	  to: (int x, int y, int mouseButton, bool isDown, Instance pluginGui, int repeatCount)

Changed the parameters of Event GuiButton.Activated 
	from: (Instance inputObject)
	  to: (Instance inputObject, int clickCount)

Removed Class InternalSyncItem
	Removed Property InternalSyncItem.Enabled
	Removed Property InternalSyncItem.Path
	Removed Property InternalSyncItem.Target

Removed Class InternalSyncService

Removed Tag [Hidden] from Property JointInstance.Enabled

(Click here for a syntax highlighted version!)


What exactly is this and what is the use-case?


It’s a new argument on the GuiButton.Activated event (not GuiObject.Activated as stated in the change log) called clickCount which stores the number of times in a row the button was clicked. The use cases are having double, triple, etc clicks on buttons which, for example, could be used like in Windows for icons that can be both selected or activated.


oh yes

Why is this RobloxScriptSecurity though? This could be extremely useful for platform specific game adjustments.


Since pcall no longer creates thread, it correctly shows the full stack trace with debug.traceback

local function c()
local function b()
local function a()
-->  ServerScriptService.Script:2 function c
-->  ServerScriptService.Script:5 function b
-->  ServerScriptService.Script:8 function a
-->  ServerScriptService.Script:10

Although… it still has issues with resuming a yield in pcall

local thread = coroutine.create(function()
print(coroutine.status(thread)) --> normal

Using bindables doesn’t fix this issue either

local bind ="BindableEvent"
local thread = coroutine.create(function()
print(coroutine.status(thread)) --> normal

literally the day after I make a utility thing for my UI for detecting device type based on screen size and last input


Odd - our test suite for this actually has a lot of coroutine.resume in it and it works. I’ll look into this, but that should have worked.


It looks like enabling the FFlag LuauNewResume fixes the issue.
Seems weird that LuauNewResume and LuauYielablePcall are separate FFlags.


NewResume works without the other one (doesn’t change pcall impl but rewires a lot of other bits). We often split flags like this to be able to independently observe the impact, so we can activate new resume internals even if the new pcall impl doesn’t fully work.


Agreed. I think this is just obstinance from Roblox’s part - they want the Roblox experience to be the same regardless of what platform you’re on, and for us developers to not know, so as developers we have to expect that a player using a keyboard and mouse could suddenly start using a controller, and Roblox wants the game to continue to work.

This makes it more difficult for us, and the benefits of such flexibility for a developer is small (I’ve measured them on my games). Cross platform matters a lot, allowing a player to pick up a game pad half way through a PC session doesn’t.

@ClockworkSquirrel, thats still important. RobloxScriptSecurity means you can’t access it


This doesn’t really make sense. If you don’t want to support input mode switching (which is a totally normal thing to support) then you can just use the UIS input properties to check which input mode you should lock your user into. Why do you need a platform readout for this?


I understand your concerns, but as far as I am aware no one has been able to provide a single, reasonable use-case for user platform identification.

Concerns of feature abuse aside, could you provide a specific scenario where it would prove advantageous to have access to this information?

I realised after I posted that it was locked. I’m using screen size to adapt UI anyway, using breakpoints like bootstrap does.

You seem to be familiar with the forums UI, just by searching osplatform you will find many use cases. On top of that, every single other platform and engine lets developers see user platform.

What feature abuse? How can something as simple as platform be abused? Roblox’s only concern is that developers would use bad practises; but bad practises will always exist and forceful limitation of functionality does not fix that.

First of all, while I appreciate the indication to search for osplatform, only three results are displayed for such a query, two of them belonging to yours truly.

Historically speaking, most of the calls to add this feature were made by developers with the intention of separating players by platform, or otherwise distinguish them in such a way that would cause harm, most frequently towards mobile or console users.

Roblox wants (as far as I can tell) to distinguish themselves as a cross-platform engine. This cannot be achieved if every developer out there differentiates between platforms drastically. By resolving any issues that could be addressed with this feature at a platform level, we can make all games cross-platform compatible.

Only thing I can imagine wanting a platform value for is analytics and correlating that with various custom events that my game would fire off to analytics. Roblox can provide built-in analytics for seeing what platforms your players are on, but it would be difficult for them to build a system that allows me to correlate it with custom events (maybe PlayFab solves this in a way that doesn’t require in-game API for a platform value? I’m not in that beta).

However, thinking about it, perhaps you would get more interesting statistics by correlating it with elements of the form factor, like input mode, and those are already available to read out.


If you collect analytics on platform identification, you are then bound to tailor the gameplay experience to platform identification as well.

As you seem to hint on your last paragraph, if you instead correlate game analytics with input devices, screen size, and other already available properties, you maintain the ability to tailor your game while ensuring cross-platform compatibility.