I think it’s related to this issue reported here, is it happening in just the specific universe you had? Like have you tried making a new game and just making a system message to see if it works?
I’m not sure if you’re automatically formatting a user’s message if it comes from an “executive” or similar, but if you are, you would need to remove the custom formatting.
For example, this should usually succeed:
local message = textbox.Text
channel:SendAsync(message)
textbox.Text = ""
Yet these will fail:
channel:SendAsync("hello")
local message = "hello"
channel:SendAsync(message)
local message = textbox.Text .. "a"
channel:SendAsync(message)
textbox.Text = ""
-- This will fail only if the string changes
local message = textbox.Text:gsub("a", "b")
channel:SendAsync(message)
textbox.Text = ""
Still having this problem and still receiving reports from players constantly telling me to “fix this”
The chat system is working for me usually, sometimes I get this error, but other players continue to tell me about this and somehow it’s affecting some people more? I can’t really understand but it’s infuriating
Hello everyone, thank you all for your patience. We recently made a change to TextChannel:SendAsync so that only messages that have been recently typed and sent by the user are delivered to other users, and have updated the TextChannel:SendAsync() documentation to reflect that coming change.
We have temporarily rolled back this change to investigate potential issues, with the plan of rolling it out again once these issues are fixed.
does this mean that as long as user typed the message (not like in a text box for better interface customizations) and press enter, it will be allowed to send to chat with SendAsync?
This is what it sounds like, but glad to see this change has been rolled back as these custom chat implementations were probably not considered. Hopefully a solution that incorporates these will be deployed in future.
In my game, players like to create data saved ‘default’ messages that they can quickly send, since this is much easier than copying and pasting text into the chat window. We previously used SendAsync for this purpose.
More recently, Roblox introduced Chat Restrictions with age groups, and SendAsync continued to work by only sending messages to players within the appropriate age groups. This is critical, as sending messages across age groups is not allowed.
Sending strings through SendAsync was, and still is, fully compliant with age group restrictions, since the backend only delivers messages to the appropriate players. Honestly, I do not see a meaningful difference between a typed message and a preset message sent through SendAsync, as both are filtered and compliant with age group rules.
When reviewing Roblox’s statements regarding Preset Messages or ‘Quick Chat,’ there has been very little detailed information disclosed. However, Roblox has stated that it intends to support this functionality on the platform and that more details will be provided in the future. In this case, ‘Quick Chat’ would need to use DisplaySystemMessage, which is inherently different from SendAsync, as DisplaySystemMessage broadcasts to all players regardless of age group.
SendAsync was our method of broadcasting player-written messages in a way that respected filtering and only delivered messages to users that the sender was allowed to chat with.
I hope this change is reconsidered so that player-defined preset messaging can still be implemented on the platform. I also hope that similar changes are communicated ahead of time, so developers with existing systems are not caught off guard by breaking changes.
well this will surely be fixed as roblox mentioned that they allow default messages (i think, correct me if i’m wrong)
but i doubt roblox is gonna care enough to add more security impl just for custom text label + input began (string + enter) stuff cuz it’s not built based on what they want us to use (textbox i assume)
Quick-chat would have to be developer set messages so player-based presets wouldn’t be allowed on the platform to be sent across age groups. SendAsync sends only to people you can communicate with, but it seems like the new intention is SendAsync will now only work if you wrote out the chat yourself ‘recently’.
Before this change have been rolled back i have experienced similar issues but with the player chat, i simply could not send any message at all and it would show “Your message could not be sent”, for now though they said they rolled the change back so i guess it still has some clear issues.
The keyboard is core functionality to my game, so I developed a virtual on-screen keyboard. Whether you are playing the game or swiping over to chat, the keyboard should always be displayed.
I use the virtual keyboard for chat because it keeps players accustomed to the virtual keyboard (not needing to switch back and forth), allows for developer-customization, and was designed specifically for the game and can include extra details.
Unfortunately, Roblox provides you no option to keep the hardware keyboard on the screen, (the hardware keyboard will ALWAYS animate down even if you immediately re-focus a TextBox, and there is no property nor way to keep a TextBox focused when a user presses the Enter key) and even if Roblox did, I wouldn’t use it regardless, due to the extra benefits the virtual keyboard provides to the game, and because bringing up the hardware keyboard from a TextBox shifts the entire game and UI to meet with the TextBox’s location on the screen, meaning you cannot always guarantee where your game and the UI will be. The virtual keyboard ensures the game and UI elements are where I want them to be.
Have you also considered the client-side cleaning developers must do sometimes with regards to the TextBox (preventing double-spaces, limiting the length of the message, blocking certain characters, etc.)? Or developers implementing custom emojis into their chat systems (writing out emoji codes for the user into a TextBox)?
Please account for these with the breaking change to :SendAsync().
i mean, it’s basically impossible to support a whole custom keyboard interface
it’s not roblox’s fault (at least i’m sure they don’t care enough to fix) that they break stuff that they don’t intend you to do, like using custom interfaces
