Script causing wait lock on MIRC program

mIRC Homepage

Greetings all,

I am running the following code that I created but there seems to be a wait lock that happens where the MIRC program will go into not responding for up to 20 seconds before displaying the end result of

<nick> has joined from <CurrentIP> there are <X> nicks for this IP:<nick>_:(11/09/2020 07:03:57:AM) & Known ip's for <nick> are:~ 11/08/2020 06:07:25:PM:~ 90.252.224.253 148.252.129.105:(11/09/2020 07:03:57:AM)

I thought maybe it was 3 $readini that was doing it so I commented them out and I am still seeing wait lock/not responding. Its not enough to crash MIRC or to cause a disconnection but just enough to be annoying when trying to type

Code

on 1:join:#:{
  set %addresslinked $remove($address($nick,2),*!*@)
  IF (( 207.192.75.252 isin %addresslinked ) || ( mibbit isin %addresslinked ) || ( kiwiirc isin %addresslinked ) || ( irccloud isin %addresslinked )) {
    halt
  }
  ;set %wildcard $readini(wildcard.ini,$remove($address($nick,2),*!*@),allnicked)
  ;set %wildnickeds $readini(wildcard.ini,$nick $+ allhosts,allhosts)
  ;set %nickcount $readini(wildcard.ini,%addresslinked,nickedcount)
  if (%nickcount == $null) set %nickcount 1
  if (%wildnickeds == $null) set %wildnickeds %addresslinked
  echo 15 $chan $timestamp $nick has joined from %addresslinked there are %nickcount nicks for this IP: $+ %wildcard & Known ip's for $nick are: $+ %wildnickeds
  unset %addresslinked
  unset %wildnicks
  unset %wildnickeds
  unset %nickcount
}

I don't see anything beyond the $readini which could possibly cause such a delay, so my guess is that you have a different script doing something during ON JOIN where the delay actually happens

You can confirm which line has the delay by having the 1st line of the event be:

var %ticks $ticks

and then sprinkled through the event you can have lines like:

echo -s debug $scriptline interval $calc($ticks - %ticks) ms

... and if you see a jump between a pair of debug messages, you know the delay is between them.

I tried your code and found no delays. It looks like you have some other script that is causing the delay. Try to localize the problem.
Install check in all scripts via to try to calculate the location of the problem and so that you can see the delay time when executing each script:

Code

/echo -s debug: $+(07,$scriptline,) - $+(06,$script,)

I have also optimized your code a bit if you find it useful to for experience:

Code

on 1:JOIN:#:{
  var %ticks $ticks
  set %addresslinked $remove($address($nick,2),*!*@)
  if ($count(%addresslinked,207.192.75.252,mibbit,kiwiirc,irccloud)) { halt }
  ;set %wildcard $readini(wildcard.ini,$remove($address($nick,2),*!*@),allnicked)
  ;set %wildnickeds $readini(wildcard.ini,$nick $+ allhosts,allhosts)
  ;set %nickcount $readini(wildcard.ini,%addresslinked,nickedcount) 
  if (%nickcount == $null) set %nickcount 1
  if (%wildnickeds == $null) set %wildnickeds %addresslinked
  echo 15 $chan $timestamp $nick has joined from %addresslinked there are %nickcount nicks for this IP: $+ %wildcard & Known ip's for $nick are: $+ %wildnickeds
  unset %addresslinked %wildnicks %wildnickeds %nickcount
  .echo -s debug: $+(04,$calc($ticks - %ticks),,ms) - $+(07,$scriptline,) - $+(06,$script,)
}

Thank you both maroon and Epic for the replies. I did some testing using he debug coding. The issue seemed to be with the with the original writeini script that created the ini file data, I think because I was just populating so much data into the file (current size was 1.98 MB 84,164 lines (with spaces)) which for a ini file is well HUGE, that it was wait locking while trying to parse the single file to find the line within to update/read.

So I created some separate files to hold the more fluid data that is getting read and updated more often. so I blew the whole INI file away and started from scratch. I guess I could have taken the time to well rip the INI file apart to preserve the data but decided to let it repop in its own time. Currently with the fresh ini files the scripts are responding fine.

I had started the script out in its first write using several files to hold the data but decided to try and put it into one file. BAD idea I guess I didn't expect the sizing to blow up so fast