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!)
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()
print(debug.traceback())
end
local function b()
c()
end
local function a()
pcall(b)
end
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()
pcall(function()
print(coroutine.yield())
end)
print"end"
end)
coroutine.resume(thread)
coroutine.resume(thread,"start")
print(coroutine.status(thread)) --> normal
Using bindables doesn’t fix this issue either
local bind = Instance.new"BindableEvent"
local thread = coroutine.create(function()
pcall(function()
print(bind.Event:Wait())
end)
print"end"
end)
coroutine.resume(thread)
bind:Fire"start"
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.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.