View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003362 | unreal | ircd | public | 2007-05-25 07:38 | 2015-07-23 22:40 |
| Reporter | Shining Phoenix | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.6 | ||||
| Summary | 0003362: A new channel mode | ||||
| Description | 1. I'm sure you have seen bots that do +l whatever whenever someone enters and leaves the channel. And you've seen it screw up(or appear to?) when netsplits occur. 2. Channel mode f .vs. modes CmMiRKN: You could leave those modes on all of the time, or use f to only set them when needed. I like using f to have modes set automatically when needed, and unset them too. 3. Join flood protection. i, j and l each have their own advantages and disadvantages, but the +l deal is most effective imo, it's only downside being the * Bot sets mode +l taking up the screen. If we had a mode that does the +l stuff for us, it would not screw up when netsplits occur. Also, we could then add a new action to channel mode f for join floods, where it sets this new mode. The result is that effective, but not too restrictive(i) and not elitist(R), join control can be done automatically only when needed. I'll refer to the new mode as +P for now. /mode <channel> +P <buffer-time>:<buffer-size> buffer-time is time between when someone joins the channel and when the limit is incremented. buffer-size is the gap between the limit and number of people in the channel after buffer-time, hopefully you know what I mean by this. Channel mode f would then get a new action for the j trigger: /mode <channel> +f [<trigger-limit>j#P<buffer-time>:<buffer-size>|<time-to-remove>]:<time-period> There should be a default <buffer-time>:<buffer-size> stored in the IRCd for when someone does: /mode <channel> +f [<trigger-limit>j#P<time-to-remove>]:<time-period> Channel mode f for the win. | ||||
| 3rd party modules | |||||
|
|
The mode itself can be done with a module. However: you can already do +f [<buffer-size>j#i1]:<buffer-time>, there's really no need to have a floating limit like that. As for the +f stuff. We don't need to complicate +f syntax further by making it possible to do stuff with parameter modes. +f syntax is already complicated for the average channel op, let's not make it worse. |
|
|
+f [<buffer-size>j#i1]:<buffer-time> You made one mistake in the above example, should look like this: +f [<buffer-size>j#i<buffer-time>]:<time-period> Which isn't as good as channel mode "P". This... /mode <channel> +f [<trigger-limit>j#P<buffer-time>:<buffer-size>|<time-to-remove>]:<time-period> ...could be changed to... /mode <channel> +f [<trigger-limit>j#P<time-to-remove>]:<time-period> ...which would make the server do... /mode <channel> +P <default-buffer-time>:<default-buffer-size> |
|
|
I think channel mode +f is already good for the joinflood scenario. I like it better than +l since it also protects again join+part floods which +l does not. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-05-25 07:38 | Shining Phoenix | New Issue | |
| 2007-05-25 09:21 | aquanight | Note Added: 0014222 | |
| 2007-05-25 09:23 | aquanight | Status | new => feedback |
| 2007-05-25 22:05 | Shining Phoenix | Note Added: 0014224 | |
| 2015-07-23 22:40 | syzop | Note Added: 0018557 | |
| 2015-07-23 22:40 | syzop | Status | feedback => closed |
| 2015-07-23 22:40 | syzop | Assigned To | => syzop |
| 2015-07-23 22:40 | syzop | Resolution | open => no change required |
