First off, there's a possible problem here if he triggers that code again, while the first time is still running, thanks to the /hfree there.

Secondly, creating a second hash table to sort the first? Oo that seems awfully inefficient.

I deal with indexes plenty, and the trick I use is very simple.
hadd table index-pos.item-name item-value
(example: /hadd Scores 5.PlayerName Player)

But there are two clear flaws with this method:
1) It doesn't offer the kind of sorting /filter does, only indexing.

2) If you remove an object from the list, and it's not the last one on it, then you'll have a Nulled out item breaking your loop.
My solution to this problem is an 'if $hget(table,i.item) != $null' check while I'm looping through the list.

This method does mean you don't have to sort out the list with something as bothersome as some of the codes displayed here, simply keep an index item in the list, and use it to determine the item-name.
Also, it means you can keep more then a single list in the same table.

If you find yourself having loads of Nulled-out items in the list, you can use a binvar as an indexing variable, storing a tokenized list of all the items that actually exist.
Removing, adding, replacing and sorting binvars isn't that complicated at all, neither is tokenizing it and treating it as $1-.
This will make things bigger, in actual size, but it'll still run faster.

Good luck,
ziv.

Last edited by ziv; 18/08/10 09:49 PM.