Device Type Detection

[GuestCapone]

How could this be misused?

[Sharksie]

Right now you can use GuiService.IsWindows.

[EchoReaper]

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.

[darthskrill]

this property is deprecated and not guaranteed to work

[Maximum_ADHD]

There might be a good reason out there (I suspect there is), but the arguments presented so far don’t convince me you get something extra out of knowing what platform your users are on. Type of screen and type of input seem to give you everything you would need. We could probably do more in the type of screen department, I agree.

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

[TheNexusAvenger (Nexus)]

Relying on a set of inputs ins’t really a good idea for platform detection (imo).
Ex:

iOS/Android -> TYPE_TOUCH

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).

[Seranok]

So maybe there should be a way to detect the platform’s ESRB requirements?

[NWSpacek]

Instead of extrapolating ESRB from device type, you can extrapolate device type from ESRB.

[TheRings0fSaturn (SaturianNightmare)]

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.

[Kampfkarren (boyned)]

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.

[TheRings0fSaturn (SaturianNightmare)]

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.

[buildthomas]

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.

[buildthomas]

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.

[sleitnick]

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).

[mightybaseplate (Opponent)]

https://developer.roblox.com/api-reference/function/UserInputService/GetPlatform

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:IsTenFootInterface
• UserInputService.TouchEnabled
• UserInputService.KeyboardEnabled
• UserInputService.AccelerometerEnabled
• UserInputService.GyroscopeEnabled
• UserInputService.GamepadEnabled

I 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 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).

This is fair ^ Doesn’t mean a solution can’t be found though

[Maelstronomer]

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

[Ozzypig]

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.

[TheRings0fSaturn (SaturianNightmare)]

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.

[vsnry]

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.

[XandertjeKnal (Xander)]

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.