This is very annoying, I’m actually missing letters because of this
To sum up, the new chat is so far one big bug and a mess, not to mention usage of various ugly hacks and weird input handling.
While bugs are expected and acceptable for such a new thing, ugly hacks and weird behaviours are not. I thought updating stuff should mean getting rid of these, but apparently that’s not the case with Roblox.
And it’s not even the first time. Example: 2020 update of Core GUI, topbar and the playerlist. The “more menu” doesn’t handle user input correctly at all. The playerlist still does not handle longer names properly. And there’s much more.
Why, Roblox, why can’t you just update well-made components instead of throwing them in the trash and putting crappy, rushed replacements in their place, and making changes that no one asked for?
2 Likes
Hi! Sorry to hear that you had such a poor experience!
We’re taking feedback and rapidly iterating to offer the best in-experience chat system we can offer. We’d appreciate if you could possibly elaborate on the “usage of various ugly hacks and weird input handling” you mentioned (perhaps a bullet point list, or if some of these have been already mentioned in above posts, links/references to them) so that we can identify the issues and resolve them.
Thank you for your patience and cooperation!
5 Likes
I’ve come across some unintentional behavior with the new chat system when used with the new bubble chat system. Each time Chat.BubbleChatEnabled is disabled and reenabled, chatting with the new chat system creates extra duplicate bubbles. This issue does not occur with the old chat system. Here’s a video of the issue, comparing both chat systems:
4 Likes
First of all I’d like to apologize that my previous post was perhaps a little bit too emotional, I was expressing my frustration with the overall poor quality of Roblox’s frontend (because there’s no other place to express it and Roblox barely ever wants to listen to user feedback but that’s another story).
Anyway, going back on track, by “ugly hacks and weird behaviours” I meant behaviours that clearly indicate that something somewhere is not done how it should be, such as:
This behaviour is not present with standard TextBoxes or the old Lua chat system.
This one is weird and also annoying (and also falls under the ugly hacks category if the reason why the delay exists is correct). Not present with previous chat systems either.
1 Like
You can use TextChannel:DisplaySystemMessage("msg") within the PlayerAdded and PlayerRemoving events to do this.
1 Like
It’s pretty nice and I would love to use it, however my originial chat commands do not work with the new chat (and I’m too lazy to change it) since it relies on Player.Chatted event, which doesn’t fire with the new chat.
It would be pretty nice if that event could fire with the new chat or have an alternative to that gives the unfiltered message when a player chatted
1 Like
I mean…
But it’s whatever lol
I’ve also noticed a small bug where sometimes the text disappears even if I am hovering over the chat.
3 Likes
We’re actively working on the two issues (movement and delay) right now!
We’ve identified the source and are working on a solution, thank you for pointing this out!
Have you tried TextChatService.SendingMessage? If this is not a suitable alternative to your flow please let us know!
Is the movement going to be the same as the current chat (character stops moving after unfocusing the chat) or are you going to disable that behaviour entirely?
(the first option would be preferred)
We’re aiming to have identical behavior between both chats. The control scripts rely on events within UserInputService like TextBoxFocusReleased. Unfortunately a recent intentional change (within the last month) has prevented TextBoxes in CoreGui from raising these events.
What was even more surprising is that UserInputService.WindowFocused (another event the control scripts uses for the behavior) was firing in Studio but not in live games when TextBoxes are unfocused, preventing this wonky auto-run behavior from happening in Studio, making this behavior even harder to notice pre-release (during the Studio Beta period, no one was able to observe this since you were not able to publish games with TextChatService enabled).
We’re working now to remedy this.
6 Likes
I was referring to the misalignment shown here.
If the goal was to keep the Text aligned with the Menu Button above, I believe a good compromise to align the Chat Box and Chat Text simultaneously would be to keep the Text aligned with the actual Image inside the Menu Button, rather than the Box encasing it. This way, the Chat Text isn’t hitting the edges of the Chat Box while keeping misalignment to a minimum.
As it currently is, the current misalignment of the Chat Box is exponentially more likely to trigger OCD in others than my suggestion. Although if this were to be considered, it’ll likely require the readjusting of other elements such as the Leaderboard/Playerlist.
Potentially Offtopic
Speaking of ui misalignment, what IS that close button (the button that replaces the menu button when opened) when you open the Roblox Menu? It’s hard to comprehend HOW someone would fail to align that with the Menu Icon. No reason in the world not to do so either, meaning it was intentional or poorly done. I firmly believe that Quality Control needs to be bumped up considerably if something like that was able to ever pass without lots of consideration.
3 Likes
Is it possible to add Icons infront of someone’s name in chat?
1 Like
It would work, unless the text gets filtered. Looking at the documentation, TextChatMessage doesn’t containt an unfiltered version of the message. If a sound id or a gear id is used in the command, it’s very likely to be filtered, preventing the command from working correctly.
1 Like
Ayo, doing this would add backdoor if command downloads other user’s product.
My exemple is with Blockate, where you can do !sound (sound id) to change the sound on the world and !gear (players) (gear id) to give a gear from the catalog to (players). The game I’m working is somewhat similar and I might add similar commands. But even so, other commands that take a username or display name could get filtered and thus wont work
1 Like
I actually prefer it like this than if it was aligned with the topbar buttons (too much wasted screen space).
It can’t be the other way around as topbar buttons have to be padded since displays with rounded corners exist
What’s up with the delay before you can type? You end up trying to walk and speak but end up with the first letter missing and a bug that forces you to move the direction until you press the same key.