FSDeveloper Wiki - User contributions [en-gb]

Mission Editors (3rd party)

2018-09-24T08:55:10Z

Jimkeir: /* List of Editors */

{{:Ambox-Content-WIP}}

{{Infobox-Applicable-FSVersion
| FSXI = false
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
}}

Mission Editors available from 3rd party sources.

== The Basics ==
Re-title as appropriate.

=== What ===
Do what text blurb.

=== Why ===
Do Why text blurb.

=== How ===
Do How text blurb.

=== Where ===
Do Where text blurb.

=== Do's/Don'ts ===
Do's/Don'ts text blurb.

== Formats ==
List of acceptable file formats.
<br>
Filesize or dimensions

== List of Editors ==
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''Availability'''
| style="background:#C0C090;" | '''URL'''
|-
| FSX Mission Editor 2
| Graphically based, highly flexible, with error checking.
| '''* * * * *'''
| Freeware '''¹'''
| [http://www.fsmissioneditor.com/product/fsx-mission-editor/ Try before you buy (8Mb)]
|-
| style="background:#F8EABA;" | FSX Mission Editor 2
| style="background:#F8EABA;" | As above, plus - Debugger, MSI creation.
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Payware '''²'''
| style="background:#F8EABA;" | [http://www.fsmissioneditor.com/product/fsx-mission-editor/ Try before you buy (8Mb)]

|}
* '''¹''' Try before you buy - Restricted feature-set.
* '''²''' Try before you buy - Un-restricted feature-set.

== Related ==

=== Internal ===
[[Link]] - Description

[[Link]] - Description

[[Link]] - Description

=== External ===
{{:Transclusion-Missions-Links-External-Common}}

* [http://www.yoururl.com Site page title] - Description

== Reference ==
'Reference' documents specifically related.

[[Link]] - Description

[[Link]] - Description

[[Link]] - Description

[[Category:Missions]]

Rewards

2008-02-25T15:27:37Z

Jimkeir: /* GUID */

Pilots earn Rewards for completing various missions, and reaching specific accomplishments throughout the game, (in 'Free Flight').

Some of these rewards exist as hidden Easter Eggs to be discovered by pilots. Some missions have multiple and hidden rewards, receipt being dependent on performing additional actions.

Achieved rewards are viewable in the user's pilot records.
== Available In ==
=== Free Flight ===
FSX comes with some rewards which you've probably seen, for things like your first landing and first ten landings. These rewards are obviously not granted explicitly by a mission action, so how do they work?

Each 'free flight' reward needs to have an additional section added to it's definition, the 'Criteria'. These are detailed in the SDK and cover things like the number of landings, types of aircraft flown and airports landed at. You can combine these in any way you like to come up with your specific criteria. When the sim detects that each of the requirements has been met, your reward is granted.

=== Missions ===
In a mission, a reward can be granted explicitly using a [[Function_Reference#Grant_Reward_Action|GrantRewardAction]]. This gives you fine control over exactly what requirements the reward has. For mission-based rewards you shouldn't define Criteria because FSX will pick that up and possibly grant the reward outside the mission.

== Creation ==
Like the other mission elements, Rewards are created as an XML file. Unlike the others, they must be [[Compiling|compiled]] before they can be used.

=== Example XML ===
The XML file looks like this:

<pre>
<FSData version="9.0">
<Reward rewardId = "{00000000-0000-0000-0000-000000000000}"
name = "Demo Reward"
description = "Postcard for doing something right"
type = "POSTCARD"
bitmap = "Images\small-1.jpg"
rewardDetailBitmap = "Images\big-1.jpg"
>
<Criteria landings="3" differentAirports="2"/>
</Reward>
</FSData>
</pre>

As with all other XML, it is very sensitive and removing any symbols, or changing the case of the keywords, will break it. You should be able to see which bits have to be changed though.

=== GUID ===
The <code>rewardId</code> is a GUID (unique identifier) which you will need to generate using GUIDGen.exe or at http://www.guidgen.com . <code>name</code> and <code>description</code> are free text.

=== Type ===
The <code>type</code> element must be one of this list:
* TROPHY
* BADGE
* CERTIFICATE
* MEDAL
* POSTCARD
* SPECIAL_ITEM

=== Bitmaps ===
Finally, the two <code>bitmap</code> elements must point to images, either JPG or BMP, which show small and detailed icons for your new reward. The <code>bitmap</code> image is the small icon, at 100x80 pixels; the <code>rewardDetailBitmap</code> image is larger at 300x370, and is shown as part of the more detailed information.

=== Criteria ===
There are a few different criteria you can set. Filtering by the number of hours the player has flown in a particular aircraft type is done with a <code>RewardHours</code> element and can be one of the following:
* ANY
* DAY
* NIGHT
* VFR
* IFR
* SAILPLANE
* LANDPLANE
* SEAPLANE
* ROTORCRAFT
* MULTI_ENGINE

For example, to grant a reward after the player has flown five hours at night:
<pre>
<RewardHours hoursType="NIGHT" hours="5.0" />
</pre>

Filtering by the airports the player has been to is done using a <code>RewardAirport</code> element. You need to specify the four-letter airport code rather than the name.

This would allow FSX to grant the reward after the player has visited Heathrow:
<pre>
<RewardAirport ident="EGLL" />
</pre>

Finally, you can make a reward dependent on the player having already achieved another reward.
<pre>
<DependantRewardId rewardId="{a guid}" />
</pre>

An entire Criteria section may look something like this:
<pre>
<Criteria landings="3" differentAirports="2"
<RewardHours hoursType="NIGHT" hours="5.0" />
<RewardAirport ident="EGLL" />
<DependantRewardId rewardId="{a guid}" />
>
</pre>
... which would mean that FSX would automatically grant this reward after the player has been to Heathrow, has flown for five hours at night, has already been granted another reward with a specific GUID and has made at least three landings at two different airports.

You don't need to specify all the types of criteria, only the ones you want to use. If you're using the reward as part of a mission, don't leave the Criteria section there, even empty, or FSX will grant the rewards automatically because it will see it has having a criteria of "0 landings at 0 different airports" - which is achieved just by running the sim.

== Tools ==
Tools overview blurb.

=== OS Tools ===
Available with the OS.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''OS'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|}

=== 3rd Party Tools ===
From 3rd party sources.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''Availability'''
| style="background:#C0C090;" | '''URL'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download Page (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|}

== Related ==

=== Internal ===
[[Compiling#Running_the_Reward_Compiler|Compiling Rewards]] - Compilation of a reward xml file.

=== External ===
{{:Transclusion-Missions-Links-External-Common}}

== Reference ==

[[Category:Missions]]

Rewards

2008-02-25T15:26:41Z

Jimkeir: /* Example XML */

Pilots earn Rewards for completing various missions, and reaching specific accomplishments throughout the game, (in 'Free Flight').

Some of these rewards exist as hidden Easter Eggs to be discovered by pilots. Some missions have multiple and hidden rewards, receipt being dependent on performing additional actions.

Achieved rewards are viewable in the user's pilot records.
== Available In ==
=== Free Flight ===
FSX comes with some rewards which you've probably seen, for things like your first landing and first ten landings. These rewards are obviously not granted explicitly by a mission action, so how do they work?

Each 'free flight' reward needs to have an additional section added to it's definition, the 'Criteria'. These are detailed in the SDK and cover things like the number of landings, types of aircraft flown and airports landed at. You can combine these in any way you like to come up with your specific criteria. When the sim detects that each of the requirements has been met, your reward is granted.

=== Missions ===
In a mission, a reward can be granted explicitly using a [[Function_Reference#Grant_Reward_Action|GrantRewardAction]]. This gives you fine control over exactly what requirements the reward has. For mission-based rewards you shouldn't define Criteria because FSX will pick that up and possibly grant the reward outside the mission.

== Creation ==
Like the other mission elements, Rewards are created as an XML file. Unlike the others, they must be [[Compiling|compiled]] before they can be used.

=== Example XML ===
The XML file looks like this:

<pre>
<FSData version="9.0">
<Reward rewardId = "{00000000-0000-0000-0000-000000000000}"
name = "Demo Reward"
description = "Postcard for doing something right"
type = "POSTCARD"
bitmap = "Images\small-1.jpg"
rewardDetailBitmap = "Images\big-1.jpg"
>
<Criteria landings="3" differentAirports="2"/>
</Reward>
</FSData>
</pre>

As with all other XML, it is very sensitive and removing any symbols, or changing the case of the keywords, will break it. You should be able to see which bits have to be changed though.

=== GUID ===
The rewardID is a GUID (unique identifier) which you will need to generate using GUIDGen.exe or at http://www.guidgen.com . <code>name</code> and <code>description</code> are free text.

=== Type ===
The <code>type</code> element must be one of this list:
* TROPHY
* BADGE
* CERTIFICATE
* MEDAL
* POSTCARD
* SPECIAL_ITEM

=== Bitmaps ===
Finally, the two <code>bitmap</code> elements must point to images, either JPG or BMP, which show small and detailed icons for your new reward. The <code>bitmap</code> image is the small icon, at 100x80 pixels; the <code>rewardDetailBitmap</code> image is larger at 300x370, and is shown as part of the more detailed information.

=== Criteria ===
There are a few different criteria you can set. Filtering by the number of hours the player has flown in a particular aircraft type is done with a <code>RewardHours</code> element and can be one of the following:
* ANY
* DAY
* NIGHT
* VFR
* IFR
* SAILPLANE
* LANDPLANE
* SEAPLANE
* ROTORCRAFT
* MULTI_ENGINE

For example, to grant a reward after the player has flown five hours at night:
<pre>
<RewardHours hoursType="NIGHT" hours="5.0" />
</pre>

Filtering by the airports the player has been to is done using a <code>RewardAirport</code> element. You need to specify the four-letter airport code rather than the name.

This would allow FSX to grant the reward after the player has visited Heathrow:
<pre>
<RewardAirport ident="EGLL" />
</pre>

Finally, you can make a reward dependent on the player having already achieved another reward.
<pre>
<DependantRewardId rewardId="{a guid}" />
</pre>

An entire Criteria section may look something like this:
<pre>
<Criteria landings="3" differentAirports="2"
<RewardHours hoursType="NIGHT" hours="5.0" />
<RewardAirport ident="EGLL" />
<DependantRewardId rewardId="{a guid}" />
>
</pre>
... which would mean that FSX would automatically grant this reward after the player has been to Heathrow, has flown for five hours at night, has already been granted another reward with a specific GUID and has made at least three landings at two different airports.

You don't need to specify all the types of criteria, only the ones you want to use. If you're using the reward as part of a mission, don't leave the Criteria section there, even empty, or FSX will grant the rewards automatically because it will see it has having a criteria of "0 landings at 0 different airports" - which is achieved just by running the sim.

== Tools ==
Tools overview blurb.

=== OS Tools ===
Available with the OS.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''OS'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|}

=== 3rd Party Tools ===
From 3rd party sources.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''Availability'''
| style="background:#C0C090;" | '''URL'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download Page (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|}

== Related ==

=== Internal ===
[[Compiling#Running_the_Reward_Compiler|Compiling Rewards]] - Compilation of a reward xml file.

=== External ===
{{:Transclusion-Missions-Links-External-Common}}

== Reference ==

[[Category:Missions]]

Missions - Function Reference

2008-01-11T16:08:34Z

Jimkeir:

[[Mission Object Reference ]]

All of the objects that are available to use in a mission are described in the [[SDK#FSX|SDK]] documentation. Some notes, exceptions and gotchas are listed here.

----
= [[Actions ]] =
Actions are what makes things happen in a mission. There are lots of different actions you can use. An Action only gets used when it is called from a [[#Triggers|Trigger]].

== [[Activate Waypoints Action ]] ==
Both AI objects and 'Living World' mobile scenery can have WaypointLists attached to them. If they do, then the model will move from one waypoint to the next. You can use this action to change the waypoints during the mission, to make these types of object react to the player's actions

== [[Adjust Payload Action ]] ==
This allows you to change the player's payload at a certain point in their aircraft. The payload station number can be found in the corresponding <code>aircraft.cfg</code> file for the player's aircraft, in the <code>[WEIGHT_AND_BALANCE]</code> section.

For example, try using a combination of [[#Random Action]]s, [[#Timer Trigger]]s and AdjustPayloadActions to simulate the effect of the entire New Zealand rugby team starting a brawl in the back or your KingAir 350 just before landing.

The OPT never saves the ObjectReference field of an AdjustPayloadAction. While it's theoretically possible to add or remove payloads from AI, this means it's not really possible unless you hand-edit the XML.

== [[Attach Droppable Payload Action ]] ==
Placeholder text

== [[Attach Effect Action ]] ==
This attaches a visual effect, one of the ones provided in the Effects folder of FSX, to an AI or scenery object. However, it has some significant limitations.

Only models which have AttachPoints built in can be used with an effect. Very few do. Furthermore, if that attachpoint was created with a particular effect in mind, it can never be used with any other effect. Put simply, you can attach effects to the GEN_SceneryEffect model, which is invisible and so can be placed alongside any static visible model. It is highly unlikely that you can attach an effect to the any of the default AI models. In SP1 only (i.e. not RTM, SP2 or Acceleration) you can attach effects to the player.

== [[Change Object Type Action ]] ==
In a more complex mission you might want to make the player fly more than one kind of aircraft. Using this action, you can specify the new container title - found in the aircraft.cfg file - for the type of aircraft you want to change to.

== [[Count Action ]] ==
This adds a value to a [[#Counter Trigger]]. By setting a negative value for ''Count'', you can subtract.

== [[Custom Action ]] ==
These are only useful when working with mission command extensions written using [[SimConnect]]. They pass the ''PayloadString'' value to the extension, which may be either an EXE or a DLL, so that it can perform some kind of action that the normal mission system doesn't support.

== [[Dialog Action ]] ==
The main way for you to interact with the mission player, this will display some text on screen and optionally play a sound file. This would typically be a recorded version of the text message.

These messages can be switched off in the simulator settings, so you can't assume that the sound file is enough. Alternatively, the player have the messages enabled but sound disabled, so you also can't assume that the text is enough. If they have both messages ''and'' sound disabled, that's their problem.

The sound file is relative to the "Sound" subfolder of the mission folder.

Do try to make your visible text and recorded speech match; mismatched subtitles get on my nerves :)

== [[Failure Action ]] ==
Some missions will simulate a system failure and expect the player to deal with it appropriately. Using this action you can make one of the player's aircraft's systems fail (by setting HealthPercent to 0), degrade (HealthPercent < 100) or restore full function (HealthPercent = 100).

== [[Goal Resolution Action ]] ==
These set the state of a [[#Goal Object]] to be one of Pending, Complete or Failed. Only goals which are activated count towards the final result of the mission though, so you can change the list of goals during the mission. When no active goals are pending, the mission finishes.

== [[Grant Reward Action ]] ==
In addition to having the mission finish successfully, you may want to issue a [[Rewards|Reward]] to the player for doing something well, or for finding hidden content. Using this action along with a Reward you can add a reward to the player's flight record.

== [[Object Activation Action ]] ==
Some types of objects, typically Triggers and Scenery, can be activated and deactivated. This is important for the flow of your mission; you should only have the appropriate triggers activated to prevent the player from taking shortcuts. Using this action you can activate and deactivate other objects.

== [[One Shot Sound Action ]] ==
Very simply, this plays a recorded sound when it is called.

== [[Play Animation Action ]] ==
Placeholder text

== [[Play List Action ]] ==
Placeholder text

== [[Point Of Interest Activation Action ]] ==
The mission compass is an easy way of showing the player where they are supposed to be next. When you want to add a new [[#Point Of Interest Mission Object|Point of Interest]] to the compass and select it as the current one, use this action.

== [[Random Action ]] ==
This is almost two actions in one. You can set the percentage of the time that you want this action to do anything at all (''ProbabilityPercent''). Additionally, only one of the items in the ''Actions'' list is fired, again at random.

This can be very useful for creating 'chatter' for making transit sections of your mission a little more interesting. You can have a non-''OneShot'' [[#Timer Trigger]], set maybe to 45 seconds, calling a RandomAction with ''ProbabilityPercent'' of 33 and half a dozen [[#Dialog Action]]s attached.

== [[ResetTimer Action ]] ==
Mainly useful with repeating timers. If you want to check that the player has done something within a certain time, the [[#Timer Trigger]] is fine. However, if you want to use the same TimerTrigger again, the ''StartTime'' needs to be reset to 0. You can't use the [[#Timer Adjust Action]] because it has no 'set' option.

== [[Rumble Action ]] ==
This provides force-feedback in a mission, but only works with XBox rumble-controllers, and not other force-feedback joysticks.

== [[Spawn Action ]] ==
This activates a spawnlist, creating any objects it contains.

== [[Timer Adjust Action ]] ==
Allows you to add or remove (by using negative numbers) the time remaining before a [[#Timer Trigger]] fires.

----
= [[AI Object ]] =
Placeholder text

== [[AircraftAI Object ]] ==
Placeholder text

== [[TakeoffAI Object ]] ==
Placeholder text

== [[LandingAI Object ]] ==
Placeholder text

== [[TaxiAI Object ]] ==
Placeholder text

== [[GroundVehicleAI Object ]] ==
Placeholder text

== [[Waypoint List Object ]] ==
Placeholder text

== [[Waypoint Object ]] ==
Placeholder text

----
= [[Area Definition Object ]] =
On some systems, small AreaDefinitions can be missed by the mission system. Normally this only affects slower PCs and faster-moving aircraft. Try to make the smallest dimensions of an AreaDefinition at least 20 meters to avoid problems on slower PCs.

----
= [[Group Object ]] =
Placeholder text

----
= [[Mission Objects]] =
Placeholder text

== [[Camera Mission Object ]] ==
Placeholder text

== [[Attached World Position Object ]] ==
Placeholder text

== [[Attached World Object ]] ==
Placeholder text

== [[Picture In Picture View Controller Mission Object ]] ==
Placeholder text

== [[Point Of Interest Mission Object]] ==
Placeholder text

== [[Realism Overrides Mission Object ]] ==
Placeholder text

== [[Ridge Lift Mission Object ]] ==
Placeholder text

== [[Scenario Metadata Mission Object ]] ==
Placeholder text

== [[Thermal Mission Object ]] ==
Placeholder text

----
= [[Scenery Objects ]] =
Placeholder text

----
= [[Mobile Scenery Objects ]] =
Placeholder text

----
= [[Spawn List ]] =
This creates new nodes during a mission. You can use it to create visual models in addition to mission actions and triggers. In FSX Acceleration, commands created by a spawnlist can refer to any other object in the mission but in all other versions, including SP2, commands created by a spawnlist ''must'' only refer to other objects in the same spawnlist.

----
= [[Triggers ]] =
Triggers are used to check for key events during the mission. You might check that the player is above a certain altitude, or has landed at a key airport, or that a certain amount of time has elapsed.

== [[Generic Trigger Properties ]] ==
All triggers can be marked as Active or Inactive using the ''Activated'' field. An inactive trigger does nothing. The usual way to make your mission storyline is to use the [[#Object Activation Action]] to enable new triggers once the player has achieved a key task.

Triggers can also be marked as ''OneShot'', which defaults to true. This means that the trigger fires once, and once only. Normally this is what you want to happen, but there are some exceptions.

ProximityTriggers have two Action lists; ''OnEnterActions'' and ''OnExitActions''. If it is a ''OneShot'' trigger, only one set of actions will ever be used because after the first set has fired, the trigger will be deactivated. If you want both sets of actions to be used, you have to mark the triggers as not being ''OneShot'' (that is, untick the box).

Another common use for a non-''OneShot'' trigger is a recurring timer, where you want something to happen, say, every two minutes.

If you want to re-use a trigger after it has been fired, but still want it to disable itself after every time, you can use the [[#Object Activation Action]] to re-enable it.

== [[Airport Landing Trigger ]] ==
Checks that the player, or an AI, has landed or touched down at a specific airport. The associated RunwayFilter object doesn't seem to care which end of the named runway you touch down on; that is, runways 4 and 22 are seen to be the same.

== [[Area Landing Trigger ]] ==
Checks to see that the player, or an AI, has landed or touched down ''anywhere''. This seems to have a lower priority than the [[#Airport Landing Trigger]], so it's common to use this to detect off-airport landings by simply not attaching any AreaRectangle.

== [[Counter Trigger ]] ==
Simply counts up from 0 to whatever level you tell it to. Use this for things like failing the mission if the player ignores five warnings that they must do something.

== [[Menu Prompt Trigger ]] ==
This asks the player to make a choice. It's usually used to give multiple ways of completing a mission by using the different menu items to call [[#Object Activation Action]]s which activate different sets of triggers and goals.

== [[Parking Trigger ]] ==
Placeholder text

== [[Property Trigger ]] ==
One of the more useful triggers, this can check a set of predefined properties of the player or an AI for being higher, lower or equal to a constant value or another property. Properties can also be combined using And/Or/Not, but you need to hand-edit the mission XML to use these groupings.

== [[Proximity Trigger ]] ==
A simple but powerful test, this checks that the player or an AI has entered or left a defined area.

== [[Timer Trigger ]] ==
It's main purpose is to simply wait for a set time and then call an action. However, it can be used for two other things. By setting ''OnScreenTimer'' to True, you get a visible timer in the sim. This can be count-up or count-down, depending on the values of ''StartTime'' and ''StopTime''.

Since this gives visual feedback that the mission system is working, this means it is also a very useful test. If you think that an error is preventing your mission from being loaded at all, create an active, on-screen TimerTrigger. If you get a visible timer, the mission is being run.

----
= [[Goal Object ]] =
Each mission must have at least one Goal. When all active Goals are complete or failed, the mission ends. You can change which goals have to be achieved during the mission by using the [[#Object Activation Action]] to switch them on or off.

----
= [[Reward Object ]] =
Rewards are used in addition to Goals. The player doesn't need to get all the rewards to finish the mission; in fact, they may not even know that rewards are available. They're just a way of saying "Hey, well done!".

Rewards are [[Rewards|created]] in a separate file to the mission, and must be [[Compiling|compiled]] before they can be used.

----
= [[Disabled Traffic Airport Object ]] =
This tells the simulator that it should not create any AI traffic at a specific list of airports. You don't want an unplanned 747 bearing down on you when you're in the last few minutes of a two hour long mission, nursing a crippled Cessna back to earth at Heathrow. It can also affect some triggers which may be set up to fire for any aircraft.

= Related content =
Placeholder text

= External links =
http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx

[[category:FSX]] [[category:Missions]]

Missions - Creation

2008-01-10T18:00:30Z

Jimkeir: /* The Plot */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.com/anglais AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
Along with your mission script, you must provide a [[Briefing]] in an HTML file.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
If you use Rewards, or you want your mission to load a little faster, you must [[Compiling|compile]] them using the [[SDK]]'s command-line tools.

== Function Reference ==
[[Function Reference|This section]] gives some basic details on the different types of object available to mission writers when writing a mission script.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG :

<code>
[Debug]
ReportLoadErrors=1
</code>

Unfortunately there are lots of errors that this won't report. Another way of testing it is [[Compiling]] it; you may get some useful error messages from the compiler.

Sometimes FSX will stop loading your mission completely. There are various reasons for this, but it's usually because an object that should be attached to another isn't, or vice-versa. A very quick way of detecting this is to add an activated TimerTrigger, and set <tt>OnScreenTimer</tt> to True. This makes a small timer appear at the top of the screen as soon as the mission is loaded. If the timer is there, the mission is running. If not, FSX hasn't loaded it because of some kind of structural problem.

Another simple way of adding some debugging information is to add DialogActions to key triggers that don't have one already. This can save you lots of time; two temporary DialogActions saying "LandingTrigger A On" and "LandingTrigger B On" might save you several minutes' flying time on every test. If you make sure your temporary DialogActions have sensible names (i.e. they all start with 'Debug' or 'Temp') they're easy to remove once you no longer need them.

[[category:Missions]]

Rewards

2008-01-08T10:02:11Z

Jimkeir:

Pilots earn Rewards for completing various missions, and reaching specific accomplishments throughout the game, (in 'Free Flight').

Some of these rewards exist as hidden Easter Eggs to be discovered by pilots. Some missions have multiple and hidden rewards, receipt being dependent on performing additional actions.

Achieved rewards are viewable in the user's pilot records.

== Free Flight ==
FSX comes with some rewards which you've probably seen, for things like your first landing and first ten landings. These rewards are obviously not granted explicitly by a mission action, so how do they work?

Each 'free flight' reward needs to have an additional section added to it's definition, the 'Criteria'. These are detailed in the SDK and cover things like the number of landings, types of aircraft flown and airports landed at. You can combine these in any way you like to come up with your specific criteria. When the sim detects that each of the requirements has been met, your reward is granted.

== In-Mission Rewards ==
In a mission, a reward can be granted explicitly using a [[Function_Reference#Grant_Reward_Action|GrantRewardAction]]. This gives you fine control over exactly what requirements the reward has. For mission-based rewards you shouldn't define Criteria because FSX will pick that up and possibly grant the reward outside the mission.

== Creation ==
Like the other mission elements, Rewards are created as an XML file. Unlike the others, they must be [[Compiling|compiled]] before they can be used. The XML file looks like this:

<pre>
<FSData version="9.0">
<Reward rewardId = "{00000000-0000-0000-0000-000000000000}"
name = "Demo Reward"
description = "Postcard for doing something right"
type = "POSTCARD"
bitmap = "Images\small-1.jpg"
rewardDetailBitmap = "Images\big-1.jpg"
>
<Criteria landings="3" differentAirports="2"/>
</Reward>
</FSData>
</pre>

As with all other XML, it is very sensitive and removing and symbols, or changing the case of the keywords, will break it. You should be able to see which bits have to be changed though.

The rewardID is a GUID (unique identifier) which you will need to generate using GUIDGen.exe or at http://www.guidgen.com . <code>name</code> and <code>description</code> are free text. The <code>type</code> element must be one of this list:
* TROPHY
* BADGE
* CERTIFICATE
* MEDAL
* POSTCARD
* SPECIAL_ITEM

Finally, the two <code>bitmap</code> elements must point to images, either JPG or BMP, which show small and detailed icons for your new reward. The <code>bitmap</code> image is the small icon, at 100x80 pixels; the <code>rewardDetailBitmap</code> image is larger at 300x370, and is shown as part of the more detailed information.

=== Criteria ===
There are a few different criteria you can set. Filtering by the number of hours the player has flown in a particular aircraft type is done with a <code>RewardHours</code> element and can be one of the following:
* ANY
* DAY
* NIGHT
* VFR
* IFR
* SAILPLANE
* LANDPLANE
* SEAPLANE
* ROTORCRAFT
* MULTI_ENGINE

For example, to grant a reward after the player has flown five hours at night:
<pre>
<RewardHours hoursType="NIGHT" hours="5.0" />
</pre>

Filtering by the airports the player has been to is done using a <code>RewardAirport</code> element. You need to specify the four-letter airport code rather than the name.

This would allow FSX to grant the reward after the player has visited Heathrow:
<pre>
<RewardAirport ident="EGLL" />
</pre>

Finally, you can make a reward dependent on the player having already achieved another reward.
<pre>
<DependantRewardId rewardId="{a guid}" />
</pre>

An entire Criteria section may look something like this:
<pre>
<Criteria landings="3" differentAirports="2"
<RewardHours hoursType="NIGHT" hours="5.0" />
<RewardAirport ident="EGLL" />
<DependantRewardId rewardId="{a guid}" />
>
</pre>
... which would mean that FSX would automatically grant this reward after the player has been to Heathrow, has flown for five hours at night, has already been granted another reward with a specific GUID and has made at least three landings at two different airports.

You don't need to specify all the types of criteria, only the ones you want to use. If you're using the reward as part of a mission, don't leave the Criteria section there, even empty, or FSX will grant the rewards automatically because it will see it has having a criteria of "0 landings at 0 different airports" - which is achieved just by running the sim.

== Tools ==
Tools overview blurb.

=== OS Tools ===
Available with the OS.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''OS'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| XP
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Vista
|}

=== 3rd Party Tools ===
From 3rd party sources.
{| class="prettytable" style="background:#f2f2f2" border="0"
|--
| style="background:#C0C090;" | '''Tool'''
| style="background:#C0C090;" | '''Description'''
| style="background:#C0C090;" | '''Rating'''
| style="background:#C0C090;" | '''Availability'''
| style="background:#C0C090;" | '''URL'''
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download Page (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|-
| Tool Name
| Descriptive blurb
| '''* * * * *'''
| Payware
| [http://www.yoururl.com Download (SizeMb)]
|-
| style="background:#F8EABA;" | Tool Name
| style="background:#F8EABA;" | Descriptive blurb
| style="background:#F8EABA;" | '''* * * * *'''
| style="background:#F8EABA;" | Freeware
| style="background:#F8EABA;" | [http://www.yoururl.com Download Page (SizeMb)]
|}

== Related ==

[[Compiling#Running_the_Reward_Compiler|Compiling Rewards]] - Compilation of a reward xml file.

== Reference ==

[[Category:Missions]]

Briefing

2008-01-07T15:24:34Z

Jimkeir: New page: = The Briefing File = Once a player has selected your mission and clicked 'Fly', they are taken to a briefing page. This is simply an HTML file, with a description of what the mission is ...

= The Briefing File =

Once a player has selected your mission and clicked 'Fly', they are taken to a briefing page. This is simply an HTML file, with a description of what the mission is about. All of the default briefings follow the same style and, while you're free to come up with your own unique style, keeping to the same one maintains the 'look and feel' of FSX and makes your mission fit well with the rest.

You can copy any of the existing briefing files, found in the various folders under the <tt>Missions</tt> folder, and edit those. Likewise, any HTML editor can be used to edit them. Both [http://www.microsoft.com/word/ MS Word] and the free [http://www.openoffice.org/ OpenOffice] can visually edit HTML, although both make lots of changes without your permission and you can end up with extremely large HTML files. Alternatively, any text editor such as Notepad or [http://www.notepad2.com/ Notepad2] will let you edit the HTML directly.

Once your briefing file is created, you need to set your [[Function_Reference#Scenario_Metadata_Mission_Object|ScenarioMetadata]] object to point at it so that FSX knows what file to load.

Missions - Creation

2008-01-07T15:13:15Z

Jimkeir: /* Briefing */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.net/ AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
Along with your mission script, you must provide a [[Briefing]] in an HTML file.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
If you use Rewards, or you want your mission to load a little faster, you must [[Compiling|compile]] them using the [[SDK]]'s command-line tools.

== Function Reference ==
[[Function Reference|This section]] gives some basic details on the different types of object available to mission writers when writing a mission script.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG :

<code>
[Debug]
ReportLoadErrors=1
</code>

Unfortunately there are lots of errors that this won't report. Another way of testing it is [[Compiling]] it; you may get some useful error messages from the compiler.

Sometimes FSX will stop loading your mission completely. There are various reasons for this, but it's usually because an object that should be attached to another isn't, or vice-versa. A very quick way of detecting this is to add an activated TimerTrigger, and set <tt>OnScreenTimer</tt> to True. This makes a small timer appear at the top of the screen as soon as the mission is loaded. If the timer is there, the mission is running. If not, FSX hasn't loaded it because of some kind of structural problem.

Another simple way of adding some debugging information is to add DialogActions to key triggers that don't have one already. This can save you lots of time; two temporary DialogActions saying "LandingTrigger A On" and "LandingTrigger B On" might save you several minutes' flying time on every test. If you make sure your temporary DialogActions have sensible names (i.e. they all start with 'Debug' or 'Temp') they're easy to remove once you no longer need them.

[[category:Missions]]

Missions - Creation

2008-01-07T15:11:18Z

Jimkeir: /* Compiling */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.net/ AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
[[Briefing]] - Creating HTML for mission briefings.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
If you use Rewards, or you want your mission to load a little faster, you must [[Compiling|compile]] them using the [[SDK]]'s command-line tools.

== Function Reference ==
[[Function Reference|This section]] gives some basic details on the different types of object available to mission writers when writing a mission script.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG :

<code>
[Debug]
ReportLoadErrors=1
</code>

Unfortunately there are lots of errors that this won't report. Another way of testing it is [[Compiling]] it; you may get some useful error messages from the compiler.

Sometimes FSX will stop loading your mission completely. There are various reasons for this, but it's usually because an object that should be attached to another isn't, or vice-versa. A very quick way of detecting this is to add an activated TimerTrigger, and set <tt>OnScreenTimer</tt> to True. This makes a small timer appear at the top of the screen as soon as the mission is loaded. If the timer is there, the mission is running. If not, FSX hasn't loaded it because of some kind of structural problem.

Another simple way of adding some debugging information is to add DialogActions to key triggers that don't have one already. This can save you lots of time; two temporary DialogActions saying "LandingTrigger A On" and "LandingTrigger B On" might save you several minutes' flying time on every test. If you make sure your temporary DialogActions have sensible names (i.e. they all start with 'Debug' or 'Temp') they're easy to remove once you no longer need them.

[[category:Missions]]

Missions - Creation

2008-01-07T15:09:45Z

Jimkeir: /* Function Reference */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.net/ AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
[[Briefing]] - Creating HTML for mission briefings.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
[[Compiling]] -

== Function Reference ==
[[Function Reference|This section]] gives some basic details on the different types of object available to mission writers when writing a mission script.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG :

<code>
[Debug]
ReportLoadErrors=1
</code>

Unfortunately there are lots of errors that this won't report. Another way of testing it is [[Compiling]] it; you may get some useful error messages from the compiler.

Sometimes FSX will stop loading your mission completely. There are various reasons for this, but it's usually because an object that should be attached to another isn't, or vice-versa. A very quick way of detecting this is to add an activated TimerTrigger, and set <tt>OnScreenTimer</tt> to True. This makes a small timer appear at the top of the screen as soon as the mission is loaded. If the timer is there, the mission is running. If not, FSX hasn't loaded it because of some kind of structural problem.

Another simple way of adding some debugging information is to add DialogActions to key triggers that don't have one already. This can save you lots of time; two temporary DialogActions saying "LandingTrigger A On" and "LandingTrigger B On" might save you several minutes' flying time on every test. If you make sure your temporary DialogActions have sensible names (i.e. they all start with 'Debug' or 'Temp') they're easy to remove once you no longer need them.

[[category:Missions]]

Missions - Creation

2008-01-07T14:57:23Z

Jimkeir: /* Debugging */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.net/ AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
[[Briefing]] - Creating HTML for mission briefings.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
[[Compiling]] -

== Function Reference ==
[[Function Reference]] with example code.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG :

<code>
[Debug]
ReportLoadErrors=1
</code>

Unfortunately there are lots of errors that this won't report. Another way of testing it is [[Compiling]] it; you may get some useful error messages from the compiler.

Sometimes FSX will stop loading your mission completely. There are various reasons for this, but it's usually because an object that should be attached to another isn't, or vice-versa. A very quick way of detecting this is to add an activated TimerTrigger, and set <tt>OnScreenTimer</tt> to True. This makes a small timer appear at the top of the screen as soon as the mission is loaded. If the timer is there, the mission is running. If not, FSX hasn't loaded it because of some kind of structural problem.

Another simple way of adding some debugging information is to add DialogActions to key triggers that don't have one already. This can save you lots of time; two temporary DialogActions saying "LandingTrigger A On" and "LandingTrigger B On" might save you several minutes' flying time on every test. If you make sure your temporary DialogActions have sensible names (i.e. they all start with 'Debug' or 'Temp') they're easy to remove once you no longer need them.

[[category:Missions]]

Missions - Function Reference

2008-01-07T14:39:02Z

Jimkeir: /* Object Activation Action */

[[Mission Object Reference ]]

All of the objects that are available to use in a mission are described in the [[SDK#FSX|SDK]] documentation. Some notes, exceptions and gotchas are listed here.

----
= [[Actions ]] =
Actions are what makes things happen in a mission. There are lots of different actions you can use. An Action only gets used when it is called from a [[#Triggers|Trigger]].

== [[Activate Waypoints Action ]] ==
Placeholder text

== [[Adjust Payload Action ]] ==
This allows you to change the player's payload at a certain point in their aircraft. The payload station number can be found in the corresponding <code>aircraft.cfg</code> file for the player's aircraft, in the <code>[WEIGHT_AND_BALANCE]</code> section.

For example, try using a combination of [[#Random Action]]s, [[#Timer Trigger]]s and AdjustPayloadActions to simulate the effect of the entire New Zealand rugby team starting a brawl in the back or your KingAir 350 just before landing.

The OPT never saves the ObjectReference field of an AdjustPayloadAction. While it's theoretically possible to add or remove payloads from AI, this means it's not really possible unless you hand-edit the XML.

== [[Attach Droppable Payload Action ]] ==
Placeholder text

== [[Attach Effect Action ]] ==
This attaches a visual effect, one of the ones provided in the Effects folder of FSX, to an AI or scenery object. However, it has some significant limitations.

Only models which have AttachPoints built in can be used with an effect. Very few do. Furthermore, if that attachpoint was created with a particular effect in mind, it can never be used with any other effect. Put simply, you can attach effects to the GEN_SceneryEffect model, which is invisible and so can be placed alongside any static visible model. It is highly unlikely that you can attach an effect to the any of the default AI models. In SP1 only (i.e. not RTM, SP2 or Acceleration) you can attach effects to the player.

== [[Change Object Type Action ]] ==
Placeholder text

== [[Count Action ]] ==
This adds a value to a [[#Counter Trigger]]. By setting a negative value for ''Count'', you can subtract.

== [[Custom Action ]] ==
These are only useful when working with mission command extensions written using [[SimConnect]]. They pass the ''PayloadString'' value to the extension, which may be either an EXE or a DLL, so that it can perform some kind of action that the normal mission system doesn't support.

== [[Dialog Action ]] ==
The main way for you to interact with the mission player, this will display some text on screen and optionally play a sound file. This would typically be a recorded version of the text message.

These messages can be switched off in the simulator settings, so you can't assume that the sound file is enough. Alternatively, the player have the messages enabled but sound disabled, so you also can't assume that the text is enough. If they have both messages ''and'' sound disabled, that's their problem.

The sound file is relative to the "Sound" subfolder of the mission folder.

Do try to make your visible text and recorded speech match; mismatched subtitles get on my nerves :)

== [[Failure Action ]] ==
Placeholder text

== [[Goal Resolution Action ]] ==
These set the state of a [[#Goal Object]] to be one of Pending, Complete or Failed. Only goals which are activated count towards the final result of the mission though, so you can change the list of goals during the mission. When no active goals are pending, the mission finishes.

== [[Grant Reward Action ]] ==
Placeholder text

== [[Object Activation Action ]] ==
Some types of objects, typically Triggers and Scenery, can be activated and deactivated. This is important for the flow of your mission; you should only have the appropriate triggers activated to prevent the player from taking shortcuts. Using this action you can activate and deactivate other objects.

== [[One Shot Sound Action ]] ==
Very simply, this plays a recorded sound when it is called.

== [[Play Animation Action ]] ==
Placeholder text

== [[Play List Action ]] ==
Placeholder text

== [[Point Of Interest Activation Action ]] ==
Placeholder text

== [[Random Action ]] ==
This is almost two actions in one. You can set the percentage of the time that you want this action to do anything at all (''ProbabilityPercent''). Additionally, only one of the items in the ''Actions'' list is fired, again at random.

This can be very useful for creating 'chatter' for making transit sections of your mission a little more interesting. You can have a non-''OneShot'' [[#Timer Trigger]], set maybe to 45 seconds, calling a RandomAction with ''ProbabilityPercent'' of 33 and half a dozen [[#Dialog Action]]s attached.

== [[ResetTimer Action ]] ==
Mainly useful with repeating timers. If you want to check that the player has done something within a certain time, the [[#Timer Trigger]] is fine. However, if you want to use the same TimerTrigger again, the ''StartTime'' needs to be reset to 0. You can't use the [[#Timer Adjust Action]] because it has no 'set' option.

== [[Rumble Action ]] ==
This provides force-feedback in a mission, but only works with XBox rumble-controllers, and not other force-feedback joysticks.

== [[Spawn Action ]] ==
This activates a spawnlist, creating any objects it contains.

== [[Timer Adjust Action ]] ==
Allows you to add or remove (by using negative numbers) the time remaining before a [[#Timer Trigger]] fires.

----
= [[AI Object ]] =
Placeholder text

== [[AircraftAI Object ]] ==
Placeholder text

== [[TakeoffAI Object ]] ==
Placeholder text

== [[LandingAI Object ]] ==
Placeholder text

== [[TaxiAI Object ]] ==
Placeholder text

== [[GroundVehicleAI Object ]] ==
Placeholder text

== [[Waypoint List Object ]] ==
Placeholder text

== [[Waypoint Object ]] ==
Placeholder text

----
= [[Area Definition Object ]] =
On some systems, small AreaDefinitions can be missed by the mission system. Normally this only affects slower PCs and faster-moving aircraft. Try to make the smallest dimensions of an AreaDefinition at least 20 meters to avoid problems on slower PCs.

----
= [[Group Object ]] =
Placeholder text

----
= [[Mission Object ]] =
Placeholder text

== [[Camera Mission Object ]] ==
Placeholder text

== [[Attached World Position Object ]] ==
Placeholder text

== [[Attached World Object ]] ==
Placeholder text

== [[Picture In Picture View Controller Mission Object ]] ==
Placeholder text

== [[Point Of Interest Mission Object ]] ==
Placeholder text

== [[Realism Overrides Mission Object ]] ==
Placeholder text

== [[Ridge Lift Mission Object ]] ==
Placeholder text

== [[Scenario Metadata Mission Object ]] ==
Placeholder text

== [[Thermal Mission Object ]] ==
Placeholder text

----
= [[Scenery Objects ]] =
Placeholder text

----
= [[Mobile Scenery Objects ]] =
Placeholder text

----
= [[Spawn List ]] =
This creates new nodes during a mission. You can use it to create visual models in addition to mission actions and triggers. In FSX Acceleration, commands created by a spawnlist can refer to any other object in the mission but in all other versions, including SP2, commands created by a spawnlist ''must'' only refer to other objects in the same spawnlist.

----
= [[Triggers ]] =
Triggers are used to check for key events during the mission. You might check that the player is above a certain altitude, or has landed at a key airport, or that a certain amount of time has elapsed.

== [[Generic Trigger Properties ]] ==
All triggers can be marked as Active or Inactive using the ''Activated'' field. An inactive trigger does nothing. The usual way to make your mission storyline is to use the [[#Object Activation Action]] to enable new triggers once the player has achieved a key task.

Triggers can also be marked as ''OneShot'', which defaults to true. This means that the trigger fires once, and once only. Normally this is what you want to happen, but there are some exceptions.

ProximityTriggers have two Action lists; ''OnEnterActions'' and ''OnExitActions''. If it is a ''OneShot'' trigger, only one set of actions will ever be used because after the first set has fired, the trigger will be deactivated. If you want both sets of actions to be used, you have to mark the triggers as not being ''OneShot'' (that is, untick the box).

Another common use for a non-''OneShot'' trigger is a recurring timer, where you want something to happen, say, every two minutes.

If you want to re-use a trigger after it has been fired, but still want it to disable itself after every time, you can use the [[#Object Activation Action]] to re-enable it.

== [[Airport Landing Trigger ]] ==
Checks that the player, or an AI, has landed or touched down at a specific airport. The associated RunwayFilter object doesn't seem to care which end of the named runway you touch down on; that is, runways 4 and 22 are seen to be the same.

== [[Area Landing Trigger ]] ==
Checks to see that the player, or an AI, has landed or touched down ''anywhere''. This seems to have a lower priority than the [[#Airport Landing Trigger]], so it's common to use this to detect off-airport landings by simply not attaching any AreaRectangle.

== [[Counter Trigger ]] ==
Simply counts up from 0 to whatever level you tell it to. Use this for things like failing the mission if the player ignores five warnings that they must do something.

== [[Menu Prompt Trigger ]] ==
This asks the player to make a choice. It's usually used to give multiple ways of completing a mission by using the different menu items to call [[#Object Activation Action]]s which activate different sets of triggers and goals.

== [[Parking Trigger ]] ==
Placeholder text

== [[Property Trigger ]] ==
One of the more useful triggers, this can check a set of predefined properties of the player or an AI for being higher, lower or equal to a constant value or another property. Properties can also be combined using And/Or/Not, but you need to hand-edit the mission XML to use these groupings.

== [[Proximity Trigger ]] ==
A simple but powerful test, this checks that the player or an AI has entered or left a defined area.

== [[Timer Trigger ]] ==
It's main purpose is to simply wait for a set time and then call an action. However, it can be used for two other things. By setting ''OnScreenTimer'' to True, you get a visible timer in the sim. This can be count-up or count-down, depending on the values of ''StartTime'' and ''StopTime''.

Since this gives visual feedback that the mission system is working, this means it is also a very useful test. If you think that an error is preventing your mission from being loaded at all, create an active, on-screen TimerTrigger. If you get a visible timer, the mission is being run.

----
= [[Goal Object ]] =
Each mission must have at least one Goal. When all active Goals are complete or failed, the mission ends. You can change which goals have to be achieved during the mission by using the [[#Object Activation Action]] to switch them on or off.

----
= [[Reward Object ]] =
Rewards are used in addition to Goals. The player doesn't need to get all the rewards to finish the mission; in fact, they may not even know that rewards are available. They're just a way of saying "Hey, well done!".

Rewards are [[Rewards|created]] in a separate file to the mission, and must be [[Compiling|compiled]] before they can be used.

----
= [[Disabled Traffic Airport Object ]] =
This tells the simulator that it should not create any AI traffic at a specific list of airports. You don't want an unplanned 747 bearing down on you when you're in the last few minutes of a two hour long mission, nursing a crippled Cessna back to earth at Heathrow. It can also affect some triggers which may be set up to fire for any aircraft.

= Related content =
Placeholder text

= External links =
http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx

[[category:FSX]] [[category:Missions]]

Missions - Creation

2008-01-07T14:38:51Z

Jimkeir: /* The Basics */

How to create missions, a supplement to the SDK.

== Overview ==
Creating a mission is a complex task involving a diverse use of tools & skills. Getting your first mission going, even following the SDK documentation, is likely to cause you some headaches.

Still here? Good. Once you ''do'' have that first one running, the sky's your limit. That basic set of rules and files that make up a mission are always the same so once you've got those sorted, it's just a case of coming up with an idea and writing it.

At it's simplest, a mission is just a scripted set of events that tell some kind of story. It may be dramatic - mountain rescue, failing aircraft, poor weather. It could just as easily be a simple flight from A to B with you pointing out areas of interest along the way, or a completely abstract challenge like finding out how many times you can touch-and-go in a 747 in five minutes.

Technically speaking, there are two main classes of 'things' in a mission; Actions and Triggers. An Action makes something happen, and a Trigger checks to see if something's happened and calls an Action if it has. By stringing together Actions and Triggers, you tell your story.

You'll also need to prepare some sound files for the mission speech, some images to appear in FSX and some HTML with the mission briefing. All of these apart from the speech can be 'borrowed' from the standard missions and edited so even if you're not an HTML whiz, it's certainly possible to do. And if you get really stuck you could always try asking in the [http://www.fsdeveloper.com/forum/forumdisplay.php?f=59 forum].

== The Basics ==

There are some simple things you will need before you start, and while you're working towards your first mission.

=== The Plot ===
First and foremost, you need an idea. If this is your first mission, it's probably better to have a ''simple'' idea; re-writing [http://www.imdb.com/title/tt0064505/ The Italian Job] with Microlights would be fun, but you'll go insane before it sees the light of day. Start with something with only one or two things to do:

# Fly above 1000 feet for three minutes
# Land at a specific airport

Once you've got this going you'll have a much better idea of how a mission hangs together and relocating it to Turin with Red, White and Blue [http://www.aircreation.net/ AirCreation] Trikes will be one step closer.

=== Instructions ===
You can safely assume that the player will get things wrong. You might be able to fly your mission from beginning to end but other people don't know what you were thinking about when you wrote it.

Messages which seem perfectly clear to you might not be as useful as you think. Some speech saying "Now let's land over there" is fine, surely? Well, maybe. But what if they've got a little lost, or distracted, and 'over there' is behind them as they circle, trying to spot a landmark?

If there's something you want the player to do, you need to tell them. They may not know that in the case of, say, being hopelessly lost they're required by law to do X, Y and Z. That's particularly important if doing X, Y and Z are what causes the next Trigger to fire; they'll fly around for a while, get bored, post a rant on a forum and curse your descendants.

''How'' you tell them is up to you. If your mission is a tour of local landmarks, explicit instructions are probably best ("Turn to 170 and fly towards the only hill on that plain"). On other missions, being led around by the nose may not work well so maybe less explicit instructions would be better ("Hey, there they are! They're OK, so let's check the next bridge downstream").

In either case, there are some tricks you can use to help out. First is the Mission Compass. This is a big help, particularly to people who don't know the area, and it can always be switched off by more experienced pilots. You set points on this using [[Function_Reference#Point_Of_Interest_Mission_Object|PointOfInterest]] (POI) objects, and [[Function_Reference#Point Of Interest Activation Action|PointOfInterestActivationActions]] to set which POI is currently active. You get a big, green rotating spike to show where you're supposed to go next.

That does take the fun out of navigation challenge missions though. Instead of having to follow instructions, ask local towers for advice and read the landscape you just play fly-towards-the-green-arrow for half an hour. On the other hand, people flying a navigation challenge are more likely to get lost. Tricky.

This is where your design skills start to come in. You need the mission compass to help people that have gone wrong, but you don't want it there all the time. There's several ways round this, but a couple are popular.

First, you could enclose the whole area inside a huge AreaRectangle attached to a [[Function_Reference#Proximity_Trigger|ProximityTrigger]]. When you leave the rectangle, the trigger calls a [[Function_Reference#Dialog Action|DialogAction]] ("Dude, where are we?") and then activates an appropriate PointOfInterest, showing where the player should be. Simple, no? They get the ''chance'' to get it right but then a bit of a prod if they need it.

Alternatively, you could do a similar thing with a [[Function_Reference#Timer Trigger|TimerTrigger]]. Start it when they leave the previous point and if they're more than, say, two minutes late getting to the next one then use the same trick with the [[Function_Reference#Dialog Action|DialogAction]] and PointOfInterestActivationAction.

Lots of handy tips are also available here:
[http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx FS Insider - Mission Building Tips]

=== Logical Structuring ===

A simple mission probably won't need much structuring but once you've got beyond that and started putting together more complex scenarios, it can help to have a written structure.
Think of it as a screenplay, and follow the same three-stage layout.

The first section is your introduction. You need to get the player's interest, explain who they are and why they're there. You use the first bit to get everything set up so that when The Exciting Thing happens, they know why and what to do about it.

In part two, The Exciting Thing happens. It doesn't matter what it is, but assuming you have some kind of event to which the player is supposed to react, this part details what happens. Once they've managed to cope with the situation and get it under control, they move on to...

Part three, the conclusion. Having successfully dealt with the engine fire/squalling brats in the back seats/condor-strike, the player gets to reflect on what they've done and enjoy the feeling of success for a little while. You could always throw in a last-minute plot twist of course.

Structuring like this gives you a tidy way of making your mission appear much more complex. You can easily provide different threads, or ways of achieving something, without too much extra effort. Let's say your Introduction sees the player getting from a bush strip to the head of a particular valley. You start with them following the river, simple enough. Later on, you could add the option to fly across the peaks and save time; as long as they reach the same head of the same valley, the rest of the mission isn't affected. If they've tried the mission before and failed, chances are they'll decide to try shortcuts anyway. Wouldn't it feel better if, having decided to cross the ridge instead of fly round, the mission reacts to that by saying "Hey, you're going over the ridge! A bit risky in this weather but the views will be stunning"? You can issue different Rewards, or maybe even alter how the next section plays out, depending on the path they took.

In short, you can see your mission sections as leading up to choke-points, such as the head of the valley. If you have three sections, each with three different ways of achieving it, that's nine different ways of flying a single mission.

=== Coding ===
This, as you might expect, is probably the trickiest bit. You may find it easier to have a big sheet of paper and draw the mission out in pencil before you start coding. That lets you work out how it fits together logically without having to worry about whether or not you've got the spelling right.

For example, you know that after you take off you want to have some speech, and then there are three ways of getting from A to B, where the next section starts. OK, so that's three boxes to draw; 'Takeoff', 'Speech' and 'At point B'. The speech should happen 30 seconds after takeoff, so note that down next to the Speech box. Then you can draw three lines between 'Speech' and 'At Point B' to show the three paths, and the first thing to do on each path is disable the other two paths.

Already you've got a decent map of what happens in what order, and translating from these into actual mission-system code will be easier.

Read the list of possible Actions and Triggers, to find out what kinds of things you can check for and do. Try and spot a likely match for each of the boxes on your sheet of paper.

To keep the example going, you might have a [[Function_Reference#Property Trigger|PropertyTrigger]] checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second [[Function_Reference#Timer Trigger|TimerTrigger]] using an [[Function_Reference#Object Activation Action|ObjectActivationAction]] which, in turn, would call a [[Function_Reference#Dialog Action|DialogAction]] for your "Speech" box. You would need one Trigger per potential path; they might be set to detect altitude, or heading, or more likely that the player has entered an area. Each of those would need another [[Function_Reference#Dialog Action|DialogAction]] (just to keep the player informed), an [[Function_Reference#Object Activation Action|ObjectActivationAction]] to enable the Trigger that checks "At Point B" and another [[Function_Reference#Object Activation Action|ObjectActivationAction]] to disable the other two paths.

Everyone will have their own style of writing, of course. Feel free to experiment.

=== Code Design ===
Your first missions will probably be some active [[Function_Reference#Timer Trigger|TimerTrigger]]s and [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s, each with some [[Function_Reference#Dialog Action|DialogAction]]s attached, and a LandingTrigger to finish the mission. This is fine for beginners, but once your missions get larger this easy design style will cause you problems.

It is far easier to test a mission if you know what you expect to happen at a given moment. Sounds obvious, right? Of course you know what's supposed to happen, you designed and wrote it.

The problem is that when you have lots of active triggers, any of them can fire. That's what they're for. They don't know that they're not ''supposed'' to fire so that the player that takes a shortcut - or the designer that's testing the last three minutes of a 45-minute mission - will find that some very wierd things are happening because triggers that are part of a completely different part of the mission are firing.

The design solution is very easy; you only activate the triggers that you need, and you deactivate any that you don't need. In other words, almost all of your triggers should be '''de'''activated by default. Only when you're ready for them should they be activated.

Let's consider a simple mission where you're flying east from A to B to pick up your wife. As you approach B you're told that the air ambulance has broken down and someone is urgently needed in town C, to the north, to ferry a transplant organ to town B's airfield. You, of course, arrive in a shining white Cessna to save the day. A nice, straightforward story with only about a dozen triggers to implement. What could possibly go wrong?

I take off from A and notice a motorway (freeway) leading to B and decide to follow that at 100 feet. Two minutes in, and still a long way from B, a timer switches on the altitude check that is supposed to fire just before I land at B to tell me to go to C. "Abort the landing, Sir Pilot! You're needed!". Huh? What landing? Okay, off I go to C as instructed. Land, collect heart, take off, fly towards B. Now I hit a set of [[Function_Reference#Proximity_Trigger|ProximityTrigger]]s around town B, intended to fill in some empty time and which should have gone off ''before'' the emergency call, wittering on about my wife's assault on the January shoe sales. With a human heart destined for a dying child on the passenger seat.

A similar thing would happen if I'd fluffed the landing on a previous attempt and decided to fly straight to C to avoid the uneventful flight to B.

Or what about the person who gets distracted for a few seconds on finals to town B - maybe his wife's at the door asking for help upstairs with some new shoes - and misses the 'divert to town C' message, lands anyway to get told he's just saved someone's life because the final landing trigger was on by default? Huh? Whose life? Just how many shoes did she buy? What a dull mission; I took off, got harangued about footwear, landed, and it finished.

Once more with feeling, then. Treat Triggers like lightbulbs; if you're not using it, switch it off.

=== Testing ===
At some point you'll want to give your mission out to others. They react by flying around like airborne sheep in a hand-grenade factory, and then tell you that your mission sucks. Dude. Some reward for the weeks of work you put in.

You've already checked that it all works when it's flown correctly, that gets done while you're writing it. Unfortunately, you're the only person that knows what 'correctly' means. Checking that it still works when it's ''not'' flown correctly is more difficult. You need to make sure that the player gets told when they've gone out of bounds, that they've been told '''exactly''' where they're supposed to park and not just 'near the buildings' (What buildings? Which wall?). What happens when they land on the right runway in the wrong direction, or the at the wrong airport? What happens when they take a shortcut because they've flown the mission before, and skip out section 1 completely?

=== Pulling it all together ===

=== Packaging ===

=== Distributing ===

== Tools ==
See these pages for HowTos & Tools used in creating -
=== Categories ===
[[Categories]] - Assigning and creating categories.

=== Mission Coding ===
[[Mission Coding]] - Creating your mission, development process & tips.

=== Rewards ===
[[Rewards]] - Creation tips.

=== Sounds ===
[[Sounds]] - Creating dialogue, and sounds, for missions.

=== Artwork ===
[[Artwork]] - Creating artwork for mission briefings, rewards, etc.

=== Briefing ===
[[Briefing]] - Creating HTML for mission briefings.

= To Sort =
These bits probably need modifying and/or relocating to appropriate subsections.

== SDK ==
[[Object Placement Tool]] - Installing, configuring, & general useage tips.

[[Tools]] placeholder text.

=== Compiling ===
[[Compiling]] -

== Function Reference ==
[[Function Reference]] with example code.

== Debugging ==
Currently there are no available tools to allow debugging of your mission.

However there is a basic form of error reporting built into FSX.

Add the following to your fsx.CFG

<code>
[Debug]

ReportLoadErrors=1
</code>

[[category:Missions]]

Missions - Creation

2008-01-07T12:53:42Z

Jimkeir: /* Overview */

Missions - Function Reference

2008-01-05T12:22:01Z

Jimkeir:

[[Mission Object Reference ]]

All of the objects that are available to use in a mission are described in the [[SDK#FSX|SDK]] documentation. Some notes, exceptions and gotchas are listed here.

----
= [[Actions ]] =
Actions are what makes things happen in a mission. There are lots of different actions you can use. An Action only gets used when it is called from a [[#Triggers|Trigger]].

== [[Activate Waypoints Action ]] ==
Placeholder text

== [[Adjust Payload Action ]] ==
This allows you to change the player's payload at a certain point in their aircraft. The payload station number can be found in the corresponding <code>aircraft.cfg</code> file for the player's aircraft, in the <code>[WEIGHT_AND_BALANCE]</code> section.

For example, try using a combination of [[#Random Action]]s, [[#Timer Trigger]]s and AdjustPayloadActions to simulate the effect of the entire New Zealand rugby team starting a brawl in the back or your KingAir 350 just before landing.

The OPT never saves the ObjectReference field of an AdjustPayloadAction. While it's theoretically possible to add or remove payloads from AI, this means it's not really possible unless you hand-edit the XML.

== [[Attach Droppable Payload Action ]] ==
Placeholder text

== [[Attach Effect Action ]] ==
This attaches a visual effect, one of the ones provided in the Effects folder of FSX, to an AI or scenery object. However, it has some significant limitations.

Only models which have AttachPoints built in can be used with an effect. Very few do. Furthermore, if that attachpoint was created with a particular effect in mind, it can never be used with any other effect. Put simply, you can attach effects to the GEN_SceneryEffect model, which is invisible and so can be placed alongside any static visible model. It is highly unlikely that you can attach an effect to the any of the default AI models. In SP1 only (i.e. not RTM, SP2 or Acceleration) you can attach effects to the player.

== [[Change Object Type Action ]] ==
Placeholder text

== [[Count Action ]] ==
This adds a value to a [[#Counter Trigger]]. By setting a negative value for ''Count'', you can subtract.

== [[Custom Action ]] ==
These are only useful when working with mission command extensions written using [[SimConnect]]. They pass the ''PayloadString'' value to the extension, which may be either an EXE or a DLL, so that it can perform some kind of action that the normal mission system doesn't support.

== [[Dialog Action ]] ==
The main way for you to interact with the mission player, this will display some text on screen and optionally play a sound file. This would typically be a recorded version of the text message.

These messages can be switched off in the simulator settings, so you can't assume that the sound file is enough. Alternatively, the player have the messages enabled but sound disabled, so you also can't assume that the text is enough. If they have both messages ''and'' sound disabled, that's their problem.

The sound file is relative to the "Sound" subfolder of the mission folder.

Do try to make your visible text and recorded speech match; mismatched subtitles get on my nerves :)

== [[Failure Action ]] ==
Placeholder text

== [[Goal Resolution Action ]] ==
These set the state of a [[#Goal Object]] to be one of Pending, Complete or Failed. Only goals which are activated count towards the final result of the mission though, so you can change the list of goals during the mission. When no active goals are pending, the mission finishes.

== [[Grant Reward Action ]] ==
Placeholder text

== [[Object Activation Action ]] ==
Some types of objects, typically Triggers and Scenery, can be activated and deactivated. This is important for the flow of your mission; you should only have the appropriate triggers activated to avoid the player from taking shortcuts. Using this action you can activate and deactivate other objects.

== [[One Shot Sound Action ]] ==
Very simply, this plays a recorded sound when it is called.

== [[Play Animation Action ]] ==
Placeholder text

== [[Play List Action ]] ==
Placeholder text

== [[Point Of Interest Activation Action ]] ==
Placeholder text

== [[Random Action ]] ==
This is almost two actions in one. You can set the percentage of the time that you want this action to do anything at all (''ProbabilityPercent''). Additionally, only one of the items in the ''Actions'' list is fired, again at random.

This can be very useful for creating 'chatter' for making transit sections of your mission a little more interesting. You can have a non-''OneShot'' [[#Timer Trigger]], set maybe to 45 seconds, calling a RandomAction with ''ProbabilityPercent'' of 33 and half a dozen [[#Dialog Action]]s attached.

== [[ResetTimer Action ]] ==
Mainly useful with repeating timers. If you want to check that the player has done something within a certain time, the [[#Timer Trigger]] is fine. However, if you want to use the same TimerTrigger again, the ''StartTime'' needs to be reset to 0. You can't use the [[#Timer Adjust Action]] because it has no 'set' option.

== [[Rumble Action ]] ==
This provides force-feedback in a mission, but only works with XBox rumble-controllers, and not other force-feedback joysticks.

== [[Spawn Action ]] ==
This activates a spawnlist, creating any objects it contains.

== [[Timer Adjust Action ]] ==
Allows you to add or remove (by using negative numbers) the time remaining before a [[#Timer Trigger]] fires.

----
= [[AI Object ]] =
Placeholder text

== [[AircraftAI Object ]] ==
Placeholder text

== [[TakeoffAI Object ]] ==
Placeholder text

== [[LandingAI Object ]] ==
Placeholder text

== [[TaxiAI Object ]] ==
Placeholder text

== [[GroundVehicleAI Object ]] ==
Placeholder text

== [[Waypoint List Object ]] ==
Placeholder text

== [[Waypoint Object ]] ==
Placeholder text

----
= [[Area Definition Object ]] =
On some systems, small AreaDefinitions can be missed by the mission system. Normally this only affects slower PCs and faster-moving aircraft. Try to make the smallest dimensions of an AreaDefinition at least 20 meters to avoid problems on slower PCs.

----
= [[Group Object ]] =
Placeholder text

----
= [[Mission Object ]] =
Placeholder text

== [[Camera Mission Object ]] ==
Placeholder text

== [[Attached World Position Object ]] ==
Placeholder text

== [[Attached World Object ]] ==
Placeholder text

== [[Picture In Picture View Controller Mission Object ]] ==
Placeholder text

== [[Point Of Interest Mission Object ]] ==
Placeholder text

== [[Realism Overrides Mission Object ]] ==
Placeholder text

== [[Ridge Lift Mission Object ]] ==
Placeholder text

== [[Scenario Metadata Mission Object ]] ==
Placeholder text

== [[Thermal Mission Object ]] ==
Placeholder text

----
= [[Scenery Objects ]] =
Placeholder text

----
= [[Mobile Scenery Objects ]] =
Placeholder text

----
= [[Spawn List ]] =
This creates new nodes during a mission. You can use it to create visual models in addition to mission actions and triggers. In FSX Acceleration, commands created by a spawnlist can refer to any other object in the mission but in all other versions, including SP2, commands created by a spawnlist ''must'' only refer to other objects in the same spawnlist.

----
= [[Triggers ]] =
Triggers are used to check for key events during the mission. You might check that the player is above a certain altitude, or has landed at a key airport, or that a certain amount of time has elapsed.

== [[Generic Trigger Properties ]] ==
All triggers can be marked as Active or Inactive using the ''Activated'' field. An inactive trigger does nothing. The usual way to make your mission storyline is to use the [[#Object Activation Action]] to enable new triggers once the player has achieved a key task.

Triggers can also be marked as ''OneShot'', which defaults to true. This means that the trigger fires once, and once only. Normally this is what you want to happen, but there are some exceptions.

ProximityTriggers have two Action lists; ''OnEnterActions'' and ''OnExitActions''. If it is a ''OneShot'' trigger, only one set of actions will ever be used because after the first set has fired, the trigger will be deactivated. If you want both sets of actions to be used, you have to mark the triggers as not being ''OneShot'' (that is, untick the box).

Another common use for a non-''OneShot'' trigger is a recurring timer, where you want something to happen, say, every two minutes.

If you want to re-use a trigger after it has been fired, but still want it to disable itself after every time, you can use the [[#Object Activation Action]] to re-enable it.

== [[Airport Landing Trigger ]] ==
Checks that the player, or an AI, has landed or touched down at a specific airport. The associated RunwayFilter object doesn't seem to care which end of the named runway you touch down on; that is, runways 4 and 22 are seen to be the same.

== [[Area Landing Trigger ]] ==
Checks to see that the player, or an AI, has landed or touched down ''anywhere''. This seems to have a lower priority than the [[#Airport Landing Trigger]], so it's common to use this to detect off-airport landings by simply not attaching any AreaRectangle.

== [[Counter Trigger ]] ==
Simply counts up from 0 to whatever level you tell it to. Use this for things like failing the mission if the player ignores five warnings that they must do something.

== [[Menu Prompt Trigger ]] ==
This asks the player to make a choice. It's usually used to give multiple ways of completing a mission by using the different menu items to call [[#Object Activation Action]]s which activate different sets of triggers and goals.

== [[Parking Trigger ]] ==
Placeholder text

== [[Property Trigger ]] ==
One of the more useful triggers, this can check a set of predefined properties of the player or an AI for being higher, lower or equal to a constant value or another property. Properties can also be combined using And/Or/Not, but you need to hand-edit the mission XML to use these groupings.

== [[Proximity Trigger ]] ==
A simple but powerful test, this checks that the player or an AI has entered or left a defined area.

== [[Timer Trigger ]] ==
It's main purpose is to simply wait for a set time and then call an action. However, it can be used for two other things. By setting ''OnScreenTimer'' to True, you get a visible timer in the sim. This can be count-up or count-down, depending on the values of ''StartTime'' and ''StopTime''.

Since this gives visual feedback that the mission system is working, this means it is also a very useful test. If you think that an error is preventing your mission from being loaded at all, create an active, on-screen TimerTrigger. If you get a visible timer, the mission is being run.

----
= [[Goal Object ]] =
Each mission must have at least one Goal. When all active Goals are complete or failed, the mission ends. You can change which goals have to be achieved during the mission by using the [[#Object Activation Action]] to switch them on or off.

----
= [[Reward Object ]] =
Rewards are used in addition to Goals. The player doesn't need to get all the rewards to finish the mission; in fact, they may not even know that rewards are available. They're just a way of saying "Hey, well done!".

Rewards are [[Rewards|created]] in a separate file to the mission, and must be [[Compiling|compiled]] before they can be used.

----
= [[Disabled Traffic Airport Object ]] =
This tells the simulator that it should not create any AI traffic at a specific list of airports. You don't want an unplanned 747 bearing down on you when you're in the last few minutes of a two hour long mission, nursing a crippled Cessna back to earth at Heathrow. It can also affect some triggers which may be set up to fire for any aircraft.

= Related content =
Placeholder text

= External links =
http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx

[[category:FSX]] [[category:Missions]]

Missions - Function Reference

2008-01-04T16:40:26Z

Jimkeir:

[[Mission Object Reference ]]

All of the objects that are available to use in a mission are described in the [[SDK#FSX|SDK]] documentation. Some notes, exceptions and gotchas are listed here.

----
= [[Actions ]] =
Actions are what makes things happen in a mission. There are lots of different actions you can use. An Action only gets used when it is called from a [[#Triggers|Trigger]].

== [[Activate Waypoints Action ]] ==
Placeholder text

== [[Adjust Payload Action ]] ==
This allows you to change the player's payload at a certain point in their aircraft. The payload station number can be found in the corresponding <code>aircraft.cfg</code> file for the player's aircraft, in the <code>[WEIGHT_AND_BALANCE]</code> section.

For example, try using a combination of [[#Random Action]]s, [[#Timer Trigger]]s and AdjustPayloadActions to simulate the effect of the entire New Zealand rugby team starting a brawl in the back or your KingAir 350 just before landing.

The OPT never saves the ObjectReference field of an AdjustPayloadAction. While it's theoretically possible to add or remove payloads from AI, this means it's not really possible unless you hand-edit the XML.

== [[Attach Droppable Payload Action ]] ==
Placeholder text

== [[Attach Effect Action ]] ==
This attaches a visual effect, one of the ones provided in the Effects folder of FSX, to an AI or scenery object. However, it has some significant limitations.

Only models which have AttachPoints built in can be used with an effect. Very few do. Furthermore, if that attachpoint was created with a particular effect in mind, it can never be used with any other effect. Put simply, you can attach effects to the GEN_SceneryEffect model, which is invisible and so can be placed alongside any static visible model. It is highly unlikely that you can attach an effect to the any of the default AI models. In SP1 only (i.e. not RTM, SP2 or Acceleration) you can attach effects to the player.

== [[Change Object Type Action ]] ==
Placeholder text

== [[Count Action ]] ==
This adds a value to a [[#Counter Trigger]]. By setting a negative value for ''Count'', you can subtract.

== [[Custom Action ]] ==
These are only useful when working with mission command extensions written using [[SimConnect]]. They pass the ''PayloadString'' value to the extension, which may be either an EXE or a DLL, so that it can perform some kind of action that the normal mission system doesn't support.

== [[Dialog Action ]] ==
The main way for you to interact with the mission player, this will display some text on screen and optionally play a sound file. This would typically be a recorded version of the text message.

These messages can be switched off in the simulator settings, so you can't assume that the sound file is enough. Alternatively, the player have the messages enabled but sound disabled, so you also can't assume that the text is enough. If they have both messages ''and'' sound disabled, that's their problem.

The sound file is relative to the "Sound" subfolder of the mission folder.

Do try to make your visible text and recorded speech match; mismatched subtitles get on my nerves :)

== [[Failure Action ]] ==
Placeholder text

== [[Goal Resolution Action ]] ==
These set the state of a [[#Goal Object]] to be one of Pending, Complete or Failed. Only goals which are activated count towards the final result of the mission though, so you can change the list of goals during the mission. When no active goals are pending, the mission finishes.

== [[Grant Reward Action ]] ==
Placeholder text

== [[Object Activation Action ]] ==
Some types of objects, typically Triggers and Scenery, can be activated and deactivated. This is important for the flow of your mission; you should only have the appropriate triggers activated to avoid the player from taking shortcuts. Using this action you can activate and deactivate other objects.

== [[One Shot Sound Action ]] ==
Very simply, this plays a recorded sound when it is called.

== [[Play Animation Action ]] ==
Placeholder text

== [[Play List Action ]] ==
Placeholder text

== [[Point Of Interest Activation Action ]] ==
Placeholder text

== [[Random Action ]] ==
This is almost two actions in one. You can set the percentage of the time that you want this action to do anything at all (''ProbabilityPercent''). Additionally, only one of the items in the ''Actions'' list is fired, again at random.

This can be very useful for creating 'chatter' for making transit sections of your mission a little more interesting. You can have a non-''OneShot'' [[#Timer Trigger]], set maybe to 45 seconds, calling a RandomAction with ''ProbabilityPercent'' of 33 and half a dozen [[#Dialog Action]]s attached.

== [[ResetTimer Action ]] ==
Mainly useful with repeating timers. If you want to check that the player has done something within a certain time, the [[#Timer Trigger]] is fine. However, if you want to use the same TimerTrigger again, the ''StartTime'' needs to be reset to 0. You can't use the [[#Timer Adjust Action]] because it has no 'set' option.

== [[Rumble Action ]] ==
This provides force-feedback in a mission, but only works with XBox rumble-controllers, and not other force-feedback joysticks.

== [[Spawn Action ]] ==
This activates a spawnlist, creating any objects it contains.

== [[Timer Adjust Action ]] ==
Allows you to add or remove (by using negative numbers) the time remaining before a [[#Timer Trigger]] fires.

----
= [[AI Object ]] =
Placeholder text

== [[AircraftAI Object ]] ==
Placeholder text

== [[TakeoffAI Object ]] ==
Placeholder text

== [[LandingAI Object ]] ==
Placeholder text

== [[TaxiAI Object ]] ==
Placeholder text

== [[GroundVehicleAI Object ]] ==
Placeholder text

== [[Waypoint List Object ]] ==
Placeholder text

== [[Waypoint Object ]] ==
Placeholder text

----
= [[Area Definition Object ]] =
On some systems, small AreaDefinitions can be missed by the mission system. Normally this only affects slower PCs and faster-moving aircraft. Try to make the smallest dimensions of an AreaDefinition at least 20 meters to avoid problems on slower PCs.

----
= [[Group Object ]] =
Placeholder text

----
= [[Mission Object ]] =
Placeholder text

== [[Camera Mission Object ]] ==
Placeholder text

== [[Attached World Position Object ]] ==
Placeholder text

== [[Attached World Object ]] ==
Placeholder text

== [[Picture In Picture View Controller Mission Object ]] ==
Placeholder text

== [[Point Of Interest Mission Object ]] ==
Placeholder text

== [[Realism Overrides Mission Object ]] ==
Placeholder text

== [[Ridge Lift Mission Object ]] ==
Placeholder text

== [[Scenario Metadata Mission Object ]] ==
Placeholder text

== [[Thermal Mission Object ]] ==
Placeholder text

----
= [[Scenery Objects ]] =
Placeholder text

----
= [[Mobile Scenery Objects ]] =
Placeholder text

----
= [[Spawn List ]] =
This creates new nodes during a mission. You can use it to create visual models in addition to mission actions and triggers. In FSX Acceleration, commands created by a spawnlist can refer to any other object in the mission but in all other versions, including SP2, commands created by a spawnlist ''must'' only refer to other objects in the same spawnlist.

----
= [[Triggers ]] =
Triggers are used to check for key events during the mission. You might check that the player is above a certain altitude, or has landed at a key airport, or that a certain amount of time has elapsed.

== [[Generic Trigger Properties ]] ==
All triggers can be marked as Active or Inactive using the ''Activated'' field. An inactive trigger does nothing. The usual way to make your mission storyline is to use the [[#Object Activation Action]] to enable new triggers once the player has achieved a key task.

Triggers can also be marked as ''OneShot'', which defaults to true. This means that the trigger fires once, and once only. Normally this is what you want to happen, but there are some exceptions.

ProximityTriggers have two Action lists; ''OnEnterActions'' and ''OnExitActions''. If it is a ''OneShot'' trigger, only one set of actions will ever be used because after the first set has fired, the trigger will be deactivated. If you want both sets of actions to be used, you have to mark the triggers as not being ''OneShot'' (that is, untick the box).

Another common use for a non-''OneShot'' trigger is a recurring timer, where you want something to happen, say, every two minutes.

If you want to re-use a trigger after it has been fired, but still want it to disable itself after every time, you can use the [[#Object Activation Action]] to re-enable it.

== [[Airport Landing Trigger ]] ==
Checks that the player, or an AI, has landed or touched down at a specific airport. The associated RunwayFilter object doesn't seem to care which end of the named runway you touch down on; that is, runways 4 and 22 are seen to be the same.

== [[Area Landing Trigger ]] ==
Checks to see that the player, or an AI, has landed or touched down ''anywhere''. This seems to have a lower priority than the [[#Airport Landing Trigger]], so it's common to use this to detect off-airport landings by simply not attaching any AreaRectangle.

== [[Counter Trigger ]] ==
Simply counts up from 0 to whatever level you tell it to. Use this for things like failing the mission if the player ignores five warnings that they must do something.

== [[Menu Prompt Trigger ]] ==
This asks the player to make a choice. It's usually used to give multiple ways of completing a mission by using the different menu items to call [[#Object Activation Action]]s which activate different sets of triggers and goals.

== [[Parking Trigger ]] ==
Placeholder text

== [[Property Trigger ]] ==
One of the more useful triggers, this can check a set of predefined properties of the player or an AI for being higher, lower or equal to a constant value or another property. Properties can also be combined using And/Or/Not, but you need to hand-edit the mission XML to use these groupings.

== [[Proximity Trigger ]] ==
A simple but powerful test, this checks that the player or an AI has entered or left a defined area.

== [[Timer Trigger ]] ==
It's main purpose is to simply wait for a set time and then call an action. However, it can be used for two other things. By setting ''OnScreenTimer'' to True, you get a visible timer in the sim. This can be count-up or count-down, depending on the values of ''StartTime'' and ''StopTime''.

Since this gives visual feedback that the mission system is working, this means it is also a very useful test. If you think that an error is preventing your mission from being loaded at all, create an active, on-screen TimerTrigger. If you get a visible timer, the mission is being run.

----
= [[Goal Object ]] =
Each mission must have at least one Goal. When all active Goals are complete or failed, the mission ends. You can change which goals have to be achieved during the mission by using the [[#Object Activation Action]] to switch them on or off.

----
= [[Disabled Traffic Airport Object ]] =
This tells the simulator that it should not create any AI traffic at a specific list of airports. You don't want an unplanned 747 bearing down on you when you're in the last few minutes of a two hour long mission, nursing a crippled Cessna back to earth at Heathrow. It can also affect some triggers which may be set up to fire for any aircraft.

= Related content =
Placeholder text

= External links =
http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx

[[category:FSX]] [[category:Missions]]

Missions - Function Reference

2008-01-04T16:29:55Z

Jimkeir:

[[Mission Object Reference ]]

All of the objects that are available to use in a mission are described in the [[SDK#FSX|SDK]] documentation. Some notes, exceptions and gotchas are listed here.

----
= [[Actions ]] =
Actions are what makes things happen in a mission. There are lots of different actions you can use. An Action only gets used when it is called from a [[#Triggers|Trigger]].

== [[Activate Waypoints Action ]] ==
Placeholder text

== [[Adjust Payload Action ]] ==
This allows you to change the player's payload at a certain point in their aircraft. The payload station number can be found in the corresponding <code>aircraft.cfg</code> file for the player's aircraft, in the <code>[WEIGHT_AND_BALANCE]</code> section.

For example, try using a combination of RandomActions, TimerTriggers and AdjustPayloadActions to simulate the effect of the entire New Zealand rugby team starting a brawl in the back or your KingAir 350 just before landing.

The OPT never saves the ObjectReference field of an AdjustPayloadAction. While it's theoretically possible to add or remove payloads from AI, this means it's not really possible unless you hand-edit the XML.

== [[Attach Droppable Payload Action ]] ==
Placeholder text

== [[Attach Effect Action ]] ==
This attaches a visual effect, one of the ones provided in the Effects folder of FSX, to an AI or scenery object. However, it has some significant limitations.

Only models which have AttachPoints built in can be used with an effect. Very few do. Furthermore, if that attachpoint was created with a particular effect in mind, it can never be used with any other effect. Put simply, you can attach effects to the GEN_SceneryEffect model, which is invisible and so can be placed alongside any static visible model. It is highly unlikely that you can attach an effect to the any of the default AI models. In SP1 only (i.e. not RTM, SP2 or Acceleration) you can attach effects to the player.

== [[Change Object Type Action ]] ==
Placeholder text

== [[Count Action ]] ==
This adds a value to a [[#Counter Trigger]]. By setting a negative value for ''Count'', you can subtract.

== [[Custom Action ]] ==
These are only useful when working with mission command extensions written using [[SimConnect]]. They pass the ''PayloadString'' value to the extension, which may be either an EXE or a DLL, so that it can perform some kind of action that the normal mission system doesn't support.

== [[Dialog Action ]] ==
The main way for you to interact with the mission player, this will display some text on screen and optionally play a sound file. This would typically be a recorded version of the text message.

These messages can be switched off in the simulator settings, so you can't assume that the sound file is enough. Alternatively, the player have the messages enabled but sound disabled, so you also can't assume that the text is enough. If they have both messages ''and'' sound disabled, that's their problem.

The sound file is relative to the "Sound" subfolder of the mission folder.

Do try to make your visible text and recorded speech match; mismatched subtitles get on my nerves :)

== [[Failure Action ]] ==
Placeholder text

== [[Goal Resolution Action ]] ==
These set the state of a goal to be one of Pending, Complete or Failed. Only goals which are activated count towards the final result of the mission though, so you can change the list of goals during the mission. When no active goals are pending, the mission finishes.

== [[Grant Reward Action ]] ==
Placeholder text

== [[Object Activation Action ]] ==
Some types of objects, typically Triggers and Scenery, can be activated and deactivated. This is important for the flow of your mission; you should only have the appropriate triggers activated to avoid the player from taking shortcuts. Using this action you can activate and deactivate other objects.

== [[One Shot Sound Action ]] ==
Very simply, this plays a recorded sound when it is called.

== [[Play Animation Action ]] ==
Placeholder text

== [[Play List Action ]] ==
Placeholder text

== [[Point Of Interest Activation Action ]] ==
Placeholder text

== [[Random Action ]] ==
This is almost two actions in one. You can set the percentage of the time that you want this action to do anything at all (''ProbabilityPercent''). Additionally, only one of the items in the ''Actions'' list is fired, again at random.

This can be very useful for creating 'chatter' for making transit sections of your mission a little more interesting. You can have a non-''OneShot'' TimerTrigger, set maybe to 45 seconds, calling a RandomAction with ''ProbabilityPercent'' of 33 and half a dozen DialogActions attached.

== [[ResetTimer Action ]] ==
Mainly useful with repeating timers. If you want to check that the player has done something within a certain time, the TimerTrigger is fine. However, if you want to use the same TimerTrigger again, the StartTime needs to be reset to 0. You can't use the Timer Adjust Action because it has no 'set' option.

== [[Rumble Action ]] ==
This provides force-feedback in a mission, but only works with XBox rumble-controllers, and not other force-feedback joysticks.

== [[Spawn Action ]] ==
This activates a spawnlist, creating any objects it contains.

== [[Timer Adjust Action ]] ==
Allows you to add or remove (by using negative numbers) the time remaining before a TimerTrigger fires.

----
= [[AI Object ]] =
Placeholder text

== [[AircraftAI Object ]] ==
Placeholder text

== [[TakeoffAI Object ]] ==
Placeholder text

== [[LandingAI Object ]] ==
Placeholder text

== [[TaxiAI Object ]] ==
Placeholder text

== [[GroundVehicleAI Object ]] ==
Placeholder text

== [[Waypoint List Object ]] ==
Placeholder text

== [[Waypoint Object ]] ==
Placeholder text

----
= [[Area Definition Object ]] =
On some systems, small AreaDefinitions can be missed by the mission system. Normally this only affects slower PCs and faster-moving aircraft. Try to make the smallest dimensions of an AreaDefinition at least 20 meters to avoid problems on slower PCs.

----
= [[Group Object ]] =
Placeholder text

----
= [[Mission Object ]] =
Placeholder text

== [[Camera Mission Object ]] ==
Placeholder text

== [[Attached World Position Object ]] ==
Placeholder text

== [[Attached World Object ]] ==
Placeholder text

== [[Picture In Picture View Controller Mission Object ]] ==
Placeholder text

== [[Point Of Interest Mission Object ]] ==
Placeholder text

== [[Realism Overrides Mission Object ]] ==
Placeholder text

== [[Ridge Lift Mission Object ]] ==
Placeholder text

== [[Scenario Metadata Mission Object ]] ==
Placeholder text

== [[Thermal Mission Object ]] ==
Placeholder text

----
= [[Scenery Objects ]] =
Placeholder text

----
= [[Mobile Scenery Objects ]] =
Placeholder text

----
= [[Spawn List ]] =
This creates new nodes during a mission. You can use it to create visual models in addition to mission actions and triggers. In FSX Acceleration, commands created by a spawnlist can refer to any other object in the mission but in all other versions, including SP2, commands created by a spawnlist ''must'' only refer to other objects in the same spawnlist.

----
= [[Triggers ]] =
Triggers are used to check for key events during the mission. You might check that the player is above a certain altitude, or has landed at a key airport, or that a certain amount of time has elapsed.

== [[Generic Trigger Properties ]] ==
All triggers can be marked as Active or Inactive using the ''Activated'' field. An inactive trigger does nothing. The usual way to make your mission storyline is to use the ObjectActivationAction to enable new triggers once the player has achieved a key task.

Triggers can also be marked as ''OneShot'', which defaults to true. This means that the trigger fires once, and once only. Normally this is what you want to happen, but there are some exceptions.

ProximityTriggers have two Action lists; ''OnEnterActions'' and ''OnExitActions''. If it is a ''OneShot'' trigger, only one set of actions will ever be used because after the first set has fired, the trigger will be deactivated. If you want both sets of actions to be used, you have to mark the triggers as not being ''OneShot'' (that is, untick the box).

Another common use for a non-''OneShot'' trigger is a recurring timer, where you want something to happen, say, every two minutes.

If you want to re-use a trigger after it has been fired, but still want it to disable itself after every time, you can use the ObjectActivationAction to re-enable it.

== [[Airport Landing Trigger ]] ==
Checks that the player, or an AI, has landed or touched down at a specific airport. The associated RunwayFilter object doesn't seem to care which end of the named runway you touch down on; that is, runways 4 and 22 are seen to be the same.

== [[Area Landing Trigger ]] ==
Checks to see that the player, or an AI, has landed or touched down ''anywhere''. This seems to have a lower priority than the AirportLandingTrigger, so it's common to use this to detect off-airport landings by simply not attaching any AreaRectangle.

== [[Counter Trigger ]] ==
Simply counts up from 0 to whatever level you tell it to. Use this for things like failing the mission if the player ignores five warnings that they must do something.

== [[Menu Prompt Trigger ]] ==
This asks the player to make a choice. It's usually used to give multiple ways of completing a mission by using the different menu items to call ObjectActivationActions which activate different sets of triggers and goals.

== [[Parking Trigger ]] ==
Placeholder text

== [[Property Trigger ]] ==
One of the more useful triggers, this can check a set of predefined properties of the player or an AI for being higher, lower or equal to a constant value or another property. Properties can also be combined using And/Or/Not, but you need to hand-edit the mission XML to use these groupings.

== [[Proximity Trigger ]] ==
A simple but powerful test, this checks that the player or an AI has entered or left a defined area.

== [[Timer Trigger ]] ==
It's main purpose is to simply wait for a set time and then call an action. However, it can be used for two other things. By setting ''OnScreenTimer'' to True, you get a visible timer in the sim. This can be count-up or count-down, depending on the values of StartTime and StopTime.

Since this gives visual feedback that the mission system is working, this means it is also a very useful test. If you think that an error is preventing your mission from being loaded at all, create an active, on-screen TimerTrigger. If you get a visible timer, the mission is being run.

----
= [[Goal Object ]] =
Each mission must have at least one Goal. When all active Goals are complete or failed, the mission ends. You can change which goals have to be achieved during the mission by using the ObjectActivationAction to switch them on or off.

----
= [[Disabled Traffic Airport Object ]] =
This tells the simulator that it should not create any AI traffic at a specific list of airports. You don't want an unplanned 747 bearing down on you when you're in the last few minutes of a two hour long mission, nursing a crippled Cessna back to earth at Heathrow. It can also affect some triggers which may be set up to fire for any aircraft.

= Related content =
Placeholder text

= External links =
http://www.fsinsider.com/developers/Pages/MissionBuildingTips.aspx

[[category:FSX]] [[category:Missions]]

Compiling

2008-01-04T14:24:15Z

Jimkeir: New page: __TOC__ == Compiling Missions and Rewards == Both Missions and Rewards are written as XML files. While missions may be (and usually are) run straight from the XML, rewards must be compile...

__TOC__

== Compiling Missions and Rewards ==
Both Missions and Rewards are written as XML files. While missions may be (and usually are) run straight from the XML, rewards must be compiled before they can be used. In short, if you don't use any rewards and don't care about saving a fraction of a second in loading time which the player won't notice anyway because they're reading the mission briefing, stop reading now.

There are two reasons for compiling a mission. First, it makes it rather faster to load. For all but the largest missions though, this isn't going to make much noticeable difference. Second, it makes it a little harder for the unwashed masses to find out your mission-writing tricks because the compiled version can't be loaded into mission editors. However, thanks to the SPB2XML [http://www.google.com/search?q=SPB2XML] tool it can be converted back to XML.

On the other hand, it can also cause a little confusion for you, the mission designer. You have to keep the original mission XML available, otherwise you can't edit it any more. When you compile your mission though, FSX has two different versions to choose between and it prefers the compiled version. That means that if you compile a mission and then make some more changes, those changes won't appear in FSX unless you delete the compiled version. It's easier to only compile your mission once it's absolutely finished, or to not compile it at all.

=== Running the Mission Compiler ===
The mission compiler, <tt>simpropcompiler.exe</tt>, is part of the [[SDK#FSX|SDK]]. It's located in the "<tt>Core Utilities Kit\SimProp</tt>" subfolder of the SDK and is a command-line tool. That means that if you double-click it, you'll see nothing more than a brief, black flash.

While it's certainly possible to set it up to work with drag-n-drop operation, there is a significant downside to this. If there are any errors in the XML, you won't see what they are because the DOS box that opens temporarily will close before you can read the error messages. It's better to open a good, old-fashioned DOS prompt.

Unfortunately there are several different paths needed, so the command-line can get rather long. After you've opened the DOS prompt (use Start->Run and type "cmd"), change directory to the folder with the file you want to compile. If you ''really'' don't do typing, you can drag the folder from an Explorer window over the DOS window and it will do it for you. Type <code>cd </code> (with the space afterwards) and then drop the folder.

The command you need will be similar to this:
<pre>
"(Path to Compiler)" 2spb -symbols "(Path to FSX)\propdefs\*.xml" my_file.xml my_file.spb
</pre>

'''(Path to Compiler)''' must be replaced with the path to the compiler, oddly enough. It must include the "simpropcompiler.exe" part. Again, the easiest way to do this is to find it using Explorer and then drag-n-drop simpropcompiler.exe onto the DOS window. The rest of the line gives the compiler instructions.

'''2spb''' tells the compiler what to do - that is, compile some XML to spb. '''-symbols "(Path to FSX)\propdefs\*.xml''' tells it where to find some important reference data. '''my_file.xml''' is the file you want it to compile, and '''my_file.spb''' is the file it will create. You need to change '''(Path to FSX)''' to wherever you've installed FSX to. If you have a standard installation, this will be:
<pre>C:\Program Files\Microsoft Games\Microsoft Flight Simulator X</pre>
so the full symbol path will be:
<pre>C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\propdefs\*.xml</pre>

