Scripting.tbl

This feature requires FreeSpace Open

Revision information.....

FSO Revision: 11242

Note: Please update the version when the page is updated. If your edit had nothing to do with new code entries then please do not edit the version

List of Tables and related code files
* Notes Modular Tables
** Notes tables which only use modular tables
Ai.tbl*	/ai/aicode.cpp
Ai_profiles.tbl*	/ai/ai_profiles.cpp
Animation.tbl**	/model/modelanimation.cpp
Armor.tbl*	/ship/ship.cpp
Asteroid.tbl*	/asteroid/asteroid.cpp
Autopilot.tbl*	/autopilot/autopilot.cpp
Cheats.tbl*	/cheats_table/cheats_table.cpp
Colors.tbl*	/globalincs/alphacolors.cpp
Curves.tbl*	/math/curves.cpp
Controlconfigdefaults.tbl	/controlconfig/controlsconfigcommon.cpp
Credits.tbl*	/menuui/credits.cpp
Cutscenes.tbl*	/cutscene/cutscenes.cpp
Decals.tbl**	/decals/decals.cpp
Fireball.tbl*	/fireball/fireballs.cpp
Fonts.tbl*	/graphics/font.cpp
Game_settings.tbl*	/mod_table/mod_table.cpp
Glowpoints.tbl*	/model/modelread.cpp
Help.tbl*	/gamehelp/contexthelp.cpp
Hud_gauges.tbl*	/hud/hudparse.cpp
Icons.tbl*	/mission/missionbriefcommon.cpp
Iff_defs.tbl*	/iff_defs/iff_defs.cpp
Keywords.tbl*	Not In Codebase
Lighting_Profiles.tbl*	/lighting/lighting_profiles.cpp
Lightning.tbl*	/nebula/neblightning.cpp
Mainhall.tbl*	/menuui/mainhallmenu.cpp
Medals.tbl*	/stats/medals.cpp
Messages.tbl*	/mission/missionmessage.cpp
Mflash.tbl*	/weapon/muzzleflash.cpp
Music.tbl*	/gamesnd/eventmusic.cpp
Nebula.tbl*	/nebula/neb.cpp
Objecttypes.tbl*	/ship/ship.cpp
Options.tbl*	Not In Codebase
Particle effects(-part.tbm)**	/particle/effects...
Post_processing.tbl	/graphics/gropenglpostprocessing.cpp
Rank.tbl*	/stats/scoring.cpp
Scpui.tbl*	Not In Codebase
Scripting.tbl*	/parse/scripting.cpp
Ships.tbl*	/ship/ship.cpp
Sexps.tbl**	/parse/sexp/sexp_lookup.cpp
Sounds.tbl*	/gamesnd/gamesnd.cpp
Species_defs.tbl*	/species_defs/species_defs.cpp
Species.tbl*	/menuui/techmenu.cpp
Ssm.tbl*	/hud/hudartillery.cpp
Stars.tbl*	/starfield/starfield.cpp
Strings.tbl*	/localization/localize.cpp
Tips.tbl*	/menuui/playermenu.cpp
Traitor.tbl*	/stats/scoring.cpp
Tstrings.tbl*	/localization/localize.cpp
Virtual_pofs.tbl*	/model/modelreplace.cpp
Weapon_expl.tbl*	/weapon/weapons.cpp
Weapons.tbl*	/weapon/weapons.cpp

The scripting.tbl is used for scripting special features like alternate HUDs or ship viewer into the game.

This table is one of the Modular Tables and can be extended with xxx-sct.tbm

General Info

