FlightGear missions and adventures

Missions & Adventures

Started in	04/2014
Description	Interactive Missions & Adventures for FlightGear
Contributor(s)	wlbragg (10/2021) Marius_A (since 04/2014) DFaber (04/2014) [1] ludomotico (04/2014) [2]
Status	Under active development as of 04/2014
Topic branches:
fgdata	missions-fgdata/

Targeted FlightGear versions: 3.10+

This article is a stub. You can help the wiki by expanding it.

Status / News

See also Mission Editor or FGjobs.

As of 04/2014, Marius_A is working on extending Stuart's Tutorials system to also support missions and adventures. That way, missions and adventures can be easily created and maintained by editing XML files, so people don't necessarily need to be coders (familiar with Nasal scripting) to add/extend missons. In fact, we could even use the existing GUI Wizard Framework to create simple missions using a step-by-step wizard:

Gallery

• 

  DFaber's Walker used for adding NPC support to Stuart's tutorial system

• 

  Experimental interactive MapStructure layer for visually placing 3D objects like mission objectives, NPCs, traffic etc

Status (04/2014)

• set up a gitorious repo with shared access for all contributors [3]
• helicopter missions (Marius_A [4] )
• Walk View support (Marius_A [5] )
• AI scenarios support (Marius_A [6] )
• NPC support (DFaber [7] )
• self-steering AI vehicles (DFaber [8] )
• extend the framework to support reloading/restarting tutorials at runtime (Marius_A [9] )
• support dynamic mission objectives instead of just static positions Not done [10] [11]
• investigate supporting Nasal blocks for having multiple instances of an AI/model i.e. for vehicle/NPC control [12] Not done
• investigate supporting optional Canvas areas for showing mission objectives via MapStructure (Hooray & ludomotico[13] ) [14]
• procedurally-created Canvas GUI dialogs, e.g. for interaction with NPCs and mission briefings Not done
• allowing startup time and environmental settings (weather/METAR string) to be stored as part of the tutorial (e.g. for CAT3 approaches at night time) Not done

Contributing

Note  Contributors wanting to check out the topics/missions-integrate fgdata branch, need to follow these 3 steps: git remote add missions https://gitorious.org/fg/missions-fgdata.git git fetch missions git checkout --track -b topics/missions missions/topics/missions-integrate This will give you a local branch named topics/missions, so that you can easily pull/push changes. When pulling, it makes sense to pull with --rebase Please never push directly to the master branch, and please don't push force (-f) either.

Roadmap

Version Attribute

add a new version tag next to author/description etc, so that we can safely add new features without breaking old tutorials

• Hooray [15] : One of the most important changes to prepare more flexible solutions in the future would be introducing a "version" tag/attribute, so that we can provide backward compatibility, while also adding new features, without breaking old tutorials. In fact, the existing tutorial subsystem is fairly flexible, but simply because it's "open-ended" due to the way Nasal scripting is recursively supported, it's so much by design, i.e. there's actually very little in terms of class hierarchies or even OOP in the first place. when it comes to renaming the tag, or supporting additional tags, I really suggest to introduce a mandatory "version" attribute first. Once that is in place, things will be safe to change in the future. [16]

Separate Modules (Hoops, AI, NPC etc)

I would suggest to keep the amount of custom Nasal code in tutorial.nas very low - any huge amounts of code are a sure "code smell" that the framework isn't yet sufficiently generic and needs to be extended. Things like AI interaction or hoops should preferably be separate Nasal modules (files) that we can either just move into $FG_ROOT/Nasal (or as a submodule), or simply include via io.nas from some other place (load_nasal)

While the tutorial/mission system will need access to such features, those features should not be a part of "just" tutorials, those should really be modules that can be reused in other places. Hoops is one such example - we need to be able to use the code, but it should not be tied/coupled to just "tutorials". Thus, we simply need to use separate files here and make sure that we can include/load and use such code.

The tanker.nas code would be another example here, its features would be immensely useful to the tutorial/mission system, because we could easily create AI traffic and control it - but this should not be tied to "tutorials & missions" obviously.

For starters, and the sake of simplicity, it should suffice to simply maintain such features as separate submodule-files inside $FG_ROOT/Nasal/tutorial, so that things can be more easily refactored later on.

