pwobjdata - Whats it for?

[Baaleos]

Ok, silly question.

But what is the point of pwobjdata table?

I have had my server running with nwnx for over a year or two, and never needed pwobjdata. What uses this table?

Im guessing it is for storing objects, but if Im not mistaken, SetPersistentObject() still uses
StoreCampaignObject() and merely adds a record of it to the database for logging its owner.


Is there any additional benefits to having the pwobjdata table made?

[Zebranky]

[Baaleos]

I asked someone before ages ago, and they explained it that the StoreCampaignObject was simply hooked, to add a record of the object storage into mySQL.


So, does that mean that a SetPersistentObject() would be less CPU intensive than a RetrieveCampaignObject()???



If so, then I can see the benefit.

[Fireboar]

The answer to that question is no, but I think you meant "is SetPersistentObject() less CPU intensive than StoreCampaignObject()?" To which the answer is yes.

[Baaleos]

Does this mean that
GetPersistentObject()

Would be faster than

RetrieveCampaignObject()


Lol

[Zebranky]

SetPersistentObject calls StoreCampaignObject.
GetPersistentObject calls RetrieveCampaignObject.

Each of the *PersistentObject functions is therefore SLIGHTLY (we're talking microseconds) slower than its corresponding *CampaignObject function.

This directly contradicts what Fireboar said. One of us might be wrong.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/

<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.

<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for?

[Mikel of Avalon]

Curious, on my server i store multiple objects in the mysql db and the storing process is much faster than using the Campaign functions. So i can't believe that using nwnx with SCO/RCO plugin is slower than using the Campaign function. In one of my tests, storing ~100 objects with Campaign function takes over 2 minutes and doing the same with nwnx i can't calculate the time, so i think it takes only some seconds.

Can anyone confirm my testings?
_________________
Mikel of Avalon

Kalandur - Die vergessene Welt

[Gryphyn]

The whole point is that the SCO/RCO functions access the data via a database engine. This means that NWN may not need to access your hard disk when reading or writing data.

The standard Bioware functions always access your hard disk and disk I/O is a costly operation (in particular open and close operations), compared to Memory access. This is where the SCO/RCO provides a performance benefit.

SCO/RCO functions are much faster on average. The very first access of data can be a little slower, but in most cases this will ALSO read in the data you want next as well (and be quicker for that).

Cheers
Gryphyn

As for performance stats.
My vendor system (using my SQLServer plugin) loads 15 vendors (stores) with 500 objects each. It takes about 3 seconds. Slow, but NWScript can only run so fast.

[Asparius]

But what about local variables on object and custom appearance when it is stored in SQL then retrieved?...

[Gryphyn]

[Zebranky]

This is a good discussion. What happens really depends on your choice of DB engine and how exactly things are implemented, but here's my understanding.

The normal campaign DB does usually involve file I/O calls. When hooked by NWNX, it involves calls to the selected NWNX DB engine instead. If it's sqlite, it will also mean file I/O. If it's MySQL, it will mean network I/O (possibly locally, though, which could be significantly faster).

The exact same object data is stored regardless of the DB engine, or even regardless of whether NWNX is in use or not. SCO and RCO deal in the GFF format, and regardless of what you're doing, if these functions are called, the object in question is being translated to or from GFF. The GFF format encapsulates the entire object data set, so no data should be lost going to or from GFF.

Let me emphasize that: If you are using EITHER SetPersistentObject/GetPersistentObject OR SetCampaignObject/RetrieveCampaignObject, every aspect of the object, including appearance, charges, variables, etc., should be maintained perfectly, regardless of settings or whether you're even using NWNX.

I should have been clearer about the efficiency question: SCO/RCO are very slightly faster than SPO/GPO if you are using the NWNX database. Otherwise, SCO/RCO are probably slower, as they will use the BioDB, which involves a lot of file I/O, as Gryphyn mentioned.

--

From a practical standpoint, I've only used MySQL with SCO/RCO (wrapped through SPO/GPO). This seems to be a perfectly acceptable system for most purposes. Use SetPersistentObject/GetPersistentObject when you actually need them (persistent chests, persistent merchants, etc.), and otherwise, don't worry about it.

I hope this clears things up a bit, though I expect there will always be a question of whether we can squeeze more performance out of the SCO/RCO hooks.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/

<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.

<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for?

[Fireboar]

[Baaleos]

Sorry for the lack of replies in this topic, I did create the topic, and I should have paid more attention to it.

Anyhow...

I've decided to create an Auction House / Trade Broker system for my PW, however, I dont want to use one of the ones from the Vault, half the fun is making it yourself. right?

Anyhow.. . .

I was wondering, the SetPersistentObect and GetPersistentObject functions.
I see that in this topic, it is said on and off, that depending on what database is being used, or rather, the name of the database, then the write times and read times will be either better or worse?


Could someone quickly elaborate on this?
Also, if there is any additional Setup required to use the most optimized method of Storing a Persistent Object.


I see in the APS_Include script, the definition for SetPersistentObject, that it tries to insert into the 'val' column, the value %s.

Could someone elaborate on what the %s is for, I have heard in other posts, things about blob data types etc,
is the %s a variable that is used by the nwnx plugin itself, to insert the Item's gff data directly into the database?


If so, how does the GetPersistentObject method turn this data back into an item?

[Fireboar]

Nonono, it's nothing like that. NWNX hooks SCO/RCO if you use NWNX as the table, replacing the default functionality with storing a binary representation of the object in place of %s in the query which is the contents of the local string called NWNX!ODBC!SETSCORCOSQL on the module.

How else can I put it? You can either use SQL, or BioDB. Calling StoreCampaignObject with the first parameter set to NWNX is the trigger for using SQL. The actual name of the database/table in SQL is irrelevant: that's all dealt with in your database query (which you set the local string NWNX!ODBC!SETSCORCO to on the module).

[Baaleos]

So, is there any setup required? - I've got the HookSCORCO set to true in nwnx.ini

I've looked at the SetPersistentObject method, and it seems to use StoreCampaignObject with NWNX by default.


If I understand this correctly, I should be able to use

SetPersistentObject(oPC,"helmet",oHelm);

and it will store binary data in the nwnx pwobjdata table.

oHelm, should be retrievable by performing

GetPersistentObject(oPC,"helmet");

I guess its just confusing with the return function, because it referrs to oObject and oOwner etc.

oOwner is just the object that is going to receive the object - correct?
and
oObject is the object that the returning object is associated with?

In this case, oPC is oObject - the helmet returned was stored associated with them, and without specifying an oOwner object, it will make oOwner, be oObject.

Right....