Item

Item objects represent all the kinds of inventory-accessible things players and NPCs can interact with. It includes weapons, wearable objects such as armour, shields,

They are present primarily as UTI blueprint files.

They use baseitems.2da for the basic definition, itemprops.2da to define what item properties can be added, and itempropdef.2da for item property definitions themselves.

Item Basics

The GFF specification for the UTI format is available in PDF form. The main gist is that an item blueprint has different optional properties for some item types such as armour and weapons (having different appearance slots). Some fields may not be applicable to some (such as stacking item properties).

Items can probably never have a negative price. Both the Cost and Additional Cost fields are limited to integers (DWORD specifically). Further testing needs to take place to see how the engine copes if Additional Cost is negative, or even if Cost is negative.

Items are always considered "usable" and glow, can't be placed outside an areas boundaries, and if created by a script must be in an inventory or on a clear place on the ground not up in the air (ie; someone must be able to path to it to be able to pick it up). The script command passes back OBJECT_INVALID if the item is not created.

Items on creature blueprints have an additional, and confusing, flag on them which relates to them being able to drop the item on death. Many module writers customise an OnDeath script instead to drop loot or a selection of what a creature is using at the time.

Items and Player BICs

Relevant information for a player BIC is that an item is copied to it. This includes expensive things for the disk such as item description fields. It's rather odd why the game hasn't (optionally) got a toggle to reference the original blueprint unless a description is overriden.

It's unknown at this time if the engine grabs and stores the entire item description in memory for every object in stores, inventories of NPCs and placeables or anything else.

Item Toolset Limitations

Pricing of Items

The toolset will autogenerate a price for an item based on item properties. It can also adjust the cost upwards (to a maximum of 32767 - which is an odd limit since the GFF specifies it can be a DWORD). Some near-useless item properties can also be added in many cases to make the item even more expensive.

Therefore making a cheaper item isn't possible in the toolset itself by default. There are also no script commands to change an items cost for singleplayer modules (eg; damaged NPC weapons/armour would need to be entirely new - possibly misc - items).

Negative cost item properties can be added in the 2da files, these tend to be set amounts of cost decreasing the items value.

(to test: can an items UTI blueprint can have any random amount set, and the game accepts it? what happens if item properties are then added?)

Stacking Items Limit

The UI in the toolset only allows for "99" as the maximum stack size (at least for ammunition). Higher stack sizes can be defined (eg: 250 arrows in a stack) but a GFF editor is needed to make blueprints with a higher number.

Of course you can increase a limit, use the usual 99 and it will auto-stack once brought into someones inventory as usual. This may be useful anyway since magical arrows tend to get very expensive and a stack of 500 can be 5x the cost.

Scripting Limitations

Until EE changing an items tag was impossible, now SetTag() exists.

Items cannot have their price changed outside of adding or removing item properties.

Stacks of items act weirdly in scripts. They can be merged or split as needed by a player. If used for quest items or custom stores be careful.

Engine Hardcoded Item Notes

Armour Appearances Linked to AC

The chest piece of armour is linked to the AC value directly. These AC values determine if it is Clothing (0) Light (1-3), Medium (4-5) or Heavy (6-7) for the purposes of feats, which are also hardcoded.

Hardcoded Dropped Item Appearances

Some items are multi-part/colourable and have a specific generic model loaded for them; not sure if these can be overriden (ie each armor/cloak get it's own appearance) or not). For normal items they'll load the DefaultModel column in baseitems.2da if no specific model for their ID is available.

Weapons Limited to On-Hand Only

There are some weapon items which are limited to on-hand (right hand) only. This is due to Bioware not coding proper animations in. Alas even if they are unlocked in the baseitems.2da file to be able to be placed in the offhand the game engine still restricts it by knowing the 2da line. A copy of the 2da line may get around this. Examples are flails and heavy flails.

Animations

As per some of the game engine:

There are some "use item" animations that are hardcoded:

Everything else uses the default "Hands, forward" use item animation - so no new potion items that, at least, make sense.

Dragging Potions to Associates

You can drag potions over associates and they'll drink them, this is hardcoded to line 49, Potions.

OnHit Ammo and 1 Remaining

The engine will not fire the OnHit event for ammo when there is only 1 bolt/arrow/bullet remaining. It's a weird quirk of the fact the item has to exist for the script to fire at all, but it doesn't exist when the final ammo flies and hits a target (the on hit happens when it reaches a target on a successful attack roll, including travel time, not when it is released from the ranged weapon).

This makes some ammo related spells with low amounts of ammo very dicey to use reliably.

Hardcoded Weapon VFX

There is a set of hardcoded weapon VFX. You can override any instances with ItemPropertyVisualEffect however.

The priority and info on each type are: