Posessed DBNPC - Please help

[PiX]

TStaticVar is normally not used for database flag storage. It is the same as a TGraalVar (every base data type) except as a global reference. This means that the data would not be stored on the database npc, but actually on a global object, which may be deleted after time or server restart. A common technique for storing persistent dynamic vars to a database npc is using a prefix like this.("option_" @ player.account) . You can then find the full list of accounts by doing getstringkeys("this.option_") .

[Restraint]

Originally Posted by PiX

TStaticVar is normally not used for database flag storage. It is the same as a TGraalVar (every base data type) except as a global reference. This means that the data would not be stored on the database npc, but actually on a global object, which may be deleted after time or server restart. A common technique for storing persistent dynamic vars to a database npc is using a prefix like this.("option_" @ player.account) . You can then find the full list of accounts by doing getstringkeys("this.option_") .

This is a terribly ugly way of doing it, as you need to do (" " @ ) every time.

You can do what you're saying via:

this.options.(@player.account)

The advantages of a TStaticVar instead of that are:

1. Easier to send between server and client via savevarstoarray()
2. Easier to write to a file via savevars()
3. Easier to access with smaller variable names and thus cleaner
4?. I would imagine a guess that .getDynamicVarNames() is an O(c) operation, while .getStringKeys() is an O(n) operation.

Also, you claim it's a "global" reference but no more than a DB NPC's variables are.

The advantages outweigh the disadvantages.

However, I am well aware that TStaticVars do not persist for long periods of time. They seem to have some time limit until they are garbage collected. If you're creating a static variable, you can reload it whenever it's garbage collected. If this is a variable that changes rarely but needs to maintain long-term data, saving it to a file is more persistent than BOTH methods described (And a TStaticVar is ideal for that, via .saveVars()).

As Scriptless has stated, even this.'s can have troubles persisting in DB NPCs. If you want true persistence for long-term database usage, I would suggest either:

1. File I/O. This is best method if the files will not change often (since I/O can be laggy). The easiest method for this is, you guessed it, TStaticVars and .savevars

2. SQL DB. This is the best method if the options will be changing frequently, as reading/writing to SQL is less intense than files.