[General] Question on hastbles

[Rybak]

Helloes Hive Workshop
I ask so many questions here that this type of greeting become some kind of my personal initiation ritual...

But to the point: let's say that i have a hashtable of integers. Let's say that I saved some number at the 'point' (as I understand Hashtables represent cartesian coordinates with only positive integers) on the table with coordinates (a, b).

And here's my question - is there a way to get the 'b' value while knowing 'a' and number saved on (a, b)? I couldn't find my answer at the hastable tutorials, they just explain the basics.

 

[Maker]

No, unless you store that data with other keys, which is not practical.

In what kind of situation do you not know both the keys?

 

[Rybak]

I don't understand why are you asking me this, I know one key, i don't know the other. I can always make a loop checking whether the given integer is found, but it will be a big loop. Well, in any case, thanks for the reply.

 

[Maker]

Why don't you know the other key?

 

[shadowvzs]

Helloes Hive Workshop
I ask so many questions here that this type of greeting become some kind of my personal initiation ritual...

But to the point: let's say that i have a hashtable of integers. Let's say that I saved some number at the 'point' (as I understand Hashtables represent cartesian coordinates with only positive integers) on the table with coordinates (a, b).

And here's my question - is there a way to get the 'b' value while knowing 'a' and number saved on (a, b)? I couldn't find my answer at the hastable tutorials, they just explain the basics.

b) u can save b this way: key1: a and key2: 0 (or anything what u dont use, could be 9999 or -1)

 

[Rybak]

Well, I already solved the problem with kinda big loop, but it works.

The case is, just to be stated, I made a save/load function and it has to somehow get the number of item in hero's eq (the number I gave it, not the ID).

By the way, does anybody know why, when loading an integer, when the number is too big, it doesn't load all the 'digits'? I mean, I have an item with index 3301. My function saves it as El (i have 82 numbers there, E is 40 and l is 21). For some reason, as I was checking, the trigger skips 'l' and saves only 'E' giving me 3280, which is empty for now. Any solutions?

 

[Maker]

You could store the number of the item into a hashtable and then load it when you need it.

 

[Rybak]

this is what I do, but I can't simply store it everytime a hero gets it in his eq. I could make a trigger saving it while hero uses and item, while he picks it up, etc., but there is just too many cases, 4000-times loop is much easier and doesn't seem to lag
Besides, even if it would, it's just for saving, loading just gives the given item. There's much more lag creating the hero himself, so I could live with it. But the problem with buggy 82-digits => decimal is troubling me.

 

[shadowvzs]

this is what I do, but I can't simply store it everytime a hero gets it in his eq. I could make a trigger saving it while hero uses and item, while he picks it up, etc., but there is just too many cases, 4000-times loop is much easier and doesn't seem to lag
Besides, even if it would, it's just for saving, loading just gives the given item. There's much more lag creating the hero himself, so I could live with it. But the problem with buggy 82-digits => decimal is troubling me.

maybe make a demo map with only this decimal transforming part

whatever why dont attach things to item type id/raw code and just loop over unit eq (if inventory then 6 slot) ?
because if only for save load then u need loop only at save/loading else only unit acquired item/lost item, i guess no other case, or ur eq's are charged items?

 

[Rybak]

Well, there are some charged, but only cheap potions, I figured I'll leave it be and maybe someday change it.

 

[Dr Super Good]

4000-times loop is much easier and doesn't seem to lag

But has the tendency to crash the thread by hitting the op limit...

But the problem with buggy 82-digits => decimal is troubling me

Thread crash? Maybe your thread is running to many opperating and thus hitting the op limit. Save/load are notorious of doing that unless coded very well (for speed).

Let's say that I saved some number at the 'point' (as I understand Hashtables represent cartesian coordinates with only positive integers) on the table with coordinates (a, b).

Hashtables store a value at the given hashes. As it is a hashtable, the hashes can assume any value (any signed 32 bit integer). Thus -746848 and 9599464 are valid indicies. A hashtable is not an array, although it has O(1) speed initially, it can drop to O(n) speed if too many values are stored in it.

And here's my question - is there a way to get the 'b' value while knowing 'a' and number saved on (a, b)?

Logically not, as that is not supported by a hashtable. Hashtables are designed to go from keys to value, not from part of a key and the value to the other key. This is even more logical when you think that a might have the same value saved many times at different values of b, what you ask would thus have no solution.

Nothing stops you from using another hashtable which maps a and the unique number to b. Many efficient systems do this to allow for data to be seached in both directions.

 

[Rybak]

Why thanks, the second hashtable instead of big loops helped and it works. What I still cannot nail is the problem with conversion 82 digits => 10 digits when having too big numbers. I guess the functions doesn't run too many operations, it's just loop from 1 to 24 (each number corresponds different data saved), then the loop 1 to (1, 2 or 3, depends on how big the saved data is stored) and then loop 0 to 81 (for changing letters into numbers). With saving there's no problem. When i split the trigger into three different ones it wouldn't even get to the problem of too big item index, as it didn't get to data nr 24 (for some reason, always stopped at 23). I don't know, I'll try fixing it some time later, I'm sitting with worldedit since 12 PM (it's almost 5PM here now) and all I did was getting more bugs while changing variables to hashtables