Kato_Yang wrote...
@Meaglyn: So you're saying that 2(or more) keys could have the same associated value? I guess I misunderstood the explanations on the wiki then.(Hash Table topic, workarounds proposed in the example associating person names(key) to their phone number(value))
Kato
Well, not really in a hashset. The example you are using with name to phone number is really a map not a set. The difference ends up being somewhat academic, but with a hashset you are not generally mapping a key to a value explicitly. The key is something which is generated from the value by some sort of hash function. In that case it is very hard to have 2 keys have the same value, that's not how hash functions work. Or functions in general for that matter. A given value will generate one and only one hash key. However, it is possible and in some cases common for _different_ values to generate the _same_ hash key. In that case you need some sort of work around to handle the collision. Often you would back this by an array of dimension equal to the range of the
hash function. This is how you get the o(1) lookups. But since nwnscript doesn't have arrays anyway you can't
really do that anyway.
For what you are doing however I don't think you need to worry abou that. I don't know what's in that 2DA file.
But if all of the ranks are different (i,e. no two rows have the same rank) then what you showed would probably work. But for what it's worth you could skip the whole hashset implementation and just write local ints yourself
named DMG + "rank". You seem to know the rank you need to look up already, which means you know the
variable name to look for.
SetLocalInt(oMod, "DMG" + sKey, nToDivide);
What you're really doing is mapping rank to some value, where rank is not a funtion of value. As long as you know upfront that all the ranks (i.e. keys) are different there's no problem. It doesn't matter if the values are the same
for different ranks.
Cheers,
Meaglyn
