Well, first of all I made an assumption that turns out to be incorrect. I had tested a group message to all voices
/notice +#channelname message
and it didn't work, so I assumed that it didn't work for group "/notice @#channelname message" to all @Ops either, but that does. However, the /version reply in the status window contains STATUSMSG=@+ which means they're *both* supposed to work.
In fact, due to the Undernet 005 message containing STATUSMSG=@+, when you use /onotice $chan, mIRC sends 1 message to @ $+ $chan instead of otherwise sending potentially multiple outbound notices to target each op individually. So in my earlier code where it used
//onotice $chan message
at Undernet or at any network which contans STATUSMSG= containing @, mIRC does the equivalent of
//notice @ $+ $chan message
... and it works.
But until Undernet either fixes this bug or tells what alternate command I'm supposed to be using, I'm afraid a group notice to voices might need to be done similar to the way Simo described for @ops, except changing $nick($1,%i,o) to $nick($1,%i,v), and determining what is the ACTUAL limit for how many nicks can be targeted in each copy of the notice.
Perhaps Simo can explain how they knew to use 5 as the max targets at Undernet? Normally the /version reply contains TARGMAX= that tells the limit for how many nicks can be combined into a single message like
/notice nick1,nick2,nick3,nick4,nick5 message
... and I'm at some networks where 4 is the limit, and others where limit=1.
However at Undernet I used Simo's style of mass-target where I had a 2nd nick as the 12th target in the list, and it did receive the notice. So if there's a limit at Undernet, I don't yet know what it is.
While testing this, it would help you to have the @debug window open to see what mirc is actually sending outbound, and what is actually received. You can't test by manually having the same nick in the list multiple times, because mIRC trims it down to sending to them once.
Also be aware that the 510 limit for IRC messages also includes the list of nicks, so even if you're allowed to send 1 notice to 30 nicks at the same time, that this limits how long the message can be, the same way as would happen if you were messaging to a single nick of length 300-ish. But if the notice is 'too long' Undernet sends an error reply back to you instead of forwarding a notice that's chopped
Update.
Undernet said that /notice +#channel not working is a bug that I should report as an Issue, though they weren't sure whether it would be fixed by removing + from STATUSMSG= or by fixing STATUSMSG=
They also said that 20 is the limit for how many nicks you can stack together in a comma-delimited target list, so if you will never have that many voices, you can just build a long list like:
//var -s %chan $chan(1) | echo -ag /notice %chan $left($regsubex($str(x,$nick(%chan,0,v)),/x/g,$nick(%chan,\n,v) $+ $chr(44)),-1) message
Apparently there's also a separate limit for how many targets you can message within a specific time period, and you'll probably need to find those out yourself, as even if you're sending out a valid /notice to 2 voices, it could violate the cumulative limit.
Also, I reported that STATUSMSG= is supposed to also allow group targets for other things besides /notice including /msg /describe /ctcp etc, but those aren't even working for the @#channel target that works for /notice
Last edited by maroon; 10/04/23 06:24 AM.