Skins: |

NWN SCRIPTS

- Jump to comments -

Title

Deity Database v 1.2 - True Persistent Data Without a Database

Author

Meldrachaun

Submitted / Updated

02-07-2005 / 11-22-2006

Category

Database Related

Expansions

Works on all versions

View Code

/**************************  Deity Database v 1.2 *****************************

By Meldrachaun

Deity Database provides database style persistent storage without the hassles
of a true database.  Rather than storing information on the character using
token inventory items, Deity Database stores data in the character's deity
field.  Although the deity field is just a string, strings can store thousands
of characters.  Deity Database parses this string dynamically, allowing for
persistent storage of a large number of data elements, similar to a true
database.

There are two requirements for using the Deity Database.  First, a call to
JMDBInit must be made in the module's OnClientEnter script.
*/

void JMDBInit(object pc);

/*
The second requirement is that somewhere in the module, preferably in an area
that is not accessible to players, there must be a placeable object, with an
inventory, with a tag of JMDB_DATA_VAULT.  This is used to store a temporary
caching object for each player, used to speed up data retrieval.
*/

const
    string JMDB_DATA_VAULT = "JMDB_DATA_VAULT";


/*
******************************************************************************
There are two circumstances that require special coding to use Deity Database.

1) When a database contains over 200 variables, you must make modifications to
   your OnClientEnter script to access persistent data in that script.
   For more information, see comments for the JMDBInitFinished command.

2) Saving data in the OnClientLeave script requires the use of two additional
   functions.  For more information, see comments for the
   JMDBBeginOnClientLeave and JMDBEndOnClientLeave commands.

******************************************************************************
*/

// The following data access commands are provided:

// Retrieves an integer value from the deity database
int JMDBGetInt(object pc, string key);

// Saves the value of an integer in the deity database
void JMDBSetInt(object pc, string key, int value);

// Retrieves a string value from the deity database
//  - limited to 40 characters in length
string JMDBGetString(object pc, string key);

// Saves the value of a string in the deity database
//  - limited to 40 characters in length
void JMDBSetString(object pc, string key, string value);

// Retrieves a longer string value from the deity database
//  - limited to 99 characters in length
string JMDBGetLongString(object pc, string key);

// Saves the value of a longer string in the deity database
//  - limited to 99 characters in length
void JMDBSetLongString(object pc, string key, string value);

// Retrieves a memo string value from the deity database
//  - no limit on number of characters
string JMDBGetMemo(object pc, string key);

// Saves a memo string value from the deity database
//  - no limit on number of characters
void JMDBSetMemo(object pc, string key, string value);

// Retrieves a floating point value from the deity database
float JMDBGetFloat(object pc, string key);

// Saves the value of a floating point number in the deity database
void JMDBSetFloat(object pc, string key, float value);

// Retrieves a vector value from the deity database
vector JMDBGetVector(object pc, string key);

// Saves the value of a vector in the deity database
void JMDBSetVector(object pc, string key, vector value);

// Retrieves a location value from the deity database
location JMDBGetLocation(object pc, string key);

// Saves the value of a location in the deity database
void JMDBSetLocation(object pc, string key, location value);

// Delete Commands
void JMDBDeleteInt(object pc, string key);
void JMDBDeleteString(object pc, string key);
void JMDBDeleteLongString(object pc, string key);
void JMDBDeleteMemo(object pc, string key);
void JMDBDeleteFloat(object pc, string key);
void JMDBDeleteVector(object pc, string key);
void JMDBDeleteLocation(object pc, string key);

/*
The first time the deity database is initialized on a character,
any existing deity that was entered during character creation is
moved into the database as a string, and can be accessed with
JMDBGetString(pc, JMDB_DEITY);
*/
const
    string JMDB_DEITY = "JMDB_DEITY";


/*
***********************************************
*******                                 *******
******* NOTE about OnClientEnter events *******
*******                                 *******
***********************************************
When a database holds over 200 variables, JMDBInit must use DelayCommands to
initialize the database, to avoid "to many instructions" errors.  This should
only be an issue if you are trying to read persistent data in the OnClientEnter
script, and the database has exceeded the 200 variables limit.  In this
circumstance, you must wait until JMDBInit has completed before you can access
persistent data.  The JMDBInitFinished command is used to determine if this has
taken place. To create an OnClientEnter script that will function correctly for
any size database, follow this format in the OnClientEnter script:

void ContinueEntering(object pc) {
    if(JMDBInitFinished(pc)) {

        // All other OnClientEnter tasks go here.
        // Persistent data can now safely be accessed.

    }
    else
        DelayCommand(0.01f, ContinueEntering(pc));
}

void main()
{
    object pc = GetEnteringObject();
    JMDBInit(pc);
    ContinueEntering(pc);
}

*/
int JMDBInitFinished(object pc);

