Skip to content

Creating an offline raid

An offline raid is a local encounter against a boss with a raid shield: one large health pool shown as a stack of bars. The player must bring the whole shield down in one fight to win; surviving until timeout is not a victory. Each attempt begins with the full shield, and nothing carries over between attempts.

Eclipse plays only the shield phase of an original raid. There is no shared boss health, no damage sent to a server, and no second “finish him” fight.

Use the content reference to register these definitions in order:

  1. A zone and a battle with type = "raid".
  2. A warrior for the boss, using a valid template, equipment, and tactic.
  3. An empty loss reward and a victory reward.
  4. A fight that connects the battle, boss, arena, and rewards.
  5. A mode registered with sf2.raids.register that includes the fight.
  6. Quest/map actions that let the player reach the raid.

A raid battle without its offline raid-mode registration is rejected. A registered boss alone does not create a playable map entry.

Two warrior fields describe the shield. They match the original game’s ShieldTotal and ShieldStack warrior attributes.

Field Range Default Meaning
health_bars 0–10000 0 (inherit) The whole shield, measured in normal health bars. A normal fighter has one health bar, so health_bars = 20 takes as much damage as twenty normal fighters.
visible_health_bars 0–100 0 (inherit) How many stacked bars the HUD shows. Each bar holds health_bars / visible_health_bars.
local boss_template = sf2.warriors.register_template {
id = "fire_boss", template = sf2.warriors.get_template("core:warrior-templates/default"),
first_name = "my.mod:localization/fire_boss.name", voice = "Male",
health_bars = 15, visible_health_bars = 15, -- 15 bars of 1.0
}
-- The hard version only raises the shield. It keeps the template's 15 bars, so each
-- bar now holds 20 / 15 = 1.33 normal health bars.
local hard_boss = sf2.warriors.register { id = "fire_boss_hard", template = boss_template, health_bars = 20 }

Each field inherits from the template on its own, as in the original game. If no warrior or template in the chain sets visible_health_bars, the boss shows one bar holding the whole shield. Set visible_health_bars when you want a stack.

Damage is applied in the same units as for any fighter: a hit that would remove 0.25 of a normal fighter’s health removes 0.25 from the shield. Damage carries across bars, and the boss is defeated when the whole shield reaches zero. The HUD shows the current bar on top of the next one (drawn in grey), a new bar fades in from grey, and a counter shows which bar is current, counting down to x 0. Raid shields are separate from the temporary damage-reduction shields that fighter methods add.

The fighter snapshot reports a raid boss’s health and max_health in these shield units, so max_health equals health_bars. Use health / max_health for a fraction. See fighter:snapshot.

For a long boss fight, set rounds = 1 and round_time = 300 in the fight definition. Choose the shield, equipment, and time together so the fight is achievable with the intended player gear.

A reward definition can contain gems from 0 to 1000000, default 0. Put the empty loss reward first and the victory reward next in the fight’s reward list. Rewards are granted through normal fight completion and save handling.

The mode API supports free entry or an optional entry-item requirement. Set hard_mode = true to use the existing Power Mode map filter; special names are not required. Each mod’s IDs keep its zones, bosses, keys, and progress distinct.

The quest API supports raid_fight_enter, raid_fight_end, raid_enter, raid_end, reset_mode, raid_map_enter, raid_floor_changed, and show_raid_loot. raid_enter means entering an attempt; raid_end means completing the sequence. Use the event that matches the progress you want to record.

Check map visibility, entry, boss health bars, victory, loss, timeout, rewards, and retry. If entry consumes an item, also check insufficient items and interrupted attempts. Verify that rewards appear once and remain correct after restarting. A script that loads successfully still needs these in-game checks.