Have you been able to replicate this issue or find any work-around?
The best “work-around” per-se is to just enable the old system, as sad as it may sound.
Do you remember what game this is?
Bug with TextBoxFocused firing after losing focus or pressing enter. I was trying to update a script that shows a little bubble above a player when they’re typing and realized that TextBoxFocused only fired after losing focus/pressing enter.
I put this in a local script under starter player scripts and testing showed that it does in fact fire at the same time as textboxfocusreleased. This was done on a new default template and on a live server.
local ui = game:GetService("UserInputService")
ui.TextBoxFocused:Connect(function()
print("test1")
end)
ui.TextBoxFocusReleased:Connect(function()
print("test2")
end)
Pressing slash or clicking on the chat bar does not fire the focused event, pressing enter or losing focus fires both.
Posting here because I can’t post in bug reports.
It’s possible to send system messages and customize them using Rich Text.
I wrote a tutorial for how to convert usage of the old game.StarterGui:SetCore("ChatMakeSystemMessage")
function (which no longer works with the new TextChatService) over to the new API
The tutorial shows how you can display system messages with custom color, font, etc.:
Hope this helps!
Please give us some way of knowing when a player is typing in the chat
well, have you tried TextChatService.ChatInputBarConfiguration.IsFocused?
I think that given the limited ability which developers have to edit this new chat’s functionality, Roblox should try to cram as much configurable functionality into it as possible. This is one I would like to see
I managed to find a way around this, that’s actually provided by Roblox in the dev hub
The new chat service is good and all but the look just doesn’t look that great which is pretty much the only reason why I still prefer and use the old legacy chat because it’s look is simplistic and generally looks fine.
The metadata looks like this: "Roblox.Notification.Friend.Joined"
However, the username or user ID of the joining friend is nowhere in the TextChatMessage
instance above.
This makes it so that if you want to change the message to add more info, like the username, you have to deal with the potential edge case of 2 friends who have the same display name joining a player.
Would it make sense for Roblox to add the username or user ID to the TextChatMessage
metadata?
Will scrolling frame bar cutting off the text get fixed?
Hi, is there any way to move the position of the InputBar without having to create a custom input box?
This was possible in the legacy text chat system using StarterGui:SetCore("ChatWindowPosition", UDim2)
This would be useful for me since I have a BubbleChat-only game, and I would like to display some info above the chat bar as if the user is writing into that info.
Even better if the position of the input bar could be decoupled from the chat window! It doesn’t matter for my use case though, since I disable the chat window
Second point. Is it a bug that Player.Chatted
event no longer fires on the Client side?
It would be nice that it continued to do so for backwards compatibility. If not, this should be mentioned in the migration guide.
I have the following, which now never fires on chat
game.Players.LocalPlayer.Chatted:Connect(function(msg)
print(msg)
end)
NOTE: it still fires correctly on the server side!
TextChatService:DisplayBubble()
doesn’t work compared to Chat:Chat()
Here’s a clip in a completely new baseplate testing these 2 methods on both Server
and Client
You can use Chat window configuration.VerticalAlignment/HorizontalAlignment to move the chat input bar. Unfortunately it can’t be decoupled from the chat window if it were visible without using your own Text box.
I’ll forward this to the team. If you have access to bug reports, I’d recommend reporting future issues there, though I understand not everyone has access to post there.
I’ll forward this interesting idea to the team. I think the usecase is valid
I’m not for certain, but it’s likely DisplayBubble isn’t enabled quite yet.
I managed to make it work by putting a join timestamp on players and then seeing whose timestamp is later to figure out which friend joined you, but it does make sense to add the extra info in the metadata.
EDIT Here is my thread on this topic that follows:
In addition to the friend joined message, there’s also another issue I had where if your place has multiple independent modules each doing their own modification to incoming chat messages — for example, you could have one module adding a chat tag to a player’s name, and another module which colors chat messages — then only one of them works, because each mod overwrites the TextChatService.OnIncomingMessage
callback function.
It makes sense why it works this way, as the internal TextChatService
code needs to have a single return value to use in the new chat. Presumably, developers would just add their own series of functions inside TextChatService.OnIncomingMessage
which processes the message with their set of modifications.
However, when working with external modules like you might get in the Toolbox or here in the Community Resources sub forum, you as the developer have to modify the code to work in your own series of “mod filters” for a given TextChatMessage
. Developers have to code up their own priority executor:
Code:
local function AddTag(TextChatMessage)
local taggedMsg = Instance.new("TextChatMessageProperties")
local newTag = string.format("<font color=\"rgb(255, 0, 0)\" weight=\"heavy\">%s</font>", "Leader")
taggedMsg.PrefixText = string.format("%s %s", newTag, TextChatMessage.PrefixText)
taggedMsg.Text = TextChatMessage.Text
return taggedMsg
end
local function CapitalizeName(TextChatMessage)
local new = Instance.new("TextChatMessageProperties")
new.PrefixText = string.upper(TextChatMessage.PrefixText)
new.Text = TextChatMessage.Text
return new
end
local rnd = Random.new()
local function ColorText(TextChatMessage)
local coloredMsg = Instance.new("TextChatMessageProperties")
coloredMsg.PrefixText = TextChatMessage.PrefixText
local color = Color3.new(rnd:NextNumber(), rnd:NextNumber(), rnd:NextNumber())
coloredMsg.Text = string.format("<font color=\"rgb(%i, %i, %i)\">%s</font>", color.R*255, color.G*255, color.B*255, TextChatMessage.Text)
return coloredMsg
end
game:GetService("TextChatService").OnIncomingMessage = function(TextChatMessage)
local FakeWrapperMessage = {Text = TextChatMessage.Text, PrefixText = TextChatMessage.PrefixText}
for Priority, Callback in {CapitalizeName, AddTag, ColorText} do
local newTCMP = Callback(FakeWrapperMessage)
if newTCMP and newTCMP:IsA("TextChatMessageProperties") then
FakeWrapperMessage.Text = newTCMP.Text
FakeWrapperMessage.PrefixText = newTCMP.PrefixText
end
end
local final = Instance.new("TextChatMessageProperties")
final.PrefixText = FakeWrapperMessage.PrefixText
final.Text = FakeWrapperMessage.Text
return final
end
Result:
This is in contrast to how the legacy chat system worked, with SetExtraData
.
Two days ago I created a module to handle this issue, such that it allows the developer to add multiple OnIncomingMessage
callbacks, with levels of priority for each.
Code (client):
local ChatInterceptor = require(game:GetService("ReplicatedStorage"):WaitForChild("TextChatService.OnIncomingMessage Wrapper"))
ChatInterceptor:AddCallback("Add Tag", function(TextChatMessage)
local taggedMsg = Instance.new("TextChatMessageProperties")
local newTag = string.format("<font color=\"rgb(255, 0, 0)\" weight=\"heavy\">%s</font>", "Leader")
taggedMsg.PrefixText = string.format("%s %s", newTag, TextChatMessage.PrefixText)
taggedMsg.Text = TextChatMessage.Text
return taggedMsg
end)
local AddTagPriority = ChatInterceptor:GetCallbackPriority("Add Tag")
ChatInterceptor:AddCallback("Capitalize Name", function(TextChatMessage)
local new = Instance.new("TextChatMessageProperties")
new.PrefixText = string.upper(TextChatMessage.PrefixText)
new.Text = TextChatMessage.Text
return new
end, AddTagPriority)
-- putting the priority argument here makes this callback get run higher (earlier) than the "Add Tag" callback
-- the "Add Tag" callback's priority then gets pushed down, making it get run after
-- this way the name gets capitalized before adding the lowercase tag
-- if AddTagPriority was nil, then the priority argument would be blank according to the wrapper module
local rnd = Random.new()
ChatInterceptor:AddCallback("Color Text", function(TextChatMessage)
local coloredMsg = Instance.new("TextChatMessageProperties")
coloredMsg.PrefixText = TextChatMessage.PrefixText
local color = Color3.new(rnd:NextNumber(), rnd:NextNumber(), rnd:NextNumber())
coloredMsg.Text = string.format("<font color=\"rgb(%i, %i, %i)\">%s</font>", color.R*255, color.G*255, color.B*255, TextChatMessage.Text)
return coloredMsg
end)
-- leaving the priority argument blank puts the priority as the latest possible
Result:
The reason this is useful is that the callbacks can be added in totally separate scripts, running in parallel, which themselves don’t even reference each other nor are they referenced by a single master script. The wrapper module can be thought of as a master script, but references are made to it from the places using it, and not the other way around.
I wanted to know if there was a plan to support the “multiple callbacks” functionality natively within TextChatService
.
One minor annoyance is that OnIncomingMessage
fires twice when then LocalPlayer
chats:
As you can see here, the text color changes on Player2’s messages because he is the LocalPlayer
, and so a random color is selected again on the second function call.
Thanks, unfortunately this isn’t quite granular enough for my need. I would like the Chat Window to be aligned in the top left, as it is by default, but offset by a bit, moved downwards (preferably using a UDim2). Is this possible?
I have a number of feedback points to give about the new system.
a)
It would be very useful for me if there were a way to mute people in the chats. Many admin scripts come with mute commands that stop players from being able to speak until they are unmuted by an admin. This is very, very useful in group event situations. The admin program I use’s mute command currently does not work with the new TextChatService. Not being able to mute players during group event situations is a big detrimental factor when it comes to adopting the new system.
b)
Bubble chats seem to be plagued with bugs, right now. They don’t seem to fade away like the old system and they seem to frequently be placed so low that you can barely read it. I will provide an image of this happening below:
c)
WidthScale on ChatWindowConfiguration does not seem to do anything beyond values of 1. This is an issue for me I would like to edit the new chat window to look more like the LegacyChatService window. You see, this is another large hinderance to my adoption of the new system. I simply prefer the LegacyChatService window over the new chat service window. As the new chat window is much skinnier than the LegacyChatService window, it would be nice if I would make it wider so that it can be more in line with the old window. I assume this is simply a bug.
d)
Continuing with that point, I would like it very much if the new chat window could have an editable “UICorner” like the bubble chats do. I would like to make the new chat window’s corners into sharp corners, rather than the rounded edges it has now, but adding a UICorner object into the ChatWindowConfiguration object does not seem to affect it.
e)
I would like it if the “TextChatService:SystemMessage()” trigger could be used from the server. I simply do not understand why that is not allowed right now. I have read it is because some users may not be allowed to see what is in the system message whereas others may, but I believe that individual users should be made to properly set their games up to account for this. In my case, on the old chat system I display a simple message that so and so team has captured a point when that point is captured. In the new system I have to set up a remote event that fires for all clients whenever the said point changes hands. I just think it would be easier and makes more sense to allow system messages to be sent by server scripts.
Thanks