The only thing to keep in mind here is to ensure that such modules are mostly declarative, i.e. do not actually do anything other than provide helper functions and classes, so that these can be easily moved around without any refactoring needed.

XML Extension Framework

Hooray is currently working on a simple extension mechanism so that a handful of XML tags can be used to directly extend the tutorial system such that new primitives (elements/tags) can be added and supported at runtime, without requiring tutorials.nas itself to be edited. The main extension mechanism is based on the following structure:

<register-element>
 <name>hello-world</name>
 <require-arg>name</require-arg>
 <nasal>
 # this is the section that will be called whenever a new hello-world tag is encountered
 # it can directly access its arguments (passed as a props.Node via arg[0])

 # get out the required arguments
 var args = arg[0].getValues();
 var name = args["name"];
 print("Hello World ", name);

 </nasal>
</register-element>

If this construct is encountered anywhere in the toplevel structure of the tutorial, it will cause a new element type to be added, which is named hello-world here, and which takes a single mandatory argument named name, whose nasal section will be called to implement the element.

The basic idea here is to allow custom building blocks to be easily added with very little needed in terms of coding - primarily, so that we can get rid of highly specialized Nasal blocks and instead come up with generic components that can be easily declared and reused via XML (i.e. maintained outside actual tutorial files, inside some generic library of elements), using the established include/params method.

For example, to expose a new timer tag to the system, we would first of all register a new handler that declares a name, a list of required arguments, including a Nasal section for actually setting up & registering the timer - this is accomplished through a file named timer.element as shown below:

<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
        <!-- this exposes the settimer/maketimer API to XML space that can be resursively used in combination with other tags/elements -->
                <name>timer</name>
                <require-arg>delay-sec</require-arg>
                <require-arg>nasal</require-arg>
                <require-arg>repeat</require-arg>
                <nasal>
                        print("timer setup requested !");

                        # get out the required arguments
                        var args = arg[0].getValues();
                        var name = args["name"];
                        var delay_sec = args["delay-sec"];
                        var code = args["nasal"];
                        var repeat = args["repeat"];

                        # print("compiling code object:", code);
                        var obj = compile(code);
                        if (typeof(obj)=='func')
                                settimer( obj, delay_sec);
                        else   
                                die("tutorial/timer.element: Could not compile timer:", name);

                </nasal>
</PropertyList>

This is just a declaration, analogous to a conventional function. Multiple of such element declarations can be put into a single XML file, e.g. named common.xml:

<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
        <!-- common building blocks, expose these to XML space -->
        <register-element include="timer.element"/>
        <register-element include="listener.element"/>
        <register-element include="random.element"/>
        <register-element include="fgcommand.element"/>
</PropertyList>

To actually make these elements available to the system, the "include file" has to be explicitly referenced from a top-level tutorial's runtime section like this:

<runtime include="Tutorials/Generic/XMLComponents/common.xml"/>

An arbitrary number of runtime entries are supported to better support modularization.

Afterwards, you can simply access and use these new elements by using their tag as part of the Tutorials markup:

<timer>
                <name>test</name>
                <delay-sec>1.0</delay-sec>
                <repeat>0</repeat>
                <nasal>print("Hello World from an XML  timer");</nasal>
</timer>

This will basically look up the implementation that we introduced earlier, and then create a new timer named test with the delay/code block as specified. recursion is fully supported, which means that this new tag/element can be used as a nested parent/child node of other tags, including not only native building blocks (set, models, view etc), but also other custom elements.

In the same sense, we can now also easily expose other elements, such as for listener handling - which makes reusable XML-constructs like these possible:

<timer>
                <name>test</name>
                <delay-sec>5.0</delay-sec>
                <repeat>0</repeat>
                <nasal>print("Timer triggered...");</nasal>

                <listener>
                 <name>myListener</name>
                 <property>/sim/signals/exit</property>
                 <nasal>
                 print("Goodbye ...");
                 </nasal>

                </listener>
</timer>

Here, we are registering a single timer named test and add a listener below it, which gets created once the timer expires (after 5 seconds here).

The most important -and most powerful- feature that needs to be supported is recursion i.e. being able to recursively use existing elements to make up new ones, which would basically allow us to consider each element building blocks for other components:

<register-element>
 <name>per-frame</name>
 <require-arg>nasal</require-arg>
 <nasal>
 # this is the section that will be called whenever a new hello-world tag is encountered
 # it can directly access its arguments (passed as a props.Node via arg[0])

 # get out the required arguments
 var args = arg[0].getValues();
 var nasal = args["nasal"];
 # look up another XML element and invoke it recursively 
 invoke_element( name:'timer', params: {'delay-sec':0.0, nasal:args.nasal, repeat:0 } );
 </nasal>
</register-element>

Ultimately, this exposes a fairly simple but powerful framework for meta programming without necessarily having to be a proficient Nasal coder. Building blocks can be created and maintained by more experienced Nasal programmers, while they can be easily reused without having to write a lot of code. Typically, it's just the "payload" (i.e. the nasal section) that needs to be populated.

The whole idea is to help better modularize things by coming up with a library of generic building blocks, such as for example:

• timers
• listeners
• random number generator
• fgcommmand
• GUI routines (showing a dialog)
• looping (forindex/foreach can be trivially exposed via corresponding XML tags)

To make this work properly, there are some key concepts that need to be supported and implemented, specifically:

• it must be possible to easily register new handlers
• custom parameters need to be supported
• recursion must be fully supported
• it must be possible to call/reuse existing components easily Not done
• switching (passing data) between XML/Nasal must be seamlessly possible Not done

Mission Briefings

Hooray & ludomotico have started to extend the tutorial dialog to add briefing related info.

Also see Mission Briefings & Map Previews

• Hooray [17] :Regarding the tutorials dialog, I would suggest two add an optional (hidden by default) canvas area, we could use that to render an included raster image, i.e. to add a logo, but we could also use the canvas to render a map to "preview" the mision, i.e. by rendering important waypoints (airport, oil rig) etc
• Hooray [18] : I am not going to do any 3D or texturing stuff, but I can help with Nasal related things, as well as adding Canvas-based features to the system so that things like the route can be visualized prior to actually flying the mission, i.e. next to the introduction - kinda like a "mission briefing" like you would get to see in a real game or combat simulator. For example, see these FSX screen shots (which we can now fully recreate using Nasal/Canvas)
• ludomotico [19] :Most of the building blocks to create missions are there, except mission briefings. At first, I would be happy if there is an easy way to show dialogs from nasal space. By "easy", I mean a single nasal call to show a window with an image and text, or ideally a "notebook window" showing a set of images linked to a set of texts with prev/next buttons. Also, the snapshots you provide show some interesting pieces of data our missions should include as metadata: estimated duration of the mission, whereabouts, difficulty, aircrafts... Currently, only a description and an airport are provided by the xml file.

Scoring & Penalties

• ludomotico [20] : I don't like competitiveness, but I acknowledge we must collect a "list of requirements" regarding scoring.
• ludomotico [21] :Some way to manage a list of high scores, or a "history of scores" to have some track of the evolution of the pilot may be adequate. A second iteration could include an online list of high scores. Personally, I'm not interested in world-wide high score lists but they may be fun for some users.
• Hooray [22] :

A performance evaluation is another thing that could greatly benefit from simple canvas-based animation showing scores/penalties. We probably need to add a simple scoring system so that people can implement their own bonus/penalty triggers. Some of the more common ideas discussed elsewhere include: autopilot usage, exceeding certain limits(.nas), time & speed.

Also, anything that involves airliners will typically be involve W&B (fuel efficiency) - i.e. see all the "economy" discussions we've here regarding fuel efficiency. If that is something that is to be supported, it would make sense to directly support only aircraft having at least an early-production status, including a configured and working W&B dialog (as per gui.nas).

Regarding post-flight evaluation, this will either involve sampling data points at run-time via timers, or hooking into the history/replay subsystems. Personally, I'd suggest to focus on those aircraft that already come with a working flight recorder configuration. That should limit the number of supported aircraft quite significantly, while also reducing the amount of frustration for users wanting to play with this using incomplete/unfinished aircraft

