Hash problem - mIRC Discussion Forums

I have a hash table that are sorted in numbers. Item 1 and 2 and so on.

But my problem is when I e.g delete item 2. Then the items are 1,3,4..... How can i reorder the table so that 3 and 4 and becomes 2 and 3 so that the 'hole' in the table disapears?

Thanks

Ordering a hash table defeats the pourpose. If what i think you mean is to put it in numeric order, why have a hash table? A hash table is for reading large amounts of information effieciently. Putting them in order would be pointless.

The problem you have is that you are forcing something upon a hashtable that isn't supposed to be. Hash table items are not sorted, nor should they be. There is a fix ofcourse, but it might be easier to just re-organize the content of your hashtable.

Code:

[color:green]; delhole: delete a hole in a numerically sorted hashtable
; usage: /delhole [table] [N][/color]

alias delhole {
  [color:green]; I need one numerical parameter and a table name ![/color]
  if (!$1) || (!$2) || ($3) { 
    echo -a [color:red]Syntax error: Alias delhole accepts exactly two arguments, and not $0 $+ .[/color]
    echo -a [color:red]Correct usage: /delhole table N[/color] 
  }
  elseif (!hget($1)) { 
    echo -a [color:red]Syntax error: The supplied hash table does not exist.[/color] 
  }
  elseif ($2 !isnum) { 
    echo -a [color:red]Syntax error: Argument 2 must be a number representing the hole in the table.[/color] 
  }
  else {
    [color:green]; set start and end of loop[/color]
    var %i = $2,%j = $hmatch($1,*,0)
    [color:green]; start loop[/color]
    while (%i &lt;= %j) {
      hadd $1 %i $hget($1,$calc(%i + 1))
      inc %i
    }
    [color:green]; delete final entry[/color]
    hdel $1 $calc(%j + 1)
    echo -a [color:blue]sequence complete[/color]
  }
}

But as said -- this is an extremely ineffecient way of using hashtables.

Thank you for your help!

The deal about my table is that i have created a login event in my script... like in xp.. for multible users, so that they have their own settings...

And the way the the table works is that i have a %var that contains how many users that are reged. E.g 5 users
So the way that istore the users in the table is

hadd tablename %users nick pass

And when i say delete nr. 3 i get the hole in the table and the mirc freezes.

But if u have a more sufficient way to replace %users, I would be glad to try it out so it gets more sufficient!

I'd store em with their address as the item:

/hadd type-3-address handle password otherinfo

It`s a login system... They don`t have an address yet... this is at the startup of the script the have to login or reg as a new user...

so? the amount of registered users (entries in the table) can be found with $hmatch(table,*,0). Plus - if you can't add em the way I described, you couldn't have added em to your table either...

$hmatch you say.. mhh... doesn`t apear in the help file... So instead of using 'hadd tablename %users name pass' I can use 'hadd tablename $hmatch(table,*,0) name pass' ?

You're not getting the point. Forget about numbering your data. Just /hadd address nick password

But there is no address!

How can anyone who isn`t connected have an address??

If you have a nick you also have an address. If you can add a nick, you can also add an address. Read up on $mask and $address.

i don`t think you understand... The nick has no adress because mirc isn`t connected yet...! When a user is registrering, he inputs the username and the password in a dialog. when ok is pressed it saves the info from the dialog to the hashtable... Thats why i have to use 1,2,3... to save as items... Do you have another way to replace 1,2,3.. with something else?

You mean you expect a user to start his mIRC, keep it disconnected, and manually input nicks and passes of users? Doesn't make sense. Or is it just to save his own nicks and passwords? That would make sense. Please explain in detail what this script is supposed to be doing.

i think he means its a local logon script, like windows 2000 u have to have a valid username and password to be able to logon. youll be logging on to mirc, u have to have a valid username and password logon to mirc and therefor be able to use it.

Never mind.. I think I got it...

But i have a problem with /hsave

its like this:

Code:

  
    var %pass = $encode($did(6))
    hadd brukere $did(2) $did(2) %pass
    hsave -s brukere $gethash(brukere.htb)

the /hsave doesn`t save/work if i don`t use -a or -o. I can`t just /hsave or /hsave -s...

/hsave also supports -o to overwite an existing file, and -a to append to an existing file.

use -o to overwrite a previously saved file.

Also -- for passwords if you want any klind of security, use md5 encryption: $md5(password)

yeah yeah.. i got it now.. it works... Should i only replace $encode with $md5? nothing more?

There's two ways to use $md5 for security

1) for storing passwords, say you have userA with password passA. You would then not save passA on your HD, but 863ca25f827367a6d16d24dd09e92171 ($md5(passA)) instead.
If userA logs in, he gives the pass, the script then does $md5 on the input, and compares it with the stored value.
This way, if someone can read the password list they will only see 863ca25f827367a6d16d24dd09e92171, so they won't know the password of the user.

2) for sending passwords over a insecure connection. The password is saved on the HD as it is (%storedpass = userA). When userA connects, he gets a string (%string = 12345) that hasn't been used before (like $ctime for example). The user then does $md5(%string $+ %pass) and sends the result($md5(12345passA) = 05adda954c1918730f37b9e4aa62c17b) to the server. The server compares that with $md5(%string $+ %storedpass) (05adda954c1918730f37b9e4aa62c17b) to verify the pass. If someone is listening in on the connection, he can't retreive the password of userA, because he only knows what $md5(%string $+ %pass) is. This is of no use, since %string is changed every time, so it can't be used to login again. The only way to get the correct $md5(%string $+ %pass) is to know %pass.

I think you are only interested in 1), since you want to make stored passwords unreadable. (Note that someone could still alter the file with passwords so the saved value matches with whatever he wants)