Missions - Creation

From FSDeveloper Wiki
Jump to: navigation, search

How to create missions, a supplement to the SDK.


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 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 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:

  1. Fly above 1000 feet for three minutes
  2. 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 AirCreation Trikes will be one step closer.


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 PointOfInterest (POI) objects, and 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 ProximityTrigger. When you leave the rectangle, the trigger calls a 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 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 DialogAction and PointOfInterestActivationAction.

Lots of handy tips are also available here: 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.


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 PropertyTrigger checking "Altitude AGL > 10" to test for takeoff. That would start a 30-second TimerTrigger using an ObjectActivationAction which, in turn, would call a 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 DialogAction (just to keep the player informed), an ObjectActivationAction to enable the Trigger that checks "At Point B" and another 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 TimerTriggers and ProximityTriggers, each with some DialogActions 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 deactivated 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 ProximityTriggers 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.


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



HowTos & Tools

See these pages for HowTos & Tools used in creating -


Categories - Assigning and creating categories.

Mission Coding

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


Rewards - Creation tips.


Sounds - Creating dialogue, and sounds, for missions.


Artwork - Creating artwork for mission briefings, rewards, etc.


Briefing - Creating the UI HTML file(s) to introduce your mission.



Compiling Missions - Description

Link - Description

Link - Description


If you haven't found what you're looking for here, then we'd recommend, (in order of preference) -

  • AVSIM - Mission downloads (newest first).


'Reference' documents specifically related.

Function Reference - With example code.

Link - Description

Link - Description

To Sort

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


Object Placement Tool - Installing, configuring, & general useage tips.

Tools placeholder text.


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

Function Reference

This section gives some basic details on the different types of object available to mission writers when writing a mission script.


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 :

[Debug] ReportLoadErrors=1

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 OnScreenTimer 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.