You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is not about introducing an actual profanity filter to RSProt, but rather supporting showing different overhead chat on players depending on if they have a profanity filter enabled or not!
As it stands, RSProt does not offer a way for one to show a different overhead string depending on their profanity filter settings. The overhead chat people see must be identical between all of them, which is a problem for anyone wanting to implement a non-forced filter that depends on the player's own settings.
We need to allow passing two overhead chats to the chat() function, one for players who have profanity filter enabled, and one for those who do not have it enabled. RSProt should then precalculate both variants of the buffer once, regardless of how many players are observing that. We should make sure to avoid calculating these buffers on demand as they use Huffman encoding and it isn't as cheap to execute as say, hits.
In addition to the two strings passed into the function, we need a 'profanityFilter' boolean on avatars that informs RSProt which variant of the encoded buffer to send for this player.
The text was updated successfully, but these errors were encountered:
Note
This issue is not about introducing an actual profanity filter to RSProt, but rather supporting showing different overhead chat on players depending on if they have a profanity filter enabled or not!
As it stands, RSProt does not offer a way for one to show a different overhead string depending on their profanity filter settings. The overhead chat people see must be identical between all of them, which is a problem for anyone wanting to implement a non-forced filter that depends on the player's own settings.
We need to allow passing two overhead chats to the chat() function, one for players who have profanity filter enabled, and one for those who do not have it enabled. RSProt should then precalculate both variants of the buffer once, regardless of how many players are observing that. We should make sure to avoid calculating these buffers on demand as they use Huffman encoding and it isn't as cheap to execute as say, hits.
In addition to the two strings passed into the function, we need a 'profanityFilter' boolean on avatars that informs RSProt which variant of the encoded buffer to send for this player.
The text was updated successfully, but these errors were encountered: