mIRC Homepage
Posted By: Aenei making the move from ini to hash - 18/12/05 04:05 PM
I've decided to move the stored data for my script from (as it is now) an ini file to a hash table.

From what I have learnt by reading the help I think am I going to need to create quite a lot of hash tables. Basically at the moment I have an ini file with several sections. As is the way of ini files each section has much the same list of items in each with their associated values. Am I not wrong I therefore need a hash table for *each* section to contain the items and values? If so, is it really going to be worthwhile to recode to use hash?
Posted By: RusselB Re: making the move from ini to hash - 18/12/05 05:08 PM
Initially it looks like you will need quite a few hash tables, however, eventually, you should be able to elimiinate some of the duplicates and use the item identifications to be able to store more information in a single hash table.

Fortunately, the hsave & hload command have an -i switch, which makes the hash table work with the ini file format.

I, personally, prefer hash tables due to their speed and accessability.
Posted By: genius_at_work Re: making the move from ini to hash - 18/12/05 05:23 PM
It depends on what sort of information you have stored in your ini file(s). Information that is read often is usually more efficiently stored in a hash table, whereas information that is read rarely can be stored in an ini file. For example, if you have a list of servers that your mIRC should connect to on START, those could be stored in an ini file. On the other hand, if you have information about users in a channel/game/etc that is regularly requested by users, storing that information in hash table(s) would make your scripts run faster. You don't have to load all of the information into hash tables. Just load the things that you are going to use many times per day.

-genius_at_work
Posted By: Aenei Re: making the move from ini to hash - 18/12/05 06:23 PM
The inifile contains as sections (ie in the [ ] bit) the text to be matched in a highlight script. In the rest of the section is settings for what to do in the event of a match - colour, sound etc.

I tried initially loadign the ini file as a hash, just to see what it would look like, and it failed. I then downloaded mr_foot's Hash Sandwich and this loaded the ini ok. I then have a hash table with all of the section titles as [ ] entires and a jumble of the other text in there all mixed up, with some item=value as a hash value and some as data.

I think I probably would benefit from loading it into hash genius, seeing as its a highlight script and so is being called on text/action/notice events and currently it is reading the ini every time.

Edit: I worked out why mirc itself wasn't loading the table. Needless to say, I was being a muppet.
Posted By: hixxy Re: making the move from ini to hash - 19/12/05 07:49 AM
I think using a table for each section will be the quickest and simplest way of doing this, in fact, that's how I store data myself.

My method:

on start, load all sections from a single ini file into hashtables.
on exit, save all tables not beginning in temp_ to an ini file.
All temporary data (for example, channel stats) is added to tables beginning in temp_
Posted By: Mail Re: making the move from ini to hash - 21/12/05 03:23 PM
I recently discovered after making a shitlist hash table using $addtok to add entries that an item value will only add around 240 characters or so. Therefore if any of your item values are larger than that it won't load or add everything. Feel free to correct me if I am wrong, but thats what I recently discovered and would like to know the limit of characters an item value will store.
Posted By: DaveC Re: making the move from ini to hash - 21/12/05 09:23 PM
mirc script lines max out at around 940 characters
Also variables, hashtable items (non binary) I assume do also (more likely becuase you cant get them in and out at any larger size than they actually error)

I would assume your addtok failed.

* the 940 (aprox) is a accumulitive effect of the variable name and the value so if you have a big variable name you cant have as much data in it.
© mIRC Discussion Forums