|
Joined: Aug 2010
Posts: 8
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 8 |
Admittedly I haven't made the effort to see if some of these bugs have been reported already, but I have a small list of some thing that I have noticed and caused me to frown upon v7.x. - SSL Sockets
- Evaluation of $chr(173) (there might be other ASCII character associated with this)
- Associating correct ports with their respective Server Connections upon startup of mIRC
Regarding the first item, SSL Sockets, I am referring to SSL capabilities associated with /sockopen -e. The connection that I was able to establish only lasted for a matter of seconds (most likely less than 2 full seconds). The second item, evaluation of $chr(173), was encountered when I tried to remove a ban that was set that contained a series of ASCII characters, 173 included. It is not possible (from what I have tried) to remove the ban on v7.1, but there is no problem removing it when on v6.35. Using this alias alias chr { echo 4 -a $qt($1-) == $!+( $+ $left($regsubex($1-,/(.)/g, $+($,chr,( $+ $asc(\1) $+ ),$chr(44))),-1) $+ ) } I did the following test: //chr $chr(173) On mIRC v6.35, it returns: $+($chr(173)) On mIRC v7.1, it returns: $+($chr(194),$chr(173)) mIRC appears to "append" this extra character wherever $chr(173) is present in v7.1, making dealing with $chr(173) by itself extremely difficult, if not impossible. And finally my last observed bug can be found during a simple start up of mIRC. Currently in v7.1, the port of the last connection is used (prior to exiting mIRC) is used automatically even if you select a Server from the list found under "History" in the File menu.
irc.swiftirc.net #mSL,#xmrfunny1x
|
|
|
|
Joined: Jul 2007
Posts: 1,129
Hoopy frood
|
Hoopy frood
Joined: Jul 2007
Posts: 1,129 |
With a little modification, your alias will work the way you want it under v7.1: alias chr {
var %r = $!+( $+ $left($regsubex($1-,/(.)/g,$+($,chr,( $+ $asc(\1) $+ ),$chr(44))),-1) $+ )
noop $regex(%r,/\54(.*))/) | var %x = $+($,+,$chr(40),$regml(1)) | echo 4 -a $iif($chr(44) isin %r,%x,%r)
}
|
|
|
|
Joined: Aug 2010
Posts: 8
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 8 |
Before you change your post for the 4th time (without being kind enough to say you edited it! ), allow me to point out that your modification is merely truncating the output of this alias by one "character" and not exactly solving the issue. As for this "issue" that you are trying to solve, there isn't really much of an issue with the alias, but more of how mIRC is treating $chr(173) as two characters when $chr(173) is used somewhere. Edit: For example, while using your alias.. //chr $chr(173) This will output $+($chr(173)) on v7.1 //chr . $chr(173) This outputs $+($chr(32),$chr(194),$chr(173)) on v7.1, which we can see is not getting us anywhere useful.
Last edited by xmrfunny1x; 23/08/10 05:20 AM.
irc.swiftirc.net #mSL,#xmrfunny1x
|
|
|
|
Joined: Jul 2007
Posts: 1,129
Hoopy frood
|
Hoopy frood
Joined: Jul 2007
Posts: 1,129 |
Ok I admit that wasn't really solving the issue. I can't see the difference between $chr(45) and $chr(173) They seem to output the dash character. Why not use $chr(45) instead?
|
|
|
|
Joined: Dec 2002
Posts: 155
Vogon poet
|
Vogon poet
Joined: Dec 2002
Posts: 155 |
mIRC is UTF-8 encoding $chr(173) when it sends it to the server, because it falls out of the ASCII range (up to 127). That's what mIRC does now that it is a Unicode application. The problem is that there is no way to know if the original nickname (or channel) mIRC received was UTF-8 encoded or not, which gave birth to the following discussion: https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=223751&page=1#Post223751In the meantime, you can use /raw -n to bypass this behavior when sending the ban command to the server. Good luck, though, knowing when a user's nick (or a channel) is UTF-8 encoded in the instance of the server, and when it's not.
Last edited by Strider; 23/08/10 06:53 AM.
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
Good luck, though, knowing when a user's nick (or a channel) is UTF-8 encoded in the instance of the server, and when it's not. $rawbytes was added to overcome that limitation, it returns non-decoded and unaltered received text. prior to its addition, /debug -i could also have been used, though less comfortably, to handle the data as it was originally received
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Dec 2002
Posts: 155
Vogon poet
|
Vogon poet
Joined: Dec 2002
Posts: 155 |
Good luck, though, knowing when a user's nick (or a channel) is UTF-8 encoded in the instance of the server, and when it's not. $rawbytes was added to overcome that limitation, it returns non-decoded and unaltered received text. prior to its addition, /debug -i could also have been used, though less comfortably, to handle the data as it was originally received With either of those solutions, you would need to store an altername nicklist for each channel you're in, as well as an alternate list of channels you're in, if you want to use a popup command to ban or kick someone. And the former becomes completely unreliable if you join the same channel twice (with ANSI and UTF-8 encodings), or if a nickname exists twice in a channel. As mIRC stands right now, there is no way to target ANSI-encoded users or channels by using mIRC's native functionality, which is the real problem. If that issue is ever solved, I hope that Khaled adds something like $rawchan, $rawnick, $rawchan(N), $rawnick(rawchan,N), $rawsnicks in the future, so that popups can work reliably with ANSI-encoded elements, though it will probably never happen.
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
quite right, it is undoubtedly non-trivial for the average scripter to maintain these associations for their scripts :P i too hope to see features along the lines of what you mentioned, though more comprehensive (consider the OP who might rely on $ibl() being completely accurate)
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Feb 2007
Posts: 17
Pikka bird
|
Pikka bird
Joined: Feb 2007
Posts: 17 |
These characters I know don’t work ‚ƒ„…†‡ˆ‰Š‹ŒŽ“”•–—˜™›šœžŸ <------ supposed to be all small black squares
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
Another user reported a similiar issue here with /sockopen -e, however I was not able to reproduce the issue. Can you please provide a short script that reproduces the issue for you? Thanks.
|
|
|
|
Joined: Aug 2010
Posts: 5
Nutrimatic drinks dispenser
|
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 5 |
[*]Associating correct ports with their respective Server Connections upon startup of mIRC
And finally my last observed bug can be found during a simple start up of mIRC. Currently in v7.1, the port of the last connection is used (prior to exiting mIRC) is used automatically even if you select a Server from the list found under "History" in the File menu. i reported this here https://forums.mirc.com/ubbthreads.php?ub...true#Post224890
|
|
|
|
Joined: Aug 2010
Posts: 8
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 8 |
I have taken this code as is from my script editor.
alias sock.clone { window -de @SBOT | var %x 1 | while ($sock($+(sock.clone.,%x))) { inc %x } | sockopen $iif($2 == 6697,-e) sock.clone. $+ %x $1 $$2 }
on *:SOCKOPEN:sock.clone.*:{
if (!$sockerr) {
sockwrite -nt $sockname NICK SSL\test
sockwrite -nt $sockname USER SSL "" "" :*
}
else { echo -a $sock($sockname).wsmsg }
}
on *:SOCKREAD:sock.clone.*:{
var %a,%s sockwrite -nt $sockname
sockread %a
if (%a && $window(@SBOT)) { echo -t @SBOT %a }
}
on 1:SOCKCLOSE:sock.clone.*:{ echo -a $sock($sockname).wsmsg }
Results while using mIRC v7.1
/sock.clone imperial.swiftirc.net 6697
(06:33.37 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Looking up your hostname...
(06:33.37 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Found your hostname (cached)
(06:33.37 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Checking ident...
[10053] Software caused connection abort I tried this code again on v6.35 and I was able to connect without a problem. I have also ran into the problem where the /sockopen failed and I received the 10101 WS error on v7.1 continuously after consecutive attempts of trying to establish a connection; although I'm not sure what would be the cause of that, when I tried to open the socket in v6.35, I also received that 10101 WS error within nearly the same time frame.
irc.swiftirc.net #mSL,#xmrfunny1x
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
Please try the following: disable UPnP in the Options/Connect/Options/Ports dialog and the Port Range options. Does that help?
|
|
|
|
Joined: Aug 2010
Posts: 8
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 8 |
I disabled all of the options listed under UPnP and Port Ranges, executed the script again, and I still received the 10053 WS error. (This was done without restarting mIRC after disabling those options.) (08:56.09 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Looking up your hostname... (08:56.09 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Found your hostname (cached) (08:56.09 PM) :imperial.tx.us.SwiftIRC.net NOTICE AUTH :*** Checking ident... [10053] Software caused connection abort
irc.swiftirc.net #mSL,#xmrfunny1x
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
Thanks for your help, I was able to reproduce the custom sockets SSL issue. This has been fixed for the next version.
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
Regarding the ports issue - I have been unable to reproduce this so far. Can you describe a step by step method that reproduces this for you? mIRC selects the port based on your servers list - if you have a server in the server list with a defined set of ports, mIRC will use that, otherwise it will use the default port as defined in the Options/Connect/Options dialog.
|
|
|
|
Joined: Aug 2010
Posts: 8
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 8 |
I am currently attempting to reproduce this error myself, but I cannot remember what caused it. I think the key to reproducing this error lies somewhere along the lines of using an SSL port (prefixed with +) prior to the last exit and then again on start up. I will continue to attempt to reproduce this error.
irc.swiftirc.net #mSL,#xmrfunny1x
|
|
|
|
Joined: Aug 2010
Posts: 5
Nutrimatic drinks dispenser
|
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 5 |
definatly has something to do with SSL connections.
i can connect to many non ssl ports just fine after i connect to non ssl ports i can connect to the first SSL port connection but the next connection uses the SSL ports number i used last.
EX.
first i connect to server1 on port 6667 connects
then i connect to the next server
connect to server2 on port 6668 connects
i now connect to
server3 on port +7777 connects
i now am connected to 3 servers
now i try to connect to
server4 on port +8888
it tries to connect to server4 using port +7777
if i try to connect to server5 on port 6669
it tries to connect to server5 on port +7777
from here its hit or miss if i can connect to other servers once i restart MIRC.
if i delete the host entry from mirc.ini it will still try to using the +7777 port on whichever server i wish to connect to.
if i change the host entry to another vaild server entry i can usualyy connect to that server.
it appears the MIRC is not reading the port # and updateing it correctly.
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
Thanks, I was finally able to reproduce the SSL port issue. This should be fixed in the next version.
|
|
|
|
Joined: Aug 2010
Posts: 5
Nutrimatic drinks dispenser
|
Nutrimatic drinks dispenser
Joined: Aug 2010
Posts: 5 |
The SSL port cycling problem is corrected in the 7.11 beta, I am still testing but that issue looks solved.
|
|
|
|
|