ITEM.INI

Item database defining all collectible objects, weapons, potions, keys, and quest items with their properties, models, and scripted behaviors.

Shipped sample path: /Redguard/ITEM.INI (e.g. .../GOG Galaxy/Redguard/Redguard/ITEM.INI).

The file is data-driven: every game object from the compass to the soul sword is defined here with associated 3D models, inventory bitmaps, and AI scripts. Item 0 is always the compass, a special case. The file’s comment says giving the player this item turns on the compass display; the display actually toggles when item 0 is used (see compass). Any item index declared as 0 in a weapon or hand-object field is treated as “no object” for this reason.

File Structure

The file contains a single [items] section with two parts:

1. A header block with global inventory settings.
2. Per-item field blocks indexed by item ID (e.g. name[0], type[1]).

[items] Header Fields

Per-Item Field Schema

All fields are optional. Missing fields are treated as unused. The index x in each field name is the item ID used in all script commands.

A field with no text after = is equivalent to an omitted field. Explicit zero remains a stored value. Item lists contain comma-separated decimal item IDs. Paths, script names, and RTX labels retain their spelling and capitalization.

General fields

name[x] and description[x] values are keys into the RTX dialogue/text system, not literal strings. Labels beginning with ? are short display names; labels beginning with ci or ti are longer descriptions.

AI script fields

Using an item

