Where are you getting this behaviour from? I have IPv6 connections and calling /sockopen <hostname> or even /dns works fine to resolve ipv4 addresses on ipv4 hostnames.
You are missing the fundamental problem here, as we can clearly see by your choice of example. vyncke.org has support for both ipv4 (91.121.200.122) and ipv6 (2001:41d0:1:d17a::1). The problem is not here.. the problem is *everywhere* else!
"IPv6 mode" is a global mode, not server specific. You enable it by binding to an ipv6 adapter or enabling IPv6 priority. From then on, all /dns and /sockopen requests will use IPv6 first, regardless of active server connection. Try it yourself before "disagreeing". I use vyncke.org as a host that resolves in both ipv4 and ipv6.
Adding a -4/-6 switch works specifically because this is a global setting, and is specifically not a bug because you are enabling a global setting to prioritize a specific protocol over another. mIRC can't actually know what protocol to use until it attempts to dns the host, because it doesn't know if it's going to be getting an ipv6 or ipv4 address until the name resolves. You should be telling mIRC which one you want if you're going to be binding to a specific address (and specific protocol by extension).
Your "ipv6 mode" has nothing to do with anything I was talking about. I was expending on the /sockopen problem. Perhaps I should dumb-down the problem I see, explanation:
From then on, all /dns and /sockopen requests will use IPv6 first, regardless of active server connection. Try it yourself before "disagreeing". I use vyncke.org as a host that resolves in both ipv4 and ipv6.
That's absolutely incorrect. Try testing it first yourself. (For the part I was talking about)
take a simple script like this:
alias goog {
sockopen g google.com 80
}
on *:sockopen:g:{
if ($sockerr) { echo -a Opps! $sock(g).wsmsg | return }
echo -a All good, header would have been here!
sockclose g
}1) Open a blank mIRC
2) Connect to some ipv4 server:
/server irc.someserver.net
3) Run the script:
/goog
As expected:
"All good, header would have been here!"
4) Now, connect to some ipv6 server as well:
/server -m6 irc.someserver.net
5) Run the script (from that connection):
/goog
Not what you expect (google does not have ipv6 on google.com dns failed)
"Opps! [0] Unknown Error"
6) Go back to the first connection
7) run that script again
/goog
As expected:
"All good, header would have been here!"
8) Trying /goog on the second connection (-6) will result in the same error again:
"Opps! [0] Unknown Error"
This can be repeated as many times as you want, and on each connection it will based on that connection type (ipv4 or ipv6) it has nothing to do with any global mode you were talking about.
As you can clearly see, AFTER "I tried it myself before "disagreeing"", there is a problem here. Like I said in my original post, the behavior is inconsistent because it relies on the current connection that is executing the script, which is clearly a bug.
