NDBE StoreCampaignObject() equivalent ?

[Legacy_MrZork]

               

I am new to scripting with the Bioware database but I have a little project I am testing that needs it. (Sadly, using an external or SQL DB will essentially not work here.) So, I quickly ran into the issue with the native system that the variable name sVarName cannot exceed 32 characters. Blargh.

 

Initially, I was resigned to working out some hashing scheme to get around that limitation, but, I try not to reinvent the wheel more often than I have to and figured someone has probably written some wrappers that get around this issue. I recalled running across the Natural Bioware Database Extension project on the new Vault, one of whose main points is "sVarName parameter for all SetCampaign functions is no longer limited to 32 chars". Woohoo!

 

But, there is no analog for StoreCampaignObject() in NBDE that I can see. And, of course, what I want to store in the DB are item objects.

 

So, am I missing something in NBDE? At first glance, the trick NBDE seems to be using would also work for objects, unless the underlying BW system doesn't support sending objects with inventories (e.g. magic bags) to the DB.

 

Or, is there perhaps another extension to the BW system that would work here?

 

Sorry if this is a trivial issue, but most of my initial search in the forums was turning up answers like, "Use SQL!" which are not helpful in this case.

               
               

               
            

[Legacy_WhiZard]

               

NDBE stores a full database worth of information on a single item.  Object data stored as a local variable would need to be linked to an instance in the module (otherwise the object is invalid).  Objects stored in a database normally would contain all the information needed to create the object, not just a reference ID.

               
               

               
            

[Legacy_MrZork]

               

I am not talking about storing objects as local variables. I know that wouldn't work. I meant that, if the underlying Bioware DB allows storing items (like creatures and magic bags) that, themselves, have inventories, then adding object storage to the NBDE system should be doable by storing the item as an item in the NBDE item's inventory.

 

Of course, I could be misunderstanding what NBDE is doing. My brief peek gave me the impression that NBDE takes the variable name and value that one wishes to store to the DB and (with some hashing) stores it as local on the special DB item (the one whose resref is nbde_database). It can do that for many variables (a whole database's worth) because one can store many locals on the item. Then (eventually) it uses StoreCampaignObject() to write that DB item to the Bioware database for persistence. It does this for ints, strings, floats, etc. because those call all be stored pretty easily as locals on the DB item. It doesn't allow storage of objects because, as you say, SetLocalObject only stores the reference to the object, not the whole object itself.

 

However, I think the underlying BW database allows storage of objects that, themselves, have inventories (like creatures). So, imagine that the NBDE item is set to be a container. Then, the NBDE system might be expanded to include storage of items by simply creating a copy of the item in the DB item's inventory.

 

My proposed expansion depends on that assumption about the sort of items that can be stored to the underlying database. If it is not possible to store items with their own inventories using StoreCampaignObject(), then what I was proposing doesn't work.

               
               

               
            

[Legacy_Lightfoot8]

               

I believe that the only object that gets stored with items intact into the NW database is a creature.   therefore you would have to make your NBDE data base item a creature. 

               
               

               
            

[Legacy_MrZork]

               

It's too bad about that. Not that I am opposed to having a Storage Seagull or whatever, but it would be nice to have a way to do this without having to turn off the AI to avoid it chewing up cycles. And, of course, a creature would require further modifications to the NBDE system, since it puts the DB items into a placeable.

               
               

               
            

[Legacy_WhiZard]

               

I am not talking about storing objects as local variables. I know that wouldn't work. I meant that, if the underlying Bioware DB allows storing items (like creatures and magic bags) that, themselves, have inventories, then adding object storage to the NBDE system should be doable by storing the item as an item in the NBDE item's inventory.

 

What you are suggesting would work and is feasible, however the NDBE is setup to regard each item in the main inventory as its own "mini database" (only one NWN database is ever used with only one object stored.  All the database items are items in the inventory).  It is possible to clump items together via containers but these have limited inventory space.  You could also clump items together by having multiple objects in the NWN database, but that causes less efficiency in writing and retrieving.

               
               

               
            

[Legacy_MrZork]

               

Good point that the containers would be limited by the usual container constraints. For my original purpose, having one container full of items would probably have been plenty. But, it would be a severe limitation for any general system.

 

Within that (considerable) limitation, though, one could potentially still have one DB item represent a whole database. Just copy the names of the items to a local string on each and then rename the items to be the database variable name (possibly meshed with a player name or whatever).

 

It looks like I might be better off just implementing a hashing scheme to get around the variable name length limitations. My primary use was to be storing a handful of items in the database (as opposed to ints, floats, strings, etc.) at each call. Access to longer names without the hassle and overhead of hashing was the primary advantage I was hoping for from NDBE.

               
               

               
            

[Legacy_WhiZard]

               

Within that (considerable) limitation, though, one could potentially still have one DB item represent a whole database. Just copy the names of the items to a local string on each and then rename the items to be the database variable name (possibly meshed with a player name or whatever).

 

If the resref is all you need, then the process is simple.  I was thinking that you were trying to avoid a ton of CopyItemAndModify() commands (especially if the player used craft armor/weapon/dyes) which can be time consuming and lag inducing.

               
               

               
            

[Legacy_MrZork]

               

If the resref is all you need, then the process is simple.  I was thinking that you were trying to avoid a ton of CopyItemAndModify() commands (especially if the player used craft armor/weapon/dyes) which can be time consuming and lag inducing.

Does the CopyItem() function take care of that, with bCopyVars set TRUE? Not that it would be fast, and performance is a concern if one were storing lots of items. But, it would be straightforward to do, and possibly acceptable given the small number of items in play.

 

Anyway, my initial query about NBDE seems answered: It doesn't currently support storing items to the DB, though a modification allowing storage of a small number of items per DB item might be doable.

               
               

               
            

[Legacy_WhiZard]

               

Does the CopyItem() function take care of that, with bCopyVars set TRUE? Not that it would be fast, and performance is a concern if one were storing lots of items. But, it would be straightforward to do, and possibly acceptable given the small number of items in play.

 

If you have the item stored then yes.  If you are recreating the item from the resref then no.