Forums Bug Reports omsg failure

Something unexpected happened, an admin bot visited the channel where my script was present. During remote events, scripted omsg commands got issued but none of the ops who followed that bot in the channel's nick list got any of the messages. After each omsg line in the status window, was a line stating that the bot doesn't accept private messages. Later I turned on debug and used a msg command to message the same bot. The same response text as before came back in a raw 486 line. I didn't find 486 in any of the documentation for raw events. Should one interrupt a omsg command in process? I could loop over the nick list and do msg commands instead of omsg (excluding the bot if he's present) but I'm guessing that would be less efficient and would record excessive info in the status log.

This is not a bug in mIRC. You are sending a PRIVMSG and receiving 486, which is an error message.

Google shows plenty on the 486 numeric:

http://www.mirc.net/forums.php?view=123368
http://www.fyrenet.com/winchat/OPERINFO/IrcNumerics/IRC-2%20Numeric%20List.htm

It means you can't privmsg the user-- the specifics of why should be detailed in the error message from the server (although one page says it is caused by attempting to msg a registered user when you are not-- in this case, the solution is to register your nick). Therefore, mIRC isn't interrupting any message, the server is. In other words, there is nothing mIRC itself can do about this; it's something either you (by registering?) or your script needs to handle.

If you have a question about how to script around a specific server issue, feel free to post in the Scripts & Popups section and ask what you can do to fix it. But please do not post a bug report because of a broken third party script.

Are you saying that mirc did issue the messages for all of the other operators? If it did then I agree with you. If not, then know that the server in question has ids and passwords as its normal registration. I am a moderator/operator in the channel (which is required for using mirc's omsg command). There is no NickServ (although server admins do apparently have some other authentication). So if mirc aborted because of this 486 error, I think it would be useful if the error could be bypassed.

As mentioned, a server error indicates that the server is the issue. Talk to the people running the server and see what they can tell you about what the problem is that you are facing. You cannot bypass a server's error messages in the way that you mean.

Suppose you're in a channel with 3 operators (other than yourself), named user1, user2, and user3. When you type /omsg hey guys, the action that mIRC will actually perform under the hood is /msg user1,user2,user3 hey guys. So basically it's a private message with 3 recipients. If you are not allowed to private message one of those people, my expectation would be that the other two people would still get the message. However, it depends on how the server was designed so we can't say what would happen for certain. In any case, this is completely outside of mIRC's control. mIRC is just passing along the list of recipients to the server, and whether the message is actually delivered to each recipient is completely up to the server. Are you sure that the message is not being received by the other people?

Also, you might consider using /notice @#channel message instead. This is a pretty common way to send messages to operators only, and it works on most (but not all) servers. The advantage of this method is the message will appear inside the channel itself instead of appearing as a private message. I think this would work even if you aren't allowed to private message one of the operators.

Again, mIRC didn't abort anything; the server did-- hence the server's error message. The *server* decided not to deliver your message, not mIRC. I'm not sure how to make it any more clear than that.

As mentioned, if your PRIVMSG included multiple recipients, it's likely the server performs "all or nothing" delivery, which would explain the problem. In this case, there's absolutely nothing you can do except: (a) use another command (/notice @#chan as suggested) or (b) split the /msg into multiple message commands. Alternatively you could talk to server admins and figure out *WHY* you're getting this error for that one user. Again, my guess is you simply need to authenticate with the server the way the other users have in order to message them, but consult the server for the real details on that.

The Bot returned to my room so I just had the opportunity to turn on debug and test the omsg command when it was present. I see now that what is sent (by way of omsg) is only one PRIVMSG with a comma separated list of recipients. So indeed this is not mirc issue. Sorry for the fuss. FWIW, this time the Bot was at the top of the nick list and none of the other recipients got the message. It doesn't seem to be kickable. So I will need to follow up with the host's support. To whoever suggested using Notices instead, I originally tried those first. They don't show up in the host's flash-based irc client (which is what most of members and moderators are using).

Edit: Have now researched with the host's support group and other documentation. The BOT is now banned from the subject channel. However I learned that anyone can set +R mode on themselves after which they will generate the error if PM'ed. The mode is getting casually used by some to "turn off" their pms. There is no provision for anyone to set +r for avoiding such errors if they send a PM to someone with +R, nor is it permitted to to detect usermodes on nicks other than your own (otherwise I could test for +R's and perhaps make up my own comma-separated PRIVMSG). The server is running Unreal3.2.8.1.

It seems like you should file a bug with the network and let them know that the server should continue delivery of a PRIVMSG even if a delivery failure occurs. For instance, on EFNet, you can do the following:

//msg NONEXISTENTNICK, $+ $me hello!

And the message will still be delivered to yourself, even though you also receive an ERR_NOSUCHNICK (401) for the first target.

I'm not sure how your server handles the above command (you should try and see), but it seems like the server does not respect this rule for the 486 numeric. It should, since as you mentioned, it can be an extremely common scenario. The admins should either upgrade Unreal, report a bug with Unreal (no idea if this is corrected in later versions, or if there are any), or fix it themselves.