This issue seems related to the other thread...

https://forums.mirc.com/ubbthreads....r-using-local-cert-by-default#Post270782

Originally Posted by Khaled
When you use /server to create a new window, it copies over the settings of the current status window

--

In this case, the GROUP parameter is remembered only if you DO use the server command to create a new window. To re-create:

1. Open new instance of mIRC, and it remembers the settings for the last server connection that was either created or closed. If mIRC closes in an orderly fashion, that will be the connection you use as $scon(1) since it defaults to closing them right-to-left, making the 1st connection be the one whose info is last written to mirc.ini. However this time I noticed a change in behavior because my computer had crashed, which resulted in mirc.ini not containing the info from $scon(1)

In this example, the only status window sees:

//echo -a network: $network servertarget $servertarget port: $port group: $server($servertarget).group target: $server($servertarget,1)

result:
network: Libera.Chat servertarget calcium.libera.chat port: +6697 group: Libera.Chat target:

(My serverlist has targets both for calcium and the round robin servers)

2. Now try to connect to a different network, using its serverlist groupname. In this example, I'm using SwiftIRC:

/server -g SwiftIRC

result: * Connecting to calcium.libera.chat (+6697)

3. Now try to do the same thing except doing it in a brand new status window

/server -n
/server -g SwiftIRC

result: same, except is now trying to connect to Libera's roundrobin instead of calcium, I'm guessing it cloned the $network from 1st window, but not $servertarget too

4. Now use -m to do the same thing:

/server -gm SwiftIRC

correct result: * Connecting to irc.swiftirc.net (+6697)

If I try to use this new connection like /server -g UnderNet
it again ignores the Group and tries to connect to the current network, SwiftIRC, instead.

The current workaround to the -g GROUP parm being ignored is something like:

doesn't work: /server -g GroupName

workaround for correct result: //server $server(1,GroupName)
... which returns the 1st $servertarget in the serverlist associated with that Groupname