View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001701 | unreal | installing | public | 2004-04-04 09:05 | 2004-04-04 11:43 |
| Reporter | brainbugs | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 3.2-RC2 | ||||
| Summary | 0001701: Enable/disable ExtMode support | ||||
| Description | Would it be possible to add a ./Config option to enable and disable use of the ExtModes such as ~q: and ~r:, in a similar way to how PREFIX_AQ can be enabled and disabled through it? Thanks :-) | ||||
| Steps To Reproduce | N/A | ||||
| Additional Information | N/A | ||||
| 3rd party modules | |||||
|
|
Why would you? There are commands/features that are not widely used. Extended bans is not something you visually see or impares in any way by liking. If you don't want to use it, don't use it. If not they might as well add PREFIX_V just because someone may not like people being voiced. As far as I know prefix bans do not bog the ircd at any level, and comparing 3.2 compiles with those without extended bans would show no difference in performance. My point is, there are many features not widely used. You don't see everyone using /time or /dalinfo. Would not be a valid reason to have a switch for it in ./Config :) Just ignore it. It may come in handy one day. Till then, it won't hunt you down, slow your net, and crash your IRCD :) |
|
|
options are your friend :) in this case, why have prefix_aq? why not tell people just to not use +q and +a? its something thats new, and non-RFC, therefore people may want to disable it to keep with the spec, if they so desire. |
|
|
+q and +a affect the channel as they are visually seen. People can see it in effect, and the effects of a user being +qa'd (protect/higher access) affects the IRC standard (if you can call it that anyhow). Extended bans are shown only when set and unset and do not affect the channel directly, instead work like normal bans. Though I can't argue the RFC fact. Though I'm not entirely sure the team would add something that would break RFC. Even so without good cause. |
|
|
Those #define/#ifdef's/etc of large subsystems are often just ment temporary, it is at least the case with: extended channelmodes, throttling, etc... As for the crap RFC... if you want a 100% RFC ircd then you shouldn't run unrealircd, one example to start with is halfops... that shouldn't be in unreal then either... hell XX options wouldn't have been in unrealircd if we were 100% RFC compatible (that said, there are nearly no 100% RFC ircd out there anyway). Anyway I don't blame you guys for not knowing that, normally RFC support is quite strict, however in the irc(d) world it's a lot different ;). As for banmasks, it's nowhere stated in the RFC how a banmask should look like.. that said, we were of course careful in choosing how to do it and have found 0 (major) clients that had problems. [request rejected, sorry ;p] |
