Removing Chat Type & Avatar Appearance Override Settings

Hey developers,

We are doing a strategic initiative to reduce confusion between places and games. As part of this, we audited the Configure Place page and decided to remove two unnecessary place settings:

Chat Type

This setting was used to control whether bubble chat appears above players’ heads. You can now achieve the same result by using this API:

local Chat = game:GetService("Chat")
local function setUpChatWindow()
    return { BubbleChatEnabled = true }
Chat:RegisterChatCallback(Enum.ChatCallbackType.OnCreatingChatWindow, setUpChatWindow)

Note that if your game already uses bubble chat, we will continue to respect the web setting behind the scenes so you do not need to change anything.

Avatar Appearance Override

This setting was used to indicate whether the game overrides custom avatars so that players could know before they join the game. It was only ever shown on one platform and we decided it was not worth keeping around.

Let us know if you have any feedback on these changes!


Another benefit to toggling bubble chat in-game is you can now see the bubbles in Play Solo


*Edit: Now it doesn’t work anymore >:


I have two concerns about this change.

  1. This API could be lost in the loads of announcements, just like the hat drop code (and probably multiple others) have.
  2. New users (with no understanding of the devforum or how to search on it) will not understand how to enable chat bubbles, and thus will be stuck.

How will these two issues be addressed?


it’d be cool if there was a link to this devforum post on that settings page. maybe remove it after a few months


I think having bubblechat as an api just makes it more confusing, now if you don’t read the api or know programming at all, you have to go and look for a bubblechat free model on the free model catalog, which could have a virus or a backdoor for exploits in it.

Also there was a third option where there was bubblechat but no chat console, and I know that was used for a lot of high rp games. I think it would make more sense if the option was in ChatService in a dropdown menu with these 4 options. As a property of the ChatService , it could be edited with code, while still being accessible visually

  • Bubble and Console Chat
  • Bubble Chat
  • Console Chat
  • No Chat (Assumes you are using a custom chat client)

edit: updated post to change Workspace to ChatService as a place to put the chat properties


That would probably work for a while.

Not keen on this update because of previously stated reasons by the others on this thread. It only makes it more complicated for new members, and will deeeefinitely break a lot of roleplay games. Some I can think of are ones like After the Flash and other similar ones.


BubbleChat should really be on by default after this change IMO


I agree honestly


I agree as well. Bubble chat is there on (most) games and the games that don’t want it can turn it off.


Honestly, even before this update. I see almost no games without it enabled, meaning most game owners want it on anyway.


I believe the chat type should stay as a option.

A platform that’s geared towards young developers and players will not know first hand how to enable chat. I think making to where its API sourced complex the overall chat “options”.

I’m also not that familiar with coding myself, but I was considering maybe there can be both API and still have the option menu available as well on the site?


Makes more sense for it to be an API in the same way dealing with corescripts in general is code based.
I would be careful to not assume intent on whether they “want” it on or not. Could be they just don’t care.
I don’t think we should be relying on web properties for such things.
If young developers want to change aspects about their game then there really is no work around to it except to learn how to code. Letting them rely on web properties for simple things will only serve to hurt them than help them learn. This actually makes a simple and very practical thing for a young dev to learn how to do.


(Did not mean to reply)

I have always been deeply annoyed by the location of the Chat Type setting. Every time I’ve needed to change it I’ve had to go through tedious place/game settings menus, and I can never remember which settings belong to which menu, so it’s always taken me an embarrassingly long time to find it.
Good riddance.

However, this API is unfriendly to new developers, and unless it is very clearly documented, they will struggle to find this setting, and even then they will still struggle. When I was young and knew nothing about scripting, even the idea of touching a script was an automatic “nope I can’t do that”, and I don’t think I was alone in feeling this way.

This needs to be very clearly documented on the Dev Hub such that it’s the first search result when you look up BubbleChat, and the snippet of code in this thread needs to be provided there. Currently, the top result for BubbleChat is Players.BubbleChat, which links to a PluginSecurity method for setting the chat type. This is not at all helpful to new developers.


There seem to be a lot of concerns about the discoverability of this setting. We are investigating if we can make it as simple as a property on ChatService.

Regardless, we’re working on DevHub documentation to ensure that developers can easily search and figure out how to enable bubble chat in their place.


A property sounds a lot more intuitive than a function to toggle it, and this will definitely help out new developers if documented correctly.


What reason is there to not use

and make those two properties able to be set in studio?
Doing so means less duplicate API members, as I see it.

1 Like

Players class is not a terribly good place for these API members. Probably best not to turn these into first class citizens for that reason, if anything under Chat service would be much more appropriate (and deprecating these you list).

1 Like

What about just moving this option to the new Studio settings button?


The Chat service would probably be a more appropriate place to put that property. It’s visible in Studio, and it makes more sense.