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 }
end
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!
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
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.
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.
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.
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).