Incarnate asked for suggestions concerning how to prevent spamming of chat channels like 100. I have noticed the limits are setup a bit strangely. 100 has no restrictions while system chat is limited to 1 message every 30 seconds or so.

Chat should be limited according to how wide the chat is broadcast and other factors.

Sector - none
Guild - determined by guild - default 0 seconds
System - 10 seconds
Nation (11) - 15 seconds
Global (100) - 20 seconds

Actual limits will need to be adjusted by the amount of traffic on a channel. A good method would be to track the number of messages per minute in a given channel and increase the delay in direct proportion to that traffic. This would put almost no limit on a channel when it is slow and increase the delay as traffic on the channel increases to insure fair access to the channel without allowing the messages to scoll faster then an average person can read. IRC relay(s), I would suggest be given twice the delay of in-game messages to help prevent non-players from spamming the channel during heated discussions.

I would also like to see the chat box be reworked into a tabbed format to help group messages together and make conversations more readable. Each tab could flash when there is traffic on the channel and the player could select which channel to monitor. one tab could be reserved to display all the messages in order of receipt. A mission text tab should also be reserved.

Rate limiting: We already did this, after release. Almost exactly this. It didn't work out well, I wrote about it recently, here.

Tabs are valid, but have certain UI caveats. Open to more discussion there. We used to actually do something like that, before we implemented the "channel" system.

Tabs would be the most logical, especially when combined with a channel system. Certain tabs would be Sector, System, Guild, Group, Local, Private, Help, and Channel. Everything but Local, Private, Help, and Channel are obvious.

-Local would tie several system channels together, i.e. if I'm in UIT space, I would see all chat from every UIT system and so and so forth with Itani, Serco, and Gray space.

-Private shows only privates messages.

-Help would basically be the current channel 1.

-Channel would be a user defined channel that they monitor and several at that.

Rate limits should be the same as the current channel limit, not including the very limited system rate.

This is just my opinion on the subject and the suggestion could most definitely be flawed.

I think a multi-level vote mute would handle flooding quite nicely. If there were x votes in y minutes (where x and y are fairly small), the player would be rate-limited or muted for a very short period of time (10 minutes or so). If there were 25 in a day (or whatever it is currently), a standard mute would go in to effect.

Another possibility would be to rate-limit on very similar posts. It would be pretty easy to compare the length of a post to its Hamming distance from the previous post and make a determination based on that.

I actually got tabbed chat (with all the tabs you mentioned, Surb) half-working a while ago, but I never finished it. I should get around to it. >.>

Not a rate limit per say..more of a variable feedback mechanism to ensure fair access. Most of the time there should be no delay apparent.

Quick and dirty Example:

Variables:

Timer - Determines frequency of updates
MessageCount - number of messages posted to channel during current time period
ChatDelay - Current number of seconds required between messages
Throttle - Used to regulate Delay, increasing it shortens delay

while timer runs:
(For each message) increment MessageCount

When timer expires:

ChatDelay = MessageCount / throttle

OR:

ChatDelay = rightshift (MessageCount) , Throttle

MessageCount = 0
Reset timer


A shorter timer of say 1 minute will give a very fine grain of control but may over react at times especially when used with shift division. Longer timers will yeild more predictable results but may be slow to react.

Right shifting the message count should be faster then straight division and will create a zero delay when the message count is low however can only adjusted in powers of two so the throttle reacts a bit on the exponetial side.

BTW instead of requiring players to repost the message it could simply be held for the required delay time in a buffer and a simple wait message on players screen to acknowledge the message is being sent.

I made a very quick and dirty plugin demonstrating variable rate-limiting with double punishment for posting similar things twice in a row. In reality, you'd probably want to compare the past several posts, but this gets the point across. Unfortunately, it doesn't seem possible to override SendChat, so I've created the /slowchat command to try it out.

ratelimit.lua

Edit: BSD license; feel free to incorporate this in to the game if it proves useful.

The file "ratelimit.lua" linked above is copyright(c) 2009 Zak Wilson. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Awesome, zak.

don't you like just type /ignore and then 100 gets quieter?

/vote mute works better but we are not discussing YOU...

We are discussing what to do when VO has a lot more players and 100 starts to scroll faster then can be read....

Back on topic:
I am thinking it would be best for the server to accept the message and send back a "message delayed xx seconds" notice so that players dont have to retype very much. It should also hold off any further messages to that channel

Don't do anything. Let 'em scroll. Imposing time limits on how often someone can post is only a temporary solution. The more players we have the more posts will be made. Even if each player posts once in 20 seconds, with 40 players doing it that's 2 messages every second. Not saying that 40 players will post that much, but what about 80? Or 200? It could get messy, and everyone would have time restrictions. The tabs idea is good. We could have a pop-up screen for general chat for people who log on just to run they mouths :/, a role play chan for people who want to immerse themselves in the environment, etc.

READ!.... its a dynamic throttle.... it only will kick in when the chat is overloaded...

Ok. With 200 players chatting, chat will be overloaded.