View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005137 | unreal | ircd | public | 2018-08-29 18:34 | 2018-09-10 18:11 |
| Reporter | Gottem | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0005137: Extended/combined user/chanmodes/etc | ||||
| Description | I couldn't find a report describing this feature by searching for relevant terms, so here we go. :> Since my modules repo just keeps on growing, we're starting to run out of mode flags (especially chmodes). I don't know if there's an official spec and Google has been exceptionally shit with returning relevant results, but something like +x:y could work I guess? No idea how services would handle it in regards to MLOCKs and the like though. Now, for my modules implementing _channel_ modes I could hack something like +g y, where y is specific to a certain module. It would be dirty as hell but should work as a temporary workaround. However, user modes don't take parameters (+s being a notable exception) so the hack wouldn't fly there. FYI: The currently _available_ chmodes are only +EWwXxYy. :D | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Wow, you really have so many channel mode modules? :D Anyway, to be honest I don't think something like this will happen, simply because there's no urgent need for most people (say 99% of the networks out there). Well, that, and because IRC is quite conservative and only changes if it's really necessary (and even then.. often not :D)... not to mention it takes many many years... I don't think it's feasible. I'm sure there's some ircv3 discussion on the subject, but... :p With UnrealIRCd 4 we cut the number of channel modes down a bit: 1) We removed the "admin only" channel mode. We only left +O and offered an extban (or invex) for operclasses instead. 2) We removed channel mode +j and made it a configuration option. Simply because it wasn't really needed to configure such values individually for each channels. 3) I was going to list more until I realized those were 8 user modes we removed, not channel modes :D So, suggestions: * Check if a channel mode is really needed, or if it can just be a configuration option effective for all channels * Consider grouping similar channel modes into one channel mode that accepts a parameter. * Consider moving functionality from channel modes to extbans Of course, the grouping (or moving) needs to make sense.. things should still be logical. |
|
|
Still wondering how you got so many channel modes though. At UnrealIRCd we use 36 and there are 52 available (26*2). So.. do you really have 52-36=16 channel modes in your 3rd party modules? Ok, you said 7 were still available, so you "only" used 9. That's not so bad? Even then, how realistic is it that people load all of these.. EDIT: Updated counts, forgot vhoaq since these are unlisted in CHANMODES= |
|
|
On a side note, I recall a discussion with codemastr about 15 years ago, with a talk about adding the numbers (0-9), which gives another 10 options. Still, I think that's a bit over the top, potentially confusing, not really willing to go that route ;) In short, see above about future and suggestions and the "not much of a problem right now" ;) |
|
|
Yeah I know IRC is pretty conservative, which is why I was wondering about there being a spec for this (draft or nah). :> Also I pretty much do need the modules as a channel mode, as the features they implement should really be done on a per-channel basis. They mostly add restrictions like rejoin delay after a kick, being unable to speak for X seconds after joining, no mass highlighting, etc. For all of them there are various scenarios where you would not want a certain restriction (or not a globally set value), so doing it from unrealircd.conf won't quite work. ;_; I don't think moving the chmodes to extbans would make a lot of sense either, so I guess that leaves the grouping thing. I doubt Unreal will let me call CmodeAdd() with the same flag from multiple modules, would it? :D Then I could do what I wrote in the OP and have module A check for +g a and module B for +g b, which should be fairly doable from the conv_param function (and would give me 52 flags to mess with). Otherwise I'll have to merge everything implementing the same hook into one module (e.g. kick join delay + join speak delay). And having "only" 9 custom chmodes isn't so bad indeed, but you know how fast it can grow. =] I also know the chances of all modules being loaded simultaneously is pretty damn small, but to prevent *any* chance for conflicts I want to make sure every module has its own flags. :> |
|
|
Understood :) As for the conv_param etc.. with the current system: no. But I also don't think that will really work in general. I mean... one module may expect a format like "x" and another one "x:y"... and even if they are compatible with "a" and "b" then maybe you want "ab" (both to be set) etc? But conv_param let's you prepare one simple param and not... well..... you get the idea/problem :D I don't think adding that sort of thing is worth the hassle. |
|
|
Yeah looks like I'm pretty much screwed with the multiple CmodeAdd() approach. :D It would be very hacky anyways sooooooo I also thought of a possible 4th option, but it would probably be hard to keep track of by chanops/owners (for starters). What's your opinion on: * Instead of /mode #chan +j 20 (to activate m_kickjoindelay) you do /kickjoindelay #somechan 20 With this there's no immediate way for chanops to see which of my modules are acting on their channel. They would need to run /kickjoindelay #somechan without a param and I could return ON/OFF or whatever. Or have all modules hook into stats X (as in TBD, not literally /stats X ;]), check sptr's channel memberships and optionally access levels and return information accordingly. Unfortunately all of stats G/g, O/o, T/t, E/e and M/m are already taken so would it be possible to use an int like 3 (as in 3rd party)? :D Besides above issues, services wouldn't be able to MLOCK it since there's no actual mode flag. It would also mean a ton of additional ModData being stored to keep track of the status per channel. As I said it's not a problem just yet, just trying to future-proof my shit before we're actually _past_ the point of no more flags. |
|
|
Yeah to be honest, that's not something I would want to go to :D (It would be similar to PROP on IRCX by the way) Right now there's no problem and it's purely theoretical.. I don't think we need to give it much more thought :) EDIT: Ok, I should speak for myself only: I'm not going to give it much more thought :D |
|
|
Yeah nah, I'm not going to spend more brainwaves on this either. :D I know of a viable fix should it actually become a problem. Thanks for thinking along. =] |
|
|
Sure :) Also, it seems the idea is even on this bugtracker (I know, hard to find between the other 199 suggestions here..): 0004116 Note that this won't be done anymore by me, so not sure if I should keep that one open, but.. ah well.. ;p |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-08-29 18:34 | Gottem | New Issue | |
| 2018-09-06 21:32 | syzop | Note Added: 0020277 | |
| 2018-09-06 21:38 | syzop | Note Added: 0020279 | |
| 2018-09-06 21:39 | syzop | Note Edited: 0020279 | |
| 2018-09-06 21:40 | syzop | Note Edited: 0020279 | |
| 2018-09-06 21:41 | syzop | Note Edited: 0020279 | |
| 2018-09-06 21:44 | syzop | Note Added: 0020280 | |
| 2018-09-06 22:12 | Gottem | Note Added: 0020281 | |
| 2018-09-07 12:24 | syzop | Note Added: 0020290 | |
| 2018-09-07 12:25 | syzop | Note Edited: 0020290 | |
| 2018-09-07 18:20 | Gottem | Note Added: 0020291 | |
| 2018-09-07 19:01 | syzop | Note Added: 0020292 | |
| 2018-09-07 19:01 | syzop | Note Edited: 0020292 | |
| 2018-09-07 19:49 | Gottem | Note Added: 0020293 | |
| 2018-09-10 18:11 | syzop | Assigned To | => syzop |
| 2018-09-10 18:11 | syzop | Status | new => closed |
| 2018-09-10 18:11 | syzop | Resolution | open => no change required |
| 2018-09-10 18:11 | syzop | Note Added: 0020319 |