Basically, I am saying that it will be less work to ensure that mature aircraft use/provide things like 1) checklists, 2) the w&b dialog and 3) the flight recorder system, than working around all those aircraft that are nowhere close to supporting either of these features but still want to support "missions" - especially given that an aircraft-based tutorial/mission system would greatly benefit from these features being properly set up by the aircraft developer in the first place.

Overall, this should also help improve consistency while reducing the chance for disappointment and frustration among new users (keeping in mind that missions are going to appeal particularly to non-contributors, i.e. users looking for gameplay)

Weather support

• ludomotico [23] :Loading METAR from a string is not as straightforward as I though Checking the weather dialog, it seems there are lots of things to do before and after loading a raw METAR string. I even think some of these settings (such as /environment/realwx/enabled) are remembered when FlightGear ends. I believe missions shouldn't change the user configuration. Is there an "easy way" to load a METAR string or we need a function loadmetar() in the __tutorials namespace?
• Hooray: Also see [24]

Multiplayer support

• ludomotico [25] :I don't know if MP integrates in any way with the tutorials/missions system. Probably they work together but do not communicate each other. For example: how can we send our score to other players? Or remove a rescued person from all connected players at the same time?
• ludomotico [26] :In multiplayer missions, some way to share individual scores between the participants must be devised. At this moment, I believe preventing cheating is unimportant. I just put the issue on the table in case someone thinks otherwise.
• Hooray: Instead of using the chat system, see Multiplayer scripting in Nasal

Background

FlightGear is especially interesting for people who already have some form of aviation or programming background. Most people without such a background, will probably find FSX/X-Plane much more enjoyable though - which comes down to usability issues. But also to lack of resources to get people easily started in an interactive fashion (tutorials, missions, adventures etc). Unlike FSX, we don't have an integrated "flight school" or other interactive features (missions/adventures).

We've had many people asking for "missions" support for years, i.e. creating "game objectives" and allowing people to complete tasks. There are many things that are possible here. The tutorial system certainly is an excellent starting point, as is flug's bombable addon.

The question is, if you'd want to create a completely new system in scripting space (i.e. similar to the tutorial system or to bombable) or if you'd want to extend the tutorial system instead. The latter would have a number of advantages, i.e. being a very direct entry point and pretty accessible for end users, even without requiring rock solid Nasal knowledge.

If you are highly motivated to do this, it should be possible to learn Nasal "as you go", i.e. at the same time. Thorsten apparently started out without any significant FG/Nasal knowledge and implemented his local weather prototype while still learning Nasal. But it seems he had some previous programming experience. So it's definitely possible. And even if you don't find anybody directly contributing, you can surely help enough people here to provide guidance and mentoring for Nasal related issues.

At the same time I first started messing around with FGFS I tried out Flight Simulator. To be honest, there was not much difference between the two, at least IMO. Only thing I saw that was there in FS that is not in FGFS is missions. I would love to see missions here in FGFS. Flying just for kicks and flying for Virtual Airliners is all good, but I would like something else to do besides these two things. — k33bz

the missions in MSFS was one of the things that drew me into it, the lack of keyboard support and decent control was one of the things that turned me away, so if you could have both, that is perfectly fine by me, apart from my favourite "mission" isnt posible in FGFS... no oil rig or moving boats... — Arthur Maiden

I had a chance to give MS Flight a whirl and felt that the mission elements do have somewhat of a compelling draw in terms of making one want to come back to build up more points, advance in pilot status, mark off more missions, etc. I suppose that's the game-like feel of it, though I imagine that having an easily accessible list of "featured destinations" that people could continually add to could be fun and mission-like without being too intrusive. The Siri-like companion in Flight also adds a new dimension to flying, both for teaching in the tutorial and also for adding a "social" element. — the4thchild

I only flew MS flight simulator in demo version long time ago but one thing I remember is the ability to choose a mission. I think this could be quite a challenge for fg pilots, too after they got to know the basics of flying and navigating. On the fg homepage one can find in the menue "places to fly" but this is only a hint for an interesting region or airport in general. I would appreciate a complete mission with descrption of the airport where you take off, description of departure procedure, important en route navaids, STARs and description of destination airport. — jaques.flightgear