A full command-line, then, might look like this:
<pre>"C:\Program Files\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\&crarr;
Core Utilities Kit\SimProp\simpropcompiler.exe" 2spb&crarr;
-symbols "C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\propdefs\*.xml"&crarr;
my_file.xml my_file.spb
</pre>
If this works, you will get an SPB file created. There is no 'success' message; if all goes well you will see the normal Microsoft copyright messages and nothing else. If it doesn't compile, you'll get a list of errors and you can use this list to find out what's wrong, and fix it. You can usually try compiling it again by just pressing the up-arrow key and then Enter.

==== Likely Errors ====
Some of the most common errors are:
# <tt>Myfile.xml(0) : error 80004005 : Unable to load symbols.</tt>
#: This means that the path to the symbols - the bit after "'''-symbols'''" - was wrong.
# <tt>MyFile.xml(0) : error 80004005 : Read failed.</tt>
#: It can't read the XML file you told it to compile. Check that you're in the right directory, and that you've typed the filename correctly.
# <tt>MyFile.xml(0) : error 80070057 : Write failed.</tt>
#: It can't write the compiled SPB file. Maybe you've not given it an output filename (the last option).
# <tt>MyFile.xml(0) : error 80070005 : Write failed.</tt>
#: It still can't write the compiled SPB file. This usually means that it's tried to write it over a read-only file that already exists, or that you don't have permission to write to the output folder.
# <tt>MyFile.xml(1234,56) : error ??????? : Some Error Description</tt>
#: This is an actual error in the XML. The first number after the filename is the line number that it thinks is wrong, and the error description should give you an idea of what's wrong and how to fix it.

