Modified Mirage F1 (WIP)

[Johan G]

Celebrating my 3000th* post I want to share my modifications so far of my favorite aircraft, the

Dassault Mirage F1

Screenshots

Forming up on the left flank by Johan G, on Flickr


Trial and error by Johan G, on Flickr

A few things I have done
I have been tinkering with this aircraft from time to time. One of the earliest additions was a working HUD that was loosely based on what I could figure out from a few YouTube videos (see the linked post).

Relatively recently I have with the help of Jan Rippl added aerial refueling capability. I have also added a few instruments starting with a now removed dependency on a magnetic compass from David Culp's Dave Pack and a fuel remaining gauge (crucial I would say ). I have also added a few other instruments of which the only fully working is a configuration indicator (seen above the Mach meter in the screenshot above).

I have been in contact with Alexis, one of the original authors, now and then. I am hoping that some of my additions might end up in the official aircraft at one time or another in the future.

Acknowledgments

• All previous contributors to FlightGear
• The original authors, Charles Ingels (FDM) and Alexis Laille (3D)
• Jan Rippl for helping me out with getting air-to-air refueling (AAR)** to work
• All the contributors creating and modifying aircraft and releasing/posting early and often. They have been my inspiration.

Download link
Link to the Gitorious repository. There is a download link there that may or may not work.

Though all the commits made to the develop branch have so far been tested first, downloading from the master branch might be a good idea.

For users of FlightGear 2.4.0 and older I would recommend using the master-2.4.0 branch as that is the last one I used with that version. A newer branch may or may not work, but have so far only been tested with FlightGear 3.0.0.

This aircraft folder have been renamed so that you should be able to have both this version and the original version installed.

License
This aircraft is released under the GNU General Public License, version 2 (GPLv2) license.

Disclaimer
This aircraft is a work in progress with a lot of things missing and some things only being partially or not at all functioning.

I may or may not act on suggestions for improvements, though they are still welcome.

Footnotes
* Unfortunately this is my 3001st post, my 3000th post was this one.
** French: "Ravitaillement en vol" (RVTV)?

[Johan G]

Finally fixed the HUD so it only shows in the pilot view. I had not figured out that I would need a small Nasal script to view one property and change another.

Note that I have not taken any measures to handle a reinit. I am a bit uncertain on how to do that.

Nasal/HUD.nas:

Code: Select all

# hide hud if view-number != 0

setlistener("/sim/current-view/view-number", func(n) {

    setprop("/sim/hud/visibility[1]", n.getValue() == 0);

}, 1);

This also required the nasal script to be added to the -set.xml file similar to below:

Code: Select all

<?xml version="1.0"?>
<PropertyList>
 ...
 <nasal>
  ...
  <hud>
   <file>Aircraft/Mirage_F1_Johan_G/Nasal/HUD.nas</file>
  </hud>
  ...
 </nasal>
 ...
</PropertyList>

This is my first Nasal script (except for those embedded in my joystick configuration files).

[AlexisFR]

Hi,
As you probably know, a new Dassault Mirage F1 is currently in development.
It need much work and I don't have a lot of time, so it is slowly in progression ...
Thanks to Johan G for his help !
PAF team subject
http://equipe-flightgear.forumactif.com/t1243-le-mirage-f1

[Thorsten]

I had not figured out that I would need a small Nasal script to view one property and change another.

You don't, actually - such things are better handled by property rules (similar to the AP specs, though they work at framerate rather than FDM rate).

[Johan G]

...such things are better handled by property rules (similar to the AP specs...).

Very good point. Totally slipped my mind. Thanks.

I guess that way they will also automagically work with reset/reinit, as well as probably give an (ever so slight) performance increase.

Edit: Probably a good way to do conversions from US gallons to liters as well. The F1 displays fuel quantities in liters (though I guess a custom fuel and payload dialog would benefit from showing both).

Edit2: Done!

[Flying toaster]

