Red-alert

   red-alert
   Causes Red Alert status in a mission. This function ends the current mission, and moves to the next mission
   in the campaign under red alert status. There should only be one branch from a mission that uses this expression.
   Takes no arguments.

Comments

Despite what the SEXP description says, red-alert has been tested with a simple branching campaign and it appears that you can branch off of a red-alert mission.

Despite occasional buggy behavior in the past, red-alert works pretty reliably as of FSO version 23.2. Alternatives to red-alert include saving and loading the mission state with scripts12; as well as in-mission jumps.

Usage

If you want to make a red-alert occur as the player jumps out, create an event that waits for the player to hit ALT+J. Chain to it an event that causes the red-alert to occur once the ship has reached jumpout velocity (40 m/s) to give the red-alert a few seconds to go into effect.

• Ships that have the "red-alert-carry" flag will have their hull HP, shield HP, subsystems HP, and weapon ammo counts saved to an internal buffer which is then used to init the red-alert mission.
• The carried ships MUST have the same name and the "red-alert-carry" flag set in BOTH the source mission and the red-alert mission in order for a successful red-alert mission to start.
  • The ships do not have to be the same type, but it is highly recommended that they are if the ships are not a player craft nor in one of the player's wings.
  • Trivia: Older versions of FSO (and FS2) only required the "red-alert-carry" flag be defined in the red-alert mission. Somewhere along the line, this code was refactored to require the flag be present in both the source mission and the red-alert mission.
• By default, the carried ships in the second mission must be present at mission start. The $Red-alert applies to delayed ships: flag allows ships not present at mission start to also inherit red-alert data.