|
|
Post by Aves Dominari on Oct 23, 2012 13:49:27 GMT -5
Blah blah blah, inventory.xt and all that.
If a theoretical modder were to want to create new inventory slots, how would s/he put in the TU costs for this new item? This completely theoretical person would have no idea what line the TU data would go in, although this theoretical person might just end up replacing non-hardcoded parts if, gods forbid, it's impossible to add new ones right now.
|
|
|
|
Post by Kyzrati on Oct 23, 2012 19:52:16 GMT -5
Fortunately almost nothing about inventory is hard-coded, so you can add as many new slots as you like.
The part which still has a small amount of hard-coding and may be tougher to understand are the race-based/anatomy inventory slots (the "usable" BODY slots that allow item manipulation), since those have to go on the HUD, so making someone with three or more hands wouldn't work very well. That and the SPECIAL types you see listed, which are required by the game in order to work.
You can add as many other normal slots as you want, to put on armor, for example (you can also make other anatomy-based BODY slots, but I've never done it myself). The TU matrix is a standard bi-directional matrix where you have to list each slot both across the top (in order matching the list) and down the right (in same order), so that you can define the cost to move something in each direction, e.g. "from hand to backpack" and "from backpack to hand."
ITEM_CHAMBER refers to weapon loading/unloading.
ENTITY_ARMOR values are not referenced, since armor defines its own equip/removal costs.
|
|
|
|
Post by Aves Dominari on Oct 23, 2012 20:02:23 GMT -5
Alright, awesome. That's what I needed to know; the table is in the same order as the list. I'm not doing anything really complicated with the bodies yet; still have five parts and up to two grasps, so there shouldn't be much of a problem.
|
|