/*
***********************************************
*******                                 *******
******* NOTE about OnClientLeave events *******
*******                                 *******
***********************************************
Calls to SetDeity do not modify the deity in the OnClientLeave event because
the character is saved to the vault before this event fires.  To persist data
in this event, call JMDBBeginOnClientLeave when entering the event, and
JMDBEndOnClientLeave when exiting the event.  This will cause JMDBSet commands
issued between the begin and end calls to be temporarily stored in Bioware's
database.  These values will be saved in the deity field the next time
JMDBInit is called, presumably when the OnClientEnter event fires.

void main()
{
    object pc = GetExitingObject();
    JMDBBeginOnClientLeave(pc);

    // All other OnClientLeave tasks go here.

    JMDBEndOnClientLeave(pc);
}

*/

void JMDBBeginOnClientLeave(object pc);
void JMDBEndOnClientLeave(object pc);

/*
Revision History

1.0 Initial Release
1.1 Fixed some minor bugs
1.2 Added JMDBBeginOnClientLeave, JMDBEndOnClientLeave, JMDBInitFinished
    and JMDBDelete commands.
*/

/*
Note about so-called scripting standards:

There are many, including Bioware, who advocate Hungarian notation for the
naming of scripting variables.  Hungarian notation is simply a one or two
letter prefix at the start of a variable name indicating the variable's type,
such as the letter "o" (for object) at the start of oPC.  Hungarian notation
is a hotly debated subject in the programming industry, and I will not get
into that debate here.  I will say that I disagree with Hungarian notion, so
you will not see it in my code unless I am copying / modifying someone else's
code, and am too lazy to change it.
*/

Select All Text | View Code in separate window

Format

Code Only

Type

Type - Other

Includes

None

Description

Deity Database provides database style persistent storage without the hassles of a true database. Data is stored in the Deity field of the character. The following data types are supported: Integer, Float, Location, Vector, String (40 character length max), LongString (99 character length max) and Memo (string of unlimited string length). The deity entered when the character is first created is not lost, but is stored in the database just as any other string.

Files

Name	Type	Size	Downloads
DeityDatabase12.zipDeityDatabase12.zip Submitted: 02-07-2005 / Last Updated: 03-17-2005	zip	9.62Kb	299
--

SCORE OUT OF 10

10
1 votes
View Stats
Cast Your Vote!

PORTFOLIO

Add this entry to your portfolio so you can track it

Manage your existing portfolios or create a new one.

SCREENS

No Images

You Must Be Logged In to Participate.

Comments (24):

Posted by Meldrachaun at 2005-05-11 15:52:37

By the way, I've done some extensive testing of this. I've been able to store over 70,000 chars in the deity field with out any problems. I suspect the actual limit may be around 2 billion, but that's just an educated guess. I've also been able to store over 1000 different database items. Since the data is cached, read time of the data is as quick as a GetLocal commands. Write access may be a little slower, since it replaces the entire deity string with each write, but modifying the string to save is pretty quick.

Posted by Meldrachaun at 2005-05-11 15:46:42

I'm really sorry I haven't checked this in a while. Didn't know anyone was even looking at the script. Glad you got it working. If anyone else has an issue, please drop me an email at [email protected]

Posted by Stormbringer ( 24.247.xxx.xxx ) at 2005-05-03 22:07:27

Ok, ok Please don't luagh for too long over this but I found my Error that I made after hours of termoil. News to all who download this pak. THIS SYSTEM WORKS BEAUTIFULY, but when you make your custom placable you must remember to check the "HAS INVETORY" solt on the placeable item you've made in order for it all ta work. *Grubles all this time and it was that simple, Slaps self upside the head* Thanks for the script!

Posted by Stormbringer ( 24.247.xxx.xxx ) at 2005-05-03 18:58:42

Well here we go again to try to get this to work right....*Grumbles* Please H..E..L..P.. = S..O..S = S..O..S = S..O..S..

Posted by Stormbinger ( 24.247.xxx.xxx ) at 2005-05-03 18:56:27

Now then I've read your posts again sir. What are the apporpriate calls? Sorry if I seem Dumbfounded by this, errr....But I kinda am. I've been told to get NWNX insted but this seems to be the better idea here if I could only get it to work....

Posted by Strombringer ( 24.247.xxx.xxx ) at 2005-05-03 18:46:13

I want this darn thing to work. but Alis I've run into set-up problems. My first post here was a flustrated example of what the Heck? and How? This post I'm simply gonna ask this: I've set up a placeable with the proper tag, used the onclient enter and onclient leave scripts that you provided with down load. All I get from it is this = The data base is set up wrong or a call to the JMDB is not present. But, I've checked the scripts and the call to it is made via. the script provided in the download. "JMDBInit(GetEnteringObject());" Why not just post a Starter mod with it all set up properly for us younger scripters to import into our mods or vise versa? Because I don't have a clue as to what to change or add to make this work. With a mod of over 500+ areas I need somthing for player storage. *Ponders the idea of just giving up on this system, but notes all the praise it has gotten from others* Please if someone can post a little more detail as to what and where things go to set this system up, I would appreciate it emensly.

Posted by Stormbringer ( 24.247.xxx.xxx ) at 2005-05-03 18:31:48

Please help me set this thing up........I added the placeable. ect. but it still don't work what the hell? I've read the darn instructions a million times thinking its something simple but I cannot make it work. What the Heck am I doing wrong??? HELP!

Posted by nereng at 2005-04-22 06:21:00

Interesting.

I've made a very small test of this system, and can confirm that it works.

Question: (Sorry if this has already been answered.)I have a memory of a topic in the Scripting Forum sometime last spring in which someone stated that the amount of data one could store in the deity string is "practically limitless". Is that the case? Is there a theoretical limit, a practical limit or something like that? Does retrieval-time increase with increased amount of data stored?

I think many builders would like a better description of the functions. A readme with some script-examples (like in the NWN Lexicon) would be helpful.

Cheers!

Posted by Meldrachaun at 2005-03-17 15:56:00

OK, hopefully this will be the final version. It provides for saving data in OnClientLeave events, and allows for
database of any size. Take a look at the comments.

Posted by Meldrachaun at 2005-03-16 22:03:00

I�ve updated Deity Database to fix a bug where cached data can get out of sync with persistent data, when attempting to save data in the OnClientLeave event. Since the character is saved to the vault before the OnClientLeave event occurs, calls to SetDeity in the OnClientLeave event do not update the deity (this is a Bioware "feature"). A warning about this problem has also been added to the comments.

I understand what you are saying about local variables on an inventory item. Both techniques have their pros and cons. This is just an option. As noted earlier, data stored in the Deity field will persist across servers and even modules.

Posted by Larnak ( 67.23.xxx.xxx ) at 2005-03-09 16:53:00

>

Local variables work great for storing all types of info, as long as you are using servervault characters. They do not save on local vaulted or exported characters. We use them to save everything from quest and journal status to the number of times a character has died. The best part is no database to compact, purge or maintain.

Local variables on items are your friend.

Posted by Meldrachaun at 2005-03-08 20:22:00

That would be nice if it were true. Don't know where you got that idea. I had never heard of it, so I wrote a little script to test it, and it doesn't work, not on the PC, not on an inventory item on the PC, and not on an undroppable item in the pc's inventory.

Posted by Chris..S ( 212.159.xxx.xxx ) at 2005-03-08 10:51:00

oops, no name on that last comment of mine. Chris..S (aka Q'el)

Posted by Anonymous ( 212.159.xxx.xxx ) at 2005-03-08 10:49:00

I would think its better to use a non-droppable inventory item and local variables. This system uses an nwn script solution to index the variables. That will without doubt be slower than GetLocalxxx & SetLocalxxx.

Since 1.62 local variables on inventory items are persistent over resets. They will even maintain their state transfering to different servers.

Posted by Chreelister at 2005-03-01 13:16:44 Voted 10.00 on 03/01/05

Posted by Chreelister at 2005-03-01 13:12:00 Voted 10.00 on 03/01/05

I am using this in a PW and so far it works really well, no problems and no lost data. I would recommend everyone to try this out, its much easier to get working than NWNX and that is about the only 2 choices you have in persistent data storage, that is fast and reliable. Also I haven't tested it, but should be persistent over different servers since the data is stored on the character. Maybe Meldrachaun knows more about this.

Posted by Meldrachaun at 2005-02-17 16:45:00

OK, I've updated this to include memo fields, strings of unlimited length

Posted by Meldrachaun at 2005-02-16 22:28:00

Create a usable, placeable object, that has an inventory, in an area not accessible to players. Give that object the tag of JMDB_DATA_VAULT.

Add a call to JMDBInit(GetEnteringObject()); in the module's On Client Enter script.

That's all there is to it. In any script you want to save or retrieve persistent data, just include this script and make the appropriate calls.

Posted by pixelknight at 2005-02-16 22:22:00

The amount of characters in the deity field is certainly a powerful resource used in the way you have put together. The 90 character long string limitation described in your documentation is what was refered too.

It turns out my current project will certainly realize much greater potential from your creation. It would be a big boon having memo texts without character limitation or hashed variable names too. Knat's natural database is another terrific alternative having those sort of things. It would be quite a fluid transition being able to serialze one of those cached databases and saved on a PC, then transported to a someone else's PW server where that data is handled. Imagine easy transfer of trade skills.. farm ownerships.. etc..

On init I saw the database gets cached. Being able to seemlessly use some of the SQL language scripts on that PC held database cache would be exceptionally powerful too.

Posted by pixelknight at 2005-02-16 22:22:00

Posted by Curious ( 216.166.xxx.xxx ) at 2005-02-16 20:48:00

Novel idea. What happens when a player customizes his pc and types in a deity? (Would that be bad?)

Posted by 9Fires ( 24.71.xxx.xxx ) at 2005-02-16 19:20:00

How does one set this up for use in one's mod? I'm kinda new at DBs and would really like some to shed some light on this li'l situation. Explaination please.

Love the concept by the way.

Posted by Meldrachaun at 2005-02-16 08:35:00

I don't think any kind of string limit is going to be an issue, I've stored over 70000 bytes in the Deity field without any problem. I was also able to store 560 database entries without any problem

Posted by pixelknight at 2005-02-15 18:21:00

What a slick idea! Gave me 4 neato ideas just by reading the description. I'll have to see how smoothly this will integrate into my current project.

The character limit on string characters might be a grinding point though.

You must be Logged In to post comments in this section.