Sooo what if someone is on PS4 (in the future if an when Roblox goes onto PS4,) how would you differentiate between a PS4 and an Xbox One? Since both platforms would be running under “10FootDisplay” or whatever, and both use gamepad input.
Imo, it’s kinda silly they’re not allowing developers access to the PlatformEnum.
They would add new KeyCode enumerator values for the shape buttons on playstation controllers, and they would either add a dedicated method to check the current controller layout + events for when it changes, or you have to use GetSupportedGamepadKeyCodes, GamepadConnected, GamepadDisconnected to determine which input labels to show to the user. All the functionality to accommodate for this is already present apart from the actual Circle/Triangle/Square/CrossButton enumerator values.
Writing platform-dependent code is really old-fashioned. Abstraction is your friend. It’s much better to write code per input mode that you can dynamically switch between such that the user can enjoy a reactive game that isn’t hinged on assumptions about their device.
That seems fine for compatibility’s sake, the point of my paragraph being that the problem described in the post above that is just implementation details that aren’t actually as hard to pull off (without having a device type API) as the poster made it seem.
As creator of this thread, I’m going to mark this post as solved.
Anytime this has been suggested, the same response has been: No. For the foreseeable future, this will not be a feature. It seems like Roblox is strongly opposing this. This makes sense, as devices are continuously changing and many devices take the form of others (e.g. a small touchscreen laptop vs. a large tablet w/ a mouse and keyboard hooked up).
As a Roblox developer, it is currently annoying for onboarding developers & me sometimes to figure out what platform players are on.
Having all the ways to determine what platform it is under one method :GetPlatform() instead of using
GuiService:IsTenFootInterfaceUserInputService.TouchEnabledUserInputService.KeyboardEnabledUserInputService.AccelerometerEnabledUserInputService.GyroscopeEnabledUserInputService.GamepadEnabledI think MACS don’t have a mouse2 or a ctrl button? This causes users to request an option to crouch with C and aim down sights with Q. I could have this turned on automatically if I detect them on a mac.
Also, a new developer might be confused on how to figure out how to check if they are on xbox, because its under GUIService away from everything else.
Why is it disabled? I don’t think it’s super privacy breaking if I know they are on a MAC or PC, Android or iPhone. If roblox can see these, why can’t I?
This is fair ^ Doesn’t mean a solution can’t be found though
Just for reference for people who may not know, this is a recent version of how to get the platform. (Includes the recent-ish change with touchscreens) It’s pretty silly how many services and weird checks we have to use. & good point from mightybaseplate about the mac controls
local GuiService = game:GetService("GuiService")
local UserInputService = game:GetService("UserInputService")
function getplatform()
if (GuiService:IsTenFootInterface()) then
return "Console"
elseif (UserInputService.TouchEnabled and not UserInputService.MouseEnabled) then
--touchscreen computers now have touchenabled so make sure to check for lack of mouse too
--also, not all phones/tablets have accelerometer and/or gyroscope
local DeviceSize = workspace.CurrentCamera.ViewportSize;
if ( DeviceSize.Y > 600 ) then
return "Mobile (tablet)"
else
return "Mobile (phone)"
end
else
return "Desktop"
end
end
I’m still floored that we’re left with this hacky way of determining things. It’s 2019 current year for god’s sake.
Literally (Unity)
Every (Unreal Engine)
Other (Love2d)
Multi-platform (Construct 2)
Game (Corona)
Engine (Gideros)
Exposes (LibGDX)
API (GameMaker)
to allows developers to detect OS, platform and/or device. What makes Roblox so special in this regard? As someone else said, this is “bubble wrapping” the API for safety.
Analytics are important. Different users behave differently, and operating system is just one more segment by which a player-base can be measured. This isn’t a matter of privacy either, since this kind of information tells you absolutely nothing useful about someone. Plus, it can be sniffed anyway.
The fact that there’s a metric crapton of different devices with different capabilities is actually an argument in favor such a feature to be exposed. More OSes/platforms/devices etc means more work for the people doing it the wrong way (detecting platform and setting up input). Abstraction via available peripherals is obviously the way to go, nobody’s arguing that. We have that feature already.
I don’t buy for a second the “there’s bad use cases” argument because if we really restricted features based on how they could be misused we’d have no features at all. Frankly, I think it’s insulting because it send the message that all Roblox developers are too naive to use the feature correctly when this is most certainly not the case.
The feature already exists. Literally the lowest amount of effort it would take to make this feature available to everyone. We’ve probably wasted more time talking about this than it would take to actually let people use this.
There’s really no security risk involved with allowing developers know what platform someone is on. Not only is the feature useful for analytics, but it’s also quite useful when coding in platform-specific functions, such as the previously mentioned Mac problem.
I completely agree with everything you’ve said. There’s really no valid reason why we should not be able to check what device a player is using.
Another important use of this could be user interfaces.
With this, you can make a separate mobile interface, separate pc interface, etc.
This would allow developers to optimize the screen real estate in a much better way.
You can make the buttons on mobile bigger. (Scale and UI constraints won’t cut it.)
You can make buttons etc. that would normally on pc take up part of the screen, completely fill the mobile screen. You can simplify menus too etc.
I should also mention that for this, the device detection shouldn’t need much more than ‘Desktop’, ‘Console’ and ‘Mobile’. (Maybe tablet?)
I’ve seen games like MeepCity optimize their UI for phone for example. The only way to do such a thing as of right now is to use those hacky methods as described above.
In other words, it would enable developers to make responsive UI without any hassle.
The strawman argument of “Just use UserInputService” is nullified when talking about multi-platform games, such as FPS games.
You don’t want console players going against PC players in a first person shooter.
Plus, it’s practically impossible to funnel players into specific servers for that specific device - a PC user could cheat into an Xbox - only lobby by using a gamepad. TenFootInterface also seems problematic because what happens if they’re playing Roblox on a PC that’s connected to a TV?
You also run into the issue with the possibility of Roblox going on PlayStation - UIS isn’t going to cut it.
I encourage you to think about the reasons behind this. It is true that some input devices provide a competitive advantage over others, e.g. keyboard/mouse is typically better than a gamepad. However, there is not a 1:1 connection between platforms and input devices. As of late last year, Xbox One players can use a keyboard/mouse with their console (I believe Roblox is looking into adding support for this). Similarly, PC players can use a gamepad. Many industry games are starting to do input based matchmaking for this reason.
So any argument that says “I want to segregate my players based on platform because of a competitive input type advantage” seems like a suboptimal solution. Instead, segregate your players based on input type.
Alright, yeah. I see your points regarding why platform detection could be bad.
However, how would we detect a user’s platform so they get the correct buttons to show up? I.e. if Playstation 4 is ever added to the Roblox ecosystem. At that point, there would need to be some kind of specific device detection in place. Or possibly even direct-driver detection so you could get PS4 buttons on PC, or N64 buttons on PC if for some reason you’re playing with an N64 controller. 
Not really, they would probably just add another input mode for the different controller layout, or perhaps some new keycodes, or both, or something entirely different that lets you distinguish between those controller layouts. You would not want the device check because then you’re excluding people who use the PS4/other controller through another device.
Currently, it’s only available on Xbox, and you can use GuiService:IsTenFootInterface() to detect if the user is on a console (and thus Xbox). If it were ever available on another console, I’m sure an API would be added to distinguish between the two.
I am making this claim due to one of the requirements for Xbox compatibility being this:
If on a platform like PS4, I imagine the same guideline would apply; therefore, I see it being reasonable to add some API to distinguish between the two.
However, that’s not the case currently.
At the moment, you can also use UserInputService:GetLastInputType() and UserInputService.LastInputTypeChanged() to distinguish if the user is using a gamepad or keyboard/mouse. From there, you can dynamically switch your UI to either show Xbox controls or keyboard/mouse controls. Same goes for Touch controls. But you can use IsTenFootInterface() to shortcut this and assume to always show Xbox controls.
Note: It is way more user-friendly to use the LastInputType method as opposed to simply checking if a gamepad is connected, because a user might have a connected gamepad but still be using keyboard/mouse.
True.
I find coding for UIS to be really confusing. When I was coding my interface for Redshift Arena to be compatible with Xbox controls, the buttons wouldn’t show up on Xbox, but would show up on PC if you were using a gamepad.
Also, wouldn’t driver-detection for input devices be better? Or could that open up security problems?
As stated previously before, a user could plugin in an N64 controller, PS4 Controller, XBX Controller, or even a NES controller and have the proper buttons show up for that device, if the developer supports it.
Of course, I’m not entirely sure if this is even possible for Roblox to add, but it would still be a cool feature, and could be done if Roblox added in a list of all possible gamepads into an API, among other input devices.
That probably means you are messing with GamepadEnabled which you should never use for input changing/setup, or you were not correctly updating the input mode whenever it changes. You should detect the last input type using UserInputService.LastInputTypeChanged and UserInputService:GetLastInputType(). Your game will be most reactive when you can literally switch input mode at any time, no matter what device you are on or what input mode was initially selected.
Probably best to let the engineers figure that one out. As developers we’d just want an API member that lets us distinguish between layouts.
I’d like to create a companion app for my game based in the same Universe as my game… Without actually being forced to make a companion app for my game… Or a new universe… for my game. See if I were able to discern between a mobile user, a pc user, and an xbox user… I could simply disable most of the need for rendering, and simply show a UI that lets players do things like be able to manage their inventory, repair their ships, or travel to a destination in x amount of time. All from the comfort of their phone while on the go. And when they actually get on the game on their PC. They would be able to actually see that the changes they made on the companion app actually made a difference.
But at this point I’d have to implement it within an entirely different universe, which means that accessing the main games datastore would be out of the question. And since Universe Scripts seem to look past Universe to Universe communication. I’d literally have to implement an external server just to get this functionality. Which could easily be obtained by simply knowing what type of device the user is on. Or I could do conditionals based on assumptions and hope no one falls in the in between.
All of this, simply because I don’t need to know the device type. At this point making a companion app albeit probably against the TOS is easier. Doesn’t make sense in my opinion.
It’s insane that we’ve been having this argument for roughly 3 years… The fact that Roblox wants to hide and block developers from certain services should NEVER be a thing. Let developers make mistakes so they know what to do in the future! That’s how people learn in the first place! Trying to safeguard (or “bubblewrap” as others have said) is ridiculous for a company striving to be a creative platform. There are certain cases where this is necessary, but some, like GetPlatform(), is kind of ridiculous.
I understand the main argument that developers will associate platform with input if GetPlatform() is unlocked, but I don’t think the majority of the large games on Roblox would even use it that way…
One of the main reasons people want this is to distinguish between the device’s performance & for analytics, not necessarily for their input.
For example, mobile devices (the majority of them) have a lower quality than most PCs. In my game, I wanted to change how I modify lighting in order for it to actually be seen by mobile. I use a sort of soft strobe light in parts of the game, but since lower quality levels don’t update lighting fast enough, it is impossible to even see these lighting changes at all. Compared to the lowest level of PCs, you can still barely see some of the changes, but at least you CAN see it.
We, the developers, should be given access to platform information based on the following :
The ability to create specific analytics by platform (because Roblox still barely provides us with any device-specific analytics to this day)
The fear that developers will think platform INSTEAD of input is invalid. The same exact mistake can still be made RIGHT now… Trust me, I’ve made this mistake with the methods we have now, and I’ve learned from it
We should have the ability so we can future-proof our game for the addition / removal of platforms. If you release GetPlatform() early, people can code their future projects with the mindset that there may be future additions ahead. This helps on changing the user interface and everything to match the platform they are using (again, input is not the same as platform, but you can still change the way the input prompts LOOK on different platforms, as others have mentioned)
As CloneTrooper put it;
The answer shouldn’t be:
We can do it ourselves with one method, why should we rely on the hacky way and ADD another method to the mess it already is?
Why make your developers rely on messy code when you can just unlock a single method to simplify everything? Seems like the fear of #2 is so much that you’d rather have your developers work around systems to achieve what they want…
I hope this is a reasonable argument in favor of unlocking GetPlatform(). Just because I would love to actually get a different argument from Roblox if they believe there is an actual reason to safeguard this functionality.
Thanks for reading 
I cannot overstate this: you should not be correlating unrelated factors with device type. ESRB ratings are not tied to device type, it just happens to be that the Xbox app has a certain ESRB rating. This information should be available through a different API, because Xbox does not have to be the only device with that rating. If a different platform is added to Roblox that also has a certain ESRB rating, you wouldn’t want to do “if Xbox or NewThing then”, you’d just want to do “if ESRB then” and have it automatically support new devices that have those policies active.
The mistake developers make is that they correlate unrelated properties to devices. Unlocking any kind of device type detection API would significantly increase this problem. We should be teaching developers to use input type and screen size detection (you can do this yourself right now, today), and we should have separate feature requests for other properties like certain ESRB ratings.
Same here, it is a different feature request: you want a way to request some more details about the current lighting quality. This is not a mobile-only thing. If a player is on a crappy laptop, they might see the same lighting setting, but your game wouldn’t handle that case because you’d only be checking for mobile. On the other hand, if I have a high-end iPhone, you might be doing corrections that don’t have to happen.
Building code off of a specific platform makes your game non-future-proof, not more future-proof. You support addition / removal of platforms when your code only takes into account input types and screen sizes.
Platform-specific code is what is messy code, not the code where you reactively respond to input and screen size changes. Refer to first quote response
TLDR; we need to stop correlating unrelated properties with certain device types. Knowing device type is only useful for analytics. (And that should probably be its own feature request)