View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002235 | unreal | ircd | public | 2004-12-11 13:41 | 2013-05-06 07:28 |
| Reporter | Stealth | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | wont fix | ||
| Summary | 0002235: Channel mode change modification | ||||
| Description | It would be nice to have an option to have Unreal filter out repeated channel mode changes. Example: mode #channel +o-o+o Nick Nick Nick Would be sent to clients as: mode #channel +o Nick This would be a nice option to have in ./Config (-advanced). | ||||
| Tags | cpu used | ||||
| 3rd party modules | |||||
| has duplicate | 0004060 | closed | prevent users from using multimodes that target same nick |
|
|
maybe send a warning message with repeat mode changes? its a great idea, eggies would classify that " mass mode change " as " mass deop " or sumthing and kick when it was allmaybe in fun, it also causes mirc scripts like " anti deop " to go off and send multiple messages to be reopped or even start a ban fight, |
|
|
I've heard that it used to be able to know that the +o-o was a no-op (assuming it was the same nick of course)... *shrug* |
|
|
I don't quite see the need for all the extra processing this involves. And yes, it involves quite a bit. We need to keep a stack of which mode changes have already occurred on which nicks and keep track of which one's cancel out which others. For example, it might not be +o-o codemastr codemastr, maybe it is, +o-o+o-o+oo-o codemastr john jim bill mike frank codemastr. So we'd need to keep a list of what is going on. That's quite a bit of extra memory and CPU usage. |
|
|
Or there's the method the usermode stuff uses (IIRC), which is to store the current flags and then call some function to calculate the real mode changes from that though this means probably about 4+(1*membership) bytes need to be reserved for this (possibly a bit more for flood/key/limit/link :/). *edit* It seems flood/key/limit/link actually aren't part of this (tested it, limit no-op'ing doesn't make anything get sent out) and flood/key/link seem to not be allowed to be set and unset in the same /mode :) . And of course the "binary" modes do this already too, so... :) */edit* |
|
|
Right, and that's quite a bit of memory that I see no reason to waste. For a 4-5 user channel, big deal, but there are channels with hundreds, if not thousands of users in them. That's a lot of memory usage. |
|
|
Hmmm, well you could just store one set of flags for every user seen in the mode change, like if one does +o-o+o-o+oo-o codemastr john jim bill mike frank codemast it would only get flags for codemastr, john, jim, bill, mike, frank. Then the most space you need is 60 bytes (five * max-modes-per-line (you only need one byte for owner/admin/op/halfop/voice status, right? :) plus four for the pointer to the aClient... )). |
|
|
Yes, 60 bytes (though it will probably be more than that because of alignment) is not a lot. However, if we allocate even a single bit that we don't need, it's a waste. I still see no need for this feature. And of course, then there is the next logical step. What if I set +bb *@*.com *@*? Should it then know to get rid of the *@*.com since *@* overrides it? Etc. It just doesn't seem worth the extra processing. |
|
|
Perhaps... unfortunately the alternative isn't very clean (bitmasking *shudder*, but then you'd only have 4 extra bits as opposed to 36... but then how do you keep track of which aClient goes to which 5 bits? Yea, real fun :P ). Also, there is the fact that for <12 user channels you wouldn't need to allocate the whole 12 bytes, but that's probably extra processing in return for only a smidge less memory usage. So I dunno... I guess really it's mostly an "appearance" thing :) and perhaps it may be better that the modes just go out anyway (in case of desynchs, which can be really fun to fix with this :) ). |
|
|
Bump.? |
|
|
limit modes per line to 1 ? |
|
|
Aztek: Hell no. I'd rather see one mode line with many modes, than a screen full of mode lines. |
|
|
This still an issue? IIRC DALnet opted for simply setting the modes once permissions were met without checking if the modes are already set. This is done because some feel it's cheaper (resources wise) to set an already set mode than to parse and check if the mode needs to be set. |
|
|
Personally, I've no intention to spend any resources on this particular request, sorry ;) |
|
|
We should not flatten modes as the current behaviour is actually useful for resolving desynced clients. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-12-11 13:41 | Stealth | New Issue | |
| 2004-12-11 15:09 | White_Magic | Note Added: 0008606 | |
| 2004-12-11 15:54 | aquanight | Note Added: 0008613 | |
| 2004-12-11 16:00 |
|
Note Added: 0008614 | |
| 2004-12-11 16:30 | aquanight | Note Added: 0008615 | |
| 2004-12-11 16:34 | aquanight | Note Edited: 0008615 | |
| 2004-12-12 00:07 |
|
Note Added: 0008622 | |
| 2004-12-12 01:19 | aquanight | Note Added: 0008623 | |
| 2004-12-12 01:20 | aquanight | Note Edited: 0008623 | |
| 2004-12-12 15:11 |
|
Note Added: 0008627 | |
| 2004-12-12 21:29 | aquanight | Note Added: 0008629 | |
| 2007-04-27 06:31 |
|
Note Added: 0013875 | |
| 2007-04-27 06:31 |
|
Status | new => feedback |
| 2008-10-08 00:52 | Aztek | Note Added: 0015407 | |
| 2008-10-13 04:54 | Shining Phoenix | Note Added: 0015408 | |
| 2009-11-15 03:18 | jnwz | Tag Attached: cpu used | |
| 2011-12-04 00:31 | Stealth | Relationship added | has duplicate 0004060 |
| 2011-12-09 00:05 | katsklaw | Note Added: 0016808 | |
| 2012-01-22 16:58 | syzop | Note Added: 0016890 | |
| 2012-02-26 21:41 | syzop | Priority | normal => low |
| 2012-02-26 21:41 | syzop | Status | feedback => new |
| 2013-05-06 07:28 |
|
Note Added: 0017501 | |
| 2013-05-06 07:28 |
|
Status | new => resolved |
| 2013-05-06 07:28 |
|
Resolution | open => wont fix |
| 2013-05-06 07:28 |
|
Assigned To | => nenolod |
