UserSettings().GameSettings.SavedQualityLevel is the only way to get the quality level a player is using. The only problem is, it totally falls flat when the player is using automatic graphics. @TwentyTwoPilots and I are working on a chunking system, and there’s no way to know if the player can handle a large render distance or a small render distance when the graphics mode is set to Automatic.
Possible changes to solve the problem:
New property UserGameSettings.QualityMode
New Enum QualityMode added
0: Automatic
1: Manual
New property UserGameSettings.QualityLevel: returns the quality level that the client is currently using.
UserGameSettings.SavedQualityLevel programmed as an alias of UserGameSettings.QualityLevel
Is this a discussion or feature request? Looks like the latter, either or, I would love to be able to actually be able to read what graphics my players are using at any point in time.
In the proposal, I propose that the behavior of SavedQualityLevel is changed to be an alias of the new QualityLevel property then depreciated. Obviously, depreciation doesn’t mean the property doesn’t work any more, just that you aren’t supposed to use them, but the behavior change is unique, in an effort to clean up the API a little. Do you care about what quality level a user has saved compared to the quality level a user is using currently? The poll is about whether or not the saved distinction matters to games.
I care about what the user’s saved quality level is
I do not care what the user’s saved quality level, only the current quality level
Bumping this because as of now because there’s no clear way of knowing what Automatic mode’s quality level represents, this is troubling for developers who want to base their LOD system on the quality slider roblox provides for players.
This hasn’t also been supported for years, and it’s about time that Roblox looked into this as this has become a relatively annoying nuisance, as of now I cannot publish some of my works due to this.
This is another great example of the many clientsided features that have essentially 0 harm but are locked behind RobloxScriptSecurity.
Great example is
UserInputService:GetPlatform()
There is literally no security issues with developers using this to properly detect the current platform, yet Roblox still does not allow us to use it like all the other useful functions that would greatly improve cross platform compatibility for many developers.
Roblox appears to encourage detection of the user’s control scheme rather than their platform. There was a feature request some time ago that asked for a way to directly access the user’s platform, and one of the concerns was that developers might make certain controls accessible for, say, Xbox, but then not PS4 by accident, instead of the current system where you can just figure out that the user is on a controller, do whatever you want with that, and people can plug in controllers to their PCs to play without hiccups.
I don’t think it’s really necessary, and apparently neither do Roblox, when they already provide a way to use user input based on control scheme rather than platform. Bringing up the PC + controller example mentioned previously, what would the platform be? If it said “Windows”, then developers will just assume that player’s are using a keyboard and a mouse, making it difficult to use a controller on PC if that’s really what someone wants to do.
You specifically said “cross platform compatibility”, and so I argued why that’s not really an issue right now. If you had other, more important reasons for having access to the player’s platform, then you should have stated them in your original reply.
I have a low-capacity laptop. What if the game crashes for me? Why not have it be a manual setting? You can have it be set automatically by checking UserInputService.TouchEnabled, and then let the player decide whether their device can handle your game. Maybe phones will soon become powerful enough to handle it at maximum quality, and so it becomes a nuisance to players when everything looks worse than it needs to be.
Devices like mobile have different technical capabilities compared to a gaming pc. The reason getting these would be helpful is for optimization reasons, my game as of currently is experiencing heavy memory crashing because I cannot detect mobile players and optimize the game for them more.
