mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#224966 23/08/10 02:46 AM
Joined: Aug 2010
Posts: 8
X
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
X
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
Code:
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
T
Hoopy frood
Offline
Hoopy frood
T
Joined: Jul 2007
Posts: 1,129
With a little modification, your alias will work the way you want it under v7.1:
Code:
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
X
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
X
Joined: Aug 2010
Posts: 8
Before you change your post for the 4th time (without being kind enough to say you edited it! frown ), 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
T
Hoopy frood
Offline
Hoopy frood
T
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
S
Vogon poet
Offline
Vogon poet
S
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#Post223751

In 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
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
Originally Posted By: Strider
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
S
Vogon poet
Offline
Vogon poet
S
Joined: Dec 2002
Posts: 155
Originally Posted By: jaytea
Originally Posted By: Strider
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
J
Fjord artisan
Offline
Fjord artisan
J
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
D
Pikka bird
Offline
Pikka bird
D
Joined: Feb 2007
Posts: 17
These characters I know don’t work ‚ƒ„…†‡ˆ‰Š‹ŒŽ“”•–—˜™›šœžŸ <------ supposed to be all small black squares

Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: Aug 2010
Posts: 5
Originally Posted By: xmrfunny1x
[*]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
X
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
X
Joined: Aug 2010
Posts: 8
I have taken this code as is from my script editor.
Code:
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
Code:
/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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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
X
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
X
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.)
Quote:
(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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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
X
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
X
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
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
Thanks, I was finally able to reproduce the SSL port issue. This should be fixed in the next version.

Joined: Aug 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
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.

Joined: Jun 2004
Posts: 6
R
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
R
Joined: Jun 2004
Posts: 6
Originally Posted By: tassat
The SSL port cycling problem is corrected in the 7.11 beta, I am still testing but that issue looks solved.


This issue is still in version 7.15 as stated in the original post without a resolve. Once you add the '+' to any port mIRC won't allow a write over with any other port.

ReZNiC

Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
I am no longer able to reproduce this issue here. Please describe a step by step example of how to reproduce this issue on a clean install of mIRC v7.15 with no addons and default settings so that I can try to reproduce it here.

Joined: Jun 2008
Posts: 28
S
Ameglian cow
Offline
Ameglian cow
S
Joined: Jun 2008
Posts: 28
Originally Posted By: reznic
Originally Posted By: tassat
The SSL port cycling problem is corrected in the 7.11 beta, I am still testing but that issue looks solved.


This issue is still in version 7.15 as stated in the original post without a resolve. Once you add the '+' to any port mIRC won't allow a write over with any other port.

ReZNiC


And I'm here to report a similar issue with mIRC 7.19. Yesterday, I decided to ditch Stunnel and use the built-in SSL support, which works fine. The problem is, I could no longer establish a non-SSL connection using a bookmarked non-SSL server. This is on DALNet where I have the non-SSL ports set to 7000 and the SSL ports set to +6697 in the server edit dialog. No matter which non-SSL server I selected, mIRC always connected to the SSL port +6697. The selected server was correct, but the port was wrong. I looked over servers.ini, but could see no obvious corruption, and all of the non-SSL ports are correctly reflected in that file. My default port is set at 6667, so that's not an issue here.

I did some more checking and tinkering and I think I've found the problem. What I did was go into the server edit dialog and set the port to 7000 for all servers, even the SSL ones. I checked servers.ini to be certain that there were absolutely no references to port +6697 left. I closed and restarted mIRC. I reconnected, and as I suspected, mIRC still connected on +6697. The only other place that port is referenced is in mirc.ini in the mirc/host section/item. I manually edited the port entry from +6697 to 7000, restarted, and reconnected. I was now able to successfully connect on non-SSL port 7000. So, what appears to be happening is that mIRC is reading the server name from servers.ini, but reading the port from mirc.ini. It's hard to imagine why this would be an intended behavior. If a port is specified in the server edit dialog, and you select a server from that same dialog, then that should be the port mIRC attempts a connect on. Or, am I missing something obvious here? I really don't want to go back to Stunnel, but I can't deal with this behavior.

Last edited by sonagaia; 29/09/11 12:17 AM.
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
Thanks for looking into it - your issue is a little different from the issue in this thread. In your situation, when you try to connect to DALnet, mIRC notices that you were previously using a secure connection and tries to find a secure port number for the new connection. When it cannot find one, it errs on the side of caution and uses the last secure port number. In the case where you are selecting the item from the servers menu, it really should use the settings for that server. This issue should be fixed for the next version.

Page 1 of 2 1 2

Link Copied to Clipboard