Hashset and its uses

[weldieran]

OK - So we're looking at a fancy array system stored OUTSIDE nwserver. (one inside nwserver is not difficult to script, in fact i think bioware has one in one of their _i0_ files)

What are some of the things you have put it to use for?


I was going to use it to store the many variables retrieved from database onto the PC (onClientEnter) - then loop through it onClientExit and savepoints to update the DB data.

But what do you do with hashsets containing Int and String?

I was going to loop through using "HashSetGetNextKey", but in order to retrieve the data of that key, I should know what data TYPE that key corresponds to. So I can do a "HashSetGetLocalString" or "HashSetGetLocalInt" on that key.

There are dirty ways of doing what I want, but this limitation makes me wonder the actual uses of the HashSet plugin.

[Alosynth]

I've forgotten exactly what I used the Hashset function for in the couple of instances I've used it for. One thing I remember doing is using a unique identifier that is assigned to new characters when they join the server as the hashset key. I can then just pull out the variable tied to that key rather than having to loop through a bunch of different results.

I guess it would be mostly useful when you want to store in one place a bunch of different variables with the same varname but belonging to different objects.

For example, you could have a varname "FOO" and three PC's that have a different FOO varable. You can then use the Hashset functions to store these all in the same spot and pull out the FOO variable for PC 1 based on that PC's Unique ID that is used as the Key. (at least if I'm remembering how these functions work correctly)

[Papillon]

Just use two hashsets, one for ints and one for strings.
_________________
Papillon

[weldieran]

ya, that was one of the "dirty" ways i had thought of.

But it just made me wonder what ppl use it for.

I ended up making all the hashsets LocalStrings as the data from the DB is setup that way too (except user and player ID numbers).

Then I just make functions to wrap around the Hashsets to retrieve teh data in the format each variable is supposed to be in.


I had decided I didn't like APS' method of storing data, although I totally understand why APS is setup like that. But really, with high traffic, that APS data can get horrific - returning huge recordsets when trying to lookup a specific player.

Instead I've opted to write my own system which sets up and uses UserID and PlayerIDs. Then the majority of data I track is in one single row of the database (well, different tables for different kinds of data, but all referenced using the PID and/or UID). This would be made easier if NWNx returned the recordset with the ability to reference COLUMN names instead of COLUMN numbers (ie: SQLGetData('autoid'))

Then onClientEnter I load up all that data into hashset for faster (pretty sure) referencing.

Then every 10 minutes (since that PC logged in), it checks the hashset to see if any data had been updated that hadn't been automatically placed in the DB (simple check of a localInt), then updates the DB from that HashSet if it needs it.

1087 lines of code (and more to come) - but its sleek!