About tagging items with variables

[Orleron]

Tagging items with a "homeworld" variable is not as easy as you think. The variable will certainly stick across servers, but when someone goes to put this into a persistent chest, the item is actually destroyed, and remade when the player takes the item out again. Thus, the homeworld variable goes bye bye.

I think that using the new version of NWNX which has object storage may fix this, but there is a problem with that too: disc space. The reason why Avlis has not switched over to this new object storage is because the amount of disc space taken up by storing these objects in the database would figure in the tens of gigabytes for the number of items that are already in storage. It's impractical. We don't have that kind of space.

So while I agree, the homeworld variable is something that is needed, it can't practically be implemented yet. PlasmaJohn is working on a solution that can store objects with less disc space, but it may be some time before he gets that running.

fyi

[JollyOrc]

For Catara, we've developed a chest system that treats each chest as an NPC and then stores the NPC as one object into the db. (in .bic format to be precise. Very neat.) And variables on the items, non-palette items, bags with stuff in them, the order of the items in the inventory, all this seems to get saved. There are still some kinks to work out though.


I've never really looked at it from a storage viewpoint. Let's see now:

the biggest character in my localvault is 100kb. Now, he's got a pretty normal inventory, I guess a fully loaded character would be, what? ~300kb. Let's assume that would be the case.

Avlis has what, 3000 player characters in the vault ? Let's assume that for now. That's nearly 900 MB ...

*whistles*

If every of these characters has three chests, this would be, round up generously, 3 GB. A bigger number than I have thought, but manageable I guess.


Point of this post ? Things should be manageable, we just need to get creative

[Starslayer_D]

Makes me wonder how large the avlis server vault is.

[teleri]

I've never really looked at it from a storage viewpoint. Let's see now:

the biggest character in my localvault is 100kb. Now, he's got a pretty normal inventory, I guess a fully loaded character would be, what? ~300kb. Let's assume that would be the case.

Avlis has what, 3000 player characters in the vault ? Let's assume that for now. That's nearly 900 MB ...

*whistles*

If every of these characters has three chests, this would be, round up generously, 3 GB. A bigger number than I have thought, but manageable I guess.


Point of this post ? Things should be manageable, we just need to get creative

The fat PC is just over 4 MB each that is full set of gear, and every space filled with a bag with differnt 1 space items (: I tested it for giggles. a p-chest with 25 pages of different 1 space items runs just under 2 MB. So your 3000 users translates to 12 GB for the users and 6 GB for the chests. Though I don't believe there are as many chests in Avlis as there are characters. (:

So in total the Avlis char + chest would be about 18 GB and double that for bad storage technique (: so 36 GB not counting back up, which would be 7 days worth (: compressed so about 10 GB each (I am a pessimist here it is probably a better compression ratio) so 70 GB of backup with the 36 GB of active files and you have a nice 106 GB of just characters and storage (:

Storage does become an issue fairly fast.

[JollyOrc]

a 4 MB database dump with ~50 NPC bics (including chests) in it compresses down to 205kb with rar.

The 18 GB backup would thus size down to less than 1 GB.

[teleri]

a 4 MB database dump with ~50 NPC bics (including chests) in it compresses down to 205kb with rar.

The 18 GB backup would thus size down to less than 1 GB.

I know I take the pessimists view and get a nice surprise (: it helps to even out the really bad shocks of dealing with the occasional bad Aurora bug, or the Server not loading even though it loaded yesterday, or the backu script not firing etc,,, been a sysadmin too long need an occasional good thing (:

[JollyOrc]

relatively simple solution: The tag would be a certain variable. Let's call it sOriginalServer.

Let's just create an additional field for the table that stores the pchest stuff.

For every entry in the pchest, you also store those variables we need copap-wide on the items. This would be comparatively quick to implement and not break stuff. It would be a slightly kludgy temporary fix until "true" persistant chests appear.

[teleri]

relatively simple solution: The tag would be a certain variable. Let's call it sOriginalServer.

Let's just create an additional field for the table that stores the pchest stuff.

For every entry in the pchest, you also store those variables we need copap-wide on the items. This would be comparatively quick to implement and not break stuff. It would be a slightly kludgy temporary fix until "true" persistant chests appear.

this would work. But there is this http://carpeterra.com/downloads-17.html which seems to be very close to what we need.

talk about it a bit here viewtopic.php?t=1127

[Orleron]

From the Avlis Team boards comes a possible solution:

On to design...

You really don't want a column per property, that makes changing the property list very difficult. Alex, you've got sort of the right idea, we can encode the properties and arguments as numbers. The containers_2 table has a field called extended which is a numeric index into the item_extension table (doesn't exist yet).

Previously I had proposed the encoding to look something like this:

Code: Select all

0000,0000|0001,0251|...

Basically a sorted delimited list of value tuples. It has to be sorted so that equivalent items will combine counts in the database correctly. The fixed length of the numbers makes operations on the string trivially easy.

The encoding is as follows: the first number of the tuple is the major. The first set (100? 200? 300?) encodes each itemproperty type, so 1 will be Ability Bonus, 2 would be AC Bonus, 3 AC Bonus v. Alignment Group, etc. In addition you need to encode Subproperty, Item Cost Parameter and Parameter 1. For instance A +3 Strength property would be:

Code: Select all

0001,0004,0003,0000

An item with +2 AC vs. Good would look like:

Code: Select all

0003,0002,0002,0000

After the itemproperties, we'd add other encodings:

Code: Select all

0500: variables
  0500,type,name,value
0501: dye
  0501,material type,color
0502: apperance alteration
  0502,partindex,partstyle

For the variables encoding, we'll need a 3rd table: strings. The strings table stores names and string values. Some of the variables will be special:

Code: Select all

_Name: name of item
_Description: item description
_WorldOfOrigin: world name that item was created on
_Signature: signature of whoever crafted the item
_Icon: resref of 2d icon
etc.

Yes, some of those will depend on a form of SCO/RCO.


Soooooo, if anybody's still awake, who's it?