"Missions" , this name come from MSFS, where you have to complete tasks like rescuing from oilplatform, landing at bad weather etc... On the one side it gives me a high Game character, on the other side it can be usefull to learn. The SenecaII and the HansaJet uses our Tutorial system for the checklists. The C172p for educating how to fly properly. "Missions" aka Tutorials should be better used to show and educate things to users. — HHS

A random mission generator or even a bit of an economy simulation would be a nice addition to FG at one point. I kind of liked these add-ons in FSX as they do add a certain purpose to flying from A to B. — Bjoern

This has already been discussed. The solution found was to use the tutorial system to make interactive missions. No one seems to have done that yet.There's a way to make those. If you learn how to make those, you can use that system to make interactive missions just like in FSX. — redneck

I thought about a tutorial integrated with flightgear that when you start up for the first time it asks you if you wan't to do a tutorial on how to use flightgear. if you choose yes it will take you to a specific airport with(parked) a specific plane (something small and easier than the c172) and show you the controls of flightgear and then how to fly the plane this tutorial must be short however and also a bit fun or else they won't wan't to play it. This is a long term project but it will encourage new players to keep flying and to have more veterans playing, and to have a less crowded KSFO. — Trez

wouldn't it be good to have some missions or tasks or what ever we call them in FG, like in other games such as silent wings, or anything. The task could bee like flying from an airport to another, but FG could calculate the avarage speed, and if its too much you have to start over the mission. I was thinking of this.. As you guys know, there's this Nellis Bombing Range Demo, where you have to bomb a couple o' M61 Abhrams tanks. I was thinking, why don't we enhance this, and transform this into a mission, where you can only 'succeed' if you bomb all of the tanks or something.. — jacksonaron

That would be nice if there was some way to control how many bombs you drop. I don't know about other planes, but right now, with the F4-E, the only way you can drop a bomb is if you drop all of them at once, which makes this mission impossible for this plane. Also, guns don't seem to have any effect on the tanks. — redneck

Each mission will be self-grading, on a pass-fail basis: either you will make it, or you will crash. — someguy

Like a mission mode, which could probably be done either in mp or solo flying. Like in a game. You would have a series of tasks you would have to complete, you may or may not have a time limit, and when you complete a mission successfully, it gives you feedback on your performance. — redneck

you could use Nasal. Just like the Air-racing script. You can then have checkpoints and scoring — Fahim Dalvi

if you like missions, then start writing some. I don't think it's very difficult to do in Nasal. — Thorsten

Actually, you might not need any Nasal.I assume the idea is that the user has to pilot the helicopter and hover over the boat? That should be easy enough. You can create an AI scenario with the boat - have a look at docs/AI_doc.html for help. You can either set a speed and rudder value (so it goes in a circle), or you can create a "flight plan" for the boat with waypoints. - have a look at AI/vinson_demo.xml for ideas, and in particular the cruise ship at the bottom of the file. Once you've got your AI scenario set up, you can create a tutorial around it. There's documentation of the tutorial system in docs/README.tutorials. Relating the aircraft position to the boat position might need a bit of Nasal - there are some simple functions in geo.nas to get the position relative to a lat/lon. — Stuart

We have support for both: We already have oil-rig models, and you can use the tutorial system to place a model wherever you wish We also have boats that can be controlled either using the AI system or using Nasal. So, I don't think there is any technical reason why you couldn't create a mission using the tutorial system using both elements. — Stuart

You can use the tutorial XML system to create missions. That gives you full access to the property system and Nasal within a nice framework with logical steps. Should be pretty easy - I was thinking of creating a fire-fighting one a while back. — Stuart

A long time ago I wrote a little mission generator. It had a number of pre-generated mission types (e.g. medevac, GA IFR), and the ability to choose appropriate start and end airports based on criteria set in the mission, plus user-entered filters. So, as a user you could ask for a mission suitable for a GA aircraft starting in France. I should resurrect it some time. — Stuart

I also really liked the single player mode ATC in FSX - I'd love to work on that, as well. Currently, I'm completely clueless where to begin. I know the feature somewhat collides with multiplayer ATC, so I'm not sure what kind of reception such a system would have. I'm also short on time, and still have lots of scenery bugs to work on. It's likely that I'll never get around to it. But I'm quite sure that if someone new to the project felt strongly about it, they may go off and do it. I would encourage them. — psadro_gm

