Database Conversion - The Scripting Side

[Baaleos]

I currently run a World of Rhun server, and I have implimented NWNX with Simtools (by Funkyswerve)

I was wondering if anyone could give me the low down on how to convert the scripting methods from a bioware db using script, to a aps mysql type set.


Specifically, the bioware db currently being used is for the artifact system that accompanys the Rhun mod. (It needs to be able to store objects)

From what I know, the SetPersistentObject() function that comes with aps merely hooks the current StoreCampaignObject() function that is already being used.

Is there any point me converting the system over? Since a SetPersistentObject() would be doing exactly the same as a StoreCampaignObject() call?

Does the Hooking increase system performance, or db reliability?
From what I understand, it would add an extra database dependancy for this functionality.
Eg - Query the nwnx db, then query the bioware db based on the results from the nwnx db - Opposed to the simpler query the bioware db.

Can somone advise?

I have no doubt that nwnx is definitly the way to go for Persistent ints, and strings and such, its just objects that I am concerned about, since I dont think these objects are actually stored in sql, but rather in the bioware db still.

[FunkySwerve]

They're stored in text format in the datbase, the bioware database is completely univolved, and waaaaaaaay slower. You should definitely use it.

As far as storing things in the database goes, what you need to understand is how the variable is associated with the object. With the bioware database, you set it on an object. The nwnx function also takes an object to store the variable (even if the var is another object), but the association simply puts two values into two database columns. For pcs, it inputs pc name and playername, for object it just inputs the tag. Other than that, all you have to worry about the variable name and value. This means using the vars is very similar, with one exception - there is no Campaign Name field in the Persistent int. If you want, you can easily fold the campaign name and variable name into the persistent int's variable name, which is the very simplest way to go about coverting. If you want an example, or that's at all unclear, just post one of your scripts and I'll convert it for you.

Funky

[Baaleos]

Lol, no matter where I post, it always seems to be you giving me a helping hand Funky. Hehe.

Anyhow, Im gonna attach the script inc that comes with Rhun, it was writen by Shayan, and was released few years back, Im sure Shay doesnt mind it being posted, since its freely available on nwnvault.

The comment at the begining of the code regarding the system being unreliable is Shayan's own comment, I believe the reason he believed it to be unreliable was because of its dependency on Bioware db. Ordinarily bioware db seem to work well.... but when you are dealing with a Rhun mod, or a mod that is 100+mb in size, it does seem to suffer. I've found that the db takes sometimes an hour or two to actually update.

(Eg - Player finding an artifact, me querying the db via dm wand, and it takes an hour before the Artifact Log actually registers as <playername> having acquired the artifact.)

If you could give any suggestions on where to start in re-writing this system, or even any suggestions on how to improve the system outside of nwnx would be great.

Currently this script is tied in with onspawn scripts and ondeath scripts. As it uses the nwn hotu treasure chest method. Low,Med,High,Unique and "Artifact" chests. The death or spawn scripts determine the probability of each treasure type spawning.

I think if this inc file were to be re-writen in such a way that it preserved the function definition layouts that it could mean very little else has to be changed in the mod. Eg - Preserve the functions, just change whats inside them.