UseItem(id) does nothing while the player is locked out (LockoutPlayer value

1. or in an edge state (10 through 19), after another use attempt in the same world-loop iteration, in shell context, with the inventory closed, in deep water, while holding a weapon, or while lighting or dousing a torch. An unknown or unowned item is an error, and so is a receiver other than the selected player. Ownership requires the current count to be greater than zero as a signed 32-bit value. Counts with the high bit set are rejected before the item-specific action, use script, or drop-list effects. Item zero toggles the compass. Weapon items (type 1) set the weapon attribute and draw the sword, and torch items (code 3) light or put out the torch. A general item starts its use_script as a shell when script_instances is zero or negative or fewer than that many shells of the script are running. It then drops one unit of each drop_use_item_list entry. When that changed the item’s own count and flag bit 2 is set, one unit of the item is dropped; flag bit 4 then empties the item.

Island map request

Using general item 83 sets a pending island-map request before the item’s use script and drop-list processing. The display handler treats this request like the map input action. It clears the request before checking admission, so a rejected request is not retained for a later update. Display requires ownership of item 83, a player lockout value other than 1, and player attribute 105 other than 1. The map screen loads SYSTEM\MAPMAP.GXA and SYSTEM\CROSS.GXA.

Island map screen

An admitted request freezes the simulation clock, stores the player marker position (below) and, when audio is enabled and the current music mode is not 1, switches the music mode to 1 for the duration, restoring it on exit. It then loads SYSTEM\MAPMAP.GXA and SYSTEM\CROSS.GXA, installs the palette read with the second file as palette 5 and activates it. The screen is 640 by 480: the map image is drawn at X 0 with its top at (480 - height) / 2.

The marker position is chosen from the current world when the screen opens. With no selected player or no current world, and in world 0, it is the fixed Q8 position (X 0xC68000, Z 0x793000), which is map units (50816, 31024). In worlds 7 and 14 it is the fixed Q8 position (X -0x196400, Z 0xB1BC00), map units (-6500, 45500). In worlds 1, 6, 27, 28 and 30 it is the selected player’s current position. In every other world the previous position is kept.

Each axis is the map position (the Q8 value divided by 256, truncating toward zero), multiplied by image_width / 65535 and by a per-world scale, then truncated toward zero to an integer and offset. For X the position is used directly; for Z the value is 65536 - z. image_width is the 16-bit width field of the MAPMAP header, used for both axes. In world 6 the scales are 0.82 (X) and 0.53 (Z) and the offsets are -86 (X) and 26 (Z); in every other world the scales are 0.88 and 1.0 and the offsets 101 and -27. The scale factors are single-precision values.

The cross animation plays once: for each frame of CROSS.GXA the map image is drawn again, the frame is drawn at the marker position, the screen is presented and the loop waits 100 ms. The screen then waits for the map action to be released. It then repeats a blocking key wait until the map action and the adjacent action word are both released: the wait polls every 50 ms and returns the first keyboard key, or a code for one of six game-controller button words (0x80, 0x81, 0x84, 0x85, 0x86, 0x87) when no key is down. Any key therefore dismisses the screen once the map action is no longer held. Both images are then freed and the clock resumes.

Objects and bitmaps

Drop and add lists

Weapon fields

Object file paths reference 3DART\ assets, which are the software-renderer models from the original CD release. The GOG release uses fxart/ equivalents at runtime; the 3DART\ paths in this file reflect the original CD asset layout.

Initialization and acquisition

The item database path comes from SYSTEM.INI’s item_ini setting. Initialization first closes the previous item system. For each new item record, it requests a zero-fill of the entire record before assigning its identifier and linking it into the ordered item list. Authored item fields are loaded after this step. Each loaded item’s initial owned count is player_total[x]. The ordered start_item_list then requests acquisition of one unit per entry, including repeated entries. Starting items therefore add to the configured counts rather than replacing them.

Acquisition clamps the requested quantity to both total[x] - player_total[x] and player_max[x] - player_total[x]. A nonpositive result does nothing. For a positive result, every entry in required_item_list[x] must have a nonzero owned count and must recursively satisfy its own requirements.

After requirements pass, acquisition processes drop_add_item_list[x] in order, requesting removal of one unit from each listed item. It then processes add_item_list[x] in order, recursively requesting acquisition of one unit from each entry. These lists run once per acquisition request, independent of the quantity admitted. Active-item fallback selection runs next; the acquired item’s owned count increases last. The quantity is not recalculated after list effects.

The authored player_total[x] assignment and the final acquisition increment write the current owned count only. Neither direct count write replaces the separate pushed-value flag or saved count used by PushItem and PopItem.

An absent start_item_select selects the first loaded item record. A supplied value selects its matching record. This initialization selection does not filter by owned count or visibility.

Empty-selection fallback

Acquisition’s fallback does nothing while an item record is selected. With no selection, it first selects item ID 1 if that record exists, regardless of its owned count, type, or visibility. This is a literal item ID, independent of default_weapon_item.

If item 1 is absent, the fallback scans records in ascending ID order. It selects the first owned type-1 item, or the first owned item of any type if no owned weapon exists. Hidden items remain eligible. If no candidate exists, selection stays empty. Whenever the fallback selects a record, it also writes the low byte of that ID to the selected player’s weapon attribute. The check runs before the acquired item’s count increases, so a newly acquired first unit is not yet owned for that scan.

Removal during acquisition

DropItem(id, quantity) does nothing when the item system is closed or the requested quantity is nonpositive. Otherwise it subtracts at most the item’s current owned count. Flag bit 0x01 then clears that count completely.

The removal-list helper runs after this subtraction and flag handling. It traverses remove_drop_item_list[id] only if the item’s remaining count is nonzero. For each listed item, it recursively applies the same helper and then clears that listed item’s owned count. If the dropped item’s count has reached zero, its removal list is not traversed.

Script count and selection queries

HaveItem(id) returns the item’s owned count, not a Boolean. It returns zero when the item system is closed. With an open item system, an unknown ID reports an item lookup error.

SelectItem(id) selects the matching record without checking its owned count, visibility, or type. It reports an error for an unknown ID. It does not assign the selected player’s weapon attribute.

ActiveItem() takes no script arguments. It returns the selected record’s ID when the item system is open, a record is selected, and the invocation has an actor receiver. Otherwise it returns zero, which is also the compass’s item ID.

Selected-player weapon validation

Before ordinary actor traversal, the engine validates the selected player’s weapon attribute against the open item system. A closed item system or absent invocation receiver leaves weapon state unchanged. Once admitted, validation uses the selected player, even if the supplied receiver is another actor.

A valid weapon requires an animation state, execution outside the shell context, a nonzero weapon attribute, and a matching type-1 item with a positive owned count. If any of these conditions fails, the engine clears the selected player’s weapon attribute and performs the normal weapon cleanup. Item visibility and inventory selection do not affect this check. The check does not acquire or select the configured default weapon.

Item Catalog

87 items are defined (IDs 0 through 86). Item 0 is always the compass.

Notes on specific entries:

• Items 19/20, 21/22, 23/24, 25/26 are paired: the base ingredient and the same ingredient already combined with another substance. Both variants share the same name[x] label.
• Items 29/30 are the empty vial and the vial filled with elixir.
• Items 32/33 are the empty bucket and the bucket filled with water.
• Items 53/57 are the open and closed versions of Izara’s journal, sharing the same name[x] label.
• Item 35 is marked “DO NOT USE” in the file comment; item 36 is the live elven book.
• Item 45 (torch) uses type 3, which the file’s comment block does not define.
• Items 62 and 63 (bar mug, watering can) reuse the journal inventory model (Ijourn.3D) as a placeholder, with distinct game_object_file paths for the actual in-world mesh.
• Items 80 and 81 (dram’s bow and arrow) reuse the bone key inventory model (ibone.3d) as a placeholder.
• Item 86 is labeled “last” with no meaningful content, serving as a sentinel or end-of-list marker.

External References

• UESP: Redguard:Console — documents the item add command, which uses item IDs matching the index numbers in this file.