Another interesting aspect to a mission generator would be some automated system to score the performance -- that would have to be pretty open-ended because so much would depend on the mission goals. But even some simple metrics like "time to complete" or "flight odometer" would be interesting because the more direct you were in completing the mission (presumably) the more optimal and better quality your performance. — Curt

Missions

• power line maintenance
• equipment transportation
• banner pickup/towing
• precision landing

Building Blocks

• flight instruction (piloting, virtual ATC, virtual copilot/instructor):
  • navaid-awareness (NasalPositioned APIs
  • route-awareness (flightplan APIs)

Implementation

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

There are also a bunch of forum threads on rescue missions, multiplayer stuff, virtual airlines etc - the glideslope tunnel script could be easily modified to check how well someone flies an ILS approach for example.

Otherwise, the bombable or the RedBull air race addons are most likely to qualify as "mission addons" with immediate feedback/interactive scoring.

To many people, "missions" just seem interesting because they add an element of "game play" and entertainment, but also achievement obviously.

This is something that has been brought up many times before. For example, see: https://forum.flightgear.org/viewtopic.php?t=14758

Existing Examples

It's not something totally unrealistic or unseen in FG: The red bull air race track that was modeled several years ago, was pretty popular and Stuart's tutorial system can also "entertain" people, i.e. once they accomplish something.

There are many gameplay scenarios and/or "missions" that could be scripted already, with FG's flexible scripting support and its property tree, you just need to make "creative" use of all these features.

Flug's bombable addon already uses Nasal to create missions. Also, a "mission generator" like the one Stuart mentioned, would certainly be of interest to the T4T folks, too.

Event Handling

Many of these "events" you are interested in, can be directly taken from the property tree, others would consist of combinations of lower level events, maybe including timers.

Many of these things are directly related to features of the tutorial system, which should conceptually also be able to "watch" a pilot, assess and evaluate the performance and dynamically provide feedback.

For instance, imagine a simple "student pilot scenario" - i.e. fixed climb rate climbs vs. fixed airspeed climbs.

This is something that would be VERY simple to check from scripting space using Nasal and polling. You would only watch a bunch of properties and see if the aircraft is climbing and if the objective (climb rate or airspeed) are met (within a certain tolerance).

Here, the feedback loop could either directly respond to the student pilot via on screen messages, text to speech or gather data in the background and use it for competition analysis (steam). This is really just a backend implementation issue and could be easily addressed by not hard coding a certain backend but instead provide a callback to be invoked for such events.

There are numerous other maneuvers that pilots could be expected to fly, while scripts (configured via the property tree/XML) are used to watch their performance. You could even implement this very generically, so that these "missions" would not be aircraft specific. Imagine flying a holding pattern: a Nasal script could obviously implement this mission without being too aircraft specific (beside speeds, altitudes - i.e. performance). So people could start different aircraft (c172, b1900d, 777) and still run the same "holding pattern mission".

You could even use Nasal to script AI/ATC interactions that pilots need to respond to properly.

For example, another simple idea to get you started might be a Nasal script to implement a GCA ("ground controlled approach") mission: http://de.wikipedia.org/wiki/Ground_Controlled_Approach

This would simulate an air traffic controller "talking you down", i.e. providing all the feedback an ILS would normally provide (vertical/horizontal deviation from the glide path). This could be very easily implemented in Nasal space. You would just need to configure the script (airport, runway, touchdown point, altitude, glide path) and the GCA script could vector you onto the right course and request you to change altitude as required.

Approaches

Missions/Adventures: something that would give an overall rating, based on the number of successful accomplishments, multiplied by an objective-specific factor, divided by the total number of objectives - where you could factor in the time it has taken to complete each invididual objective.

Doesn't seem too complicated to come up with some Nasal code for this.

Starting completely from scratch will obviously require a fair amount of Nasal knowledge, because you need to come up with a design that works. That will be more powerful in the long run, because the system can be specifically crafted for this purpose in particular.

On the other hand, using the XML-configurable Tutorials system will be very simple in the beginning, even people without significant Nasal knowledge could get started quickly. But you'll be more likely to hit road blocks eventually, because the tutorial system was never designed to be as interactive as required here.

But then, extending the tutorial system to provide better support for interactive features would obviously be useful for many different tutorial-related aspects.

Starting from scratch, you'll have all the power you need, simply because you get to design your architecture right from the beginning. Borrowing concepts from others scripts (including the tutorial system!) might still be a good idea though.

If this approach is pursued, you'd basically end up with another system entirely implemented in scripting space, like flug's bombable addon or Thorsten's local weather system.

But, if you don't know Nasal yet, or if you have not yet done any programming before, then this is going to be the least gratifying pathway, because it's going to take you ages. Somebody already knowing Nasal or another scripting language could probably get started fairly quickly, though.

So the tutorial system is certainly easier to get started with. Even if you should hit any road blocks, you won't need to write an entire system from scratch, but you could just augment it where necessary - either by patching the existing system, or forking the script and creating a mission-specific version of it.

Another advantage here might be that you might get some fellow Nasal coders here to implement some of the required infrastructure as part of the existing tutorial system.

Personally, I would recommend looking into creating a new system though. In its current form, the tutorial system doesn't really have any concept of "tasks" or job queues running in the background, but once you start assigning missions, you need some system running in the background to monitor the performance of the pilot, gather data, create statistics and populate a feedback loop.

This may sound much more complex than it really is. For instance, remember the "GCA" idea I mentioned: if you were to create such a system entirely in scripting space, it would certainly end up being less than 150 lines of Nasal code. The important thing here to keep in mind, is to "rinse and repeat": come up with similar ideas and then keep generalizing, unifying and refactoring the system, so that it becomes increasingly flexible for different scenarios/missions.

I would suggest to favor those aircraft and airports which are generally considered "well developed" or actively maintained, and which are featured in "suggested flights" or "suggested aircraft" respectively. So the wiki should contain some good suggestions (i.e. see past newsletters).

In other words, I'd suggest to pick "ingredients" (airports, aircraft) which are unlikely to frustrate people due to some shortcomings and which are unlikely to be abadoned soon.

For instance, if you want to keep it simple, picking the c172p and some airport like KSFO or KOAK should be simple enough: people don't need to download/install additional stuff (aircraft/scenery), and one of the simplest tutorials could be flying straight and level, doing turns, doing standard rate turns etc.

Basically, most flight instruction stuff could be turned into tutorials. Obviously, one should start simple (engine start up, taxiing etc).

That doesn't mean however that your tutorials need to have a focus on flight instruction, the tutorial system could just as well be used to create missions or adventures.

But if you haven't created tutorials before, I'd suggest to keep it simple in the beginning - you'll learn quickly how to implement more complex missions.

Also, there's tons of existing stuff that you could learn/borrow from - take a look at aircraft which already have interactive tutorials, and see how they work - you could copy/paste and customize the XML stuff easily.

To make things entertaining and interesting, you could try to provide some incentive (scoring with points/percentage, best of, timing, precision during flight maneuvers etc). Just look at the tutorial.nas file, it already supports stuff like progress/completion messages - and it can be easily extended to also support scoring, high scores or whatever else you may have in mind - making a handful of modifications like these should be straightforward, even if you don't know a thing about Nasal scripting - there are enough folks around here who are happy to lend a helping hand to walk you through, or even post full snippets of code - afterwards, it just boils down to opening existing tutorials or creating new ones.

I suggest to read through these docs, and you'll see that creating simple missions is already supported - even without touching any code, just by editing XML files. So, that's not a real issue - unless of course you are asking US to create missions for you? :D

For starters, you could look at existing tutorials and see how they work - start by modifying them, copying snippets around - for example, change messages, numbers, targets - and it will all fall into place pretty quickly. Next, you can start your own little tutorial, such as flying a pattern at KSFO - it really isn't rocket science, and it doesn't require any coding either.

Related

• Missions for Helicopters
• Tutorials/Missions/Adventures: requests for features
• FlightGear on Foot
• Halloween Special: The evil Graveyard
• Achievements: New Motivator and Feature Introduction Method
• FlightGear and Unity3D
• Missions
• Races
• A Failure Management Framework for FlightGear (FSM stuff)
• Flightgear On Steam