Ability to detect or respect client settings: Show Names, Show Badges, and Haptics

As a Roblox developer, it is currently impossible to respect the user’s specific choices regarding the newly added “Show People’s Names” and “Display my badges” settings when using custom UI implementations. Additionally, we lack a direct way to check if Haptics are disabled in settings for optimization purposes.

I propose exposing these settings as read-only properties, OR updating the behavior of existing APIs to reflect these settings.

Here are the specific use cases and proposed solutions:

  1. Handling “Show People’s Names”

With the introduction of this setting, users expect a cleaner view or privacy when they toggle this off. However, custom BillboardGui elements (overhead ranks, names) remain visible.

  • Proposed Solution A (New API): Add GuiService.ShowUsernames (bool). If true, we can manually hide or destroy our custom overhead UIs.

  • Proposed Solution B (Behavior Change): Alternatively, if the user has disabled names, Humanoid.DisplayDistanceType could strictly return Enum.HumanoidDisplayDistanceType.None for that player. This would allow scripts checking this property to naturally adapt and hide custom tags without needing a new API.

  1. Handling “Display my badges”

Users can now choose to hide special indicators like the Verified badge

  • Proposed Solution A (New API): Add GuiService.ShowBadges (bool). Developers can check this before displaying custom badge icons.

  • Proposed Solution B (Behavior Change): Alternatively, Player.HasVerifiedBadge could strictly return false if the user has explicitly chosen to hide their badges. This ensures that even existing scripts automatically respect the user’s privacy choice without requiring updates.

  1. GuiService.HapticsEnabled (Boolean)

Currently, if a user disables vibration in the settings, the engine correctly suppresses the haptic feedback, but developers cannot check this state beforehand.

Use Case: I would like to check this boolean before creating HapticEffect instances or calling play methods. If the user has haptics disabled, I can skip the logic for creating/playing effects entirely. This serves as a code optimization, preventing the allocation of resources for effects that will never be felt by the user.

24 Likes

bummmmmmmppppppppp we need this!!!

bump, we need this.
also-

  1. why is the show badges setting available to users without special indicators (eg. verified, star creator, employee/intern, experience dev, etc)?
  2. why do i not have the show badges setting (my account is verified)?

Definitely agree, there’s many places in our game which show the verified badge, so this setting is effectively useless until we can add support for it.

2 Likes

I want to share some recent observations regarding these requests.

It appears that “Display my badges” now partially behaves like my “Proposed Solution B”. Currently, Player.HasVerifiedBadge returns false if the player has the setting disabled, and true if enabled.

However, there is a significant limitation: the property value seems to be cached upon joining. It does not update in real-time if the user toggles the setting while in the game. The player is forced to rejoin for the new setting to take effect, which is not ideal for User Experience.

It would be great if we could simply write the following code to handle these changes dynamically:

player:GetPropertyChangedSignal("HasVerifiedBadge"):Connect(function()
    local isHidden = not player.HasVerifiedBadge
end)

Ideally, this property should replicate in real-time so we can hide/show badges instantly without requiring a rejoin.

Additionally, I still haven’t found any way to detect “Show People’s Names” or the “Haptics Enabled” state for optimization purposes. Explicit support for these is still needed.

1 Like

:frowning: this would be helpful :slight_smile: I would love to be able to show/hide badges based on players choice

Their names are still showing because they’re custom and there’s no way to respect this user setting as of now. Please add this!

It would be a nice feature to have, however would other developers go out of their way to respect this setting? Most probably won’t update their game to respect this…

…However there is an alternate solution which solves everything.

People who have scripted a system to detect a verified badge did it like this:

player.HasVerifiedBadge

So instead of implementing new code, Roblox can simply return false if their privacy settings are enabled.

This can also work with Show People’s Names in a similar way.

What’s ironic about this is that Roblox has been so inconsistent with what the purpose of exposing these player choice settings even is.

First, they introduced preferred transparency and reduced motion which does virtually nothing unless the game goes out of its way to implement them, then they added preferred text scaling which bypasses developer intent since they believed user intent > game design, and then they added these privacy settings that don’t even give developers the ability to respect them.

So, which one is it, are these settings meant to be handled by the developers, automatically applied for the players unconditionally, or in this case, neither?

3 Likes

The API for showing player names already exists: UserGameSettings.PlayerNamesEnabled

However, it is Roblox Script Security. Please allow normal game scripts to read it so we can properly support this feature it in our games.