Forums Active Threads Past Month

I'm running Windows 10 21H1.

Since upgrading my installation of mIRC from 7.6x (don't recall the exact version, sorry) to 7.72, I've experienced hangs when connecting to my PC via Remote Desktop. When the hang occurs, mIRC is completely unresponsive and doesn't answer server pings, etc. The hangs seem to occur randomly, although thus far I haven't seen one when mIRC has had focus. I don't know if they're limited to Remote Desktop, as I don't currently have physical access to the machine.

Task Manager shows ~25% CPU usage when this happens, which corresponds to using all of one core on my machine.

I generated a core dump and can provide it privately, if that'd be helpful.

Suggesting some kind of "ON MIRCTEXT" EVENT to handle window messages generated by the client itself, which would allow a script to monitor them for content, so they could ^HALT them or take action based on their content.

There are some settings in mIRC where there's not an identifier call to find the value, but the setting can be found in mirc.ini [options], but those aren't officially documented for new scriptors to find them, and in some cases would force the script to issue a /saveini to make sure the $readini value is correct. But there are other things where you can't peek at disk to see the setting.

This would be easier and more accurate than trying to inspect the status window from the bottom-up looking for content without actually being able to confirm that this was a message created by the client instead of created by something else like /echo /loadbuf /filter.

I'm seeing this as a 'catch all' event to handle all the text that's not something that can be handled by intercepting 'raw' or other events. If it's not something generated by 'raw' or some other event where the info can be obtained, it would trigger this instead.

Depending on what happens when you use a silencing dot for commands like /.dcc passive, a script can see the setting for something without the message being displayed, if the event handler has some kind of $shown identifier returning $true or $false, to indicate whether the text can actually be seen.

One use case for this would be for situations like the problem I encountered related to this thread

https://forums.mirc.com/ubbthreads.php/topics/270577/new-play-switches

I was helping fix someone else's script, where they were using /play to send significant amount of text to channel, but when the /play stop command was issued, it kept sending output to channel because several lines were queued in the flood que. I didn't want to just clear the que too, because there's no way for the script to know how many of the lines in the que were for this script vs other text. Also, as far as I know, other than looking at the output from the /flood command, there's no other way to find how many lines are in the flood buffer. So instead I used the /flood command to send the message to the status window, from where I could use

$gettok($line(status window,$line(status window,0)),-6-,32)

to get the content of the last line in the status window, to show a message to channel telling how many lines were pending in the que. It worked fine for me, but not for the person I was helping, and it took a while to figure out there was different behavior because they didn't have the line separator deleted, so the last line of their status window was a "-" instead of being the message I was looking for.

Other use for this would be things like detecting the reconnect 'retry #N' message text showing to screen, so a script could take action based on what was (or was not) happening.

Possibly the most common use for this would be - if the midnight "Session Time:" were also echoed to the status windows - this would be an easy way for scripts to be triggered every midnight without the complications of trying to do this with a timer, where there would also be the risk that something could ruin it with /timer* off. If the decision were that the Session Time message would be shown only to the status window, it would be easy for a script to use this event to hook that Client Message and echo it to the open channels and queries.

This would be for 'real' client messages, so something showing up because of reloading a logfile shouldn't count. It also is for client messages, and not for the expected output for commands. So all lines of /filter output should not trigger it, but the error message for /filter -sw @mirc * should.

Since this is a grab-bag event, it would be up to the script to have an appropriate text match for the thing they're looking for, but I can't think of any cases where 2 unrelated things would return the same text string.

In a #channel window, when you have the 'keep open' setting enabled, you get timestamped "* Disconnected" and "* Rejoined" messages that let you see which window(s) of time could potentially have messages you missed. But this would also be useful for query window too, where currently you can't look at the query window to see if you had disconnected after it opened, without scripting it.

Similarly, for both Query and #channel windows, it would be useful for the "Session Time:" line sent to the logfile is also sent to the #channel Query windows too. As things are now, in low volume channels it can be hard to figure out which day a message was made in without including the day as part of the timestamp, or by slowly paging through the history to see how many times the clock circled. And when you have a Query window opened 3 days ago, it's hard to tell whether a message was made today or 2 days ago, without opening the logfile to look for the midnight message.

I'm ambiguous whether it's needed to include a 'noon message' for those whose timestamps use 'hh' instead of 'HH', or just go ahead and have a twice daily 'session time' message for everyone.

1. For the options hiding behind the hamburger icon, underline the key-letters to indicate the presence of the undocumented hotkeys for Add Edit.

2. Add another item behind the hamburger icon to 'clone' the visible serverlist entry. This makes it easier to add multiple server addresses for the same network GROUP without needing to manually fill in each blank, or using notepad to add the new item.

For example, I was given an o-line at a network that was valid only at 1 of the servers, so if I connected using the round-robin address, it was a dice-roll whether I would be oper. But if that 1 server was down, then I couldn't connect at all.

So, the solution was to add the individual server to the GROUP while retaining the round-robin item as a fallback for when the 1 server fails.

However, in order to add the new server address to the GROUP, I had to ADD the new item, then input every field, including editing the port from the 6667 default, as well inputting the non-global client certificate, and the password or other login-method settings. I ended up editing servers.ini in notepad in order to have a modified clone of the round-robin entry without risk of making a typo.

To avoid confusion between editing a clone vs editing the only copy, there probably should not be a hotkey for this choice, and the titlebar should say something like 'clone server' instead of 'add server'. And the new item wouldn't actually be added to the serverlist until <enter>.

https://forums.mirc.com/ubbthreads....entifiers-accept-missing-parm#Post271190


So I guess that, if something has been around the block long enough, the default can't change, and the only solutions are to leave it as-is, or make the alternate behavior available only from a switch, or change only if the behavior is considered a bug.

• $totp TIMESTEP
  
  One example is something I mentioned previously, where the TIMESTEP parm in $totp does the same thing that $xor and many other identifiers do, and evaluate text the same as if zero were used, so $and(123,text) is same as $and(123,0).
  
  Much of the time, text in numeric parameters results either from a typo when putting the %variable name in, or by mis-counting the parameters and putting a valid parameter in the wrong spot, such as $totp(key,sha1)
  
  However the TIMESTEP parameter seems to be a case that, even if it's valid to see text as the number zero, that is still invalid input.
  
  The TIMESTEP is a floor divisor for the TIME value, so zero and negatives are invalid floor divisors for a result that is supposed to be an integer [0,2^64-1], so that should be an invalid parameter rather than silently changing the input into the default of 30.
  
  So this example shows that TEXT and $null are returning the same result as if 30 were used.
  
  //var %timestepvar 60 , %time 123456789 | echo -a $totp(key,%time,sha1,6,%timestepvar) vs $totp(key,%time,sha1,6,timestepvar) same as $totp(key,%time,sha1,6,30) same as $totp(key,%time,sha1,6,0) same as $totp(key,%time,sha1,6,-1) same as $totp(key,%time,sha1,6,$null)
  
  Another aspect of the default behavior of TIMESTEP seems to be the exception to the general behavior that if a parameter is present, where normally that parm being $null is considered an error or causes the return value to be $null. i.e. there are exceptions like $tip where a $null parameter can be followed by a not-null parameter, but generally when an optional parameter is present but is blank, the identifier returns blank or an error, like with $sha1(abc,$null)
  
  But if I want to change the timestep from 30 to 60 without changing any of the other defaults, it doesn't let me do $totp(key,,,,60), but makes me list the 3 defaults in order to change the timestep. But if I do $totp(key,$ctime,sha1,6,) it lets me do that and treats $null as the default 30.
  
  Summary: it seems that a timestep 'value' that evaluates to zero should either return $null or generate an 'invalid parameter' error, because a (TIME // zero) is not a legit value. i.e. the default is correct, but should be used only when the parameter is not used, not when the parameter is not within the valid range of positives.
  .
• Interpreting text as zero for the newer math identifiers
  
  Most of the time, having text in a parameter is a typo from forgetting the % of a variable name or some other kind of error, and returning a value as if zero were used is not going to be useful behavior, and can make it hard to track down an error.
  
  I kept getting results that shouldn't be possible, until finally figuring out that a typo was causing $gcd to see one of the 3 parameters as text, making it return the wrong answer as if the parameter were zero.
  
  //var %a 25 , %b 35 , %c 29 | echo -a $gcd(%a,%b,%c) and $lcm(%a,%b,%c) vs $gcd(%a,%b,c) and $lcm(%a,%b,c)
  
  result: 1 and 1575 vs 5 and 0
  
  Summary: it seems more helpful for the newbies if it's an error/blank return if a parameter is not numeric:
  
  $cbrt(varname)
  $log2(varname)
  $powmod(2,varname,10)
  $modinv(varname,varname)
  $gcd(5,vartext)
  $lcm(5,vartext)
  $numbits(text)
  $fibonacci(varname)
  $factorial(varname)
  
  depends if you think the other long-in-the-tooth math identifiers should also interpret text as zero
  
  $xor(123,varname)
  $and(123,varname)
  $not(varname)
  $cos(varname)
  etc
  
  Also, since these new identifiers are valid only for integers, the current behavior of stripping fractions to make floats be integer is fine, but should not be handling scifi notation by translating it into integer, because this notation by definition has a limited precision, and 1e99 in the input is not necessarily going to be exactly 1 followed by 99 zeroes, and same goes for 1.123457e99.
  
  //echo -a %.bf $powmod(3,1e3,65539) should be error not same as $powmod(3,1000,65539)
  
  If there is the intent to have the input interpreted as scifi when it's present, then those edge cases can simply use the behavior of $int to handle situations where the input should interpret the notation, $powmod(3,$int(1e99),65539)

**

Missing parameters related to encryption keys:

• $hotp and $totp
  
  /help $totp says 'The key is required'
  /help $hotp says 'The key is required'
  
  But they have never required that.
  
  //echo -a $totp() same as $totp($null) same as $totp($null,$ctime)
  
  $hotp allows a missing key, but only when the COUNT parameter is present since it treats that as required, but doesn't require the key be present:
  
  //echo -a $hotp($null,123) same as $hotp(,123)
  
  --
  
  The purpose of $hotp and $totp is to prove that you know the key without actually sending the key itself. By having the output be a 6-digit number, it boils the key strength down to $log2(10^6) = 20 bits, and there's no usefulness or use-case for allowing the 'required' key be null length
  .
• $hmac This is restatement of the feature suggested I made for $hmac hex/binary keys
  
  HMAC is the only case I can think of where it's legit to have a crypto key be null length, due to people using HMAC as a keyless hash substitute for $sha256 or $sha512 that can be vulnerable to the length-extension attack in certain situations. Plus, HMAC is defined so that short keys are padded to full length, so a null key just gets more padding than other not-so-short keys do.
  
  However, when HMAC does use a key, it's almost always shown as hex, and the RFC test vectors can't be matched without being able to have the key be non-UTF8. The existing handling of the key defaulting as text can't be changed without a switch that makes it be seen as hex.
  .
• Restatement of suggestion Blowfish 'k' switch for $encode/$decode hex keys
  
  Likewise for Blowfish, the official test vectors all use hex keys and IV's, with virtually all of them being binary strings other than UTF8 text. The existing default has been there too long to enable hex keys without an optional switch for the Parm3/Parm4 to be seen as hex
  
  The default behavior of allowing the Parm3 key to be $null is also not desirable for encryption ciphers. Even though $encode(message,mc,$null) changes the output each time due to mixing a random salt with no-key-used, it ends up being no more secure than if using ROT13.
  
  When the Parm3 key is $null, $encode is treating it as if the input were a hex key of all 0x00 null bytes, which isn't the same thing. The design for Blowfish states that the key input is repeated until it's 72 bytes. There's 2 ways of doing this.
  
  Code

  for (key72=$null ; length(key72) < 72 ;) { key72 = $left( key72 $+ input,72) }
  
  or
  
  for (i = 0;i < 72;i++) { key72[i] = input[ i % length(input)] }
  

  However a null key is invalid in both scenarios, either an infinite loop trying to repeat length 0 until it reaches length 72, or a divide by zero error when trying to use the Nth byte of a zero length key.
  
  So, currently the user cannot depend on an error message to prevent the encryption being done with a missing key, and needs to explicitly add an extra check against the %key variable being blank, or halt the script like $$+(%key)

One thing I'd like to see is a -m flag for both /sockaccept and /sockopen which allows the socket to be marked, rather than having to do /sockmark in post.

Expand /color command or new alias for changing colors in mIRC Options/Display: Event, Highlight, Message would make it more convenient to create custom Theme. It would also be nice if it would be possible to read these three colors e.g. with $color. I know it is possible manually from mirc.ini but after all that is not the point.

Regards.