Board index FlightGear Development Aircraft

Jabiru J-170 (DEVELOPMENT)

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Fri Mar 16, 2012 7:42 pm

Image

Working on the Garmin aera 500 GPS. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Sun Mar 18, 2012 9:15 am

Did a bit of work on the Garmin Aera500 GPS unit. It's a very nice little instrument with fortunately, a LOT of documentation available. In the default (without XM subscription), you have 10 pages/features - Terrain/VFR Map Display, Terrain Proximity Map, Horizontal Situation Indicator Panel, Nearest airport information, Numbers (this is not exactly a flight feature, but is used to change what different corners of the screen shows - like GS / BRG / NEXT WPT / WPT DIST), Active Flightplan Editor, Waypoint Information (you can search for a waypoint here), Direct to (a simple feature that works like the alternate airport diversion on the 787 but applies to any kind of waypoint, not just airports), Position Information and Tools.

I started working on the Terrain Map Display and Terrain Proximity Map and have some things ready and working. As for the VFR Map, I don't really know what to do about it directly from FlightGear, so I got an area (LAX Area) VFR map from vfrmap.com (the total are image size is about 4096 x 2048 only and includes the Los Angeles area. I played around a bit and created a method of using these images as VFR charts. Basically, you take any 2 points on the image (I took the foot of a runway at KLAX and the foot of another at Ventura airport), specify their co-ordinates and their norms (x,y) on the image. A nasal script will find the scale of the image and do all the calculations required to place you exactly where you are in the VFR map. The map ofcourse moves with you at the center (just like the Terrain/Terrain Proximity maps. I still haven't completed the VFR display, but I'll get back to you on that really soon.

As for the rest of the GPS, I'll still work on it. Atm, it has functional menu and quick access buttons, displays GMT time on top, shows aircraft's battery charge etc. Now, back to the Terrain and Dedicated Terrain Maps.

