boop
There’s a subtle difference, re-read Tomarty’s post. Basically, he’s sending all requests before one of them returns. It’s a different situation.
1 Like
It should be fine. All Lua code is running sequentially in a single thread, so you don’t need to worry about any race conditions. You can time it to see if there are any abnormalities.
Edit: this is incorrect
This isn’t true. Lua threads aren’t real threads but if one lua thread yields the other ones will continue running. So lua thread A could be the first caller, but if tomarty has another lua thread B that makes the same call before A’s call finishes then it would make two separate requests if it doesn’t recognize that it has one already pending.
1 Like
Looking at it carefully, you’re actually right.
Doing lua threads with the same message and source you can potentially get a bunch of duplicate requests since it only caches it once it arrives.
Don’t do lua threads for this, or do a thread for every unique (message and source) combination.
Considering this is used for custom chats, I would argue that 80% of the time this function will be called in a loop over all players.
For that reason, maybe it would be an idea to add a function “FilterStringForAllAsync(String msg, Player src)” (or something like that) that will return a table of messages for every player in the game. Internally you know exactly which messages to send a request for and which are cached, and then you can send those requests in parallel so that the overall time it takes to complete would be lower than if we put it in a loop ourselves.
Alternatively it could take the message, the source player, and a list of players as the third argument. Then you can also use it for party/team chats in-game etc.
Maybe this function could remain the same, but have a cache that lasts a few seconds, which caches the exact string for both age groups.
From what spotco said I assume it already does this:
That’s the whole point of this function already… 
(Except it caches X source-message combinations)
This started giving me tons of errors this night.
Worked flawlessly for like a week and now it spams:
1 Like
ROBLOX servers have been acting up the past couple of days: datastore requests taking up to a minute to return (or not at all), HTTP errors, server lists not loading on the website, games with players showing “0 players” on the website, etc. Not sure it’s an issue with the new chat filtering. Then again, all of this only started happening as soon as the new chat filter was introduced as far as I can tell, so maybe something’s not working as expected.
Edit: Serial ninja strikes again 
1 Like
What’s the scope of the issues? Only the HTTPService or more?
Should be over now.
2 Likes
What was wrong?
I can’t really answer that. 
Hey everyone, we adjusted a setting that should stop the 503 errors from happening. They were caused by a throttle preventing too many chat calls going out from the game instance. Please let us know if you continue to see 503 errors.
I also want to point out that the functions can’t be swapped 1 for 1. You may need to re-work your chat systems for this update. Please refer to the code sample linked in the first post.
Edit: @buildthomas now I know.
I don’t think this is entirely right. You still make the same amount of calls, check the code sample that you referred to. You’re still looping over all receiving players and doing the call for each of those. (Because the call takes 2 players, the source and the receiver)
This is why I suggested above to have another method where you can filter directly for all/a group of players.
For entering RP names: in a billboardgui over their head, do I have to filter it for everyone, every time the person respawns and the billboardgui it put back on their head?
Normally calling it once for each name should be enough.
If for some reason it gets filtered differently afterwards, something’s wrong with the filter.
(pretty sure words aren’t to be filtered one moment and not the other, or the other way around)
4 Likes