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:

$site: Returns the portion of $address after the @ for the user associated with an event in the form user@host.> $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.