Coffre de stockage persistant pour les joueurs

Persistent Player Item Storage 1.00 - using Bioware campaign database
by OldManWhistler

This is but one of many, many scripts I've written. Check out my portfolio:
http://nwvault.ign.com/portfolios/data/1054937958.shtml


This is a very simple script to allow players to efficiently store items using the Bioware campaign database. It is easily extendable via the user defined functions.

If you are running a large scale PW then use NWNX2 instead because the Bioware campaign database does not scale well at all.

How it works:
- There is a visible chest placeable.
- When the chest placeable is used, it really opens an unique invisible object inventory for that player that is only accessible through the main object. This prevents other players from stealing.
- Items are transfered over to a creature on database reads/writes to minimize DB size and DB access time.

Zip includes example module and erf.


FEATURES
- 2 scripts, 2 placeables, 1 creature.
- Stores items and gold. Handles stackable items properly. Can store an unlimited amount of gold (in 50000 gp stacks).
- Does not store containers (prevents container exploit for storing a lot of items).
- Keeps a running total of the items added/removed.
- Has a userdefined function for preventing access to player storage. Default is to always allow access.
- Has a userdefined function for limiting the number of items that can be stored. Default is 20 items.
- Items are not written to Bioware database until after the player has move 5m away from the inventory creature. This cache significantly reduces the number of database accesses.
- Database access only happens the first time the player opens their chest at a new location and, whenever the player walks away from the chest after having used it.
- Unlimited number of players can access the chest at the same time, with each one using their "unique" storage location. The only physical limit is how close you have to be to the storage location to open it.
- There can be multiple locations for accessing the storage vault.
- Only uses one database record per character.
- Never deletes database records (no need for packing). This keeps the items database as small as possible. (It will only have as many records as you have players).


INSTALLATION

#1: Import the ERF.

#2: Place the "Player Storage Locker" placeable in Containers & Switches where you want a player to have an access point to their storage vault. You can have multiple access points.

#3: Er, that's it.


CUSTOMIZATION

The PPISUserDefinedAllowAccess function in "omw_ppis_start" can be modified to prevent access unless the player meets specific conditions. Some ideas:
- limit based on player level
- limit based on player class
- limit based on faction
- limit based on having paid a one time fee
- limit based on paying a fee to access the vault

The PPISUserDefinedInventoryLimit function in "omw_ppis_disturb" can be modified to prevent storing items unless the player meets specific conditions. Some ideas:
- limit based on number of items
- limit based on item type (no gold, no armor, etc)
- limit based on specific item tags
- set up different amounts of storage space for different fees


ANALYSIS: STORING ON CREATURE VS STORING INDIVIDUAL OBJECTS

I actually implemented this storage system two ways. Method A uses a creature to store the objects and method B individually stores the objects in the database one by one. Profiling was run using the NWNX2 profile and SOU 1.31.

Method A - creature
- Limited to the number of items as can be stored on a single creature (around 100-175 depending on size of items to be stored).
- Can store 360 grid squares worth of items. Actual limit depends entirely on how items are copied over, and how well the space is used.
- There is a real NWN limit of 6 10x6 grid squares worth of items that can be stored on a creature (since it doesn't attempt to use the equippable slots).
- 100 items had DB size of 64kb, storage time of 0.428 sec, retrieval time of 0.092 sec.
- 360 items had DB size of 198kb, storage time of 3.607 sec, retrieval time of 2.397 sec.

Method B - items
- Database is limited to 9999 items (because of unique identifiers).
- Can store 875 grid squares worth of items. Actual limit depends entirely on how items are copied over, and how well the space is used.
- There is a real NWN limit of 25 7x5 grid spaces worth of items that can be stored on a placeable.
- 100 items had DB size of 128kb, storage time of 26.368 sec, retrieval time of 0.084 sec.
- 360 items had DB size of 448kb, time unknown (storage crashed the server at 86.763 sec).

So the clear winner is using the creature to store the items, because you save on DB size, have faster storage times, but *might* lose a little on retrieval time.


CREDITS

I got the idea for doing this from reading a thread by Prophecy Eye on the bioware scripting forum. I'd been thinking of adding persistent storage to the HABD death system for dropped items. Seeing how poorly the Bioware campaign database functions handle storing large chunks of data convinced me against it