Board index FlightGear Development Tutorials and missions

Tutorials/Missions/Adventures: requests for features

Interactive in-sim tutorials and missions

Tutorials/Missions/Adventures: requests for features

Postby Marius_A » Mon Apr 14, 2014 7:47 pm

Here is the place to share ideas and feature requests related to tutorial/mission system.

Current wish/to do list (will be periodically updated according to your feedback):
  1. Navaids support,
  2. Power line maintenance missions (helicopters),
  3. Equipment transportation missions (helicopters),
  4. Banner pickup and towing missions,
  5. Precision landing challenges,
  6. ...
Marius_A
 
Posts: 92
Joined: Wed Dec 04, 2013 3:20 pm

Re: Tutorials/Missions/Adventures: requests for features

Postby ludomotico » Mon Apr 14, 2014 8:10 pm

My two cents:

- 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
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Mon Apr 14, 2014 8:26 pm

Regarding instrument failures: This is something that galvedro is working on: http://wiki.flightgear.org/A_Failure_Ma ... FlightGear
And 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):

Subject: Seriously skilled heli pilot

Johan G wrote:You beat me to it. I had the intention to post it here, so I settle for the YouTube version.


And just to clarify regarding the first item on that list:

Hooray wrote:we may need to add some features, especially for piloting/flying, i.e. route manager/waypoint awareness, and ability to track course/bearing to certain positions (via geo.nas) - e.g. for navigating via VORs, NDBs or DMEs

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Tutorials/Missions/Adventures: requests for features

Postby galvedro » Wed Apr 16, 2014 9:59 am

A few ideas for missions:

- 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.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Wed Apr 16, 2014 5:24 pm

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#Models
But 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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Tutorials/Missions/Adventures: requests for features

Postby ludomotico » Wed Apr 16, 2014 5: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?
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Wed Apr 16, 2014 5:52 pm

ludomotico wrote in Wed Apr 16, 2014 5: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?


This is true, there's a built-in limitation in that "tutorials" need to be loaded via the aircraft-set.xml files currently: http://wiki.flightgear.org/Tutorials#Using_tutorials

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:

https://code.google.com/p/flightgear-bu ... il?id=1295
http://wiki.flightgear.org/Plan-zakalawe
http://wiki.flightgear.org/Reset_%26_re-init

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Tutorials/Missions/Adventures: requests for features

Postby galvedro » Wed Apr 16, 2014 8:04 pm

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.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Wed Apr 16, 2014 8:23 pm

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Tutorials/Missions/Adventures: requests for features

Postby Marius_A » Thu Apr 17, 2014 8:04 am

My current approach:

  • All the tutorials/misions files are stored in "fg-root/Tutorials";
  • The common mission files are stored in "fg-root/Tutorials/Generic/Models" and "fg-root/Tutorials/Generic/Sounds";
  • The tutorial/mission itself is a single *.xml file (or a folder, if mission needs additional mission-specific models/sounds);
  • The tutorials are registered in fg-root/tutorials/list.xml:
    Code: Select all
    <?xml version="1.0" encoding="UTF-8"?>
    <!-- list.xml -->

    <PropertyList>
       <tutorial include="Helicopter_missions/Oil-Rig-Landing/Oil-Rig-Landing.xml"/>
       <tutorial include="Helicopter_missions/helicopter1.xml"/>
       <tutorial include="helicopter2.xml"/>
       <!-- ... -->
    </PropertyList>

    Therefore, I can fly the missions with any aircraft without modifying aircraft's -set.xml.

However, I like the mission files browser idea. I'll try to modify current tutorials dialog.
Marius_A
 
Posts: 92
Joined: Wed Dec 04, 2013 3:20 pm

Re: Tutorials/Missions/Adventures: requests for features

Postby galvedro » Thu Apr 17, 2014 8:41 am

That sounds like pretty well organized to me! Good job!

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:

Code: Select all
<PropertyList>
   <mission include="Helicopter_tutorials/hovering_tutorial.xml"/>
   <mission include="Helicopter_missions/Oil-Rig-Landing/Oil-Rig-Landing.xml"/>
</PropertyList>


(I don't know if this is even a good idea, use your common sense and double check with more seasoned FG contributors first :D)
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Thu Apr 17, 2014 9:51 am

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 *.xml
However, I'd suggest to use a non-standard file extension, like for example *.tutorial, *.mission - while keeping the format itself PropertyList-encoded XML
That 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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Tutorials/Missions/Adventures: requests for features

Postby Michat » Mon Apr 21, 2014 6:23 am

== Missions ==
* power line maintenance
* equipment transportation
* banner pickup/towing
* precision landing





* rescue
* bombable??/firefighters (without using frame killing fire)
* interesting flights/tours
User avatar
Michat
 
Posts: 1226
Joined: Mon Jan 25, 2010 7:24 pm
Location: Spain
Version: 191b
OS: MX 21 Fluxbox oniMac

Re: Tutorials/Missions/Adventures: requests for features

Postby DFaber » Mon Apr 21, 2014 10:35 am

Hooray wrote in Wed Apr 16, 2014 5: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#Models
But 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:
Code: Select all
      <model>
          <path>Aircraft/Generic/Human/Models/npc0.xml</path> 
          <longitude-deg-prop>/sim/model/npc/longitude-deg</longitude-deg-prop> 
          <latitude-deg-prop>/sim/model/npc/latitude-deg</latitude-deg-prop>     
          <elevation-ft-prop>/sim/model/npc/altitude-ft</elevation-ft-prop>   
      </model>


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

The models appearence can be configured individually:
Code: Select all
      <!--NPC0 -->
      <set>
         <property>/sim/model/npc/character</property>
         <value>2</value>
      </set>
      <set>
         <property>/sim/model/npc/gender</property>
         <value>0</value>
      </set>
      <set>
         <property>/sim/model/npc/outfit</property>
         <value>1</value>
      </set>
      <set>
         <property>/sim/model/npc/hair</property>
         <value>1</value>
      </set>
      <set>
         <property>/sim/model/npc/headgear</property>
         <value>3</value>
      </set>
      <set>
         <property>/sim/model/npc/mask</property>
         <value>1</value>
      </set>
      <set>
         <property>/sim/model/npc/toolr</property>
         <value>0</value>
      </set>
      <set>
         <property>/sim/model/npc/longitude-deg</property>
         <value>-0.5419</value>
      </set>
      <set>
         <property>/sim/model/npc/latitude-deg</property>
         <value>38.28027048</value>
      </set>
      <set>
         <property>/sim/model/npc/altitude-ft</property>
         <value>35</value>
      </set>


Poses can be loaded from XML Files via Nasal:
Code: Select all
      <nasal>
            <script>
         io.read_properties("Aircraft/Generic/Human/Models/Poses/help.xml", "sim/model/npc[0]/pose");
            </script>
      </nasal>


Greetings
Detlef Faber
FlightGear Development:
http://flightgear-de.net

my 3D-Art:
https://www.sol2500.net
DFaber
 
Posts: 709
Joined: Fri Dec 01, 2006 8:51 pm
Location: Aachen, Germany
Version: GIT
OS: Linux

Re: Tutorials/Missions/Adventures: requests for features

Postby Hooray » Mon Apr 21, 2014 3:59 pm

that's all looking very good indeed!

thanks for the update - yeah that should work, too.

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 ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Tutorials and missions

Who is online

Users browsing this forum: No registered users and 0 guests