Hi,
well regarding the hash tables, perhaps some people are confused with this, but the N number of slots that you set when making a hash table, doesn't represent the limit of the number of items that can be loaded.
For instance:
/hmake test 1 would mean that a table is made, taking into account that the total amount of items will be +/- (1*10) = 10
/hmake test 10 means a table is made, taking into account to contain around +/- (10*10) = 100 items
This on the other hand doesn't mean that the Hash Table is limited to that number that you put for N slots.
In the help file, it is clearly stated:
---------------------------------------
A hash table can store an unlimited number of items regardless of the N you choose, however the bigger N is, the faster it will work, depending on the number of items stored.
---------------------------------------
So if we do /hmake test 10000, it will create a hash table, taking into account an amount of items at +/- 100000
Though that doesnt mean you cant add more. You can add as many as you want, as long as your RAM lets you. The reason the N is there, is so that mIRC knows how much memory it is going to have to keep available for the hash table data to be stored in memory. The real limit here is in other words, your RAM.
Now the reason that the original poster requested this limit of 10000 for N to be increased, is because of: ".... however the bigger N is, the faster it will work, depending on the number of items stored." Meaning it would be (prolly) be faster to do /hmake test 100000 and load 1 million items, than /hmake test 10000 and load 1 million items. If that wasn't the reason, then I suppose he also thought N would mean the max. number of possible items, which means there is good news for him.
Regarding the "string too long" issue, yes, that is indeed annoying, but there are sometimes ways around that. Binvars etc. come to mind.
Greets
