Once again, the importance of platform is already demonstrated by the website analytics showing platform data. And clearly developers here see a good use for it and are asking for it. So, again, why not include it?
Quenty nailed it on the head. Exposing the device type means developers will invariably assume that the player is using whatever input their device comes with rather than peripherals. Analytics is a decent use case but it’s probably not worth it considering how misused this feature would be.
Trying to bubble-wrap features is not the right way to stop that. There are a million things that can be misused in the ROBLOX API and another million ways those things can be misused. GetPlatform is the odd one out, and locking it unlike the countless other API members that can be misused, preventing any proper use, is dumb.
My thoughts exactly. If “people can misuse something” is the sole reason against it, its dumb not to include it.
I (and most other developers) already used it wrongly at first. The input should change dynamically, meaning you can connect/disconnect your game controller to use a keyboard/mouse on the fly, however a lot of games on ROBLOXForXbox didn’t do this (Bird Simulator, Davidii’s game, etc) the only ones who I believe did this correctly were Tiny Tanks and Perilous Skies. So yeah It’s not as if this isn’t an issue already.
Other use cases aside from analytics:
- I can theme input icons / text i.e. if a user is on Mac I can say press “Cmd + C” and show the symbols for those and if they’re on Windows I can say press “Ctrl + C” and show the symbols for those. If on XBox I could show an XBox controller when I need to show users which button to press, and when not on XBox but using a controller, I can show a generic controller
- Reward special items based on platform (e.g. give XBox users a special weapon skin) to entice users to play on specific platforms. ROBLOX did this in one of the egg hunts for instance
- Targeted product display. People who use iOS products might be more willing to buy a product if it seems super sleek and trendy (how iOS products are advertised) while someone on XBox might be more willing to buy a product if it makes them feel like a badass (XBox stuff is generally marketed this way) – by owning a specific platform, a user has already communicated that they’re susceptible to specific marketing tactics, and by knowing which platform they’re on, we can take advantage of that
There are your use cases. Use cases coming from one person over the course of a couple minutes. I’m sure others have different use cases, and I can come up with more with more time thinking if that’s not enough. I’ll continue to add new use cases to this thread over time until GetPlatform is unlocked if that’s what it takes to convince you that there are enough use cases.
How could this be misused?
Right now you can use GuiService.IsWindows.
The point of mentioning those use cases is to show that there are use cases worthy of unlocking GetPlatform so detection doesn’t have to be done hackily, but thanks for mentioning that.
this property is deprecated and not guaranteed to work
Hey, I have a good reason for it.
How am I supposed to filter my game to meet ROBLOX’s Xbone ESRB if I don’t know what platform I’m running on? My game has blood/gore, which isn’t allowed, so I have to apply a local filter to the game so that I can keep the game on there, while allowing users to still experience what they please on other platforms because it isn’t restricted.
while not userInput.GamepadEnabled do userInput.Changed:wait() end while not game:FindFirstChild("OneStatFrame",true) do if not userInput.KeyboardEnabled then break end wait(1) end
This code is a gross hack, and I shouldn’t have to do that to verify if I’m on a console or not
Relying on a set of inputs ins’t really a good idea for platform detection (imo).
Controllers (mostly) work with Android. If someone can confirm if a keyboard case does/does not work, I could use that info,
Also, what happens if it suddenly becomes true for anyone with a touch screen on a laptop (ex: my Lenovo Yoga 2 for an example).
So maybe there should be a way to detect the platform’s ESRB requirements?
Instead of extrapolating ESRB from device type, you can extrapolate device type from ESRB.
First things first, I’d like to apologize for this huge necrobump.
However, I do feel this is a much needed feature, and it’s already in Roblox, but it is locked to RobloxSecurity (for a reason I do not know, other than it might be due to privacy concerns, but you can’t get much info from knowing the platform.)
Not only would allowing access to the PlatformEnum enable better input controls, but it would also allow for much, much easier creation of interfaces, scripts, settings, etc. for specific platforms. I.e., you could make an OSX-styled menu for Mac users, while using say, an Xbox-styled menu for Xbox users, or as Clone said, the disabling of certain things Client-Side.
This would be very beneficial and would allow the use of much cleaner code, and wouldn’t have to be hacky in nature.
They were asked about this at RDC and they said this is something they’d never add. UserInputService provides all the information you’d need for user input. The only downside to not having the exact device type is analytics, which they were asked about and were iffy about.
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.
I’m not sure this is the best idea. Generally, Xbox and PS4 controls are very similar so games should immediately be able to adapt to the new platform with existing code.
Just personal speculation here, but I’d bet they would map to their Xbox-equivalent keycodes.
How you go about showing PS4-specific labels would probably have to be it’s own API.
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.