Maintain support for old bubble chat and custom bubble chat handlers: throw out any plans of dropping support for pre-Roact bubble chat

Feature Requests Engine Features
#1

As a Roblox developer, the new bubble chat is inadequate and does not suit my needs accordingly. I am expecting to turn it off in all current and future games of mine, however the thread leaves me unsatisfied and unsettled on a concern of dropping support.

I expressed my concerns on the thread which were glossed over, so I am bringing it to the Platform Feedback category to continue my fight against any potential of removing support for old bubble chat. This is a hill that I am willing to die on: I do not like the restrictiveness of the new bubble chat code.

Literally the only reason why the bubble chat code is becoming a CoreScript is because modules it needs (e.g. Roact) are CoreScripts. Considering these modules are open source, available and used by developers for their other work, it would be nice to just make these developer-facing to kill two birds with one stone: continuing the tradition of making more parts of the game customisable and granting access to already-used libraries. Instead, we’re going backwards to not being able to edit the code.

The following quote was issued on the bubble chat release thread:

Taken literally, this says that there is no guarantee that engineers will continue to support the old bubble chat either natively or through forks down the line. That means that games will have to be stuck using a CoreScript bubble chat, which is anti-developer. You are unable to edit CoreScripts and thus extend it with your own behaviour, code and the like. Additionally, this might mean that it will be much more difficult to or impossible to write our own bubble chat handlers, opting us to take much longer and tedious routes to set that up, including writing our own chat system from ground up.

The new bubble chat and related CoreScripts can be forked to create a working copy in your game, however not every developer knows how to do that over just forking the BubbleChat LocalScript and editing it due to its use across 2 or more years. Additionally, knowing how to fork it is just one piece of the pie: I preference the old bubble chat because it snaps well, it’s sharp and doesn’t look cartoony. It fits a general feel which is good for all themes, moods, atmospheres, so on.

The new bubble chat and its limited customisation options don’t fully allow you to get that same generalised and snapped feel, missing options like the following two for example:

  • Fade in time: the bubbles start at 0 height and tween up into their expected height. I want the bubbles to instantly be sized appropriately, no tweens.

  • Per-player customisation: I made a tutorial on accomplishing this with Lua Chat System version 0.8.2018.05.16. It’s easy to do with the Lua Chat System already, all it does is pull some data given in speakers. Per-player bubble customisation was considered on the thread, but that means going the extra length of having to customise both the ChatSpeaker and bubble chats independently instead of doing it once. Arguably pretty trivial if the new bubble chat can take overrides from the ChatSpeaker object.

You can view my initial post of concern here:

41 Likes
Allow us to fork the player list and new bubble chat
#3

Im bumping this issue as Roblox have silently started to phase out the well-loved Lua Chat System in favour of a restricted API and Roact Gui thats controlled by a CoreScript.

The same issue is happening here as with the bubble chat, phasing out developer-forkable systems in favour of locked down APIs that Roblox can control more tightly.

I dont care if there’s an exploit with SetCore, a small majority of users abusing it shouldn’t mean we lose access to one of the best features in Roblox

3 Likes
#4

I shouldn’t pretend like I’m surprised this was going to happen. All control is gone, Roblox has become the bottleneck for backend updates and we’re only allowed to update the frontend. I hate this loss of control just because they think they know better about how chat should function across experiences instead of giving us APIs for compliance like in the past.

Removing support for the Legacy Chat System is one thing, but gutting support for custom chat solutions as well is just heartbreaking. This feature request focused more on the bubble chat handler specifically but that’s now bundled to TextChatService so the update and policy change affect the ability to execute this as well. That being said, as far as bubble chat goes, the only use case not currently covered is inlining images. After that, I won’t need any bubble chat fork.

3 Likes
#5

You can make custom bubble chats by simply hooking onto the pre-existing TextChatService API.

#6

See:

#7

See:

#8

…? I mean yeah? That response was directed to the question I posted. I linked that post to point you towards the fact that I asked a question related to my circumstances and got a staff reply regarding my issue in that it would be okay to continue to use a forked bubble chat script as long as I hook it to TextChatService instead of remotes or obscure Chat service events.

This isn’t telling me anything new. You should probably check if a linked post has replies or scroll down a bit so you can follow the conversation better.

1 Like