Sorry to be a nuisance, but I have a Blender 3D model standing idle on my hard drive ...
If it can be of any help ...



Needs animations and textures but ...

[Johan G]

As AlexisFR, one of the original authors, are working on a 3D model I think I will leave it to him if we are going to use his model or yours.

Your model looks good though.

[Flying toaster]

Drop me a PM if you want the model

[Johan G]

Latest addition: Dodane Type 11 cockpit clock!

Features:

• Rotating bezel (using the knob animation, and kept in place between sessions)
• Start / stop / reset button
• Chronograph minute hand moving every 1/2 minute

No sweeping chronograph second hand though (should be five steps per second instead of one).


Latest addition, Dodane Type 11 cockpit clock by Johan G, on Flickr

Worked on this one now and then the last couple of months.


I have been longing for this one for years. I expect dead reckoning navigation will be "a bit" more fun now.

[Johan G]

I just moved out the control logic from the animation xml file for the chronograph and created what I think is my first Nasal module. In addition the chronograph now have a keyboard binding: [q]

Here it is in its full "glory" (I need to start using the GPLv2 preamble in my files though). The reason I have split off a few functions is that some other cockpit clocks I might do have separate start/stop and reset buttons:

Code: Select all

# Nasal module that handles some common tasks related to
# the cronograph of the cockpit clock.
#
# When /instrumentation/clock/chronograph-state == "started"
# the property rule defined in Chronograph.xml
# will continuously update /instrumentation/clock/elapsed-time-sec.


# Cycles trough the clock states started/stopped/reset
var cycle = func() {

  # The property to cycle and its valid states
  var states = props.Node.new ({
    "property": "/instrumentation/clock/chronograph-state",
    "value": ["started", "stopped", "reset"]
  });

  fgcommand("property-cycle", states);

  # Whate state is the chronograph in after cycling the state?
  var state = getprop("/instrumentation/clock/chronograph-state");

  # Reset the elapsed time if the chronograph was reset
  if (state == "reset") {
    resetElapsedTime();
  };

  # Instantaneously reset the offset before the chronograph is started
  if (state == "started") {
    resetChronographOffset();
  };

};

# Slowly resets "/instrumentation/clock/elapsed-time-sec"
# This property is used for the animation of the chronograph hands.
var resetElapsedTime = func() {

  interpolate (
    "/instrumentation/clock/elapsed-time-sec", 0, 0.2
  );

}

# Resets "/instrumentation/clock/chronograph-offset-sec"
# This property is used by the property rule that updates the elapsed time.
var resetChronographOffset = func() {

  var t = getprop("/instrumentation/clock/indicated-sec");

  setprop("/instrumentation/clock/chronograph-offset-sec", t);

}

The animation xml file now has this binding (instead of something much longer):

Code: Select all

      <binding>
        <command>nasal</command>
        <script>chronograph.cycle();</script>
      </binding>


And the <aircraft>-set.xml file this one:

Code: Select all

   <key n="113">
    <name>q</name>
    <desc>Chronograph start/stop/reset</desc>
    <binding>
     <command>nasal</command>
    <script>chronograph.cycle();</script>
    </binding>
   </key>
  </keyboard>


For the curious, this is what Chronograph.xml with the property rule looks like. (At some point I might add a smoothed elapsed-time-sec that I can use for a sweeping second hand):

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>
 <filter>
  <name type="string">Chronograph elapsed time</name>
  <debug type="bool">false</debug>
  <enable>
    <condition>
      <equals>
        <property>/instrumentation/clock/chronograph-state</property>
        <value type="string">started</value>
      </equals>
    </condition>
  </enable>
  <type>gain</type>
  <gain>1</gain>
  <input>
    <expression>
      <sum>
        <property>/instrumentation/clock/indicated-sec</property>
        <product>
          <property>/instrumentation/clock/chronograph-offset-sec</property>
          <value>-1</value>
        </product>
      </sum>
    </expression>
  </input>
  <output>/instrumentation/clock/elapsed-time-sec</output>
 </filter>
