Forums Bug Reports +j parameters not shown in titlebar

Dunno if anyone noticed but with DALnet's (bahamut) new implementation of +j the parameters (N:N) do not show in the modes of the titlebar. $chan(#).mode also doesn't return them.

Its not just +j On UnrealIRCD theres a +f for flood it shows the +f but not the expanded part like +f[15:30] blah, maybe its just part of mIRC?

I am willing to say that mIRC only displays +k and +l because it was built that way, rather than storing and then displaying what is returned from raw 324.

mIRC is built on the IRC RFC, not specific software, which, to me is common sense, and unless a 'newer' version of the IRC protocol (which i doubt, since the existing one is more than sufficent), is released it shouldnt be added to mIRC.

Doing so would result in alot more work for Khaled, and then you'd have idiots adding random modes, just to be "different", which of course would need to be added to mIRC.

Saying that however, there must be something wrong your side, since, it appears perfectly here..

* Now talking in #eansdkons
* Coolkill sets mode: +j 1:1
Channel Modes: -> +j

Titlebar; mIRC - [#eansdkons [1][+j]]

Eamonn.

Yes but why cant mirc get that mode when you can simply by doing /mode #channel and itll appear to you? mIRC should be able to handle those raw numerics


/mode #scripts
-
#scripts +ntrf [10t]:2
-
Titlebar:+fnrt

Things change, the IRC standard is over a decade old and simple put, lacks the necessities for a changing internet world. We've seen on DALnet various modes being implemented over the years like +M, +R, etc to stop various annoyances from entering channels. Now we have join throttling (which, if i might add, has been present on various other IRCds for much longer) which only improves the service.

1) People need to stop complaining when something is changed. As long as there's a function to turn it off and revert back to the old way many people enjoy then that's fine.
2) Specific channel modes ARE NOT part of the IRC RFC standard. What is standard is CHANMODES=modes-with-entities,modes-without-entities.
3) mIRC should be dynamic. No two IRCds are exactly the same. mIRC is used to connect to IRC, not specific IRCds. Sure not everything can be implemented, but when it is dynamic it can implement such structures itself. How hard would it to base $chan(#).mode and whatnot on the raw 324 as it is then changing its internal value when modes are edited, rather than forcing it to only accept entities of the +l and +k modes alone?

Come on people. Common sense please

/me throws roses

RFC 1459 : Internet Relay Chat Protocol, J. Oikarinen, D.Reed.

4.2.3.1 Channel modes

Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
[<ban mask>]

The MODE command is provided so that channel operators may change the
characteristics of `their' channel. It is also required that servers
be able to change channel modes so that channel operators may be
created.

The various modes available for channels are as follows:

o - give/take channel operator privileges;
p - private channel flag;
s - secret channel flag;
i - invite-only channel flag;
t - topic settable by channel operator only flag;
n - no messages to channel from clients on the outside;
m - moderated channel;
l - set the user limit to channel;
b - set a ban mask to keep users out;
v - give/take the ability to speak on a moderated channel;
k - set a channel key (password).


While I agree, mIRC should be "dynamic" it should not include functionality for something that is not, "cast in stone", for example; +k and +l have specific "spaces" in /channel, as they are defined in the RFC, I see no reason why +f/j should have the same "treatment" when it was simply dreamed up by some "coding team".

Eamonn.

I apologise, I did not see that section. But if you do read the top, the RFC was last revised in 1993. That is over a decade ago. But remember, every single item in that RFC was also dreamed up by a "coding team". The RFC is no longer managed by a single entity, it is controlled by the creators of IRCds. If they did not do that, we wouldn't even be here today.

Times change, and so does the standards IRC are based on. If mIRC doesn't want to be updated every time something new and major is changed in the service it connects to then it should be made to be dynamic.

mIRC isn't the only thing that has had problems with RFCs today, people need to wake up and grasp the fact that things do change and stop hating on them (this is a general reply, not just to you). Giving more service and more choice to users is better than sticking to standards which were made in a world 10 years ago. Just think about it. If everything remained as it was 10 years ago, how different would the Internet actually be today?

Futhermore, I did not say anything about /channel having spaces for them, but now that you bring it up... There is also a button for +I and +e modes (which were just introduced to DALnet as well). These are not in the RFC but were included probably because they were requested. They've been there since the dawn of time, and I've never had a use for them until today.

Bug or not, I see no reason why mIRC shouldn't be changed to display all type C chanmodes' parameters. No mode information has to be hardcoded.