Messages

This article provides an insight into how mission messages are handled by the FreeSpace engine.

Prerequisites

• A rudimentary insight into the SEXP system.

Inputting your messages

Use the right-hand side of the Events Editor (SHIFT-E) to input your messages.

New Msg

Creates a new message entry with the default parameters.

Delete Msg

Deletes the currently selected message. If the message is already used, FRED will ask for confirmation.

Message parameters

Name

This is a shorthand description of what the message is about. Messages will be referenced in FRED through their names. Typical message names are like: "Beta says hello", "Bastion hull critical","Transport panics", "Beta 2 hates Hercs". Optimally, your message names are succinct and descriptive: if you end up with 50-60 messages in a mission, it is imporant to be able to tell what the messages are about by looking at their names. Obscure names like "YEEEEAAAHH" (where the message reads "Good work, pilots. The NTC Abominable has been destroyed. Reinforcements will arrive in 2 minutes.") are not recommended. Transparent message names are all the more important if you cooperate with someone else on the mission. If you do need to change the name of the message, make sure it is not referenced anywhere. You can see which events use the selected message by double-clicking the name of the message in the upper-right message list.

Message Text

The message itself that is sent in-game. Make sure to keep each message at a reasonable length. While the game allows very long messages, the in-game message system cannot display so many characters. A rule of thumb is to stay within a six-line length. If you want a long monolog, simply split it into several messages.

Semicolons and double quotation marks must be avoided, as these characters break the mission file. To insert a semicolon, type in $semicolon. To insert a double quotation mark, type $quote.

ANI file

This is the "talking head" animation on the HUD. See head ani for a list of head animations and corresponding wingmen persona.

Wave file

The sound file that is played while the message is being sent. These sounds are usually intelligible voice-acted lines, but it can also be anything, including untranslated Vasudan gibberish, an engine hum, or something scary, a la Return to Babel.

For unvoice-acted lines, use emptymsg.wav, which is a single beep. According to a 2011 poll, players overwhelmingly prefer the emptymsg.wav over no sound.

Persona

The wingmen persona that is eligible to send the message. If the originally intended sender is dead, but there is another friendly fighter with the same persona, it will send the message instead.

Technically, any ANI file can go with any persona, but for pure esthetics, they must match. See head ani for a list of head animations and corresponding wingmen persona.

Team

Multiplayer only. The message could be sent to all players (like in single player or coop), or sent to either of the TvT teams.

SEXPs to know

Now that you have at least one message in your mission, it is time to instruct FRED to send it in-mission. Create a new event and set the conditions.

There are three SEXPs that send messages.

send-message

The "standard" way of sending messages. Send-message sends a single message.

You need to input the sender (by default: #Command). Any ship, regardless of IFF, that is present in the mission can send messages. You can use right-click --> Replace Data to find your intended sender, or type it in manually. If your sender is not a physically present ship, add a # before the sender,

You also need to set the message's priority. See the dedicated subsection for details

And lastly, you need the message to be sent. You can use right-click --> Replace Data to browse your messages.

send-message-list

Send-message-list is somewhat similar to send-message, but this SEXP allows you to send a whole list of messages. A fourth parameter is added to the SEXP: message delay, which is the delay (in milliseconds) the game will wait before sending the message.

The way this SEXP is input is a bit tricky, however. You need to keep adding the extra parameters manually, using right-click (on the SEXP) --> Add Data. FRED is smart, so if you need to add the priority, it will not give you a list of messages in Add Data.

Tip: Because of how the SEXP works, send-message-list is true when its first message is played, and it checks the ships listed in the event when it becomes true. If a ship that is on the list arrives after the event comes true (e.g. the messages start playing), the event does not recognize that the ship has arrived, and so either does not play the message that corresponds to that ship or tells command to play the message. In this situation, to make sure that the message is played by the ship you want, edit the name of the ship and add a "#" character before the name, as if you were typing "#Command".

training-msg

They are called "training messages," because this method is used in training missions in the Volition campaigns. Training messages are displayed above your lead indicator, centered, in blue text. Training messages have no senders or priorities—the sender is always universal and each new training message will override the previously displayed one.

In retail FreeSpace, a ship called "Instructor" had to be present for training messages to be sent. The Source Code Project, however, removed this restriction.

Training-msg mandates only one parameter: the message. Optionally, you can add three more if you want/need to: a secondary message that is sent if, for whatever reason, the first message cannot be sent; the delay in seconds to wait before sending the message; and the duration of the message. The latter is specially useful if you believe the message will disappear sooner than your players can read it.

Priorities

There are three priorities: High, Normal, Low. Higher-priority messages always interrupt lower-priority messages. Messages of the same priority do not interrupt each other, except for high-priority messages, which always interrupt any message. By interruption, we mean that the next message does not wait until the previous message finishes playing its assigned wave file. If you have no wave file for a message, message priority has no effect as far as interruption is concerned.

Also, high-priority messages are always sent, regardless of the status of its sender (not arrive/arrived/destroyed). If the sender is not readily present, Command will send the message, but the message's head-ani won't be Command's! More often than not, you can see Command with a wingman head-ani, talking like a wingman, because all messages in the given mission are set to high priority. To prevent this, use normal or low priorities, which simply will not be sent if the sender is not present.

A rule of thumb is to assess the importance of the message using common sense. The player must know when the return to base order is issued, or the primary target's hull is going critical so he could respond as quickly as possible. Beta 2 complaining about the Herc II is not nearly as important.

Send-message vs. send-message-list

These SEXPs have their own advantages and disadvantages.

Send-message sends a single message, while send-message-list can send a whole list of them. While this would imply that if you want to script a dialog, send-message-list is flat-out better. When it is in the beginning of the mission—before the action begins$mdash;it is.

Problems arise when you have a dialog in the middle of the mission, and you cannot make sure that all participants of the dialog are present to deliver their lines. Beta 2, who complained about his Herc II in the beginning of the mission, may have died in the action, and if he has a line in the middle of a mission, then (depending on his message's priority) level, it will be sent as either Command or not sent at all. This presents a problem if there's a message that responds to Beta 2, because the game will not break the list of messages just because one if its senders is dead. Depending on the messages, this may end up as a weird, confusing, or even nonsensical dialog. Logically, you can work around this by granting Beta 2 invulnerability, but that affects gameplay, and if players notice it, they can exploit it. <any wingman> is less risky, because it needs only one wingman to be alive. When there's only a wingman-warship dialog, then any wingman can converse with the warship, but if you have a wingman-wingman dialog, then it's a bit harder, because <any wingman> does not randomize which wingman sends the message, but picks the one closest in designation to the player. Chances are, you end up with Alpha 2 conversing with himself.

Using several events with send-message to script conversations allows you to customize the dialog as much as you like, but it requires effort, awareness, and some expertise to pull off flawlessly. If Beta 2 is dead, then Command may something along the lines in the aforementioned example that lets the dialog flow uninterrupted. Or, if you script it so, Beta 2's death could end the dialog after the 5th message. If the dialog is such that the remaining messages are in response to Beta 2's remarks in the 6th message, all you need to do is to restrict the last 3 messages to be sent if Beta 2 is present, using ( not ( destroyed-or-departed-delay "Beta 2" 0 ) ).