COMBAT.INI

Combat system configuration defining attack moves, defense moves, and combat dialogue (taunts) for all combatants.

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

The file is 54 KB and 3,728 lines, the largest INI in the game. Every move, defense, and voice line for every combatant is defined here, making the combat system fully data-driven.

File Structure

The file contains 474 sections in four types:

The file opens with a block of commented-out constants defining animation group IDs and attack type enums, followed by the sections in the order listed above.

Section suffixes are numeric IDs. A missing section leaves a gap in the ID space; later sections keep their suffixes. Numeric fields contain decimal integers, including signed arc_center offsets. An omitted field is distinct from an explicit zero in the file. Taunt labels retain their RTX spelling, including leading & characters.

Animation Groups

The header comments define the animation group ID table used by animation fields throughout the file:

[misc] Section

Global parameters for the combat system.

[attackNN] Sections

Each [attackNN] section defines one attack move. There are 89 sections (attack00 through attack88).

Attack Types

The type field selects the attack category:

Elevation Values

The elevation field controls the vertical targeting zone:

Field Schema

Standard attack (type 0, 1, 3, 4):

Combo attack (type 2):

Combo sections reference other attack sections by index rather than defining collision geometry directly.

Attack Allocation by Combatant

The file comments identify which attack indices belong to each combatant:

Large creature attacks (Golem, Serpent, Dragon) use col_vertex and col_sphere_size to attach the collision sphere to a specific model vertex rather than the combatant’s origin point.

[defendNN] Sections

Each [defendNN] section defines one defense move. There are 5 sections (defend00 through defend04), shared by Cyrus and guards.

Field Schema

The five shipped defenses correspond to: default (defend00), low (defend01), right (defend02), left (defend03), and high (defend04).

Runtime Attack Loading

The engine scans attack00, attack01, and subsequent numbered sections in order. A section is admitted when either damage or type has a nonempty value. The first section with neither value ends the scan; later sections are not loaded. This runtime rule differs from parsing the INI as a collection of sparse sections.

A non-combo attack loads one move. A combo reads its referenced moves in the order of attack00, attack01, and attack02, using num_attacks as the count. Each attack reserves three zero-initialized motion slots. Loading fills the authored motions and leaves unused slots zeroed. Each move’s numeric loader reads an omitted or empty value as zero. This applies to motion type, ranges, collision and defence timing, arc, damage, force, defence selector, collision vertex, collision sphere size, animation and elevation. Raw INI parsing still distinguishes omission from an explicit zero. The runtime motion record stores the converted value for every loaded field.

Each loaded move adds 97 with signed 32-bit wrapping to its configured animation value to obtain the actor animation group. An omitted animation therefore selects group 97. A single attack copies its move’s minimum and maximum ranges. A nonempty combo starts its minimum at 65,535 and maximum at -1, then lowers the minimum and raises the maximum for each referenced move.

Each attack also retains a damage total, initialized to zero. A single attack adds its move’s damage; a combo adds each referenced move’s damage in authored order. The additions wrap as signed 32-bit values. A combo with no moves retains zero damage. Defence pacing reads this accumulated total, rather than only the first motion’s damage.

Runtime Defense Loading

Defense loading scans defend00, defend01, and subsequent numbered sections in order. A section is admitted when its numeric max_range is nonzero. The first zero value ends the table; later sections are not loaded. Each admitted record loads its minimum and maximum ranges, first collision frame, collision duration, arc and animation. The configured animation value is increased by 97 to obtain the actor animation group.

Actor Move Selection

Combat initialization binds nine attack slots from actor attribute bytes 70 through 78. Each nonzero byte selects the attack record with that index; zero leaves the corresponding slot empty. An empty attack slot does not prevent later attack slots from being populated.

Four defense slots use an attribute cursor starting at byte 79. A nonzero byte selects the defense record with that index and advances the cursor. A zero byte leaves the slot empty without advancing the cursor, so all remaining defense slots also stay empty. Defense selection therefore uses only the nonzero prefix of attribute bytes 79 through 82. A zero selector does not select defend00.

Binding a nonzero defense slot marks its shared defense record available and stores the actor animation group’s signed frame count in that record. An absent animation group supplies zero. The four-slot availability query succeeds when one bound record has its availability marker equal to one.

[tauntNN] Sections

Each [tauntNN] section defines one combat voice line or audio cue. There are 379 sections with indices spanning 00–599, with large gaps between combatant blocks.

An actor’s taunt list begins at its RAEX taunt_id and contains attr_num_taunts consecutive entries. A zero count creates no list. The range is selected per actor; it is independent of which taunt sections are present elsewhere in the file. Without RAEX, the first index is zero. Each actor allocates exactly attr_num_taunts pointers and fills them from that range in order. The per-actor pointer list has no additional sentinel entry.

The loader creates an empty record for each absent section and an additional empty sentinel at max_taunts. Empty records have a zero label, type, and animation. Present records copy the first four rtx_label bytes directly, including a leading &. A nonzero animation value is increased by 152 before storage; zero remains zero and requests no accompanying animation.

Taunt Types

The type field identifies when the taunt fires:

Field Schema

Combat taunt selection is skipped when the actor satisfies IsDead, including the selected player’s death override. Begin-combat writes lifecycle selector 6 before this check; the selected-player override remains independent.

Begin-combat, hurt, death, and opponent-unarmed selection scans the actor’s list in order. Only entries with the requested type and a nonzero RTX label participate. Each matching entry becomes the current selection and consumes one random draw. The scan stops when floor(4 * draw / 32767) == 1; otherwise the last matching entry wins. Death selection retries with the hurt type only when no death entry matched. The other four types have no such fallback.

Taunt Allocation by Combatant

The file comments define the index ranges reserved for each combatant:

Not all reserved slots are populated. Many combatants use only a subset of their allocated range, and some ranges overlap in the comments (Dragon at 580–587 falls inside Pirate Hideout 4 at 570–589).

External References