Definitions and behavior

A mod usually has two parts: definitions that describe its content, and functions that respond to gameplay.

Definitions describe what exists

Your entry script runs when Eclipse loads the selected mods. Use it to register items, shop listings, battles, opponents, quests, perks, and other content. Lookups and registrations return handles you pass into later definitions. Define dependencies before the content that uses them.

Your entry script can run more than once in a single launch. The title screen loads the enabled mods once to show their equipment on its sparring fighters (no campaign or profile is loaded then) and discards that load before a campaign or versus session starts, which then loads the mods again. Keep the entry script to registrations and lookups, so every run produces the same content. Anything a player does happens only in the later session load.

Registration does not mean the player has received an item or that a fight is visible: a weapon needs a shop listing or reward, and a battle needs the appropriate quest/map and fight connections.

Callbacks respond to gameplay

A callback is a function you give the API to call later, such as when a round starts. Register it as part of a behavior, then attach the behavior to a perk or enchantment that a fighter can actually have, or directly to a fight through a behavior rule.

-- A callback field inside a behavior definition:
on_round_begin = function(params, fighter, event)
    if fighter.health > 0 then
        fighter:change_health(params.heal)
    end
end

This fragment belongs inside a behavior table, not alone at the top of a script. It requires a declared heal parameter and combat.change_life. See Behavior instances for complete definitions and Combat callbacks for available events.

Choose where state belongs

Need	Use
A number that configures each perk, enchantment, or rule	Behavior parameters.
A value that changes during a round or fight	Behavior instance state with the corresponding lifetime.
Saved behavior state	Saved behavior state, where supported for player-owned instances.
General mod progress between sessions	The mod state API.
Opponent decision memory for one fighter/controller	The memory table in on_decide; it is transient.
A generated encounter that must survive reload	Return or resolve an encounter plan; the host saves it before entry.
An achievement total	Counters and achievements.

A local Lua variable is useful for connecting definitions. It is not automatically a saved value. Use a callback’s fighter handle only during the callback that supplied it.

Choose the appropriate system

Quest tables describe supported events, conditions, and actions. Move triggers describe native animation actions. Tactics accept a documented on_decide function for programmable decisions over currently playable actions. Modes accept on_prepare for procedural encounters and asynchronous choices, and on_result for routing after settlement. UI callbacks handle player interaction. Use those explicit callback boundaries and ordinary Lua control flow; adding an invented callback field does not create a new runtime hook. For combat mutations, use the documented combat callbacks and scoped fighter methods.