• Scripting table consist of several sections identified by a hash mark preceding the section name (i.g. #Global Hooks)
• All sections must end with #End
• All sections are optional
• Most entries are optional

Note: Information on this page does not apply to pre-3.6.10 builds

Sections

#Global Hooks

DEPRECATED: Global hooks have been deprecated in favour of state hooks since they are more flexible and can be specified multiple times.

Global hooks are the simplest form of scripting hooks available. They are at preset locations in the code, and are generally executed every time that point is reached. Exceptions to this rule (such as the HUD hook) only depend on one or two variables to determine execution. All other scripting execution is determined by the modder. Note that, as with other tables, the game expects these entries in precisely the order given here; if this is not followed, the parser will throw an error.

$Global:

Script in this section is executed almost immediately before each frame is drawn. This means that any scripting elements will be drawn, or take effect, after everything else, except for the "On Frame" conditional hook. It is not used with the standalone server. In addition, note that use of this hook should generally be avoided, since all scripting will have to be processed every frame.

$Splash:

This hook is executed once, when the splash images (PreLoad and PreLoadLogo) would be drawn. This hook should generally be used only for drawing the splash screen; any initialization could should be placed in GameInit. This hook is executed before virtually any other subsystem has been loaded, aside from the graphics and filesystem subsystems, so scripting elements such as the table and mission libraries will be nonfunctional.

+Override:

Executed just before default splash images are loaded and displayed. Note that the frame is still drawn regardless; it is not necessary to flip the backbuffer manually.

$GameInit:

This hook is executed once, after all of the Freespace2 subsystems have been initialized. It is executed before the game switches to the main hall or, in the case of standalone server mode, begins the game.

$Simulation:

This hook is executed only during missions. It is executed after all damage, movement, physics, SEXPs, and other "physical" in-game changes have been applied. It is executed before anything has been rendered. This hook should be used only for damage, movement, and physics related scripting, as if the game needs to be rendered without any in-game time having been passed, this function will not be called.

$HUD:

The HUD hook is executed after the HUD has been drawn. Note that if the HUD is turned off, this hook will be disabled as well, until the HUD is turned back on.

+Override:

Executed immediately before anything on the HUD is drawn, and controls whether the default FS2_Open is drawn.

#State Hooks

In Freespace2, a "state" more or less refers to a room. It may also refer to a separate mode - playing a mission is the GS_STATE_GAME_PLAY state. The main menu is the GS_STATE_MAIN_MENU state. This section should only exist in 3.6.9. It is included here for the sake of documentation; it has since been removed (Dec 2006) and superseded by the conditional hook system.

$State:

Specifies the state name. A full list of states is located here: List of Game States

$Hook:

Executed after all of the state code has been executed, but before the game frame is actually drawn.

+Override:

Determines whether the specified state is handled at all by Freespace. If true, then none of the loading or exit code for the state will be specified as well.

#Conditional Hooks

Scripting hooks have been available since Sep 2006. They consist of any number of conditions, followed by any number of actions. All available conditions and actions are located in the file generated by -output_scripting.

One way to think of conditional scripting is like this: The condition specifies the object that the action will apply to, or the place that the action will occur in. All conditions must be met for their associated actions to execute. Actions are associated with a set of conditions by simply adding them after that set of conditions. (Obviously, you may want to space out each pair of action/condition sets in the TBL to make it easier to read.)

The flexibility of conditional scripting comes in due to its inherent scalability. If you specify a mission and ship condition with a warpin action, that script will only be executed when the ship warps in on that particular mission. Removing the mission field will make that warpin scripting apply to the ship for all missions; or removing the ship field will make the warpin scripting apply to all ships in that mission.

This prompts the question: if this is all conditional scripting does, why not just use the global hook?

1. Organization - conditional scripting is generally easier to read and modify because it is grouped in a standardized manner.
2. Speed - All conditions can be evaluated by FS2_Open itself, without invoking the Lua interpreter at all.
3. Scalability - As of the time of this writing, you can only have one global hook. Modular tables will simply replace it. With conditional scripting, if you want to specify additional actions for a set of conditions in a modular table file, you may do so.

Format

$Condition:

Where "$Condition:" is one of several conditions specified in scripting.html, such as $State: or $Ship:. Takes a value representing the object the condition should be checked against (such as a state, ship, or mission name)

$Condition:

...

...

$Action:

Where "$Action:" is one of several actions specified in scripting.html, such as $On Frame or $On Warp In. Takes a scripting hook, using the bracket configuration outlined at the top of this article.

$Condition:

...

...

A brief description of all Conditions and Actions at the time of this writing:

Conditions

$Application:

Specifies which application the execution will apply to. Can be FS2_Open or FRED2_Open.

$State:

Controls execution based on what state FS2_Open is in, such as the main hall, options screen, or in a mission.

• The full list of states can be found here: List of Game States

$Campaign:

Controls execution based on the current campaign's filename. (It is under consideration to change this to the campaign's name, instead).

$Mission:

Controls execution based on the filename of the last mission to have started. This condition will remain true even after the mission has been exited until another mission is started.

$Object Type:

Defines a specific object type that the action will apply for, such as a "Ship", "Asteroid", or "Jump Node".

$Ship:

Defines a specific ship (name) that the action will apply for.

$Ship class:

Defines a specific ship class (name) that the action will apply for.

$Ship type:

Defines a specific ship type (name) that the action will apply for.

$Weapon class:

Defines a specific weapon class (name) that the action will apply for.

$KeyPress:

Defines a specific key that the action will apply for.

• Experimental.

$Action:

FS2 Open, 3.7.2:

Defines a specific control that the action will apply for. For example "Fire Primary Weapon" or "Match Target Speed".

Actions

$On Game Init:

Executes immediately after game has been started.

• No associated hook variables.

