Question on Item breakdown

11 posts / 0 new
Last post
Question on Item breakdown

I probably just don't understand the ID system yet, as I can't see how items break down into their components.

Take a dead squirrel for example (itemtypes: id 109.16)

The breakdown is "vDegradeTreasureIDs">54,3

however itemtypes 54 and 3 have nothing to do with a squirrel.

What am I missing here?

Degrade treasures don't point to other items, but to treasure tables (basically, whenever/wherever game "gives" player a new item, it does so via a treasure table).

First one, which is a degradation effect from time, points to treasure table 54, which is a small spoiled chunk of meat. The second one, which is a degradation effect from usage, points to table 3, which is empty - it still have to be there, but nothing is added since the squirrel is not usable.

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Ok, so where do I find the treasure tables?

Bottom of the xml file

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

ok, got it...somewhat...

The squirrel item-type (itemtypes: id 109.16) breaks down to treasuretypes of 54(spoiled meat) rather than some other itemtype? Do item-types always break down to treasure-types or can they breakdown to other item-types? Can treasure-types exist and be used on their own, or are they always referred to by an item-type?

Is there a description or discussion about the fields of the treasuretypes that you know of?

For example, the aTreasures field. It looks like that points to itemtypes rather than treasuretypes? Is there a discussion on how all these types inter-relate? Who points to who, or which types use other types?

There is no discussion directly about it, but it's quite easily to figure out, simply by looking at the xml file. Also, all the sticky topics in this sub-forum are about explaining different parts of the xml file, so you can use those. This topic talks about the itemtypes format.

And yes, item degradation is always done via treasure tables. And as I said, the game only creates new items via treasure tables. Tables can contain either items (designated by Group/subGroup) or other treasure tables.

The format is: (Group).(subGroup)x(chance)x(number of items) for items and (table ID)x(chance)x(number of items) for other tables. The chance is given in 1.0=100%, 0.34=34% format. If the entries are divided by comas (",") it means "and" or with those vertical lines ("|") meaning "or". With the second option, the chance is spread among all the items, and the total must be 100%.

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Thanks for the help!

So, the treasuretable entry for a sleeping bag:

table name="treasuretable"
"strName">Sleeping bag

In the aTreasures field, I see that 14.0 generates 75% of the time and 14.1 25%.

In the itemtypes, item 161.14.1 is the mummy sleeping bag, and item 154.14.0 is the normal sleeping bag.

I don't understand why the aTreasures field doesn't require the ID of the itemtypes (161 and 154), and only uses the nGroupID.nSubGroupID ?

They simply don't. It's easier, in case of items, to go by groups/subgroups and not by ID.

Also, you don't give itemtypes with ID at all. So it's not "161.14.1" - it's simply "14.1".

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Thanks for the clarification.

From Dan's stickied message:

Parts of an ID:

◦AA - The ID of the data set we're loading from
◦BB - The ID of the thing we want in that data set
◦CC - The optional subgroup ID of the thing we want (for items that have IDs like BB.CC)

the BB referred to here is the nGroupID of the itemtypes and not the ID field, correct?

Does anything use the first ID field of the itemtype?

No, nothing actually uses the ID of the itemtype (except of the game's loading process itself, so the IDs still need not to double themselves, etc.).

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Just for clarification, items are an exceptional type of data that don't use the ID field at all. Most data in the game uses an ID field because it's an easy way to uniquely identify the object.

However, for items, the nGroupID and nSubgroupID are used instead (As Kaaven says), and this is mainly because there are some groups of items that the game needs to treat similarly. E.g. newspapers, recipe scraps, software, skills, etc.

The ID field is still there for items due to the way it's stored in the database.

Also, the "vProperties" field was something added much later in the game, but probably does a better job of classifying objects than the group IDs, and even the nFormatIDs/ContentIDs (which are used to control which items can go in which containers). I think in future games, I'll probably look for some way to consolidate the nGroupID, nSubgroupID, vProperties, aContentIDs/nFormatID, since they overlap in purpose quite a bit.

Dan Fedor - Founder, Blue Bottle Games