You might have misunderstood what I was saying. My code works. In fact, I use Data::Dumper all throughout my code to watch my hash grow and shrink. What I was saying was (which works but I don't think its the best way to do it from an ease-of-code point of view) is I am using a hash reference with rvalues of the data as the keys to the hash. Thus a key to %$player_dbref would actually be referenced as $$player_dbref{$player_name}{$ip}{$id} since I don't know what the keys in the reference are yet. Therefore, I have to traverse the hash table to get the values (first the player name, then the ip, and then the id) in the HoH.

Actually, I was able to make a change based from Paladin's comments. May I just say right now...DUH to me in reference to the idea of using $$player_dbref{$player_name}{id} and $player_dbref{$player_name}{ip} for my hash table! Why didn't I think of that?!?! =P (/me humbly kicks himself). I already sent a message to Paladin for his remarks but thank you again Paladin! So I have changed my code as thus and it works *much* better (much easier to add or subtract keys from the hash) and is way more portable. See? I was making it harder than it needed to be.

Also, I now fully understand the arrow operator! Thanks again fellow monks!

As a sidenote I realized something. A hash of hashes need only be as difficult as related to what needs to be unique in the table. In other words, in my code, the unique key was the player name only because that will always be unique in the game (the IP won't always be because of multiple clients running on the client machine and the id would be but I haven't made a clear decision to key off that value yet). Thus, for tracking a player if I don't know what a player's name is I need only traverse the hash for a particular player's name and from there I now have everything I need for that player; the id, the ip, eventually the map, and anything else I need to know about that player.

_ _ _ _ _ _ _ _ _ _
- Jim
Insert clever comment here...