mIRC Home    About    Download    Register    News    Help

Topic Options
#257381 - 03/04/16 03:39 PM v7.44.54 /vmsg does not work when voiced.
KindOne Offline
Fjord artisan

Registered: 23/02/11
Posts: 310
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?

Top
#257386 - 03/04/16 07:46 PM Re: v7.44.54 /vmsg does not work when voiced. [Re: KindOne]
Zmodem Offline
Babel fish

Registered: 10/12/02
Posts: 86
Loc: California, USA
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


Edited by Zmodem (03/04/16 07:49 PM)
_________________________
-Zmodem

Top
#257394 - 04/04/16 08:59 AM Re: v7.44.54 /vmsg does not work when voiced. [Re: KindOne]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
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.

Top
#257395 - 04/04/16 10:13 AM Re: v7.44.54 /vmsg does not work when voiced. [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 832
Loc: The Netherlands
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

Top
#257423 - 06/04/16 09:22 AM Re: v7.44.54 /vmsg does not work when voiced. [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
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.

Top
#257426 - 06/04/16 11:55 AM Re: v7.44.54 /vmsg does not work when voiced. [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 832
Loc: The Netherlands
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

Top
#257462 - 12/04/16 07:43 AM Re: v7.44.54 /vmsg does not work when voiced. [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
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.

Top