Re: [Flightgear-devel] Replay mode
Am Montag 17 Januar 2005 17:50 schrieb Jim Wilson: Having just hit it unintentionally, I'm wondering if the replay key should be bound to a combo key (a Ctrl+key) or Fxx key? It has pretty dramatic and sudden effect. Making it the r binding not very good UI design (unless one is doing more replays than flying). For some reason I thought r was reverser. It'd be nice to have r and R for thrust reverser on/off, which is a binding that is as fundamental for the jet aircraft as the brake keys or magnetos are for the others. If there is consensus on this one change (not a discussion of the entire layout again please :-)) then I can commit a change or wait for post release. It seems that this as a non-critical UI-bug. IIRC, there is a keyboard.xml in $FG_ROOT where you can define the key bindings of FG. So no code change should be necessary. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Paul Surgeon wrote: How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. I'm not convinced FlightGear cannot handle all this already (or requiring just a couple of small changes). But I agree that this will be a huge task. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On January 18, 2005 02:21 am, Paul Surgeon wrote: Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. Each aircraft systems are tailored to that aircraft. Using C++ here will be too restrictive and is not going to be a good idea. A central processing blackbox that contains all the logic for the aircraft that also get's updated in the rendering loop. The blackbox will simulate/handle the hydraulic and electrical systems, generate and feed the display data to the intruments, handle the logic for failures, receive input from all the simulated aircraft sensors and cockpit switches, etc. Putting everything in one script is not a good way to do it either. If the hydraulic system recieves a runtime error, the electrical system plus everything else are dead. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. May be the bus can be simulated using the property tree, or inside a root-less node. Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. In the mean time, new planes will come out and they will be just as empty. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
Oliver C. wrote: Hello and Merry Christmas! i fixed the inverted view elevation setting for the sidewinder precision pro joystick because the view elevation was inverted under windows. I've committed this file to CVS after changing the NASAL'ified section to be two separate sections, one for UNIX and one for Windows. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
The roll out is on, LIVE! http://www.tv-radio.com/station/public_senat/public_senat-150k.asx For German user, they can tune to N-TV. Right now, it is 6:00 here. I woke up at 4:30 just to watch this! The aircraft has yet been revealed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On January 18, 2005 05:53 am, Ampere K. Hardraade wrote: The roll out is on, LIVE! http://www.tv-radio.com/station/public_senat/public_senat-150k.asx For German user, they can tune to N-TV. Right now, it is 6:00 here. I woke up at 4:30 just to watch this! The aircraft has yet been revealed. Ampere JUST UNVALILED! Awsome! Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. ...[snap]... Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Cheers, Durk [1]. As an example: In the early days, around 1997, Curt asked me if I could write some code that would return the latitude and longitude of the sun's current positin, for daylight computation purposes. Having written it, adding a visual representation of the sun, moon, and the planets at their exact position turned out to be pretty trivial to impliment, and the overhead to run the code neligable, so I went ahead and did it. I remember lots of complaints from people claiming that we were focusing on the wrong things, etc etc. However, there wasn't really an alternative for me to work on at the time, so shifting priorities wasn't really an option either. And see what we have now. I don't think it hurt when we sometimes impliment things in seemingly weird orders. :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 11:53, Ampere K. Hardraade wrote: The roll out is on, LIVE! http://www.tv-radio.com/station/public_senat/public_senat-150k.asx For German user, they can tune to N-TV. Right now, it is 6:00 here. I woke up at 4:30 just to watch this! The aircraft has yet been revealed. Ampere Also BBC-World, and German ZDF (the advantage of living the the Netherlands :-). Good coincedence I was at home today. D. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
JUST UNVALILED! Awsome! Ampere http://i.a.cnn.net/cnn/2005/BUSINESS/01/18/airbus.380/top.unveiled.jpg http://edition.cnn.com/2005/BUSINESS/01/18/airbus.380/index.html After the unveiling, the aircraft still can't be seen clearly because of the blue light. This continued for about another hour of speeches. I must say, the German Chancellor has an excellent posture during his speech. =) I waited patiently during that hour. When the Christening came and the entire hangar is lit, the Aircraft/Airbus has a new livery. Surprise, surprise. ;-) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Missing scenery
I've just noticed something a little odd while testing out my objects export code - I'd accidentally removed a chunk of scenery, and noticed that shared and static objects are not displayed when there is no terrain available in a tile. While this isn't a problem most of the time it means that it's not possible to place oil and gas rigs in the sea unless they're close enough to the coast to be on the same tile as the land. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Missing scenery
On Tuesday 18 Jan 2005 13:11, Jon Stockill wrote: I've just noticed something a little odd while testing out my objects export code - I'd accidentally removed a chunk of scenery, and noticed that shared and static objects are not displayed when there is no terrain available in a tile. While this isn't a problem most of the time it means that it's not possible to place oil and gas rigs in the sea unless they're close enough to the coast to be on the same tile as the land. Aha! I wonder if that is why I couldn't find the Morcambe field? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Removing PLIB SL dependencies
Martin Spott wrote:
I'd love to hear if it still builds working binaries. If this is the
case then I'd post a second patch that removes unused declarations,
O.k., next time I'll add the patch right to the posting :-)
--- configure.ac.original Tue Jan 18 11:56:48 2005
+++ configure.acTue Jan 18 11:58:56 2005
@@ -148,10 +148,7 @@
fi
dnl add correct audio libs and configure for audio support
-LIBS=-lplibsl -lplibsm
-
-dnl search for FreeBSD library
-AC_SEARCH_LIBS(hid_init, usbhid)
+dnl LIBS=-lplibsl -lplibsm
case ${host} in
*-*-cygwin* | *-*-mingw32*)
@@ -213,6 +210,9 @@
AC_SEARCH_LIBS(cos, m)
AC_SEARCH_LIBS(dlclose, dl)
+dnl search for FreeBSD library
+AC_SEARCH_LIBS(hid_init, usbhid)
+
base_LIBS=$LIBS
dnl Check for SDL if enabled.
@@ -299,9 +299,6 @@
opengl_LIBS=$LIBS
LIBS=$base_LIBS
-
-dnl search for FreeBSD library
-AC_SEARCH_LIBS(hid_init, usbhid)
dnl check for OpenAL libraries
case ${host} in
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Missing scenery
Dave Martin wrote: Aha! I wonder if that is why I couldn't find the Morcambe field? Most likely. When you do find it, don't laugh at my model - it was done in about 5 mins as a placeholder, while I was trying to work out why I couldn't find any of them (which is why it's high vis red and yellow :-) I was only reminded of this problem today when I managed to remove w010n50 - starting at EGLC the dome is in front of you, but the terrain stops, and One Canada Square is also missing, because 0 degrees runs right between the two models. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Durk Talsma writes On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. ...[snap]... Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. Nice that you guys have brought this up at this time. Here is what I need right now(only if you are interested of course) a way of swiching the screens on the fly preferably in XML.My idea would to be to have all the ECAM(EICAS), PFD,ND's,I think these days they are collectivly called MFD's,in one folder with the ability to choose which one is displayed on which screen.The idea is to work along the lines of the livery choice for the aircraft.But from what understand the livery choice is made at runtime. This would have to be able to be done on the fly. We probably have about 75% of the properties we need already in FG.One little property I would like is total fuel onboard but as I dont know how to add properties to the property tree I have to leave it to someone else. The other thing that is urgently need is a moving map display on an instrument.So anyone who has an idea to marry the atlas moving map to an instrument step forward. The main thing with a glass cockpit is do you try and display all the screens that the aircraft can produce or do you just do the screens that the pilots would normally fly with?. Paul what do you consider an empty cockpit, do you for instance consider the 747 an empty cockpit and if so what instruments do you think constitutes a populated cockpit. Do you think the 737 2D cockpit has enough instruments. Anyway if you guys can come up with a way to do the switching on the fly I can do the screens. Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Innis Cunningham wrote: Anyway if you guys can come up with a way to do the switching on the fly I can do the screens. If all 3d instruments are contained in one 3d model file and separated with objects names (or object group names) then it could be as easy as using the select animation to turn on the appropriate instrument. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Erik Hofman wrote: Innis Cunningham wrote: Anyway if you guys can come up with a way to do the switching on the fly I can do the screens. If all 3d instruments are contained in one 3d model file and separated with objects names (or object group names) then it could be as easy as using the select animation to turn on the appropriate instrument. I was just thinking, I expect it would be possible to name an included 3d (sub)model like this: model nameRudderAndStickPilot/name pathAircraft/pc7/Models/rudderandstick.xml/path offsets x-m-0.25/x-m y-m0.0/y-m z-m0.15/z-m /offsets /model and use the select animation on the provided name (RudderAndStickPilot in this case). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Erik Hofman Erik Hofman wrote: Innis Cunningham wrote: Anyway if you guys can come up with a way to do the switching on the fly I can do the screens. If all 3d instruments are contained in one 3d model file and separated with objects names (or object group names) then it could be as easy as using the select animation to turn on the appropriate instrument. I was just thinking, I expect it would be possible to name an included 3d (sub)model like this: model nameRudderAndStickPilot/name pathAircraft/pc7/Models/rudderandstick.xml/path offsets x-m-0.25/x-m y-m0.0/y-m z-m0.15/z-m /offsets /model and use the select animation on the provided name (RudderAndStickPilot in this case). The thing is that several screens models would be using the same area of panel. How ,for example. could you turn the fuel system screen model off and the main engine indicating screen model on. Erik Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. 2. A central processing blackbox that contains all the logic for the aircraft that also get's updated in the rendering loop. The blackbox will simulate/handle the hydraulic and electrical systems, generate and feed the display data to the intruments, handle the logic for failures, receive input from all the simulated aircraft sensors and cockpit switches, etc. There are far too many aircraft specific systems than could ever be handled by FG properly. An aircraft like this is a simulation of its own. How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. Paul Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. Take a look at this one: http://svgl.sourceforge.net/ What do you think about such a solution? Is this possible? Best Regards. Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Innis Cunningham wrote: The thing is that several screens models would be using the same area of panel. How ,for example. could you turn the fuel system screen model off and the main engine indicating screen model on. That would be no problem. You can draw them all in the same location (0,0,0) for instance. Selecting which one to turn on (or off) is done with one or more properties, for example like this: !-- turn on moving map if /mdfs/mfd[0]/type=movingmap -- animation typeselect/type object-nameMap/object-name condition equals property/mdfs/mfd[0]/type/property valuemovingmap/value /equals /condition /animation !-- turn on compass if /mdfs/mfd[0]/type=compass -- animation typeselect/type object-nameCompass/object-name condition equals property/mdfs/mfd[0]/type/property valuecompass/value /equals /condition /animation (etcetera) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
On Tuesday 18 January 2005 11:07, Erik Hofman wrote: Oliver C. wrote: Hello and Merry Christmas! i fixed the inverted view elevation setting for the sidewinder precision pro joystick because the view elevation was inverted under windows. I've committed this file to CVS after changing the NASAL'ified section to be two separate sections, one for UNIX and one for Windows. Erik Thank you, it works great now. But there is one problem. I found another bug, when I checked the complete config file today. This is my fault, sorry. I missed to fix a small error in my last patch for the shift button which was from days back, when i played around with the xml settings to test a fix for the invert view elevation bug. Here is the correction. I added a diff file to this email. button descGear Up./desc number unix8/unix windows9/windows /number repeatablefalse/repeatable binding commandproperty-assign/command property/controls/gear/gear-down/property value type=double0.0/value /binding /button Sorry for circumstance this was my fault. Could you apply this patch too? Best Regards, Oliver C. --- sidewinder-precision-pro.xml 2005-01-18 16:12:33.0 +0100 +++ ../sidewinder-precision-pro.xml 2005-01-18 16:15:01.0 +0100 @@ -259,25 +259,11 @@ windows9/windows /number repeatablefalse/repeatable - !-- -binding + binding commandproperty-assign/command property/controls/gear/gear-down/property value type=double0.0/value -/binding - -- - unix -binding - commandproperty-assign/command - property/controls/gear/gear-down/property - value type=double0.0/value -/binding - /unix - windows -binding - commandview-cycle/command -/binding - /windows + /binding /button ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
Oliver C. wrote: I found another bug, when I checked the complete config file today. This is my fault, sorry. I missed to fix a small error in my last patch for the shift button which was from days back, when i played around with the xml settings to test a fix for the invert view elevation bug. This has been committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Erik Hofman writes Innis Cunningham wrote: The thing is that several screens models would be using the same area of panel. How ,for example. could you turn the fuel system screen model off and the main engine indicating screen model on. That would be no problem. You can draw them all in the same location (0,0,0) for instance. Selecting which one to turn on (or off) is done with one or more properties, for example like this: !-- turn on moving map if /mdfs/mfd[0]/type=movingmap -- animation typeselect/type object-nameMap/object-name condition equals property/mdfs/mfd[0]/type/property valuemovingmap/value /equals /condition /animation !-- turn on compass if /mdfs/mfd[0]/type=compass -- animation typeselect/type object-nameCompass/object-name condition equals property/mdfs/mfd[0]/type/property valuecompass/value /equals /condition /animation (etcetera) Ok Erik thanks for this I will give it a try and see what the results are and get back. Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
On Tuesday 18 January 2005 16:29, Erik Hofman wrote: Oliver C. wrote: I found another bug, when I checked the complete config file today. This is my fault, sorry. I missed to fix a small error in my last patch for the shift button which was from days back, when i played around with the xml settings to test a fix for the invert view elevation bug. This has been committed. Erik Thank you. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Removing PLIB SL dependencies
Martin Spott wrote:
I'd love to hear if it still builds working binaries. If this is the
case then I'd post a second patch that removes unused declarations,
I've tested successfully on FreeBSD and IRIX, so here's the second one
on top of the first one:
--- configure.ac.1stTue Jan 18 15:14:46 2005
+++ configure.acTue Jan 18 15:17:50 2005
@@ -147,24 +147,7 @@
AC_DEFINE([HAVE_TIMEZONE], 1, [Define if system has timezone variable])
fi
-dnl add correct audio libs and configure for audio support
-dnl LIBS=-lplibsl -lplibsm
-
-case ${host} in
-*-*-cygwin* | *-*-mingw32*)
-LIBS=$LIBS -lwinmm
-;;
-*-apple-darwin*)
-LIBS=$LIBS -framework IOKit -framework CoreFoundation
-;;
-*-*-irix* )
-LIBS=$LIBS -laudio
-;;
-
-esac
-audio_LIBS=$LIBS
LIBS=
-AC_SUBST(audio_LIBS)
dnl ENABLE_AUDIO_SUPPORT could be depricated at any time in favor of
dnl just assuming we have audio support on all platform. We can
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Removing PLIB SL dependencies
Martin Spott wrote: I've tested successfully on FreeBSD and IRIX, so here's the second one on top of the first one: Here you'll find the summary of both: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/FGconfigure.ac.diff Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] b1900d FDM
Is anyone currently working on the b1900d FDM? The reason I ask is that while the model is gorgeous, the FDM is relatively broken. I've tried fixing the FDM before a couple of months ago but I didn't get anything acceptable. The aircraft accelerates at a hell of a rate on the ground but wont unstick until about 160kts with flap and when it does, the torque effect requires full right aileron to counteract until the airspeed reaches 200kts. (which takes a matter of seconds). Also, if you fight the aircraft level and then apply full-flap, cut the throttles and hold your altitude to the stall, you find that the stall occurs at 120kts and immediately causes a vicious spin. For the Torque, don't the b1900d's have counter-rotating props? As for the FDM's aerodynamics, I've yet to work out exactly what is wrong (the numbers look right but the result is rather like a dragster without wings). Any thoughts? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Terrain photo-real howto
On Mon, 17 Jan 2005 21:02:01 +0100, Robicd wrote in message [EMAIL PROTECTED]: Hi, Sorry, I know it's not a Developer's question but I don't find anything in the docs so I ask here. How do I use photo-real terrains? I have some nice aerial pictures of ..these pix _you_ owns the copyrights to? Next step is GPL them, and paint them onto the scenery tiles. the city I leave in and I would like to use them into FGFS but I really don't know how to include them into a scenary. Any hint? ..search this list and the users list for photo and scenery, AFAIR this was discussed a year or less ago. Also chk Jon Stockill's and Mat Churchill's sites. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d FDM
On Tue, 18 Jan 2005 16:47:04 + Dave Martin [EMAIL PROTECTED] wrote: Is anyone currently working on the b1900d FDM? The reason I ask is that while the model is gorgeous, the FDM is relatively broken. I know there is a YASim model, and I've wanted to work on a JSBSim model for some time, but as the coordinator for JSBSim, editor for the Houston AIAA chapter newsletter, trying to get somewhere on the 1st quarter JSBSim newsletter, being in the middle of a job transition, and being a father of four ... it's a near miracle that I've almost completed the code transition to support JSBSim config file v2.0. :-) If you are interested in doing a JSBSim version of the B1900, I can probably put together a data packet to support that work. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d FDM
Dave Martin wrote: Is anyone currently working on the b1900d FDM? The reason I ask is that while the model is gorgeous, the FDM is relatively broken. I've tried fixing the FDM before a couple of months ago but I didn't get anything acceptable. The aircraft accelerates at a hell of a rate on the ground but wont unstick until about 160kts with flap and when it does, the torque effect requires full right aileron to counteract until the airspeed reaches 200kts. (which takes a matter of seconds). Also, if you fight the aircraft level and then apply full-flap, cut the throttles and hold your altitude to the stall, you find that the stall occurs at 120kts and immediately causes a vicious spin. For the Torque, don't the b1900d's have counter-rotating props? As for the FDM's aerodynamics, I've yet to work out exactly what is wrong (the numbers look right but the result is rather like a dragster without wings). My guess is the approach speed is too high ... you have to be careful because as the file is setup, approach speed is 105 at 13 deg aoa, but full stall is 14 deg aoa. This is saying the aircraft approaches at 105 kts just above the edge of a stall. Add some additional weight (which is often the case) and this could put you right up near 120 for a stall point. I think that either the approach aoa should be dropped significantly, or the speed you can just barely fly without stalling needs to be decreased. Just a guess, but I bet you could fly it down into the range of 80-85 kts full flaps without stalling it (given a moderate load and reasonable temp conditions.) I don't have a b1900 POH, but I wouldn't be surprised if I ended up with one by the end of the year ... I'd agree that the propellors should probably be made counter rotating by negating the moment on one of the sides. The Beech99 is a similar airplane which actually flies pretty close to the POH numbers so you could probably yank data out of there and at least make the 1900 a bit more plausible. Yes, the 3d model and 3d cockpit is gorgeous. :-) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver C. schrieb: Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? In principle it is possible to set up the current OpenGL context to draw to an limited area and allow a plug in to render there. But - probably - the better solution is to have the plugin code to render to an off screen texture and use that dynamic texture as an instrument. I guess that that would be faster (no big changes in viewports, etc) and create higher quality graphics (z buffer fighting, etc.) The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. This is a totally different kind of problem. If the plugin is written in C/C++ it should use OpenGL (OpenGL is fine as a 2D library and there's no need to slow it down by wrapping it). If the plugin is writen in NASAL then NASAL would need an OpenGL like extension. That is - I guess - not hard to do. But - I guess - it'll be too slow when the graphics gets complex. I think the best would be, to add the OpenGL extension to NASAL (for flexibility) *and* write the more complex things in native C/C++ and add those to NASAL as well. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. As long as the interface to FGFS is clear and easy it doesn't matter where the code lives. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. Atlas is basically vector graphics. It tries really hard to generate the bitmaps... As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. Atlas can already create SVG. (Or it could when I added the SVG output a few years ago...) There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. I don't think that that sould be a good solution. It would be *much* better to use the geometry data that FGFS has already loaded to the graphics hardware as it needs it for scenery. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7T/WlhWtxOxWNFcRAiQsAKCJqY6Q7E2gsS2Az03sUc53m1KolwCeN7SO lVMlMQ+XsB8E9b5VaWeOJ0M= =ojF9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. As I wrote in the other mail I think we need to explore how to render to an texture and use that texture in an instrument. Then it's no problem to write C/C++ code that renders (a part of) an instument to that texture. This could then be added to NASAL (plus some basic OpenGL commands) to create a full MFD out of these bulding blocks. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Why not use the property system for that? So far I found the property system very good for unidirectional communications (I'm responsible for system foo and tell everybody that it is in the state bar). But I couldn't solve a bidirectional point-to-point communication with it (I need from system foo the state of bar at position lat/lon somewhere on the world) - but it doesn't sound that you need such a capability. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7UHQlhWtxOxWNFcRAgHDAJ0cazzJtFS+2SS04x2SyEUrpMEuOwCgsWQi AalCWiCgYBHCwUl6t94ZtcU= =7qmi -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] A380
Erik Hofman wrote Paul Surgeon wrote: How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. I'm not convinced FlightGear cannot handle all this already (or requiring just a couple of small changes). But I agree that this will be a huge task. This looks eminently doable in xml or Nasal (it's what Nasal was built for after all). It would be big, but not all that big a task, either. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] QuickSilver MX - anyone making this?
Is anyone in the process of making a QuickSilver MX ultralight for Flight Gear? If not, I would like to combine learning to make 3d models in Turbocad with learning to make an aircraft for Flight Gear. The MX is a very simple aircraft, with no instruments, and only a lever for throttle, and a joystick for rudder/elevator. The ones that I flew in the early 80's didn't even have brakes. Don __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday, 18 January 2005 13:04, Durk Talsma wrote: So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Point taken - model away! :) I just find it frustrating when I start up a nice aircraft to find out that there no way to navigate the thing across open oceans. I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday, 18 January 2005 15:34, Innis Cunningham wrote: Paul what do you consider an empty cockpit, do you for instance consider the 747 an empty cockpit and if so what instruments do you think constitutes a populated cockpit. Primarily a working FMC/FMS and ND so that one can enter waypoints in the FMS and then navigate via the ND using compass, rose or arc modes. I think this is the most important thing to get working first. Overhead, pedestal and main panels with working switches so that from a pilot perspective the aircraft functions in a procedurally correct manner. Once we have about 30% of the above functionality I'll consider a cockpit as being not empty. :) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] QuickSilver MX - anyone making this?
On Tuesday 18 Jan 2005 18:45, Don Oliver wrote: Is anyone in the process of making a QuickSilver MX ultralight for Flight Gear? If not, I would like to combine learning to make 3d models in Turbocad with learning to make an aircraft for Flight Gear. The MX is a very simple aircraft, with no instruments, and only a lever for throttle, and a joystick for rudder/elevator. The ones that I flew in the early 80's didn't even have brakes. Don I was mucking about with a flexwing design for a while. I did think of doing a Quicksilver but I decided against it because I like 'navigable' aircraft ;-) It'd be really good to have a fairly detailed aircraft like the Quicksilver with an 'ultra-open' cockpit to check out the scenery that we are starting to build. I also wondered about trying to simulate a BRS system that you see on many Quicksilvers but I'm not sure if the FDMs would support such a thing. Look forward to seeing it :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Terrain photo-real howto
Hi, How do I use photo-real terrains? I have some nice aerial pictures of ..these pix _you_ owns the copyrights to? Next step is GPL them, and paint them onto the scenery tiles. Sorry no, I can't distribute them because they are copyrighted but I'd like to have them for private use (that's allowed) and that will help me positioning a few 3d objects I'm currently building into the right place in the scenery. Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] QuickSilver MX - anyone making this?
--- Dave Martin [EMAIL PROTECTED] wrote: It'd be really good to have a fairly detailed aircraft like the Quicksilver with an 'ultra-open' cockpit to check out the scenery that we are starting to build. I also wondered about trying to simulate a BRS system that you see on many Quicksilvers but I'm not sure if the FDMs would support such a thing. Look forward to seeing it :-) Dave, Thanks for the encouragement. It will take me some time, as I have a lot of learning to do. I have found information on how to get a model into Flight Gear, once it is made, but not too much success yet in finding info on how to actually make the model. At the moment, I am working on the assumption that I will find a way to convert the Turbocad format to Flight Gear format. Don __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 19:28, Paul Surgeon wrote: On Tuesday, 18 January 2005 13:04, Durk Talsma wrote: So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Point taken - model away! :) :-) I just find it frustrating when I start up a nice aircraft to find out that there no way to navigate the thing across open oceans. I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. I can imagine that. My gut feeling is though that as soon as there is a breakthough in the design of glass cockpits these changes can be traversed back to the existing models relatively quickly. I'm glad to see some discussion in this area. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 19:28, Paul Surgeon wrote: I just find it frustrating when I start up a nice aircraft to find out that there no way to navigate the thing across open oceans. I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. You can use the GPS. You can add a GPS driven HSI to your favorite aircraft 2D panel, like this: instrument include=../../Instruments/hsi-bk-hi.xml nameGPS driven HSI/name params gs-needle/instrumentation/gps/wp/alt-deviation-ft/gs-needle vor-needle/instrumentation/gps/wp/wp[1]/course-error-nm/vor-needle radial-selected-deg/instrumentation/gps/wp/wp[1]/desired-course-deg/radial-selected-deg to-flag/instrumentation/gps/wp/wp[1]/to-flag/to-flag vor-in-range/instrumentation/gps/serviceable/vor-in-range has-gs/instrumentation/gps/serviceable/has-gs heading-deg/instrumentation/gps/indicated-track-true-deg/heading-deg autopilot-heading-deg/instrumentation/gps/tracking-bug/autopilot-heading-deg /params x264/x y-25/y w115/w h115/h /instrument The CDI is bound to to waypoint2 (wp[1]), the to-waypoint. You can set it in the GPS Settings dialog from the Equipment menu. Note that the compass rose shows true tracking. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
Curtis L. Olson said: Jon Berndt wrote: In addition to the status tag, I also support a author and version tags. It would be great if people could go through and fill in these fields as they can. Is that for the FDM? JSBSim v2 config files will feature this header (partially in working with the DAVE-ML spec): fileheader authorTony Peden/author filecreationdate1999/filecreationdate descriptionModels a 1997 Cessna 172R./description version$Id: c172x.xml,v 1.25.2.16 2005/01/13 13:52:39 jberndt$/version reference refID=None author=n/a title=n/a date=n/a / /fileheader Actually, for building the web page, the script is looking in the aircraft-set.xml file(s). I'm done doing thumbs for now. Feel free to replace the ones I've posted with improved versions, especially authors may want to. Related(?) question: Would it be possible to combine all the c172 stuff under one directory (or maybe two, since the c172p model is a complete package)? Otherwise we probably should tell people they've got to download the c172_*.tar.gz file as a pre-requisite in order for the c172le, c172r, c172x, etc. to work. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
Jim Wilson wrote: I'm done doing thumbs for now. Feel free to replace the ones I've posted with improved versions, especially authors may want to. Hi Jim, Thanks for all your efforts (and thanks to everyone else who's generated thumbnail images or filled in missing fields.) Related(?) question: Would it be possible to combine all the c172 stuff under one directory (or maybe two, since the c172p model is a complete package)? Otherwise we probably should tell people they've got to download the c172_*.tar.gz file as a pre-requisite in order for the c172le, c172r, c172x, etc. to work. I understand how we got where we are with the c172 stuff, but I think I can say that it is a big hairy mess. It would be nice to get someone to clean it up and break all those of the bizarre and twisted dependencies. On a similar subject, I vote that for aircraft with only one variant, we get rid of all alias entries. We can add them back later if we need to differentiate between a jsbsim vs. yasim version, but many aircraft have a single alias pointing to a single model and there probably will only ever be that one model. The unneeded alias just clutters things up in my opinion. Any one want to work on cleaning some of those up? Once we are happy with the current state of things, I'd like to propose we add category tags to the aircraft-set.xml files. We can debate the categories and we should allow multiple categories. This will allow us to better organize the aircraft downloads page which will become increasingly important as more aircraft are added. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] *-set.xml files refer to non-existent files (via include=...)
$FG_ROOT/Aircraft/c172/c172-ifr-set.xml refers to $FG_ROOT/Aircraft/c172/c172-set.xml $FG_ROOT/Aircraft/c310u3a/c310-3d-set.xml refers to $FG_ROOT/Aircraft/c310u3a/c310u3a-3d-jsbsim-set.xml $FG_ROOT/Aircraft/c172p/c172-larcsim-set.xml refers to $FG_ROOT/Aircraft/c172p/../c172p/c172p-base.xml none of which exist. (Can't fix it myself. I'm busy with something else that should go into the release. And I wouldn't know which c172* need which base files, anyway. Maybe the one who broke it can fix it too. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7Xn9lhWtxOxWNFcRAsK7AKC9BXKP7D84/fDG7lGHV2z6S7wHrQCgvcS/ IatYStdya8WuDCb5aH7inWM= =vtLk -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian And some information data and text about the aircraft itself. This could be also usefull later for a in game menu. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. Maybe for the *next* release! Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian One thing more, that i have forgotten in my last message. A way to filter the aircrafts on the webpage by their status, fdm and aircraft type. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Monday 17 January 2005 20:25, Dave Martin wrote: On Monday 17 Jan 2005 17:06, Vivian Meazza wrote: Dave Martin wrote On Monday 17 Jan 2005 15:31, Martin Spott wrote: Dave Martin wrote: http://www.airshowphotography.com/videos/videos2.html Nice, a 45 degree turn just one wing-span AGL :-) Martin. I've been playing with the FDM and changing the line in the yasim file: flap1 start=0.75 end=0.95 lift=1.15 drag=1.3/ to flap1 start=0.75 end=0.95 lift=2.0 drag=1.3/ seems to give a realistic response at low speed. Just changing the lift factor of the aileron makes the detail in the videos flyable and doesn't seem to give any unrealistic behavior at full deflection etc (50% deflection seems about the same as 100% at low speeds). If anyone else would like to try her out with that lift factor change we can compare notes :-) The AN-225 is Lee Elliot's pet, but remember that air-shows are very often done with minimum fuel and no load. Heuristically, a lift factor of 2.0 is perhaps too high for a plain aileron. 1.2 - 1.5 would be normal, and with drag to match. But I agree that as it is the aircraft seems on the sluggish side. Regards, Vivian I was originally testing with absolute minimum fuel and I could still get it into situations where it wouldn't lift the inner wing from 45' bank at 170kts. I'm going to have a go with a figure of 1.5 for lift. One thing tho; the lift figure is the 'maximum' ie: at full deflection. Could we expect that the Aeileron might make that much at full deflection but such a deflection would also be structurally damaging to the aircraft at above takeoff / landing speeds. In the videos, the aeileron deflection used to induce high rates of roll doesn't appear that much. Dave Martin By all means have a go at tweaking any of the a/c I've done:) Be aware that flight testing is a very time consuming process though;) The point about the low fuel load for displays is pretty important - with a very low proportion of fuel on board the TOW is going to be around 700,000 lbs but the total thrust available i still going to be around 300,000 lbs - that's a pretty good thrust to weight ratio. On that other hand, at MTOW the AN-225 can't even taxi i.e. turn on the ground. In the video it looks like it's getting roll rates of about 20-30 deg/sec - I'll have a look into it myself a bit later. One thing that's just occurred to me is that I'd expect the roll rate to be higher at low TOWs because there's less mass to move. Has anyone any idea of what the minimum required roll rate would be for something like this? Another important factor with the AN-225 in the low speed regime are the slats but they don't seem to produce the pitch-up I'd expect. Dunno... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Tuesday 18 Jan 2005 22:07, Lee Elliott wrote: By all means have a go at tweaking any of the a/c I've done:) Be aware that flight testing is a very time consuming process though;) The point about the low fuel load for displays is pretty important - with a very low proportion of fuel on board the TOW is going to be around 700,000 lbs but the total thrust available i still going to be around 300,000 lbs - that's a pretty good thrust to weight ratio. On that other hand, at MTOW the AN-225 can't even taxi i.e. turn on the ground. In the video it looks like it's getting roll rates of about 20-30 deg/sec - I'll have a look into it myself a bit later. One thing that's just occurred to me is that I'd expect the roll rate to be higher at low TOWs because there's less mass to move. Has anyone any idea of what the minimum required roll rate would be for something like this? Another important factor with the AN-225 in the low speed regime are the slats but they don't seem to produce the pitch-up I'd expect. Dunno... LeeE I've been trying to get the aircraft to do the display detail with the outer tanks empty and light fuel load on the inners. Does the FDM accurately model roll inertia when the outer tanks are full? Fantastic model btw :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Monday 17 January 2005 18:49, Curtis L. Olson wrote: For the upcoming release of FG, I'm working on a couple scripts to create/manage a web page for individual downloads. Here is where I'm at so far. There is plenty room for improvement, but this will at least get us started: http://www.flightgear.org/Downloads/aircraft/ If aircraft developers put a 171x128 pixel image in the top aicraft directory called thumbnail.png, this will automatically get picked up and put on the web page. There's no need to get these all populated before the v0.9.8 image, but it would be great if people could start filling thes in with nice pictures. The one's I created can be replaced if someone comes up with something better. Aircraft developers can continue to use our base package cvs, or they can maintain their files locally and submit a ready to install .tgz package ... either way will work fine. As part of this, I hope to significantly trim down the default base package. There are obvious areas of improvement such as categorizing the aircraft and putting them in their own sections (and we should do that eventually) but this at least is a workable starting point for this release. Regards, Curt. I loved the entry for the ufo:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Tuesday 18 Jan 2005 22:31, Lee Elliott wrote: I loved the entry for the ufo:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Dammit! Its a conspiracy! Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
On Tuesday 18 January 2005 14:26, Oliver C. wrote: On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. 2. A central processing blackbox that contains all the logic for the aircraft that also get's updated in the rendering loop. The blackbox will simulate/handle the hydraulic and electrical systems, generate and feed the display data to the intruments, handle the logic for failures, receive input from all the simulated aircraft sensors and cockpit switches, etc. There are far too many aircraft specific systems than could ever be handled by FG properly. An aircraft like this is a simulation of its own. How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. Paul Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. Take a look at this one: http://svgl.sourceforge.net/ What do you think about such a solution? Is this possible? Best Regards. Oliver C. The HUDs do something like this, don't they? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Tuesday 18 January 2005 22:40, Dave Martin wrote: On Tuesday 18 Jan 2005 22:07, Lee Elliott wrote: By all means have a go at tweaking any of the a/c I've done:) Be aware that flight testing is a very time consuming process though;) The point about the low fuel load for displays is pretty important - with a very low proportion of fuel on board the TOW is going to be around 700,000 lbs but the total thrust available i still going to be around 300,000 lbs - that's a pretty good thrust to weight ratio. On that other hand, at MTOW the AN-225 can't even taxi i.e. turn on the ground. In the video it looks like it's getting roll rates of about 20-30 deg/sec - I'll have a look into it myself a bit later. One thing that's just occurred to me is that I'd expect the roll rate to be higher at low TOWs because there's less mass to move. Has anyone any idea of what the minimum required roll rate would be for something like this? Another important factor with the AN-225 in the low speed regime are the slats but they don't seem to produce the pitch-up I'd expect. Dunno... LeeE I've been trying to get the aircraft to do the display detail with the outer tanks empty and light fuel load on the inners. The fuel tank arrangement is currently very primitive - just five equally sized tanks. Try it with just the fuselage (last) tank. Does the FDM accurately model roll inertia when the outer tanks are full? I don't know but I'd be surprised if it didn't. Fantastic model btw :-) Thank you. It could really do with some panels and the u/c is pretty basic. Dave Martin LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On January 17, 2005 01:51 pm, Christian Mayer wrote: When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 CU, Christian ;) Of course not. Check out: http://flightgear.org/Gallery/ Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Paul Surgeon writes I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. I don't know I guess the pilots that ferry Cessna's from America to Australia don,t have the luxury of an FMS system Paul Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] B1900D
Hi all ... I see someone else is having problems with the B1900D. It was my first attempt at a yasim aircraft ... and I still cant get it to fly right ! I dont know about the counter rotating props ... it was a LOT of guess work. So if someone can find a cure for it or give me specs , I'll be happy to attempt to fix it . ( It is a long way from being finished). I did read somewhere that it had a wing incidence of about +3.5 at the root and -1 at the tip , but it crashes the program every time I try to implement it . Im currently fixing the panel for plib 1.8.4 , should be able to send an update tonight. Im afraid Ive tweaked the FDm to the point where it crashes FGFS AND FGRUN :) ... so I'll leave that out .Cheers Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question
It sounds to me like you should just drop the virtual function
declaration in the abstract A class (or make it non-virtual). It
serves no purpose other than trying to enforce your design on the
subclasses. Since you require the foo() function to take a parameter of
the subclass type, only a B can foo a B, and only a C can foo a C. Let
us not use complex language constructs (templates for example) just to
allow the compiler to check that you're following your own convention.
Put a comment in the base class that defines this requirement on
subclasses and call it a day. OTOH, if generic code is going to tell an
X to foo another X (somehow knowing they are the same type) this might
not work. H. I think another option is to declare A:foo(A p1) and
then have the B class explicitly cast the parameter p1 to a B inside
B:foo when using the B-specific functionality of the parameter. I don't
know how to do templates, so this is what I might do until it got too
ugly.
Hope that helps,
Paul
On Sat, 2005-01-15 at 15:12 +0100, Christian Mayer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
can someone help me to solve thise problem:
Imagine I've got this class hierachy:
class A
{
virtual bool foo( A bar ) = 0;
}
class B : A
{
bool foo( B bar )
{
...
}
}
int main( void )
{
B foobar;
}
this won't compile as my class B is still abstract as I didn't provide a
bool foo( A bar ) member.
But I only want class A to be an interface that tells everybody what to
expect from it's derivated classes. And one of these things is, that
every child must have a member that is called foo and has one
parameter of the type of the child itself.
How do I achieve that?
The only workaround I can come up with is, that I have:
class B
{
friend bool foo( class B, class B );
}
bool foo( class B bar1, class B bar2 )
{
...
}
I this doesn't guarantee me, that every child of A must have a foo
function...
Thanks,
Christian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D
On Wednesday 19 Jan 2005 01:14, Syd wrote: Hi all ... I see someone else is having problems with the B1900D. It was my first attempt at a yasim aircraft ... and I still cant get it to fly right ! I dont know about the counter rotating props ... it was a LOT of guess work. So if someone can find a cure for it or give me specs , I'll be happy to attempt to fix it . ( It is a long way from being finished). I did read somewhere that it had a wing incidence of about +3.5 at the root and -1 at the tip , but it crashes the program every time I try to implement it . Im currently fixing the panel for plib 1.8.4 , should be able to send an update tonight. Im afraid Ive tweaked the FDm to the point where it crashes FGFS AND FGRUN :) ... so I'll leave that out .Cheers Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Lovely model! Well, so far, I've counter-rotated the props for now till I can find out if they do in real life. I've got the thing flying reasonably and the stall normalised at about 80-85 dirty / 100ish clean. I've already experienced what you mention with the incidence at the tips (the twist of the wing). I'm trying to work out if I can make an average between the two that wont make Yasim throw the toys out of the pram. I've also managed to reduce the 'dragster' runway performance a bit but it needs more work to match up things like rate-of-climb etc to the real figures. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D
Dave Martin wrote: Lovely model! Well, so far, I've counter-rotated the props for now till I can find out if they do in real life. I've got the thing flying reasonably and the stall normalised at about 80-85 dirty / 100ish clean. I've already experienced what you mention with the incidence at the tips (the twist of the wing). I'm trying to work out if I can make an average between the two that wont make Yasim throw the toys out of the pram. I've also managed to reduce the 'dragster' runway performance a bit but it needs more work to match up things like rate-of-climb etc to the real figures. Yasim has a magic solver that is sometimes sensitive to specific inputs. In the back of my head I imagine a little robot trying to climb to the highest point on the map by always going up ... but then coming to the top of a smaller hill and getting stuck. The solver tunes the lift and drag coefficients to make the aircraft hit the numbers you specify ... so if you provide engines that are too weak, you will end up with a super slick model which an incredibly efficient wing ... thus it can still hit the numbers but has really slow acceleration and climb. On the other end of the spectrum, if you provide too much power, you end up with a high drag, low lift model (so you don't blow past the provide performance numbers.) This will give you great ground acceleration and probably great climb, but will still top out at whatever numbers you specify. So once you have your basic YAsim model flying, you can tune things like rate of climb by adjusting actual engine output. You can tune roll/pitch rates by adjusting the size or effectiveness of the control surfaces. I'm not convinced you could get a YASim model close enough in every area to get FAA level 3 certification or higher, but you can get a really fine flying model in most regimes with a bit of tweaking and understanding (at least at a simple level) how various configuration options relate to each other. The other thing that confused me early on was how YAsim handles weight. I don't remember the rules well enough off the top of my head to summarize them here, but the solver solves at 80% fuel load I believe. This means that unless you are very careful with your fuel load and the weight the solver uses, you won't hit your performance numbers exactly ... those number only are for one particular aircraft weight. Once you figure out how to control the weight the solver uses and figure out how to configure the aircraft at that exact same weight, you do hit the performance numbers dead on. For someone like me with zero aeroengineering background, YAsim is a *really* fun tool to play around with. After a few hours with it, I almost feel like I understand it enough to build pretty plausible numbers. When it comes to stability derivatives and aero coefficients, I'm still pretty much as clueless as the day I was born. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Aircraft included in base package
I know we can debate this endlessly so I hesitate to even bring this up, but are there any particular aircraft that absolutely, positively, must be in the base package. Now that we have a separate aircraft download page, there's no need to include every aircraft in the base distribution. I went through our list and tried to come up with a variety of aircraft that represents some of the major aircraft types as well as includes examples from many of our major aircraft designers. Here's the list I came up with. It's still probably too long. If you suggest a different aircraft, you have to tell me why it's better than two aircraft on my list so I can reduce the size of my list. So here's what I have ... 737 - large commercial jet. Reasonably well done. Flies pretty well. Nice 2d panel with some simple glass elements. A-10 - A gorgeous external 3d model by Lee with nice flight dynamics and really well done gear animation. bo105 - I could say a lot of nice things, but why bother, it's our only helicopter so it has to be included anyway. c172, c172-le, c172p, c172r, c172x - I don't have the energy to sort out the dependencies so throw it all in. c310, c310u3a - light twin, again I think there are cross dependencies so just include them both for now. dhc2 - Our only sea plane, a cool aircraft, nicely done 3d cockpit, flies well. f16 - A nicely done high performance military jet. j3cub - Another nicely done aircraft, simple, easy to fly. Hunter - A classic/early jet. Well done. 3d cockpit, european representation. p51d - A classic WWII fighter ... also well done. Full 3d cockpit. ufo - handy for debugging. wrightFlyer1903 - First successful powered flyer. So what did I miss and why should I replace something on my list with it? Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Terrain photo-real howto
On Tue, 18 Jan 2005 20:08:00 +0100, Robicd wrote in message [EMAIL PROTECTED]: Hi, How do I use photo-real terrains? I have some nice aerial pictures of ..these pix _you_ owns the copyrights to? Next step is GPL them, and paint them onto the scenery tiles. Sorry no, I can't distribute them because they are copyrighted but I'd like to have them for private use (that's allowed) and that will help me positioning a few 3d objects I'm currently building into the right place in the scenery. ..ok, the rest of my advice stands, and if you document how you do it, that's gonna be useful to anyone who _can_ redistribute pix this way for use in FG photo sceneries. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] QuickSilver MX - anyone making this?
On Tue, 18 Jan 2005 11:17:15 -0800 (PST), Don wrote in message [EMAIL PROTECTED]: --- Dave Martin [EMAIL PROTECTED] wrote: It'd be really good to have a fairly detailed aircraft like the Quicksilver with an 'ultra-open' cockpit to check out the scenery that we are starting to build. I also wondered about trying to simulate a BRS system that you see on many Quicksilvers but I'm not sure if the FDMs would support such a thing. Look forward to seeing it :-) Dave, Thanks for the encouragement. It will take me some time, as I have a lot of learning to do. I have found information on how to get a model into Flight Gear, once it is made, but not too much success yet in finding info on how to actually make the model. At the moment, I am working on the assumption that I will find a way to convert the Turbocad format to Flight Gear format. ..Turbocad has support for several export file formats, no? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Tue, 18 Jan 2005 20:57:48 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: c172, c172-le, c172p, c172r, c172x - I don't have the energy to sort out the dependencies so throw it all in. We should try to sort them out and include just the C172p by default -- in any case, you should be able to remove the c172-le, c172r and c172x without any damage (I think that all the dependencies are downwards on c172). Since that's three removed, it might be worth including a Cherokee (pa28-161), since it is the other common entry-level trainer at flight schools, and that way we'd have most student pilots covered. Do we have a glider that's well enough along to include? That seems to be one big gap on the list (I'd remove one of the military jets to make room, if you have to). It might also be nice to include the Sopwith Camel so that we have WW I biplane. All the best, and thanks for putting together the list, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Aircraft included in base package
c172, c172-le, c172p, c172r, c172x - I don't have the energy to sort out the dependencies so throw it all in. The C-172X is purely a development model It should definitely NOT be released. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Announce v0.9.8
I have finalized the v0.9.8 release and rolled up the source and base packages, updated the web site, and made the new files available on the ftp site. Everyone should be clear to start building binary versions for their favorite platforms. Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] QuickSilver MX - anyone making this?
Arnt Karlsen [EMAIL PROTECTED] wrote: .Turbocad has support for several export file formats, no? Yeah, I should have looked before I said that, instead of after. g Don Do you Yahoo!? Meet the all-new My Yahoo! Try it today! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Web site changes
Curt, I think that the changes made to the web site recently make it much better; especially the aircraft download area. Maybe you could think about adding the aircraft downloads to the Quick Links? Don Do you Yahoo!? Yahoo! Mail - You care about security. So do we.___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce v0.9.8
Curtis L. Olson wrote: I have finalized the v0.9.8 release and rolled up the source and base packages, updated the web site, and made the new files available on the ftp site. Everyone should be clear to start building binary versions for their favorite platforms. Great ! Is there any consensus wether to build PLIB for the binary releases with or without the 'Plib_ssgDList2' patch as in ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/Plib_ssgDList2-20050105.diff Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Wednesday 19 January 2005 00:58, Ampere K. Hardraade wrote: On January 17, 2005 01:51 pm, Christian Mayer wrote: When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 CU, Christian ;) Of course not. Check out: http://flightgear.org/Gallery/ Cool. Is this what you were working on with Innis? Looks good... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. Another thought: There are some other hangar pages out there like the ones made by David Culp and Wolfram Kuss. Would it be an idea to add a link to these pages at the bottom of the aircraft download page? Presumably we can't merge these pages due to licence incompatibilities... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
Durk Talsma writes On Wednesday 19 January 2005 00:58, Ampere K. Hardraade wrote: On January 17, 2005 01:51 pm, Christian Mayer wrote: When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 CU, Christian ;) Of course not. Check out: http://flightgear.org/Gallery/ Cool. Is this what you were working on with Innis? Looks good... Told ya there would be something around the 18th of January. :-) And if you ask Ampere nicely he might upload it for you. Cheers, Durk Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