$On Splash Screen:

Executes when initial game splash screen is shown

• No associated hook variables.

$On State Start:

Executed when specified game state starts

• No associated hook variables.

$On Frame:

Executes immediately after the global scripting hook, which is right before the frame is drawn.

• No associated hook variables.

$On Key Pressed:

Executed when specified key is pressed

• Key, The pressed key

$On Key Released:

Executed when specified key is released

• Key, The released key

$On Mouse Moved:

Executed when mouse is moved

• No associated hook variables.

$On Mouse Pressed:

Executed when mouse button is pressed

• No associated hook variables.

$On Mouse Released:

Executed when mouse button is released

• No associated hook variables.

$On State End:

Executed when specified game state ends

• No associated hook variables.

$On Mission Start:

Executed when mission starts

• No associated hook variables.

$On Gameplay Start:

FS2 Open, 3.6.16:

Executed when the gameplay part of a mission starts

• No associated hook variables.

$On HUD Draw:

Executed after the HUD has been drawn. Note that if the HUD is turned off, this hook will be disabled as well, until the HUD is turned back on

• Self, the viewer (object)

$On Ship Collision:

Executes when the specified object collides with a ship. Sets a handle in the HookVariables library with the name of the object type ("Weapon", "Debris", and so on) with the type of the object. If both objects are ships, the other object gains the name "ShipB". (If both ship objects define a collision hook, the variables will be swapped for the other ship, so the ship that the script is executing for will always be called "Script".) The override will disable FS2_Open code, as well as the other object's collision code. If both objects have an override set, only one of the objects' hooks will be used (Chosen arbitrarily). Note that the override receives the same variables.

• When colliding something other than other ship:
  • Ship, the ship (object)
  • Debris, Asteroid, Weapon, depending what it collided with (object)
  • Self, the object referred by the condition (object)
  • Object, the ship (object)
• When colliding with other ship:
  • Ship, the ship (object) referred by the condition (object)
  • ShipB, the other ship (object)
  • Self, the ship (object) referred by the condition (object)
  • Object, the other ship (object)

$On Weapon Collision:

Like the ship collision hook, but for weapons.

• When colliding something other than other weapon:
  • Weapon, the weapon (object)
  • Debris, Asteroid, Ship, depending what it collided with (object)
  • Self, the object the weapon collided with (object)
  • Object, the weapon (object)
• When colliding with other weapon:
  • Weapon, the weapon (object) referred by the condition
  • WeaponB, the other weapon (object)
  • Self, the weapon (object) referred by the condition
  • Object, the other weapon (object)

$On Debris Collision:

Like the ship collision hook, except for debris.

• Debris, the debris (object)
• Weapon, Ship, depending what it collided with (object)
• Self, the object the debris collided with (object)
• Object, the debris (object)

$On Asteroid Collision:

Like the ship collision hook, only for asteroids.

• Asteroid, the asteroid (object)
• Weapon, Ship, depending what it collided with (object)
• Self, the object the asteroid collided with (object)
• Object, the asteroid (object)

$On Object Render:

Executes when the specified object is rendered. The override is run before the object is rendered, and both the hook and its override receive an "Object" variable of the object to be rendered.

• Self, the object rendered (object)

$On Warp In:

Run when a ship has begun warping in, immediately after everything has been set up for per-frame processing. This hook is only executed once, when the ship begins warping in. An override will disable _all_ behavior related to warpin. Both the hook and an override receive an "Object" handle in the HookVariables library, with the type of the object that is warping in.

• Self, the object warping in (object)

$On Warp Out:

Same as warping in, except for warping out.

• Self, the object warping out (object)

$On Death:

• Currently only valid for ships.

Receives "Self" and "Killer" variables of the object and killer, respectively. Overriding it will override all default death behavior.

• For asteroids:
  • Self, the asteroid (object)
• For ships:
  • Self, the ship (object)
  • Killer, the other object (object) - NOTE, not guaranteed to exists

$On Mission End:

Run on mission end.

• No associated hook variables.

$On Weapon Equipped:

FS2 Open, 3.6.14:

Runs once each frame, for every ship that has the weapon defined in the $Weapon class condition equipped.

• User, the ship carrying the weapon
• Target, the ships' current target

$On Weapon Fired:

FS2 Open, 3.6.14:

Runs once when a ship fires a weapon defined in the $Weapon class condition

• User, the ship carrying the weapon
• Target, the ships' current target

$On Weapon Selected:

FS2 Open, 3.6.14:

Runs once when a bank with a weapon defined in the $Weapon class condition is selected

• User, the ship carrying the weapon
• Target, the ships' current target

$On Weapon Deselected:

FS2 Open, 3.6.14:

