I’ve noticed the size of the chat frame is smaller than how it was in the Legacy Chat when following these steps:
Here’s a comparison:
I found that it’s caused by the system using DefaultWindowSizeDesktop from the ChatSettings module. With normal Legacy Chat, it does not use it for some reason.
Also, this works whenever TextChatService.ChatVersion is set to LegacyChatService. Is this intentional?
This is a bug I’ve fixed in my old thread:
I’m not quite sure what the correct size would be if you want to have the exact size of the LegacyChat. I think that bug was inconsistent, and so the size was inconsistent, but I am not sure (I went on a game that still used the LegacyChat, and got the DesktopSize). You can try to set DefaultWindowSizeDesktop to be the same as DefaultWindowSizeTablet
I have tried setting TextChatService.ChatVersion to LegacyChatService, and disabled Chat.LoadDefaultChat, and I get this error:
TextChatService is not enabled. Check TextChatService.ChatVersion and make sure it is not set as ChatVersion.LegacyChatService.
If I don’t disable Chat.LoadDefaultChat, I don’t get any errors, but every chat message seem to go through LegacyChat. The two are using the same EventFolder, and my guess is that the LegacyChat ends up taking over the CallbackFunction for the RemoteFunctions, making it so the custom Lua chat system isn’t throwing an error?
Fixed minor bugs, and added some features including (see section v1.2 for full list):
– Types! No more guessing if a method takes in the name of a speaker, or the speaker object itself. These types are applied to ChatService, ChatChannels, and Speaker by default, but are also available from the main Chat module
Note that the types do not include Internal functions, those that start with Internal
– Channel.CanJoinFunction and Channel.CanLeaveFunction, for more control over whom can join a channel, instead of a boolean that acts upon every single speaker
– Chat:GetChatService(), a more practical way to get ChatService
Here is a little code snipped for creating an admin channel, using some of the new features:
local Chat = require(game.ReplicatedStorage.Chat)
local ChatService = Chat:GetChatService() -- New v1.2 method to get ChatService, from Chat
local function CanJoinFunction(Speaker : Chat.Speaker)
local Player = Speaker:GetPlayer()
if not Player then return false end
-- This could be modified to check if a player is in a group
if not Player:GetAttribute("Admin") then return false end
return true
end
local Channel = ChatService:AddChannel("Admin", false)
Channel.Private = true
Channel.CanJoinFunction = CanJoinFunction -- New property of Channel for complex join conditions
Channel.Leavable = true
Channel.WelcomeMessage = "This is a private channel for Admins"
ChatService.SpeakerAdded:Connect(function(SpeakerName : string)
local Speaker = ChatService:GetSpeaker(SpeakerName)
local Player = Speaker:GetPlayer()
if not Player then return end -- A non-player speaker
-- Do an initial check to see if the speaker can join the channel
-- Joinable/CanJoinFunction (and the ones for leaving) is only for /j, /join and /l or /leave
if CanJoinFunction(Speaker) then
Speaker:JoinChannel("Admin")
end
-- Automatically join and leave the channel as the attribute changes
Player:GetAttributeChangedSignal("Admin"):Connect(function()
if not Speaker:IsInChannel("Admin") then
if not CanJoinFunction(Speaker) then return end
Speaker:LeaveChannel("Admin")
else
if CanJoinFunction(Speaker) then return end
Speaker:SendSystemMessage("You've been kicked from the Admin channel as you are no longer an admin", "System")
Speaker:LeaveChannel("Admin")
end
end)
end)
Does anyone know if my fork suffers from the same performance issues that plagues TextChatService?
TextChatService’s ui is disabled, but I’ve heard people say that disabling the ui doesn’t fix the lag issue. I’ve also heard that the performance issues only arise after some time (probably after a lot of messages have been sent). Has anyone used this fork in a game that has many players, or tested it in a server with many players?
My own game doesn’t have enough players for me to test this I don’t think, although there is one game, that isn’t mine but I’ve done some small things for, where I could update the chat to the forked version, and I might do that
Your input is appreciated :D
Love this! However, one issue. When I try to use :DisplaySystemMessage() I get an error saying:
ReplicatedStorage.Chat.ChatScript.ChatMain.TextChatServiceWrapper:44: table index is nil
Below is the script I tried using:
local function sysMsg(message)
TextChatService.TextChannels_PortedChat.System:DisplaySystemMessage(message)
end
sysMsg("Hello!")
Thanks for making this port!
My port of the Lua chat system doesn’t support calling the TextChannels directly, although you can destroy them to remove a Channel or Speaker
Supporting a direct call to TextChannels is not something I currently plan on adding
On the server, you can get the speaker from
ChatService:GetSpeaker(Player.Name), and then use Speaker:SendSystemMessage(message : string, channel : string?)
On the client I am not too sure, I know the client can send system messages to itself (the methods are in ChatMain I believe), but I don’t know if they can be accessed from outside scripts
You can use the StarterGui:SetCore(forgot the arguments) method to send system messages from the client, that one still works
I also haven’t added types for ChatMain on the client. This is something I’ll have to look into
I’ve tested the performance of both chats, and it’s actually very easy to replicate. ExperienceChatMain will be active when a message is sent. I don’t think it gets worse as more messages are added, although I did not test it after a while and just base this assumption on the fact it’s slow from the first message you send
However, I’ve also seen ExperienceChatMain take up a lot of cpu time when LegacyChat was being used, so it is possible that both LegacyChat and TextChatService suffer from performance issue. I do not know by how much this issue is exacerbated on TextChatService (assuming it is worse on TextChatService)
The default UI seems the same
Also, Topbar is another trouble maker, and seems to also cause lag spikes when a player chats, or shortly after?
Then you have PlayerListManager also taking several miliseconds…
I dunno if this is a known issue or if it’s just happening to me, but when I type the & key, after sending the message it turns into &, even if I was only trying to send the symbol (&)
It’s probably due to TextChatService replacing some symbols into other characters.
Quite annoying to be honest.
Interesting, seems like the reason is @Sun_Battery23238’s answer
I could probably match and replace it when the message is received, perhaps by marking & and others with one of the disallowed whitespace characters of the legacy chat, to mark those characters (or just assume people wont write & themselves and replace it directly)
i just janked the module to response to .chatted functionality while you chat on system (also overwriten the bubble chat with ‘…’ for privaciyer)
i added a fixer for it æææææææææææææææææææææ (useless æ filler)
thank you for this imformation i will add dis-
This is really cool, though one question. are you able to make it so you cant see the chat history?
Chat history is disabled by default
How to customize Lua chat to only show chat bar, and not chat window? - #8 by TheGamer101
You can do so my changing these two settings inside of the ChatSettings module
--- Replace with true/false to force the chat type. Otherwise this will default to the setting on the website.
module.BubbleChatEnabled = true -- PlayersService.BubbleChat
module.ClassicChatEnabled = false -- PlayersService.ClassicChat
Not very intuitive setting though…
Chat history is using the old text filtering api, which wont be allowed past april 30th
By default it is disabled, it can be enabled in the FFlags module
TextChatService doesn’t have any api to store the chat history, meaning it’s impossible to do so without breaking the ToS or whatever terms (without some extremely impractical workaround like making players resend messages for people who just joined)
Unless chat history doesn’t count as a chat, but I heavily doubt that
Just to tag on about chat history here - we don’t really have a true chat history per-se, more just a log of messages the player has been there to observe since connecting.
A chat history like how IRC channels work is totally possible for the lifetime of the server, however, it’s a cause for a security concern, memory usage concern and/or an overwhelming of a player’s network connection. I considered adding Chat History to WinryChat because it’s something I was used to, but there’s a few issues with the implementation of this feature that I’ve considered.
I am absolutely sure ROBLOX’s staff have done their best to find a way to handle this properly - they likely did it before, and they’ll likely do it again because they’ve got an all-star team of computer scientists behind them.
Feel free to correct or question everything here, I’m just presenting things as if they’re worst-case scenarios, not everyday concerns. This is me overthinking the entire problem for the sake of making sure there’s a record of this somewhere.
These are problems which, while considerations, aren’t exactly major issues. This section is just here to go “this would be a worst case scenario - i hope we never run into it” and provide a preamble to a generally workable solution.
Constant 1. We have to somehow verify the receiving player’s device has enough memory to handle all messages. (We can’t, we aren’t allowed low-level access to devices).
Constant 2. We have to pace the creation of messages accordingly so that the receiving player’s device doesn’t freeze or stutter. (Processing Speed of a CPU).
Constant 3. We have to account for if the player has a bandwidth weaker than 8 Megabits (8Mb/s) This is not uncommon on 3G and 4G networks on mobile devices in countries with access to ROBLOX and while we can get away with 4-8 mb/s, we should really try make it as least impactful on the player’s network as possible. (Networking & Resources Concern)
ROBLOX is a game that should be able to run on a variety of devices. Whether it runs well on some… well, that’s another topic for others to delve into. If you’re making a static environment that doesn’t have any major scripting outside of the chat system, then this really shouldn’t be a worry. This is likely only a concern for games that are REALLY hammering a player’s device.
We are talking in the kilobytes of storage for TextLabels (and buttons for whispers for each user-name) for each message at most. 1-2kb maximum. A message alone isn’t enough for us to worry about on most experiences, it’s an insignificant transient object for the lifetime of the application. But we’ve got a resource to worry about - Device Memory (RAM).
RAM is admittedly only a concern if we’re creating and storing thousands, of message frames on the client. It’s entirely possible for a message log to meet 50MB on it’s own if a server has lasted long enough (social games can no doubt hit this if a server lives long enough). We can minimize this by say using numerical tables instead to associate words to numbers or hexadecimal keys, but that itself is an engineering effort all of it’s own.
Memory Usage on it’s own is fine. Everything we do uses memory in the ROBLOX engine. How much depends on how many things we’re doing. Just food for thought on the general problem of memory management. For developers like myself and Chilly, we absolutely should consider the resource costs (Processing, Rendering & Memory Usage) of our UI, players’ messages & any intermediary content/objects. For a Chat History feature, it’s a foundational concern… even if an excessive one when we’re dealing in mere kilobytes.
As for pacing message creation - not all CPUs are made equally. Android and iOS devices are especially known for having some really powerful, and really power-efficient, CPUs that can push through a lot nowadays. That said, ROBLOX still supports (even if only partly), old models powered by old ARM Chipsets. Most, if not all, are multi-core 1.0-1.6GHz chips with performance and efficiency cores. That being the case… then Parallel Luau would be wonderful for this type of heavy-compute task.. But it doesn’t support parallel object creation - dangit!
So we’re stuck in serial processing for the creation of messages - the bulk of our workload. We’d need to make it so that messages are created either when the player scrolls up far enough, or so that messages are created in bursts until all are created. Realistically, we’d cache the data for when it is needed, and load messages in chunks because we really do not want to be hogging memory from a user’s device for something they’ll never read.
Lastly for networking bandwidth, we can’t just send a bunch of messages at once nor can we send them in measured bursts until the player client reports that it has all messages. Well… we can, but it won’t be pretty for some users. We’d be doing the burst method of say 16 messages after the user scrolls up some point.
Our solution is to then only send what the player requests, not what we think they will want to see immediately. There are tons of ISPs and Mobile Carriers that cap data for a mobile/wired contract, cap bandwidth speeds and so much more around the world. It’s irresponsible of us to be sending needless data to players that may already struggle to enjoy life on the internet. No resource is truly free and everything has a cost at the end of the day.
Now onto the bad method…
This is the first interpretation that came to mind from:
The major issues with this come straight away in the method header.
You rely on one or more players to broadcast the contents of their chat history to the server, and have the server broadcast to the new player.
You trust the output of each player or filter each message description again as a precaution.
One or more players already on the server and the new player joining expend bandwidth to send and retrieve the history.
By doing peer-to-peer replication of chat history, you essentially have to verify who has longest lifetime on the server (or the most complete message history). Or you could do it at complete random and end up trying to get history parity with a person who only joined moments before the new player did.
If you want to get someone with the most complete message history, you’ll have to filter through all players through some (admittedly menial) back and forth communication. Then that player has to asynchronously send a bunch of packets to the server for all messages.
If you want to get someone at random then you may get someone with an incomplete message history who has also just joined the server. In which case, their incomplete message history is used as a template for the new player. You can try resolve this by attempting to pace the replication of messages to match or be slower than that of the other player (a complete fools errand for many reasons) or break away with new player not being able to see the full chat history.
Once you have your player to replicate from, then comes the replication itself. Do you want to trust that player’s log as a source of truth? Absolutely not! Players can still use easy-to-access tools to modify objects, and although it’s not worth the hassle to modify message logs, it can still be done. Instead, we’ll likely need to filter again… but what with? Messages from some players may not even be able to be refiltered because that player already left the game, which is, at the time of writing, a limitation of TextService.FilterStringAsync.
We can just bypass filtering altogether, trust the source and deliver previously filtered messages as a “trusted resouce”… but- oh noes… We may break ToS! We can’t verify if any (or all) given messages are safe or appropriate for all ages - which is why we’re in this mess of a new chat system migration to begin with.
In this case, we’re instigating the issues of two of the constants potentially twice. We’re going to possibly make two households with poor connections struggle. We’d using bandwidth for data we really don’t need to use to make this feature work for no good reason. We’d also be increasing the processing power (and power draw) for two or more devices at once… that’s really not good.
Of course, no one in their right mind should chose this option. Needless risk for no meaningful gain.
This is the second interpretation of the following quote:
This is more about having players store a log of every message they sent since they joined from within their Chat UI (this is really the only place they can store the raw string).
However, we’ve got three major issues:
We’re flooding chat with messages we don’t need to for each player.
If a player leaves during this process, or left before this process, while another user they were having a conversation with still remains on the server… we’re sending half of a conversation (if that) to the recieving player.
The first issue is that this solution would affect all players’ Chats. You won’t be whispering the messages to one player, you’ll be outright flooding chat with every conversation each player had since they first joined that server. Not only would you wash out players’ current conversations, you would make it nigh impossible for players to remember what they were talking about. It might even lead to players getting reported for spamming chat (not good at all).
The second issue is that by handling a chat history this way, you are having each player broadcast through a TextChannel again. For each player that is having to rebroadcast their messages, they will very likely be floodchecked because they will likely have more messages than is permitted within the floodcheck restrictions. Even if you find a way around the first issue, this isn’t just bad for the chat experience in general. It’s bad for the player as now they have to wait for the chat system to rebroadcast everything between floodchecking periods. They won’t be able to have fun or continue socialising with friends.
Lastly, there’s a good chance that players will just leave before or during this process and new players will miss context to things said in chat. We’ve all been there once to enjoy someone who has been spinning a good tale in chat. But if we only have the reactions as the user, and not the story, we might just view the server as full of fake players or bot accounts. And if a player leaves during this process, we’ll have the issue of only partial context. This one’s purely a UX issue, but it’s an integral one on why this can’t work.
This is possible, but the implementation will vary based on the programmer and their experience with networking & data management. If you want to just get things up and running regardless of the server, this should do.
A Server’s lifetime varies. One server may last 4 hours, while another lasts 37 minutes. The amount of text logs generated can also wildly vary, and we can’t guarantee a consistent timing of each message log - though we can get close with the help of DateTime.FromUnixTimestampMillis in exchange for a byte or few.
We’re either making messages visible to all clients, or using a ModuleScript to store all filtered messages.
By doing this, we can get a message history going… we can’t get it going for all players though. We’re effectively making a blanket system and hoping it’s a one-size-fits-all thing. By doing this, we’re also using more server-side resources. Just like our devices, ROBLOX’s servers also have allocated memory for the virtual machines used to run our experiences.
This is completely fine to do if you’re making an error logger that anyone can see in a lobby or a pop-up UI to help report issues. After all, a global server log for this is really helpful. The problem for chat history comes into how do we store them. We can store them in ReplicatedStorage and offload the workload to ROBLOX’s core engine (why?), or in a ModuleScript.
The ReplicatedStorage option is outright terrible for message security and for wasting resources. We’ll be making messages visible to all clients for all channels, even if that player isn’t connected to that channel. We’ll be wasting the resources of every player and the resources of the server at the same time because we’re admittedly being lazy and misusing the intended purpose of ReplicatedStorage (much like people did with Lighting before ReplicatedStorage was a thing).
The ModuleScript option is good, especially for the data sharing properties of ModuleScripts in a thread, but is a complex task. With this method, you’ll need to send the messages to the receiving player(s) for only the channels they’re connected to. When any player joins a channel, they’ll also need the messages. This also means re-sending the same messages if a player leaves, then re-joins a channel.
For there to not be a significant enough impact on server performance, you should be able to make this work with an Actor and Parallel Luau, as this would be a task that’s purely data-driven without Instances. It might even be a good use-case for a SharedTable, though someone correct me if I’m wrong there.
As for the consistent timing of each message log, this is more of a niche issue. We can use milliseconds to get a pretty good idea of where to place the message in an ordered list. The only problem is there may genuinely be times where two messages are somehow (however unlikely) sent at the same time. That’s nanoseconds apart, really. You may have two separate conversations running on two separate things and if the message order is wrong on one client, then it’ll look strange.
Needless to say, the ModuleScript option is more desirable because we’ll be able to manage how messages are sent, who they’re sent to and how they’re organized. Just at the cost of server memory.
If I were to approach this for a project, the main components I’d look at are:
Parallel Luau & Multi-threading for asynchronous processing & sharing of chat history on request
A SharedTable or ModuleScript containing all the messages ever sent, being logged in real-time, so that we can have one or more actors on the task.
RemoteEvents to faciliate server-client communication explicitly for Message History. We can leave the messages already being sent through TextChatService alone as they’re already being managed just fine.
A way to compress the data as finely as possible to use the least amount of memory with the least data loss.
A Chat UI that can detect when a player is at the top of a channel. That way, we can ask the server for more messages to read if it can. There is a hacky way to do this with an upside down scrolling frame, but I’d try find an approximated way instead.
Of course, there are other ways to do message history that people may come up with - or have come up with. It’s a very complex, technical feature that requires server and client scripting. I personally have no plans to introduce this into WinryChat - it’s client-sided only and is meant to be there so any developer can drop it into their game without any scripting issues. I also have no reason to implement this in any other project right now as there doesn’t appear to be any demand for it.
If you wish to further explore this idea, feel free to… just be warned. Here be dragons.
I have been writing this for 4 hours straight and trying to correct what’s over the top, incorrect, or just unnecessary. But someone will definitely find something later and call me out on it or something. This is an intentional exaggeration of some of the concerns with design & logic so that it’s a bit more clearer on the how and why of a Chat History than a “just add it now”.
I’ll also probably regret going on a tangent, so uh- yeah thanks for reading and please be kind… I’m very sleepy now.
I’ll go over how the LegacyChat handles the MessageHistoryLog system, it’s quite a simple system, much simpler than your overthinking lol
So, each channel has a chat history table, that is limited to contain 200 messages. Each message also has a limit of 200 characters. The server also wont accept messages that overall use more than 6 bytes per character (if all characters are used. basically limit of 200*6 bytes)
If we assume each message is 200 bytes, and the chat history table is full, that is 40Kb of data. This is in the upper bound of what is acceptable as Kb/s
However, this only happens when the speaker joins a channel
(The client doesn’t display more than 50 messages by default per channel, but still receives 200 messages max)
It is also worth noting that more than just the raw text is sent, the whole MessageObj is sent
{
ID = ID,
FromSpeaker = speaker and speaker.Name or nil, -- Stays nil for system messages
SpeakerDisplayName = speakerDisplayName,
SpeakerUserId = speakerUserId,
OriginalChannel = channelName,
MessageLength = string.len(message),
MessageLengthUtf8 = utf8.len(utf8.nfcnormalize(message)),
MessageType = messageType,
IsFiltered = isFiltered,
Message = isFiltered and message or nil,
ProcessedMessage = nil, -- New key to allow the sending client to get the processed message, to give to TextChannel:SendAsync()
--// These two get set by the new API. The comments are just here
--// to remind readers that they will exist so it's not super
--// confusing if they find them in the code but cannot find them
--// here.
--FilterResult = nil, -- TODO_REMOVE - Still used for message history logs
--IsFilterResult = false, -- TODO_REMOVE
--TranslatedMessage -- This field contains the translated message, but is only set on the client
RecipientUserId = nil, -- UserId of the recipient when in a DirectChat (for wishper basically). I added it for the custom Player.Chatted implementation, but that ended up not working
Time = os.time(),
ExtraData = {},
}
The most intensive part, is probably this function right here:
function methods:GetHistoryLogForSpeaker(speaker)
local userId = -1
local player = speaker:GetPlayer()
if player then
userId = player.UserId
end
local chatlog = {}
for i = 1, #self.ChatHistory do
local logUserId = self.ChatHistory[i].SpeakerUserId
if self:CanCommunicateByUserId(logUserId, userId) then
local messageObj = ShallowCopy(self.ChatHistory[i])
--// Since we're using the new filter API, we need to convert the stored filter result
--// into an actual string message to send to players for their chat history.
--// System messages aren't filtered the same way, so they just have a regular
--// text value in the Message field.
if (messageObj.MessageType == ChatConstants.MessageTypeDefault or messageObj.MessageType == ChatConstants.MessageTypeMeCommand) then
local filterResult = messageObj.FilterResult
if (messageObj.IsFilterResult) then
if (player) then
messageObj.Message = filterResult:GetChatForUserAsync(player.UserId)
else
messageObj.Message = filterResult:GetNonChatStringForBroadcastAsync()
end
else
messageObj.Message = filterResult
end
end
table.insert(chatlog, messageObj)
end
end
return chatlog
end
This function is used to get the HistoryLog for a specific speaker, because roblox filters text differently, for different users. the FilterResult (returned by TextService:FilterStringAsync() when the message is initially filtered) is stored within the MessageObj, and the system uses :GetChatForUserAsync() to get the message to send to specific players
(This is the “newish” filtering api from TextService, I believe it used Chat:FilterStringForBroadcast() and Chat:FilterStringAsync() for whisper, in the past)
This means :GetChatForUserAsync() is called like 200 times basically at the same time, and it is an async method suggesting it relays the call to roblox servers? That would be quite ludicrous though, and perhaps they made it smartly, and the filterResult instance contains every possible filtering (ie 13-, 13+, and 17+, maybe some others), so a call to that method would be basically free, but then it wouldn’t be async. Maybe it is async because the first time it is used for a filtered result, it filters it, but caches the result so future requests of the same time are free
Roblox might want to avoid such a heavy load on the backend, by not having a history log, if every single call really is reaching their servers
Now, implementing the history log back using TextChatService is impossible because there is no api such as TextChannel:GetHistoryLog(). Using the same method as the LegacyChat would be against the ToS, and the only solution I’ve thought about that would be possible, would be extremely impractical, for reasons somewhat different to what you’ve stated
I can’t just take the history logs of the clients and broadcast them to other players, that would break the ToS as different players are supposed to have different filtering applied to the messages they see. So the message needs to go through the filter before reaching the newly arrived player. Aka, it needs to go through TextChannel:SendAsync().
Let’s suppose that when a player request the History Log, they ask each sender to resend messages they previously sent (with a limit of 50 perhaps). TextChannel.ShouldDeliverCallback (or the TextChatService equivalent) Would have to be used to prevent the messages from reaching existing players again (well it could be allowed to reach other players, and then compared against previously received messages to avoid duplicated, which can be done and is already done to some extent in LegacyChat for replacing the placeholder message with the filtered messages)
But that has the disadvantage that people using our chat systems cannot use TextChannel.ShouldDeliverCallback without breaking the chats, and TextChannel.ShouldDeliverCallback is tailored towards individuals wanting to customize the sending of messages, and not for custom chat systems to use.
This would be the most practical solution, out of all the solutions I thought about
If roblox could just let us send messages from the server, that would fix so many issues. Then it would be possible to do that step without using ShouldDeliverCallback. But that one is just a small use case of sending messages from the server
(Rant) Because we cannot send messages from the server, it is basically impossible to do custom processing of the message from the server, something that is very much useful. Things like OnIncommingMessage also only works on the server. So if you want to do some custom processing, you have to send the message to the server, process the message, send it back to the client, and then the client can use TextChannel:SendAsync(). This basically adds twice the latency to every chat message, and something I unfortunately had to do for my port
Message flood check would likely be an issue as you’ve stated, and if it was done without ShouldDeliverCallback, then the other TextChatService callbacks would receive duplicates of messages, because I can’t filter duplicates out before that step, which would be an unexpected behaviour I absolutely want to avoid, and would drastically increase network usage as every client would receive the history log when a user joins a channel
As for streaming the message history log, that would be unnecessary as the history log is capped (a very sensical approach considering the chat is very dynamic and old messages are basically irrelevant)
However, that is something I’ve done to some extent in one of my games. I made a backpack system that has an infinity horizontal scrolling frame, and well, using normal scrolling frames ended up causing performance issues, so I ended up, using a custom scrolling frame, making my infinite scrolling frame have I think 11 frames that looped, but displayed different information as they looped, making the whole thing very cheap even with thousands of items
And I ended up using that system as for my games scrolling frames in Game Discovery Hub, where I have lists containing upwards of a thousand games (if I remember correctly). It works wonders
The games aren’t streamed from the server though, but it doesn’t seem necessary to do so, memory usage is not out of the ordinary
Other notes:
– MessageObj contains the timestamp of messages, so message are ordered using that. Since it is on the server, it is centralized, so identical for everyone. Even if it wasn’t, messages sent in close proximity already often aren’t ordered correctly simply because the user sent the message to late. If two messages were sent at about the same timestamp, they were probably not responding to the message that just got sent
– Missing messages from players who left would be a bit annoying, but I think that already happens to some extent with the LegacyChat, although I couldn’t find it in the code and I very well could be wrong. It’s not a major issue though, usually, that happens when the chat went stale for a little while
So at least the messages are efficient, and while I was trying to think of the absolute worst and extreme case scenarios, it is good to know the message logs integrated into the engine for LegacyChat. The ways I thought about it were all about trying to find ways around the filtering issues in general, but each of them are impractical in their own right.
I know that a server chat logging every message for the lifetime of the server (as impractical and resource-wasting as it would be) is entirely possible, but it’s just against ToS is all. If it were possible to have as part of a 17+ Social Hangout, then I think we’d see a practical use for it.
It also has apparently been done in 2023 (in a very hacky, and probably ToS breaking way) here:
i added a return if the metadata is empty and i am not getting a error anymore
So far I’m loving this system. I’d really love to see the planned support for the “BubbleChat” script come out.
Very nice job overall! 