Nick Listing Logger v1.1

Platform: mIRC

Published Jul 09, 2012

Updated Jul 12, 2012

538 5

This was requested by iObsession on SwiftIRC.

Simply logs each nick used by $site and displays them when the nick joins.

WHAT'S NEW?

+ added a /check command; /check nick
+ added %nick and %site vars for $nickChange to allow for defined and default use
+ supplemented $site to allow for $site(nick)

on *:start:{

  hmake nickChange 1000

  hload nickChange nickChange.hsh

}



on *:nick:{

  $iif($nick !isin $hget(nickChange,$site),hadd -m nickChange $site $addtok($hget(nickChange,$site),$nick,44))

  hadd -m nickChange $site $addtok($hget(nickChange,$site),$newnick,44)

  hsave nickChange nickChange.hsh

}



on *:join:#:{

  echo -s $nickChange

}



alias check { return $nickChange($1) }

alias site { return $gettok($address($1,2),2,64) }

alias -l nickChange {

  var %nick = $iif($1,$1,$nick), %site = $iif($1,$site($1),$site)

  if $hget(nickChange,%site) {

    var %i = $numtok($v1,44), %nickList = $v1

    while %i {

      var %n = $addtok(%n,$+(04,$gettok(%nickList,%i,44),),44)

      dec %i

    }

    return ** %nick $+ 's nicks: $replace(%n,$chr(44),$+($chr(44),$chr(32)))

  }

  else return

}

Comments

Jethro - Jul 22, 2012

Or there's another way that you can take advantage of the /ialmark command and $ial().mark identifier to work side by side with the hash table:

		Code 			
on !*:join:#: check $nick
on *:exit: hsave nc nc.hsh
on *:start:{
  if (!$hget(nc)) hmake nc 1000
  if ($isfile(nc.hsh)) hload nc nc.hsh
}
on *:nick:{
  var %nc = $addtok($ial($newnick).mark,$newnick,32)
  .ialmark $newnick %nc | hadd -m nc $wildsite %nc
}
alias check {
  if ($hget(nc,$address($1,2))) {
    echo -s * $1's nick(s) : $replace($v1,$chr(32),$+($chr(44),$chr(32)))
  }
}	

mIRC's IAL will always return the rightful nicknames, whether it's new or old.

Respond

Jethro - Jul 22, 2012

The on start event does nothing if one doesn't restart his or her mIRC but copy and paste the snippet into their remote directly. Without the -m switch utilized, they're surely to get an error of "hash table not found" if that happens.

I still don't see the point of using a timer to save a hash table periodically. Again, mIRC adds or updates the item and data when triggered by the nick event when change takes place and then overwrites the old info. If one gets disconnected, quit or parted, the hash table is still there, not lost. The only time hash table is gone with the wind is when mIRC itself is closed completely.

Once again, the noticeable difference between $site and $wildsite is that, $wildsite adds *!*@ while $site doesn't. I'm not sure what $wildsite has to with being able to see the network easily or not. In your example, you use the $network identifier in conjunction with the $wildsite, the network name itself has to present anyway. According to the help file:

Quote

$site: Returns the portion of $address after the @ for the user associated with an event in the form user@host.

Quote

$wildsite: Returns the address of the user who triggered an event in the form *!*@host.

If you have a modern PC running with latest operating systems today, be that as XP, vista or windows 7, aka the NT system, they all come with ample amounts of RAM...compared to Windows 95/98/Me, which cannot digest too much RAM, say, more than 512 MB. That will have a negative effect on the running of a hash table indeed.

The point is, a modern system that runs mIRC does not have to worry about limitation or "slow to a crawl" or "grind to a halt" concern anymore. What a hash table runs is based on your computer, not mIRC. Of course, slow internet connection is another story.

Respond

KindOne - Jul 22, 2012

I rather deal with an 'on start' than a '-m' switch.

My timer is a waste of resources?!?! ..
The entire 'saving the hash table on a nick change' is just horrid in my eyes.. look at the big picture.. Assume this script is going to run FOREVER. What happens when that hash table starts to hit ~100,000 items? mIRC will of by now started having lag because its having to waste pointless time to save a hash table the the disk on every little nick change. ... vs a timer that is called once or twice a day...

$network $+ $site == ' foobarKindOne.meh'
$network $+ $wildsite == 'foobar*!*@KindOne.meh'
I like the $wildsite better.. because i can EASILY see what network its on.. when looking at the tables.

Please start creating hash tables with ~100,000 or even ~500,000 items then run this script while on 100+ channels. I'd love to see your mIRC grind to a halt every second vs a few times out of the day with my timer idea.

Respond

Jethro - Jul 22, 2012

You don't really need the on start event to create a hash table to begin with. Get rid of it in favor of the -m switch being used.

The timer suggestion is a waste of resource. A hash table won't get lost so long as you don't close mIRC, let alone the trigger upon a nick change in this snippet. The essential one you'll need is the exit event.

There's no difference between $site and $wildsite. They are releatively the same; one is shorter and the other longer.

Hash table virtually has no size limit according to the RAM of your computer, which is what mIRC's hash table function adapts to ultimately. The more memory you have, the better for a hash table to work fast and effectively.

Respond

KindOne - Jul 22, 2012

Slight issue(s).

Does not check if hash table exists while loading.
No 'on unload' to save hash table/unload.
No 'on exit' to save the hash table.
Not multi-network friendly. (id suggest ' $network $+ $wildsite' , instead of '$site').
hsave .. inside a nick event.. That just screams mIRC lag when it starts to grow.. In my opinion, id gut that..
I'd create a timer to save on occasion (id do a save every 24 hours or 12). (save it into a 'nickChange.hsh.bak')
Make 'on start' check for file size and compare the size of files and load the biggest one $file(foobar.hsh).size .. could use $calc

Respond