mIRC Home    About    Download    Register    News    Help

Print Thread
v7.44.54 /vmsg does not work when voiced. #257381 03/04/16 02:39 PM
Joined: Feb 2011
Posts: 315
K
KindOne Offline OP
Fjord artisan
OP Offline
Fjord artisan
K
Joined: Feb 2011
Posts: 315
1, Connect to freenode
2, Join a channel
3, Only wearing voice enter "/vmsg foobar"

* /vmsg: must be an op on #channel

/msg +#channel This just works fine.

Should /vmsg work while voiced?

Re: v7.44.54 /vmsg does not work when voiced. [Re: KindOne] #257386 03/04/16 06:46 PM
Joined: Dec 2002
Posts: 86
Zmodem Offline
Babel fish
Offline
Babel fish
Joined: Dec 2002
Posts: 86
This is not a command within mIRC, or any IRCd that I am familiar with. Is this a custom command you have created, or downloaded for yourself?

Update: Alright, so it has been brought to my attention that this command does exist, but only if the server supports it: /vmsg, /vnotice, and /wallvoices. If server does not support STATUSMSG

Last edited by Zmodem; 03/04/16 06:49 PM.

-Zmodem
Re: v7.44.54 /vmsg does not work when voiced. [Re: KindOne] #257394 04/04/16 07:59 AM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
Thanks for your bug report. When I first added support for /omsg, /onotice, and /wallchops, many users asked me to limit their use to ops (due to the potential for spamming), even though they could have been made usable by non-ops (using mIRC's built-in implementation). So, in the same way, I have limited /vmsg, /vnotice, and /wallvoices to ops, under the assumption that these commands are primarily intended to be used by ops for channel management, off-channel user notifications, and so on.

In addition, it is not clear how different IRCds implement these features. For example, do all IRCds that support WALLVOICES allow any user, only + users, or both + and @ users to use it? (and perhaps +h helper users?)

So while I could make /vmsg, /vnotice, and /wallvoices usable by any user, only + users, +@ users (and perhaps +h helpers), or only @ users, I opted for the more conservative option of only @ users.

Re: v7.44.54 /vmsg does not work when voiced. [Re: Khaled] #257395 04/04/16 09:13 AM
Joined: Apr 2004
Posts: 840
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 840
How about mIRC apply its own policy only when the ircd has no native support for the commands? If the ircd does, there is no need for mIRC to know up front what policy the ircd is going to apply, either. And yes, people are using vmsg/vnotice for two-way communication between ops and voiced users in practice.


Saturn, QuakeNet staff
Re: v7.44.54 /vmsg does not work when voiced. [Re: Sat] #257423 06/04/16 08:22 AM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
Quote:
How about mIRC apply its own policy only when the ircd has no native support for the commands

This would also have been possible with /omsg, /onotice, and /wallchops, however users (mainly channel ops) asked for them not to be accessible to non-ops. So while I could do this, the main issue is that it may make abuse of the commands far easier.

This would also make the commands behave differently on different IRCds, which would make them inconsistent?

Just to confirm: is it common for voiced users to use /vmsg/vnotice to send messages to all other voiced users on a channel? Even though it is possible to communicate on the channel? I was assuming that /vmsg/vnotice would be used primarily by ops for off-channel notifications to voiced users.

Re: v7.44.54 /vmsg does not work when voiced. [Re: Khaled] #257426 06/04/16 10:55 AM
Joined: Apr 2004
Posts: 840
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 840
Originally Posted By: Khaled
the main issue is that it may make abuse of the commands far easier.

For mIRC's internal implementation I agree, but with native support, given how easy it generally is to use the native method directly instead, I don't see this as a substantial point.

Quote:
This would also make the commands behave differently on different IRCds, which would make them inconsistent?

Not inconsistent, just less restrictive. Lots of command behave differently across networks in that respect, even e.g. /msg due to ircd-specific channel and user modes.

In general, I don't think it is mIRC's role to artificially restrict ircd-native commands. You could argue that /omsg and /onotice are mIRC's own, but mIRC is in fact already effectively restricting /wallchops right now, since that is also a native ircu command. Given that /wallvoices is a native ircu command, you may even end up breaking people's aliases/scripts by applying a new ops-only restriction (hypothetically, anyway).

Quote:
Just to confirm: is it common for voiced users to use /vmsg/vnotice to send messages to all other voiced users on a channel? Even though it is possible to communicate on the channel?

We use it on EFnet #mirc this way, at least. If you view nothing/voice/ops as status levels, it makes sense for each level to have its own means of this-and-upward level communication. Then again ircu applies no such restrictions for its own wallchops/wallvoices commands, which I think is not a great idea either.

Overall, the whole situation is kind of a mess. I think you'll mainly have to decide what you want the commands to be - a thin layer on top of whatever is available or a tightly controlled standard interface. My vote would be for the former, but if you implement the latter, we can always continue to use the native methods of course.


Saturn, QuakeNet staff
Re: v7.44.54 /vmsg does not work when voiced. [Re: Sat] #257462 12/04/16 06:43 AM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
Quote:
Overall, the whole situation is kind of a mess. I think you'll mainly have to decide what you want the commands to be - a thin layer on top of whatever is available or a tightly controlled standard interface. My vote would be for the former, but if you implement the latter, we can always continue to use the native methods of course.

Thanks for the feedback. I will go ahead with the former in that case, so that the voice-related commands are available to voiced users and higher.