=== Running the Reward Compiler ===
As with the mission compiler, the reward compiler is also a command-line tool. However, it's a little less complex to use.

The reward compiler, <code>BGLComp.exe</code>, is also found under the [[SDK#FSX|SDK]] folder, in a subfolder called "<code>Environment Kit\BGL Compiler SDK</code>". Unlike the mission compiler, all you need to do to compile your rewards is change into the directory containing the XML file that contains your rewards, and run the compiler with:

<pre>(Path to BGLComp.exe) MyRewards.xml</pre>

With a standard SDK installation, that would be:

<pre>"C:\Program Files\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\&crarr;
Environment Kit\BGL Compiler SDK\BGLComp.exe" MyRewards.xml</pre>

If this works as expected, a .RWD file will be created and you will see something like this:
<pre>Parsing document: MyRewards.xml

Parse complete!</pre>

==== Likely Errors ====
If BGLComp.exe can't open the XML file, you will get no output at all! However, if there are any errors in the XML, the reasons for the errors are clearly described. For example:
* <tt>INTERNAL COMPILER ERROR: #C2623: Couldn't open file: (a filename)</tt>
*: A file referenced by the reward, most probably an image, couldn't be found.
* <tt>INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:</tt>
*: There's some kind of problem in the XML, and the next lines of output show where the error is.

[[Category:Missions]][[Category:SDK]]