In the Map menu from the Home page, you go to a terrain map with a resolution of about 1.5 Megapixels (that's even more than the 787-8's terrain map and using interpolation+a line at a time, I've got some great update speed (less than a second to update the full screen) with almost no frame-rate loss. So, the terrain map just shows the terrain with color codes representing the elevation at the point. Here's a screenshot of me navigating over a river in Singapore.. (Sorry about the blank SV-D1000, I haven't modeled it yet)

Image

And a closer look at the GPS...

Image

You see only green and blue here as the region around Singapore is more or less flat...

Now, taking the J-170 to a bit more exciting area, Innsbruck Valley...

Image

Here, you can see the multiple colors on the terrain map representing their elevations. Looking from the general pilot view, the pixelation doesn't really seem to matter much here...

And a closer look,

Image

Now the dedicated terrain map. This is a separate page as the function is kind of different. This page includes a 1 Mega Pixel Area Navigation Map and the bottom's being used by a vertical profile (aka. Vertical Situation Display). Atm, I haven't completed the VSD (this isn't like the 787s, it's a bit more complicated) so just look at the RNAV map. The reason this is a separate page is cuz it's not simply a terrain map with brighter colors, it's used to show the proximity of the aircraft to the terrain. If the terrain is less than 100 ft below the aircraft (or even if the terrain is ABOVE the aircraft's altitude), it shows bright red meaning that the area is very dangerous. And then the other codes include orange, yellow, light green and green for altitude differences (that's altitude - elevation) 500, 1000, 2000 and 3000 and blue for 0 elevation (water basically)...

Here's a screenshot of the j170 flying through Innsbruck valley with mountains higher than my altitude (that explains the hell lotta red) around me. :)

Image

And then ofcourse, as these are altitude differences and NOT elevations, this'd be quite handy even when flying around regions with rather short hills too, like San Fransisco Bay.

Image

I'll get to work on the VFR map and VSD soon and the rest of the GPS as soon as I can... And then I have the biggest challenge in the aircraft, the Dynon Skyview SV-D1000 display, which has a PFD, a Terrain Map (not that hard as we already have code from the GPS), Engine Controls and the control center for the aircraft's TruTrak Autopilot System. The challenge here is synthetic vision. Which means I need to either be able to render 3D terrain view to texture, OR be able to create my own 3D terrain view with projection calculations.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Sun Mar 18, 2012 10:50 am

Synthetic Terrain Display Development

So, I was thinking a bit about this synthetic terrain WITHOUT rendering terrain view to texture and here's a very simple solution.

Image

Image

Image

In the above diagrams, I show how we can get and create a virtual plane with elevations from geodinfo(lat, lon) and project it to a 2D screen. I've showed just 1 strip/column of the screen as the rest would be done the same way as this one.

So, we using the elevations, we take the top point of that terrain region and get (x,y) where x corresponds to distance from the aircraft (lateral) and y is altitude - elevation. Then, we create a virtual plane... (When I say create, I mean line a vector with the values of all the points, not really draw anything yet) which faces the way the aircraft does, based on pitch. Then we use a simple incrementing-value-for-loop to check if there is an elevation top point along the line. (for the center, it'd be the normal, for the rest, see the first image) If there is, we take that distance and use it for reference as textranslate. Then we'd have to textranslate along a gradient, like in the third image to show the respective distance (3D, not lateral or vertical) of the top elevation from the aircraft. In the third image, I show a very low resolution projection and how it's done. We could increase the resoultion to upto maybe 50x50 or 50x60. But then again, we'll only be taking the altitude of 1 line (max) every frame to prevent any major impact on frame-rate, so this could be kind of slow. Therefore a terrain camera view rendered to texture would be faster (Well, Zan said that would reduce the frame-rate to half! but we can simply reduce it's resolution) and MUCH less pixelated than this method. But then people in the IRC said that it may take a VERY long time b4 we can do that, so do you think I should continue with this or just work on the GPS?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby redneck » Sun Mar 18, 2012 7:32 pm

So, we've decided to include some tutorials with this plane. I decided the first one I'd make would be for power-on stall recovery training. Furthermore, I thought I'd make the whole thing an entire flight that includes takeoff and landing, since, in RL, it'd be kinda hard to practice stall recovery without first taking off, and b/c landings are mandatory. However, I thought I could add some nasal to simulate a CFI operating the aircraft, forcing it into the stall and then leaving the student recover from it. I have no idea if I've even done that right. I used elevator, instead of trim in an attempt to prevent pilots from being able to override it. If it fails, I can still set the tutorial up to instruct the pilot to pull the yoke into his lap while applying full throttle.

Then, I realized that I would also need to create some properties to find the highest altitude the plane reaches when it stalls - another need for Nasal. I need to do this b/c I want to make the tutorial impossible to complete without safely recovering from the stall, which means losing no more than 100 ft during recovery.

The problem: The tutorial causes FG to crash on startup, UNLESS I comment out all the Nasal stuff. I've followed the wiki and referred to a c172P tutorial as a guide. Perhaps the wiki missed something. The c172P tutorials don't have any Nasal that I can find (I haven't checked them all yet). Based on what I've read in the wiki, I haven't made any mistakes. I'm totally clueless as to why this is happening. I'll post the bits and pieces of code below that may be causing the problem.

This one simulates a CFI forcing the plane into a power-on stall.
Code: Select all
<nasal>
            <script>
               setprop("/controls/flight/elevator", -1);
               setprop("/controls/engines/engine/throttle", 1);
            </script>
         </nasal>


This one finds the highest altitude the plane reached as it goes into the stall, and uses that value to set a minimum altitude, which you may NOT descend through until after you have successfully recovered from the stall.
Code: Select all
<nasal>
            <script>
               if (getprop("/tutorial-props/max-altitude") == "")
                  setprop("/tutorial-props/max-altitude", 0);
               if (getprop("/tutorial-props/max-altitude") < getprop("/instrumentation/altimeter/indicated-altitude-ft")){
                  setprop("/tutorial-props/max-altitude", getprop("/instrumentation/altimeter/indicated-altitude-ft"));
                  setprop("/tutorial-props/min-altitude", (getprop("/tutorial-props/max-altitude") - 100));
               }
            </script>
         </nasal>


This one is used to step back two steps in the tutorial if you fail to recover in less than 100 ft.
Code: Select all
<nasal>
               <script>
                  if (getprop("/instrumentation/altimeter/indicated-altitude-ft") < getprop("/tutorial-props/min-altitude")){
                     screen.log.write("You lost too much altitude.  Climb back up to 3000 and try again.", 1, 1, 1);
                     previous([n=2])
                  }
               </script>
            </nasal>


This one is used to find the landing rate by grabbing the vertical speed and putting it in another property only while the plane is airborne.
Code: Select all
<nasal>
            <script>
               if ((getprop("/gear/gear[1]/rollspeed-ms") == 0) and (getprop("/gear/gear[2]/rollspeed-ms") == 0))
                  setprop("/tutorial-props/landing-rate", getprop("/velocities/vertical-speed-fps"));
            </script>
         </nasal>


And finally, this one gives feedback to the pilot on his landing.
Code: Select all
<nasal>
               <script>
                  if (getprop("/tutorial-props/landing-rate") > -5)
                     screen.log.write("Great landing!", 1, 1, 1);
                  else
                     screen.log.write("Ouch!  Terrible landing!", 1, 1, 1);
               </script>
            </nasal>


If anyone is able to provide any help, it will be greatly appreciated. Thanks.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Sun Mar 18, 2012 8:05 pm

redneck wrote in Sun Mar 18, 2012 7:32 pm:The problem: The tutorial causes FG to crash on startup, UNLESS I comment out all the Nasal stuff.


Console output please? (Btw, I can't get on skype as it ain't working. :evil:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby redneck » Sun Mar 18, 2012 9:17 pm

Right. It's not very informative.

Code: Select all
Error reading aircraft: not well-formed
 at C:/Program Files (x86)/FlightGear 2.4.0/data/Aircraft/Jabiru-j170/Tutorials/
power_on_stall.xml,
line 403, column 50
Config option parsing failed ...


And the line in question:
Code: Select all
if (getprop("/tutorial-props/max-altitude") < getprop("/instrumentation/altimeter/indicated-altitude-ft")){


Would be nice if it said HOW it's not well-formed. Sounds more like it's just being a conventions-nazi, instead of there actually being some syntax error.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Jabiru J-170 (DEVELOPMENT)

Postby Hooray » Sun Mar 18, 2012 9:33 pm

You can always use a conventional XML validator to validate FG XML files.
And keep in mind that Nasal code embedded in XML files should ALWAYS be added in between a CDATA section so that XML characters (>< LTE/GTE) don't mess up the parser. See the Docs in $FG_ROOT, the W3C tutorial or any other XML tutorial: >< are XML characters which need escaping (or a well-formed CDATA section).
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: Jabiru J-170 (DEVELOPMENT)

Postby redneck » Mon Mar 19, 2012 2:38 am

Ah crap! I even read about that CDATA thing, and was planning to use it. I can't believe I forgot. Hopefully, that fixes the problem. The XML alone is fine. It's the Nasal that's been screwing things up.

EDIT: Problem solved. Thanks. Now, I just gotta see if the tutorial works the way I want it to work.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Jabiru J-170 (DEVELOPMENT)

Postby Figaro » Mon Mar 19, 2012 3:13 am

I've tested the FDM, its rather average at the current time. I'm in the process of getting git to work, and understanding how to use it in order to commit my updates.

Cheers,
Sam.
User avatar
Figaro
 
Posts: 1312
Joined: Fri Feb 25, 2011 10:23 pm
Callsign: 4L-FIG
OS: Ubuntu/Win10

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Mon Mar 19, 2012 4:06 am

connect wrote in Mon Mar 19, 2012 3:13 am:I've tested the FDM, its rather average at the current time. I'm in the process of getting git to work, and understanding how to use it in order to commit my updates.


Alright, that's cool. Take a look at these so you find out what to change to get what.. If you need any help, feel free to ask, but I'd rather say you ask jentron.. He's simply awesome at this. :)

http://www.jsbsim.org/
http://www.jsbsim.org/JSBSimReferenceManual.pdf
http://www.holycows.net/datcom/ < I have started on an EXTREMELY basic datcom model but it hasn't gone anywhere yet...

FlightGear Wiki Pages
http://wiki.flightgear.org/JSBSim_Aerodynamics
http://wiki.flightgear.org/JSBSim_Engines
http://wiki.flightgear.org/JSBSim_GroundReactions

Cheers. :twisted:

------------------------------------------------

Alright, so back to synthetic terrain. He's the procedure for it working, and each loop body would have this in this order if we're still sticking to the Nasal+XML version.

Assuming, we're making a 3 MegaPixel Screen (51x61, we'll use some interpolations too to increase the surface "smoothness" and increase update speed.

  • Incrementing-Index-For-Loop for every column/strip on the screen (index from 1 to 61)
  • Use geodinfo(y,x) to plot a virtual (basically, a vector) elevation graph for 51 points in each strip. (This is inside the above for-loop)
  • Get Aircraft's Altitude and Pitch to create a virtual POS at the correct position.
  • Use another incrementing-index-for-loop to "scan" (check) it's FOV for any interactions with the elevation graph.
  • If there are interactions, get the points where the Line of Sight meets Elevation and use basic trig to get the distance to that point.
  • Place the distances throughout the screen into the property tree (for XML reference)
  • Use textranslate animation to textranslate the points based on it's distance using a colored scale.

I'm gunna get started on this soon... Need to finish my inverse trig problems. :P
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Mon Mar 19, 2012 7:50 am

Alright, I made the "screen" model after finishing all the Inverse Trig. and Matrix problems on my textbook... But then, now I'm afraid of frame-rate loss due to model complexity. Alright, the model isn't too complex, but then due to the huge number of pixels... 50x61 = slightly over 3 MegaPixels with a skydome gradient behind it makes 12,204 surfaces/polygons! That's almost more than what the aircraft's exterior model has!!! :shock:

Can anyone tell me the potential impact of this on the frame-rate? I DO NOT want too do anything that kills frame-rate too bad. :(

EDIT: I was thinking if we should use elevations from the GPS instead of wasting FPS on getting the elevations again. But the problem is that we don't have the right amount...
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby redneck » Mon Mar 19, 2012 3:03 pm

As I said on Skype, which you guys seem to have neglected checking, I have followed your advice, and managed to actually improve the FDM. It works probably almost like the real thing at low speeds. It doesn't work very well at high speeds (nose-down cruise). The FDM you have now, Sam, if you have not increased the drag due to elevator deflection, will NOT stall with full power. To fix this, I've changed the multiplier from 0.0001 to 0.1. This way, pulling the yoke all the way into your lap will actually reduce speed, instead of simply pitching the plane up. That's good enough for me for now, as I need low speed to work to test my tutorial. And about that, apparently I am unable to use Nasal to override the joystick. So, I'll have to make it so it instructs the student on how to enter a power-on stall.

Btw, Omega, you missed a link. You don't think he knows EVERYTHING about the plane from just one flight that was done comfortably within the bounds of the flight envelope, do you?

Be sure to see the POH.

Some important speeds to keep in mind (KIAS):
Stall clean: 47
Stall landing: 42
Vref: 65
Vy: 68

I got the tutorial to work. I had to take out some of the Nasal that was in the tutorial, and make a Nasal file to create the properties I need to check in the tutorial. Had a few kinks in it. Fixed them. Now, I just gotta check and see that it can detect poor recoveries (one in which more than 100 ft is lost). Then, I'll also throw in the power-off recovery, which shouldn't be too hard - I only really have to copy and paste the contents of the power-on recovery tutorial and make a few changes.

Well, it seems that it's impossible to screw up the stall recovery as far as the tutorial is concerned, and Idk why. Below is the step that's having problems. For some reason, the last error never executes. I made sure to satisfy the condition, and even wait a minute or two below the minimum altitude, which means, if it was working as I had expected, there's no doubt it would have been triggered.

Code: Select all
<step>
         <message>You are about to stall!  Get ready!</message>
         <error>
            <message>You are now stalling.  Lower the nose gently to increase speed.</message>
            <condition>
               <and>
                  <less-than>
                     <property>/instrumentation/altimeter/indicated-altitude-ft</property>
                     <property>/tutorial-props/max-altitude</property>
                  </less-than>
                  <less-than>
                     <property>/controls/flight/elevator</property>
                     <value>-0.75</value>
                  </less-than>
               </and>
            </condition>
         </error>
         <error>
        <message>You are heading too far left, Turn right slightly to heading 090.</message>
        <condition>
         <less-than>
           <property>/orientation/heading-magnetic-deg</property>
           <value>80</value>
         </less-than>
        </condition>
      </error>
      <error>
        <message>You are heading too far right, Turn left slightly to heading 090.</message>
        <condition>
         <greater-than>
           <property>/orientation/heading-magnetic-deg</property>
           <value>100</value>
         </greater-than>
        </condition>
        <error>
         <message>You lost too much altitude.  Climb back up to 3000 and try again.</message>
         <condition>
            <less-than>
               <property>/instrumentation/altimeter/indicated-altitude-ft</property>
               <property>/tutorial-props/min-altitude</property>
            </less-than>
            <nasal>
               <script>
                  <![CDATA[
                     previous([n=2]);
                  ]]>
               </script>
            </nasal>
         </condition>
        </error>
      </error>
         <exit>
            <condition>
               <and>
                  <less-than>
                     <property>/fdm/jsbsim/aero/alpha-rad</property>
                     <value>0.0395415</value>
                  </less-than>
                  <greater-than>
                     <property>/velocities/vertical-speed-fps</property>
                     <value>-100</value>
                  </greater-than>
                  <greater-than>
                     <property>/instrumentation/altimeter/indicated-altitude-ft</property>
                     <property>/tutorial-props/min-altitude</property>
                  </greater-than>
               </and>
            </condition>
         </exit>
      </step>
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Jabiru J-170 (DEVELOPMENT)

Postby icecode » Mon Mar 19, 2012 10:11 pm

Accurate and realistic cockpit with ambient occlusion and some photo textures used


Why to use ambient occlusion? Rembrandt is coming with AO and many other features. :wink:

Good work at it, another great aircraft coming from TheOmegaHangar! :)
icecode
 
Posts: 709
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Jabiru J-170 (DEVELOPMENT)

Postby Figaro » Mon Mar 19, 2012 11:51 pm

Because we know that Rembrandt is going to be pretty buggy, laggy etc. until its finetuned much better. If Rembrandt is released before or with FlightGear v2.8.0 (or whatever they decide to call it :lol:) then we will most definitely alter the code in the aircraft's files to allow the aircraft to be compatible with Project Rembrandt.

But not just TheOmegaHangar ;) it is, indeed, another collaboration between TheOmegaHangar and FlightGear Australia :D


Cheers,
Sam.
User avatar
Figaro
 
Posts: 1312
Joined: Fri Feb 25, 2011 10:23 pm
Callsign: 4L-FIG
OS: Ubuntu/Win10

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Tue Mar 20, 2012 3:54 am

Icecode GL wrote in Mon Mar 19, 2012 10:11 pm:Why to use ambient occlusion? Rembrandt is coming with AO and many other features. :wink:


Btw, if Rembrandt is coming out pretty soon, we should just stop work on the synthetic vision... I'm making a Nasal+XML version cuz I know it's gunna take a while for anything from C++ to be ready and fully distributed.

connect wrote in Mon Mar 19, 2012 11:51 pm:But not just TheOmegaHangar ;) it is, indeed, another collaboration between TheOmegaHangar and FlightGear Australia :D


So Sam, have you started work on the FDM? :lol:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 16 guests