I posted a personal project of mine (not an official BioWare release): unlimited variable storage. With a single include file and a simple function call in your module script you get full support for unlimited persistent variables and arrays.
This is a 1.0 release and should be solid, but I'm calling it a beta for now. More features will be forthcoming but all functions will remain backwards compatible, so there should be nothing to stop you from using the package now.
Unlimited variable storage
Débuté par
Craig Graff
, févr. 04 2010 03:12
Retour en haut
#2
Posté 04 février 2010 - 01:15
fluffyamoeba
-
- Members
- 264 messages
How does this work? I downloaded it just before work so not had chance to look properly. It appears that you create a storage creature/placeable with an inventory and then make an item that is a token with the variable's name and value stored on it. Is that about right? If so, I have some keyboard/head interactions to do (tenjac will know why 
).
).
#3
Posté 04 février 2010 - 01:48
Tenjac
-
- Members
- 48 messages
Hehehe.... don't bruise your poor self fluffy.
#4
Posté 04 février 2010 - 01:59
Sunjammer
-
- Members
- 925 messages
The following is based on the code before Craig added the load balancing so it may not be 100% accurate ...
Variables are stored as effect variables in a single effect on an item in a invisible placeable in the party picker area (as it is available from anywhere and gets round the "area list" limitation). There is only one area (obviously); one placeable; which can have many items but, if memory serves, only one effect per item.
Individual variables are stored by name in named "general purpose" caches. Each cache corresponds to an item (and the name of the cache becomes the item's tag). The actual variable names are held in an effect string and the position of the string determines the index of variable in the effect's variable list for that data type. This approach allows you to organise variables in to groups or to simply dump them in a single cache at your discression.
Arrays of variables are each stored in a named cache. Each array requires its own cache (and these are separate from the general purpose caches used for individual variables) which again corresponds to an item (and the name of the array becomes the item's tag). The index in the array determines the index variable in the the effect's variable list for that data type. This approach allows for very efficient storage and retrieval of array elements (or entire chunks of the array).
I'll have to double check but the code may allow, I should say not prevent, storing a float array, int array and string array in the same cache however even if you can it is probably best to not.
Variables are stored as effect variables in a single effect on an item in a invisible placeable in the party picker area (as it is available from anywhere and gets round the "area list" limitation). There is only one area (obviously); one placeable; which can have many items but, if memory serves, only one effect per item.
Individual variables are stored by name in named "general purpose" caches. Each cache corresponds to an item (and the name of the cache becomes the item's tag). The actual variable names are held in an effect string and the position of the string determines the index of variable in the effect's variable list for that data type. This approach allows you to organise variables in to groups or to simply dump them in a single cache at your discression.
Arrays of variables are each stored in a named cache. Each array requires its own cache (and these are separate from the general purpose caches used for individual variables) which again corresponds to an item (and the name of the array becomes the item's tag). The index in the array determines the index variable in the the effect's variable list for that data type. This approach allows for very efficient storage and retrieval of array elements (or entire chunks of the array).
I'll have to double check but the code may allow, I should say not prevent, storing a float array, int array and string array in the same cache however even if you can it is probably best to not.
Modifié par Sunjammer, 04 février 2010 - 02:01 .
#5
Posté 04 février 2010 - 02:05
fluffyamoeba
-
- Members
- 264 messages
Yup, roughly speaking that's how the PRC 2da cache system worked in NWN. 
#6
Posté 04 février 2010 - 02:08
Sunjammer
-
- Members
- 925 messages
I should add that you don't need to know any of that if you simply want to use the system!
#7
Posté 04 février 2010 - 02:34
Craig Graff
-
- Members
- 608 messages
There are actually approximately (n / 8000) + 2 placeeables, where n is the number of variables stored. All items are in the first cache, but effects are balanced among the placeables since more than about that many effect variables per placeable tends to slow down storage and retrieval significantly.
Modifié par Craig Graff, 06 février 2010 - 08:44 .
#8
Posté 12 avril 2010 - 02:57
Rogue World
-
- Members
- 46 messages
How is this any different from the Get/Set local functions? Speed?
#9
Posté 12 avril 2010 - 07:31
Proleric
-
- Members
- 2 352 messages
The difference is that Get/Set Local only work with variables you have pre-defined in the 2DA table. Craig's method cuts out that extra work.
#10
Posté 12 avril 2010 - 10:27
Rogue World
-
- Members
- 46 messages
Proleric1 wrote...
The difference is that Get/Set Local only work with variables you have pre-defined in the 2DA table. Craig's method cuts out that extra work.
Thanks for clarifying. I thought that was the case, because I couldn't find any mention of that having changed, but I have been out of the loop for a while.
Thanks.
