- instrument failures. Actually, it is not a mission and it is already implemented on some aircrafts Let's say: instrument failures under bad weather.- historical flights: Wright brothers, Spirit of St. Louis, Wold War I and II, Amelia Earhart, Saint-Exupéry...- aerobatic flights. For example, the area of Douro river (city of Porto, Portugal) is already prepared for aerobatics in FligthGear, and there are some nearby airports that deserve some attention. http://www.mckislev.com/images/portugal ... rtugal.jpg

Regarding instrument failures: This is something that galvedro is working on: http://wiki.flightgear.org/A_Failure_Ma ... FlightGearAnd he's aware of Marius' work here - He's hoping to finish his own work in time for 3.2 - and it is designed in such a way that failure management can be externally controlled (e.g. by a missions/adventure subsystem), so we're going to support that via tutorials.nas (missions/adventures), too. It should be fairly straightforward according to galvedro's own words.

anything related to piloting/aerobotatics (red bull air race) and maneuvers will require some means to do flight profile tracking, either by sampling lat/lon/alt or by hooking into the replay/history subsystems (currently not exposed to Nasal).

Functionality-wise, it would be cool to provide all the building blocks to allow people to create "adventures" like this one we talked about a while ago (and it's helicopter-centric too):

Currently, the tutorial system doesn't have any built-in support for "fly to the SFO VOR" - but once we have that, we could even support flying holding patterns ( "fly to sfo maintain 8000, hold left on the 180 radial"). Such things would be useful also for virtual flight instruction - but also for an ATC adventure, i.e. where a virtual ATC controller guides pilots down a GCA path using radar vectors and AGL altitudes

All this stuff is already exposed to Nasal thanks to the work that Zakalawe & TheTom have done as part of "NasalPositioned" and those flightplan() APIs - so we really only need to expose a handful of building blocks so that people can create route/navaid-aware missions. This would be primarily useful for any "flight instructions"-based scenarios, i.e. perfectly in line with the original purpose of the "tutorials" system, while also allowing additional functionality to be developed on top, i.e. having scripted virtual pilots or ATC controller.

For aircraft-specific tutorials, I would hope to use the upcoming "Catalog metadata" to ensure that similar aircraft can be chosen to work through the same tutorial/mission/adventure: http://wiki.flightgear.org/Catalog_metadata

Basically, aircraft making use of catalog metadata have sufficient meta information, so that the tutorial system could allow people to fly the same "power line maintenance" mission with different helicopters, i.e. R22, bo105 or ec135 - aircraft specific stuff (e.g. max speeds) could be looked up using the data provided via aircraft checklists: http://wiki.flightgear.org/Aircraft_Checklists

In the same sense, a twin-engine mission could be flown with different twin-engine GA airplanes that way.

To track mission objectives, we could use a procedurally-created canvas dialog that shows some bar charts.

content-wise, we should focus on aircraft and locations that are fairly well-developed, to ensure that there's not too much maintenance overhead involved due to missing/incomplete features.

- Maritime rescue: Go find a damaged ship, get all crew on board and take them back to a safe place. Add bad weather and night as a topping - Mountain rescue: Go find a crazy climber in a mountain range (with perhaps just fuzzy indication about his location), get him on board and return to base.- Mountain refuge supplies transport: Take a load of supplies and deliver them in a mountain refuge.

most of these missions should require very similar features, i.e. in terms of building blocks that need to be supported/added by extending tutorial.nas - this may boil down to just having a handful of additional primitives added.

Being able to control daytime and weather as part of the setup seems like a cool idea that should be straightforward to implement, weather would be best supported by simply storing the METAR string to keep things simple.

The tutorial system itself already has support for placing 3D models in arbitrary locations, no matter if it's a vessel, climber or a vehicle: http://wiki.flightgear.org/Tutorials#ModelsBut those are all static currently, so we would need to use this in combination with an AI scenario, which is not overly flexible, and also not that easy to deploy.

I would consider extending the current "models" tag to also support movable AI objects, we have enough code doing this sort of thing (tanker.nas, bombable, fox2.nas) and it would allow us to encode other traffic (vessels, aircraft, ground traffic) as part of the actual XML file. Some kind of "traffic" or "aiobject" would be simple to add and support, and each tag could have its own Nasal section that controls it.

I agree most of the code is already there by extending the tutorial system and a bit of nasal.

The only thing I'm not sure is how to load "mission files". Should missions be defined in the -set.xml of each aircraft? Should they be defined as a scenario? A new entry in the menu? How could we load a mission from fgrun, for example?

ludomotico wrote in Wed Apr 16, 2014 4:44 pm:I agree most of the code is already there by extending the tutorial system and a bit of nasal.

The only thing I'm not sure is how to load "mission files". Should missions be defined in the -set.xml of each aircraft? Should they be defined as a scenario? A new entry in the menu? How could we load a mission from fgrun, for example?

fgrun itself is completely unaware of tutorials, while it would be possible to use some --prop: argument to change that easily, I am not even sure if that makes sense:

Given the recent progress in the reset/re-init department it is foreseeable that we'll sooner or later be able to switch aircraft at runtime, and for most purposes/end-users we're hoping to eventually get rid of having to use external launchers by providing a simple integrated GUI wizard using Canvas/Nasal (initialized much earlier than the rest of the sim) - this is something that Zakalawe & TheTom have been working on as part of the reset/re-init effort:

And for the "missions" system itself it would actually be good to support aircraft/location-agnostic missions, so that people can use the same system with different parameters (aircraft, location, daytime, weather etc) - so it would make sense to get rid of this limitation at some point - for example by allowing some tutorial.setup() routine to be invoked during initialization, rather than requiring tutorials to be statically defined/integrated by editing the -set.xml file

There could still be a simple wrapper that parses some custom --prop: argument for these purposes.

From a usability point of view, the option that sounds best to me is to make the missions a file (or pack of files) that can be loaded at runtime. If you want to make them aircraft specific for whatever reason, a "<compatible-aircraft>" kind of tag would be a possible solution.

But it is also a sane exercise to look at how "the industry" has addressed the issue, and how it works for them:

I am not an FSX guy, I have no clue about how they organize the mission stuff, but X-Plane (vanilla) implements the "all missions in the menus" option and, to be honest, it looks so-so, if not amateurish. It works, but is not scalable at all. It works for them because they support a very limited number of missions, and they rely on third party pluggins for doing more advanced stuff.

DCS (the military series) use the "missions are files that you load" approach, and I think it works nicely. It doesn't really matter if you have a gazilion missions or if they are aircraft specific (they are). You just locate the mission file in your harddisk from the launcher, and fire the mission. Simple (for the user) and scalable.

Condor (a soaring simulator) also goes for the "missions are files" (I guess we could say that Condor "tasks" are in fact some kind of "missions"). One good consequence of this choice that can be seen in Condors community, is the potential for sharing and interchanging the missions. You can only achieve that level of dynamism if missions are made a detached asset.

I think at least for now, we'll have to live with the current method of tutorials being included via -set.xml files. Sooner or later it would indeed make sense to decouple and generalize things a little.Currently, tutorials are already "self-contained" in that they're "just XML files". But required resources (textures, sounds, liveries, aircraft, scripts) are simply referenced, i.e. need to be put in the proper location separately. But that touches the realms of aircraft management and fgdata resource management.

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.

Being able to "package" missions/adventures would be great, and there's already code in SG/FG to support reading gzipp'ed files (archives), but none of that is currently exposed to Nasal, so that would need to happen first in order provide a straightforward mechanism to have fully self-contained "missions" with all required files/resources being included.

From a technical standpoint, I would also still prefer "missions/adventures" to be just conventional XML files, but maybe we need an option to declare dependencies, so that sounds/textures/models etc can be looked up accordingly. But I do believe that such missions need to be aircraft agnostics, and anything that is aircraft-agnostic should be handled by "catalog metadata" (to define the type of aircraft supported/required), and performance specific stuff should be looked up via the existing checklists system - that would allow people to come up with generic missions/adventures, without them having to be specific to a single aircraft. And given that manpower is our main bottleneck, that should also help equip existing aircraft with missions easily - because just the aircraft specific stuff would need to be filled in, while the mission itself would remain untouched.

Being able to share and exchange missions seems like a worthwhile goal to aim for in my opinion, because we could basically cultivate a culture of "mission/adventure development", where people would not necessarily need to be aircraft/scenery developers, and where even Nasal knowledge may not be required.

For example, coming up with a mission that runs a simple twin-engine CAT3 approach at LOWI with strong turbulence, and a failing engine, should not require too much work with the existing system, and the same mission could then be used by different aircraft, including airliners, biz jets, but also twin-engine GA aircraft like the Seneca, requiring very little in terms of customization, all outside the actual mission/tutorial XML file.

That way we could grow a library of missions and adventures and provide examples on integrating those with different types of aircraft/vehicles.

May I also suggest to refactor the existing naming convention and replace "tutorial" for "mission". Tutorials came first, but now you are extending the system to encompass more than that, I think it deserves a promotion to "the missions system", so the files can eventually read like this:

that sounds all very good - however 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.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

The tutorials are registered in fg-root/tutorials/list.xml

not important at the moment, but: we should have all the stuff in Nasal available to do this kind of thing procedurally, i.e. using the directory() function to get a list of files matching a pattern like *.xmlHowever, I'd suggest to use a non-standard file extension, like for example *.tutorial, *.mission - while keeping the format itself PropertyList-encoded XMLThat way, things will be straightforward to process, and we could then also easily support reloading stuff from disk, i.e. for more rapid prototyping, without having to exit/restart FG.New *.mission files would then be added to the directory, and the Nasal script would pick them up automatically, without anybody having to edit XML files.

Hooray wrote in Wed Apr 16, 2014 4:24 pm:The tutorial system itself already has support for placing 3D models in arbitrary locations, no matter if it's a vessel, climber or a vehicle: http://wiki.flightgear.org/Tutorials#ModelsBut those are all static currently, so we would need to use this in combination with an AI scenario, which is not overly flexible, and also not that easy to deploy.

I'm currently researching this and it should be possible to move them. You can add Models and specify a property for locations like this:

With this the model can be re-located by modifying the Properties. I'm about to modify my self steering AI Vehicles to be used with the Tutorial/Mission System. With the tuorial systems ability to load nasal code per step it should be possible to alter directives for every step. Very promising!

Apart from that I have created human Non Player Characters for the Tutorial System:

But I guess I would still extend the whole thing to directly support Nasal for adding stuff procedurally, so that we are not limited by the number of tags having to equal the number of actors/agents. That is something that would be particularly important for things like scripted AI traffic or even AI missiles. And the Nasal code for tankers/Bombable/fox2 has all the building blocks required to make this a dedicated feature of the tutorial system.

I don't see anything wrong with the approach outlined above, but the tutorial system is as flexible as it is mostly because of allowing free-form Nasal, rather than requiring tags that have a 1:1 relationship with stuff in the world.

But looking at your code example, we may get along with just supporting a <nasal> block per "model", and maybe making the path dynamic, so that a single nasal block can control multiple instances of an object. For example, think in terms of having multiple NPCs, AI aircraft or tanks - those should ideally just be "instances" of a corresponding "AIEntity" class.

@DFaber: Also, you may want to coordinate your work with Marius_A, especially given that you are a fgdata committer, Stuart already mentioned being fully supportive of these changes in the other thread - so it would be good to have some fgdata committers willing & able (Nasal!) to actually review and commit things in time for the next release preferably.

Technically, most building blocks for simple missions & adventures should be in place now - so I wonder if we should add some wiki howtos on creating such missions - alternatively, we could also explore adding a simple "mission editor", e.g. using the "ufo scenery editor" for placing stuff or getting coordinates ?