Runs once when a bank with a weapon defined in the $Weapon class condition is deselected

• User, the ship carrying the weapon
• Target, the ships' current target

$On Turret Fired:

FS2 Open, 3.6.16:

Executed when a turret fires.

• Ship, the parent ship
• Weapon, the weapon which was fired
• Target, the intended target

$On Ship Arrive:

FS2 Open, 3.7.2:

Executed when a ship arrives.

• Ship, the arriving ship
• Parent, the ship acting as the anchor when arrival location is "in front of ship", "near ship" or "docking bay"; nil or invalid handle otherwise

$On Action:

FS2 Open, 3.7.2:

Executed when an action is triggered, regardless of which key or button it is bound to. Does currently not trigger on mouse or joystick movements.

• Action, the textual description of the action (for example "Fire Primary Weapon" or "Match Target Speed")

$On Action Stopped:

FS2 Open, 3.7.2:

Executed when a continuous action is released (for example "Fire Primary Weapon", "Turn Left" or "Afterburner").

• Action, the textual description of the action

$On Message Received:

FS2 Open, 3.7.2:

Executed when the player receives a message.

• Name, the message name that was received. The message handle can be accessed with mn.Messages[hv.Name]
• Message, the message text that would be displayed on the message gauge. Takes in account scrambled messages and variable replacements.
• SenderString, the displayed string that shows the origin of the message.
• Builtin, boolean, true if the message was a builtin message (eg: automatic messages from Command or wingmen)
• Sender, object handle of the ship that sent the message. This might not always be valid, so check is :isValid() if you need to use it

$On HUD Message Received:

FS2 Open, 3.7.2:

Executed when the HUD should display a message. This is similar to $On Message Received but it will also receive messages that were not generated by a message (e.g "Firing artillery" for SSM strikes).

• Text, the plain text of the message
• SourceType, a number representing the type of the sender. The number can be one of the following:

• 0 A message sent by the computer
• 1 A training message
• 2 A message from a hidden source
• 3 An important message (this type is currently unused)
• 4 An failed message (this type is currently unused)
• 5 An satisfied message (this type is currently unused)
• 6 An message sent by (Terran) command
• 7 A multiplayer message
• ≥8 When the type is greater or equal to 8 then the source is one of the teams in the mission. You can get a team handle using mn.Team[hv.SourceType - 7] (as lua uses 1 based indexes)

$On Afterburner Engage:

FS2 Open, 3.7.4:

Executed when a ship engages its afterburner.

• Ship, the ship object of the ship engaging its afterburner

$On Afterburner End:

FS2 Open, 3.7.4:

Executed when a ship stops its afterburner.

• Ship, the ship object of the ship stopping its afterburner

$On Beam Collision:

FS2 Open, 3.7.4:

Executed when a beam hits something.

---

If the beam hit a ship:

• Self, the target ship that the beam hit
• Object, the beam object that was fired

---

If the beam hit an asteroid:

• Object, the beam object that was fired
• Self, the asteroid that was hit by the beam

---

If the beam hit a weapon, such as a torpedo:

• Object, the beam object that was fired
• Self, the weapon object that was hit by the beam

---

If the beam hit a piece of debris:

• Object, the beam object that was fired
• Self, the debris object that was hit by the beam

$On Beam Fire:

FS2 Open, 3.7.4:

Executed when a beam is fired. This will occur after warm up is complete, as the beam starts to render and give damage.

• Beam, the beam object being fired
• User, the parent ship object firing the beam
• Target, the target object that the beam is trying to hit. Not guaranteed to exist!

$On Campaign Mission Accept:

FS2 Open, 19.0:

Executed when the outcome of a campaign mission is accepted.

$On Ship Depart:

FS2 Open, 19.0:

Executed when a ship departs the mission. This hook accounts for all departure types and it is not limited to only warping.

• Ship, the ship departing

$On Waypoints Done:

FS2 Open, 19.0:

Executed when a ship or wing completes a waypoint path.

• Ship, the ship that completed the waypoint path
• Wing, the wing that completed the waypoint path; nil or invalid handle otherwise
• Waypointlist, the waypointlist that was completed

$On Subsystem Destroyed:

FS2 Open, 19.0:

Executed when a subsystem is destroyed.

• Ship, the parent ship of the destroyed subsystem
• Subsystem, the name of the subsystem that was destroyed (string)

$On Goals Cleared:

FS2 Open, 19.0:

Executed when a ship's goals are cleared via the clear-goals sexp or scripting function.

• Ship, the ship that had it's goals cleared

Misc. Hook Variables:

Viewer

• Active if (non-player) viewing object is valid

Player

• Active if player obj is valid

Examples

See Scripting Examples category