So just a quick update, the web request limit is 1000 requests per minute per instance (which is similar to the previous filterstring function).
This does not mean that you can only call FilterStringAsync 1000 times per minute, but that, with correctly implemented code, you should be able to handle 1000 custom chat messages per minute (see my last post a few posts above for more details).
If you run into that limit regularly for your game (you’ll be seeing a friendly red 503 Please try again later error) please let me know
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.
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.
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.
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.
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.
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?
(Except it caches X source-message combinations)