</PropertyList>

A rant
Getting the fgcommand to work in Nasal was no pleasant effort. I had a hard time figuring out what fgcommand() wanted, in particular what the props.Node hash should contain. In the end I brute-forced it using trial and error with the Nasal console... trying to figure out what to feed the beast so it would not spew flames all over me, or even worse, totally ignoring me and not do anything.*

* I am of course speaking of trying one set if inputs, and seeing if it did anything and/or if there was any errors reported in the console window.

[Johan G]

The cockpit clock chronograph now has a sweeping second hand like like the real deal.*

Some limitations overcome
The problem getting there is that the only non-integer time related property is /sim/time/elapsed-sec, which tells how long FlightGear have been running. Unfortunately it does not take time warping into account. In addition /sim/time/warp-delta is not a factor (which one quickly can figure out as it normally is zero).

Ideas
As a first idea, before I had figured out that warp-delta was not a factor, I tested driving the second hand animation with (/sim/time/warp-delta * (/sim/time/elapsed-sec - /instrumentation/clock/chronograph-offset-sec)). This obviously made the hand rotate in a reasonable tempo only when warp-delta=1.

After looking through the source code (which I am nearly hopeless at) I stumbled upon these helpful comments "warp += warp_delta" in sg_time.cxx[1] and "@param warp Optional time offset in seconds. This allows to advance or rewind "time"".[2] In essence /sim/time/warp-delta is the number of seconds to be added to /sim/time/warp each second, and /sim/time/warp is an offset!

Solution
The way I solved this was to ignore warp-delta, and instead use (elapsed-sec + warp) - chronograph-offset-sec, and of course have chronograph-offset-sec calculated against those two. This added changes to the Nasal function that calculated the offset and the property rule that updates the property driving the hands, /instrumentation/clock/chronograph-elapsed-sec.

Finally I noted that I had to change the property type as declared in the <Aircraft>-set.xml file, to actually get the sweeping hand. Doubles will be converted to integers when stored into an integer (and integers by definition are in steps).

Edit: A very shaky video depicting a cockpit clock with practically the same movement: Breguet type 11 Mirage 3 (YouTube, 5 min)

* Though I have not bothered to have it sweep with five steps/second. Adding that would be both relatively cheap and easy though. I just do not think it is worth it at this time.

[Johan G]

Added a wiki page, Dassault Mirage F1 development, to help any collaboration.

[Hooray]

A rant
Getting the fgcommand to work in Nasal was no pleasant effort. I had a hard time figuring out what fgcommand() wanted, in particular what the props.Node hash should contain. In the end I brute-forced it using trial and error with the Nasal console... trying to figure out what to feed the beast so it would not spew flames all over me, or even worse, totally ignoring me and not do anything.*

* I am of course speaking of trying one set if inputs, and seeing if it did anything and/or if there was any errors reported in the console window.

In general, fgcommands should be documented in $FG_ROOT/READE.commands
If they are not, your best bet is looking at $FG_SRC/Main/fg_commands.cxx
The props.Node.new() stuff will merely create a temporary property tree, which is equivalent to using an XML file on your disk - i.e. via io.read_properties()
So once you know what properties are needed, you can provide data to the fgcommand using basically 2-3 ways: a temporary property tree node, or a file on disk.
The 3rd possibility is to use a branch in the public property tree.

The basic structure of a fgcommand is relatively simple, especially once you have taken a look at: http://wiki.flightgear.org/Howto:Add_ne ... FlightGear
For starters, it would also be a good idea to implement your own fgcommands in Nasal space using the addcommand() API.

So, basically whenever there is an undocumented fgcommand, I would first of all check fgdata for existing uses of it, then refer to the source code to see what it expects, and then play with it using the Nasal console (like you did).

Obviously, you could have also just asked around here
Which will give you a pretty good understanding of all the concepts involved.

(I agree that it would make sense to update the corresponding wiki articles accordingly)