Re: [Flightgear-devel] Autopilot
On Wednesday 30 November 2005 17:34, Steve Hosgood wrote: or 2) Maybe the c172 doesn't have an autopilot. It has an autopilot, but you operate it with buttons on the panel, you know, like in Real-Life[TM]. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). Is this possible, Melchior, to disable the autopilot menu entry just for the C172? I think it's the right thing to do, besides adding a big plackard with RTFM next to the autopilot on the panel ;-) Seriously, you really need to read the Pilots Guide for the KAP140 to operate it. It is available for download from the Bendix/King website (Warning: it's huge! about 12MB) https://www3.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_2.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .tgz extractors for windows
On Monday 21 November 2005 16:52, Curtis L. Olson wrote: Can someone post a link to a good, free, unencumbered windows uncompresser that handles the .tgz format? http://www.7-zip.org -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] howto compile on SuSE 10.0 running gcc 4.0.2 and freeglut 2.4.0
On Tuesday 08 November 2005 17:36, Torsten Dreyer wrote: Hi everybody, just tried to get latest CVS compiled on a fresh install of SuSE 10.0. It has gcc 4.0.2 and freeglut 2.4.0 installed. It compiles, but does not run due to the known freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. FWIW I took the freeglut CVS route, on Debian unstable. After that freeglut compiles and a rebuild of plib, SimGear and FlightGear brings back my FlightGear. Looks more like a freeglut-thing, but maybe someone on this list also cares... Cheers, Torsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
On Thursday 29 September 2005 13:51, Hans-Georg Wunder wrote: Time, reference,input,output 09:10:00,0,0,0 09:10:01,0.6,0,-0.4999 Jump into saturation. Thats OK. Only a P-Part, no I-Part 09:10:02,0.6,0,-0.4999 snip! 09:10:13,0.6,0,-0.4999 09:10:15,0,0,0.0999Here the output value should return to zero, because there is no I-Part Maybe it should?! In this example, the output flips from the min saturation to max-saturation. In a two phase controller (climb - altitude), it impossible to control the aircraft. Are you saying that it's not possible to make cascade configurations? We've had cascade configurations since day one! The problem is, that the change of input is store in ep_n. Only the changes are given to the output. But in saturation the change is not given to the output because of the windup logic The controller gets out of sync Same test with delta_u_n =u_max - u_n_1 and ep_n = (ep_n * u_max )/(delta_u_n+ u_n_1 ); (My solution. Meanwhile I think it is not necessary to change the edf_n-value, because the windup logic is for the integrator part, but I am not completly convinced. snip! This should work in any situation. Of course I can not deny the fact that your altering of ep_n does return the output closer to zero in one time step for the open loop case, but what about the closed loop case? Open loop PID controllers are really useless. Does this altering of ep_n improve the performance when used in closed loop controllers? I think that some of the problems that your tests expose can be traced back to the fact that you use an open loop configuration. I suggest that you do some tests with closed loop controllers to see if there is any performance gain. I also suggest that you fiddle around with the beta value, try setting it to zero. PS! I'm a bit disappointed by the BESTune application. I seems that the demo version is able to recognize the original input data, and when you try to change them it barks that it don't want to use anything but the _original_ input data. It does display the custom input data, but it does not seem to calculate useable values for Kp, Ti and Td. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller =?iso-8859-1?q?Bug??=
På 29.09.2005 00:47 CEST skrev Hans-Georg Wunder Behaviour with delta_u_n = 0 and an input jump function of 0.6 Saturation at the beginning o Time, reference,input,output 21:56:54,0,0,0 21:56:55,0,0,0 21:56:56,0,0,0 21:56:57,0,0,0 21:56:58,0,0,0 21:56:59,0,0.6,0.02549 Here the P-part is missing There has to be a jump to u_max You should not set the input to 0.6. You should set the reference to 0.6. The input is the process value, and the reference is the set point. You can not set the process value directly. If you could then you would not need a controller at all ;-). In your example here it does not matter, results would have been similar if you set the reference to 0.6. But you have to remember this when you use live values with your controllers. The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n is still 0.6: 0.6 (0.5 - 0.5) : true delta_u_n = 0.5 - 0.5 = 0.0 u_n = 0.5 + 0.0 = 0.5 u_n jumps to u_max and stays there as long as delta_u_n is positive. P.S.: The test result for delta_u_n = u_max - U What? Where are the results for delta_u_n = u_max - u_n_1? Am I right in assuming that the results you presented her were for version 1.19 of xmlauto.cxx and _not_ version 1.20 of xmlauto.cxx? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
On Wednesday 28 September 2005 21:03, Hans-Georg Wunder wrote: The original problem is, when there is an input change from 0 to u_max/kp, the output value is zero. This is wrong. It has to be u_max. The fix from Erik was also my first approach. But it does not solve the problem. Under some circumstances the controller stays in saturation for ever. If you tune the PID controller to be a P only controller (Ti=inf, Td=0) then this can happen because of steady state error that can not be reduced by a P only controller. Maybe I did not stress this enough in my last post on this subject: The velocity form of the PID controller should _not_ be used as a P only controller! I found a site with a good explanation of the PID equation: http://bestune.50megs.com/typeABC.htm The equation that most of the controllers in FlightGear autopilots use is the type B. The equations here are of the independent type. We use the dependent type, but that does not matter. Our PID equation is actually able to act as type A, through type B to type C. This is done with the gamma and beta values. Gamma is the weighing of the reference for the derivative error: ed_n = gamma * r_n - y_n. beta is the weighing for the proportional error: ep_n = beta * r_n - y_n. So for a type A controller we would set gamma = 1 and beta = 1. For the type B, gamma = 0 and beta = 1, and finally for type C, gamma = 0 and beta = 0. Notice that we have complete power over how much we want to weigh the reference value for the derivative and proportional error term. I think, my solution solves the problem, but it would be great, if Jeff is also able to test it. The guys at BESTune claims that the type C controller is the best. I suggest that you try setting beta = 0 to make you controllers type C. I'm sorry but I'm very sceptical to your idea of altering ep_n and ed_n on saturation. Also on BESTune's site they have a demo of their BESTune application. It's Windows only, but I'm very exited about this app. I'm going to try and test it this weekend. I suggest that you check it out too. I really think that it can prove to be very helpfull in tuning our controllers. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 September 2005 16:43, Paul Kahler wrote: I'm not trying to flame, but why would you be using a moving average filter? That's the most complicated filter I've ever seen - it calls other functions! It calls some of the methods of the deque datatype. I'm sorry! That's the implementation my limited skills came up with. I chose 4 filters from one of my textbooks: Exponential, Double Exponential, Moving Average and Noise Spike. That's what the author of the textbook called them. Both of the exponential filters are IIR filters. I always liked the simplicity of a low pass filter: output += (measurement - output) * gain; Using floats, doubles, or fixed point of course. You are welcome to add this filter (or any other filter that you think might be usefull) to the already existing filters. No need to call a function either, just in-line it where you need it. Want fast convergence on startup? Just sweep the gain from 1.0 down to whatever the steady state value needs to be. I bet this is nothing new - it's probably in the code under else if (filterType == IIRfilter) or something. So why do people use moving average filters? The Scientist and Engineer's Guide to Digital Signal Processing says about the moving average filter that it is the most common filter in DSP, because it's easy to understand and use. It's optimal for reducing random noise, while retaining a sharp step response. http://www.dspguide.com Why does FGFS? The best I can think of is why not? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re:[Flightgear-devel] Bug in moving-average filter?
Lee Elliot: Hello List, I think there's a small bug in the moving-average filter in xmlauto.cxx I noticed that the output from it was always out a bit and checking with a calculator showed that it seemed to be dividing by the number of samples + 1 instead of just the number of samples. subtracting 1 from 'samples' in line 702 seems to fix the problem and as 'samples' doesn't seem to be used elsewhere I think it's safe. Possibly implies that the number of samples may be one less than specified but I'm not familiar enough with c++ to spot it. You are right. I would suggest resizing input[] to (samples + 1) instead. Change lines 654 and 661 to: input.resize(samples + 1, 0.0); That way we average over the number of samples as configured. Can anyone commit this?! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GPS Track
On Monday 12 September 2005 00:20, Steve Knoblock wrote: The Digitrak autopilot project is coming along. I have the first mode running, which captures and holds the GPS track. I get the GPS heading to feed to the autopilot controller from the default GPS instrument. The autopilot is set to reduce the GPS bug error to zero by driving the aileron until the orientation roll equals the target roll. This works fine, however, I notice some differences in the numbers reported by the heading and track properties. Are you sure that the Digitrack actually knows the roll angle of the airplane? I may be a dummy, but can anyone explain this? Not the variation between true and magnetic, but between GPS and orientation. Heading and track are _not_ the same thing. Heading is the direction that the nose of the aircraft is pointing. Track is the direction that the aircraft is moving. You probably have a crosswind that is blowing your aircraft to one side. The numbers that you observe seem quite reasonable. If you try to fly parallell to the wind, heading and track should be similar. For a good explanation of the different GPS navigation terms read chapter 7 of John Bell's Cockpit GPS available on-line http://www.cockpitgps.com -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digital Autopilot
On Friday 26 August 2005 23:19, Steve Knoblock wrote: My attempts so far have left me with some questions. Is there a complete and comprehensive list of properties that are built-in to the FG system (not those created by a particular instrument)? I think the best way to explore all the properties is to use the property browser from the file menu. As a rule of thumb you can assume that properties that update in real-time and when you click the . (for current directory) are what you might call built-in. Do I understand correctly that properties in the instrumentation/ hierarchy are built-in values, that come from the system and are not produced by a custom instrument or script? The majority of them are. In addition these are the properties that should be the most interesting to you as autopilot designer. Don't be tempted to use the properties from position/ or velocities/ ! Those are perfect values that would not be accessible in real-life. I do understand that you can bring a property into existence by naming it and it appears that the properties in autopilot/ hierarchy are somehow part of the standard autopilot. I believe this means I should create my own set of properties, such as autopilot/digitrak/settings etc. Is that correct? I thought that was a good idea too, so that's what I did with the KAP140. I tried adapting the controller, the cascading one for Heading Bug, but it will not track. It just spins around. I can see it hit a bump when it equals the setting. The original HDG controller uses the heading bug error as an input. But I need to input the difference between the orientation of the a/c and the GPS track into the controller. I tried making the orientation in roll axis the input and the GPS track the reference, but that does not seem to work. An autopilot needs to control the roll axis. Either by roll angle as input or turn rate as input. From browsing through the installation guide it looks to me that the _only_ flight data input (ignoring the internal magnetic system for a moment) is from the GPS. It would be difficult to derive the roll angle from the data that the GPS can provide, but it should be quite possible to derive the turn rate. You simply take the time derivative of the track. This can be done in nasal. It might be a bit tricky handling the 360 - 0 wrap. Now another controller can be used to set the reference for the pitch axis controller. This will normally be another PID controller, but it could also be you, the pilot, setting the reference to say 3 degrees-per-second turn rate. Also, I do not really understand the GPS system in FGFS. I need to take the heading value from the GPS ground track. The Digitrak in its NAV mode follows a GPS track and ground speed from the GPS. That is all it needs to function. It has various other modes as well, but that is the one I want to get working first. There is a tracking bug and a tracking bug error values in the GPS system. I think that eventually you will find that they will come in handy. I find this autopilot interresting seeing that it only uses GPS data for it's input. It's quite different from the traditional designs that use the turn coordinator or the attitude indicator to control the roll axis. Are you using version 0.9.8 or CVS? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug or feature in xmlauto.cxx ?
On Friday 19 August 2005 23:58, Hans-Georg Wunder wrote:
Hi all,
I try to configure a P-Controller, but I have problems with the
anti-windup logic:
The velocity form of the PID control algorithm _needs_ to have an integral
component. If you need to use a P only controller, try the
pi-simple-controller.
Snip! ...
Now u_n_1 = 0, so delta_u_n = 150 and greater as u_max,
and then u_n = 0 + 0 = 0. The controller does not work.
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
// Calculates absolute output:
u_n = u_n_1 + delta_u_n;
if ( debug ) coutoutput = u_n endl;
I think, this is not okay. delta_u_n = 0; has to be replaced by
something like that
delta_u_n=u_max - u_n_1;
That's a good idea. I seem to remember trying to fix this by setting
delta_u_n = u_max;
Which of course was a bad idea :-(
But that's not enough. The value of ep_n also has to be changed,
but I do not know how. Any ideas ?
As I mentioned earlier: since you _have to_ include the integral term for the
velocity form PID, changing ep_n shouldn't be necessary.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
On Tuesday 26 July 2005 00:02, Gerard Robin wrote: Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. I seem to remember that the CVS version of Atlas is compatible with the new airport format. Try that! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
On Tuesday 26 July 2005 18:25, Gerard Robin wrote: Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
On Tuesday 26 July 2005 19:20, Gerard Robin wrote: If we look at /systems/electrical/outputs/ we get gps to null when volt=28 we get gps to 60 when volt=60 in gps.cxx we find Line 102 _electrical_node = fgGetNode(/systems/electrical/outputs/gps, true); That's the initialization of the property. This is where it gets created. I am far be expert, it seems that gps needs a good electrical value, is it right ? That's right. At line 215 that property needs to be true (that is not zero/null) for the gps to update. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
On Monday 25 July 2005 20:49, Gerard Robin wrote: Get Nearest Airport (From Menu Equipment GPS) seems not working. It was working with olders CVS. Is it any new modifications which deleted that function ? AFAICT there hasn't been any significant changes to Instrumentation/gps.*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Saturday 23 July 2005 15:58, Lee Elliott wrote: I could probably do an external model, including the cabin space, in a couple of weeks. I still haven't got around to doing any panels yet but was planning to do one for the MiG-15 I've just started so I guess I'd have a go at one for an sr20. Would anyone else be able to collaborate on the panel? (external model and panel gpl'd for FG) I did make an STEC System Twenty some time ago, but somehow it got deleted when I moved to Linux :-( Well, now I'm rebuilding it and incidently The POH said that the SR20 comes with a System Twenty autopilot. I can also do the Garmin audio panel, and at least take a look at the Garmin GPS unit that also control the radios. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Turn Coordinator is out == c172r and others
On Sunday 26 June 2005 16:36, Gerard Robin wrote:
It's the new nasalised electrical system. The turn indicator is hardcoded
to expect 60 ampere as input. The new system outputs 28 volts instead (I
told Curt that it made more sense to output volts rather than amperes).
So the result is that the gyro is not spinning fast enough.
I tried the radiostack just now, and it seemed to work fine.
Well, what must be done to solve that ?
Short term ugly hack:
--- c172-electrical.nas 14 Jun 2005 21:31:13 - 1.2
+++ c172-electrical.nas 26 Jun 2005 16:01:25 -
@@ -111,7 +111,7 @@ AlternatorClass.new = func {
obj = { parents : [AlternatorClass],
rpm_source : /engines/engine[0]/rpm,
rpm_threshold : 600.0,
-ideal_volts : 28.0,
+ideal_volts : 60.0,
ideal_amps : 60.0 };
setprop( obj.rpm_source, 0.0 );
return obj;
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Turn Coordinator is out == c172r and others
On Sunday 26 June 2005 04:04, Ampere K. Hardraade wrote: I notice it as well, but I thought my CVS version is outdated, so I didn't mention it. Beside the turn coordinator, everything on the radio stack seems to be out as well. It's the new nasalised electrical system. The turn indicator is hardcoded to expect 60 ampere as input. The new system outputs 28 volts instead (I told Curt that it made more sense to output volts rather than amperes). So the result is that the gyro is not spinning fast enough. I tried the radiostack just now, and it seemed to work fine. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Short Reference Document error?
On Sunday 19 June 2005 13:50, Jon Berndt wrote: This short reference: http://www.flightgear.org/Docs/FGShortRef.pdf shows the rudder control on the numeric keypad as being the 0 and , (comma) keys. There is no comma on the numeric keypad. This is confusing. IMNSHO the really confusing part is that the rudder control is actually 0 and Enter on the numeric keypad. It looks like the political issues unleashed in this thread have made you all blind ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
On Saturday 11 June 2005 13:44, eagle monart wrote:
i am totaly lost. i ve tried different declarations of delay functions but
they starts infinite loops. i tihnk nasal expalined only for xml usage
but i didnt find a source to declare settimer() in a source code . I need
a reference...
settimer(foo(...), time)
where foo(...) is the function to call and time is the delay in seconds. This
will call foo(...) in time seconds from when settimer() is called.
Here is a function that repeats, or calls itself every 5 seconds.
foo = func
{
# Do something really neat
settimer(foo(), 5.0);
}
This is of course an infinite loop. If you want to stop the loop you have to
check for some condition and simply not call the settimer function:
foo = func
{
# Do something really neat
if (stopTheLoop)
{
# Do nothing
}
else
{
settimer(foo(), 5.0);
}
}
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
On Saturday 11 June 2005 14:15, Roy Vegard Ovesen wrote:
settimer(foo(...), time)
where foo(...) is the function to call and time is the delay in seconds.
This will call foo(...) in time seconds from when settimer() is called.
Here is a function that repeats, or calls itself every 5 seconds.
foo = func
{
# Do something really neat
settimer(foo(), 5.0);
}
This is of course an infinite loop. If you want to stop the loop you have
to check for some condition and simply not call the settimer function:
foo = func
{
# Do something really neat
if (stopTheLoop)
{
# Do nothing
}
else
{
settimer(foo(), 5.0);
}
}
Whoops!
Replace foo(*) with foo wherever it appears above.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Modifying nav.dat file and waypoints
On Friday 27 May 2005 23:22, YENEW T KASSAYE wrote: Hello Everyone. Has anyone attempted to modify the listings in nav.dat file and run flightgear 0.9.8? I am trying to edit the nav.dat file. My idea is to create waypoints for the autopilot to follow by using the NAV 1 CD1 Course and NAV 1 Glide Slope. Right now, there are a bunch of airports, GS, LLZ listings. I tried adding a location with long,lat,alt,freqz and give it a name like KYEN for both the GS and LLZ. This doesn't work. How does it not work? Do you get an error? Are you not getting what you expect when you tune the navradio to your frequency? Simply adding a localizer (LLZ) somewhere should work, but (off the top of my head) in addition to lat, log, alt, freq, a localizer needs at least a heading. Take a look at the database dataformat definition: http://x-plane.org/home/robinp/FileDef.htm In _my_ opinion adding localizers and/or VORs to the nav database to be used as waypoints is not a good idea. I would rather add my custom waypoints to the GPS, and connect a HSI instrument to it. For example (from my Aircraft/c172p/Models/c172p-2d-panel.xml file): 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/nav[0]/has-gs/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 -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model's xml properties
On Monday 16 May 2005 16:51, Ben Morrison wrote: I have added a tank to flightgear but the model is not to scale, appears below the ground, and doesn't face the right direction. As in water tank, or as in battle tank? If I understand correctly the model should have values to correct this in a xml file, but I can't find documentation for the properties to define them. Can someone point me in the right direction? http://www.flightgear.org/Docs/fgfs-model-howto.html Looking at other model xml files is also quite educational. IIRC Blender uses the same coordinate system as Flightgear. That is, the X, Y and Z axes are pointing in the same direction. AC3D uses a rotated coordiante system, I forget how it's rotated, but I guess you'd figure that out when you start using it. In order to have a 3D object face the right direction you have to know that * Forward is the negative X axis direction * Rightward is the positive Y axis direction and * Upward is the positive Z axis direction So when creating you model (in Blender) you should have it facing in the negative X axis direction. For scale you must remember that units in both Blender and AC3D are meters. One unit in Blender equals one meter in FlightGear. When you include you model in FlightGear, it is positioned relative to it's origin. If that happens to be in the middle of the model bulk, and you position it at ground level, then consequently part of your model will appear below ground. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Simgear props dialogs
On Saturday 14 May 2005 14:56, Melchior FRANZ wrote: * Melchior FRANZ -- Saturday 14 May 2005 14:29: * Harald JOHNSEN -- Saturday 14 May 2005 14:11: The last commit on props.cxx and prios_io.cxx has a side effect on dialogs. They appear correctly the first time you invoke them, but on the second time they are drawn in the bottom left corner of the screen with a transparent background. I'll look into it. (But I can say already, that it's a dialog bug, not a simgear bug.) It's actually this change that fixes the problem: (don't apply in cvs yet!) diff -u -p -r1.8 props.cxx --- props.cxx 9 May 2005 14:31:41 - 1.8 +++ props.cxx 14 May 2005 12:50:49 - @@ -928,7 +928,7 @@ SGPropertyNode::removeChild (const char _removedChildren.push_back(node); } node-setAttribute(REMOVED, true); -node-clearValue(); +//node-clearValue(); ret = node; fireChildRemoved(node); } ... and this line wasn't even needed to fix the original problem. I just added this there, too, because it makes sense. It makes removed(!) nodes forget the type they had. Otherwise, after deleting /foo[0] of type bool and then creating a new node /foo[0], this brand new node was already born as bool with no way to change the type. This is silly and wrong. Unfortunately, something in the dialog code seems to rely on that bug. Working on it ... I'll add that reloading the gui (Debug-Reload GUI) at runtime fixes the dialogs. Hope this info helps solving the problem. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
On Friday 22 April 2005 01:46, Norman Vine wrote: Andy Ross writes: Vivian Meazza wrote: I used the power form because it is easier to read, but if the other form produces a performance advantage, then of course we must use it. It's actually not so much about performance, really. Readability can mean different things. The problem is that when I see a trancendental function in code, I immediately start thinking that it much be some complicated formula typed in from a book, as these things don't occur in typical programmer's brains all that often. Basically, even though in isolation it's easier to read pow(foo, 3) than foo*foo*foo, when you look at the whole expression, your original one is complicated to me: (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) + (1.11 * rpm_norm); Whereas this one is just really obviously a polynomial, and I understand polynomials, they're simple and not scary at all: rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) I'll work up a version of the new one with the sign bug fixed, and try to get that checked in tonight. Hmmm. I find it all to easy to make silly mistakes with nested parentheticals and usually avoid them unless absolutely needed The silly mistake was that 0.15 and 0.25 got swapped. This is what it should have read: rpm_norm * (1.11 - rpm_norm * (0.25 * rpm_norm + 0.15)) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Unknown IO option
On Thursday 14 April 2005 12:28, Luuk van Hal wrote: I'm still working on the unknow IO option but now I have some doubts about my way of compiling because it seems that none of my changes help. Every time I adjust my code, I save the file and I do: ./configure , make , make install .does it work this way? You mentioned that you added some source files, did you run autogen.sh? When you add new files and modify makefile.am, you have to rerun autogen.sh. In addition I don't think you are supposed to modify makefile.in yourself, only makefile.am. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SG_LOG output?
On Thursday 14 April 2005 16:33, Luuk van Hal wrote:
Where can I find the output of SG_LOG?
Because I don't get any output on the command line.
Or can I use printf / cout? (these commands don't seem to work either)
This might not be what you are looking for, but you can set the log level with
the --log-level={bulk,debug,info,warn,alert} command line option.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
On Wednesday 23 February 2005 18:11, Paul Surgeon wrote: Are you now talking about a separate C++ instrument? Yes. So the way I see it is I need two C++ modules that need to be created and hooked into FG. Right. How does one do that? Instrument modules are located in src/Instrumentation. This is where I would suggest that you create the Variometer instrument module. Take a look at the existing VSI module (vertical_speed_indicator.*xx), and use that as a template. The work is done in the update method. System modules are located in src/Systems. Where you create your TE tube module. System modules and instrument modules are really the same thing programming-wise, they are all children of SGSubsystem. Can I write shared libraries with a defined interface and get FG to load it when the panel references it? This is not how it is currently done, but that's an interesting idea. All the instrument modules and system modules are compiled into the fgfs executable. If there is a defined API for this stuff I'll manage but if it requires designing software architectures then I'm stuck. I think I'll rather fiddle around with the existing mess and leave the serious stuff up to the guys who have brains. I think that if you take a look at the aforementioned VSI module, and also the static-port system module, you will find that creating new instrumentation modules is pretty straight forward. You also have to modify the instrumentation manager (FGInstrumentMgr) and the systems manager (FGSystemMgr) to include your new modules. If you get stuck please feel free to mail me off-list, I'll be happy to help you out! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
On Tuesday 22 February 2005 22:20, Paul Surgeon wrote: Hi guys I'm busy creating a variometer for FlightGear. My instrument needs to be able to : 1. Display total energy (using some maths I haven't figured out yet) 2. Play sounds (audio cue) 3. Accept user input to its 2 knobs and 3 toggle switches. From what I've seen in FG I would have to generate the total energy property from a nasal script, play the sounds from the aircraft XML file and accept the user input through the panel hot spot (actions) config file. I would like to suggest a different approach. 1. Create a new Variometer instrument module i C++. Actually you might want to create a more generic Total Energy Tube module to add to the systems modules (static, pitot, vacuum, etc.). I urge you to try to model the Total Energy Tube principles as closely as possible. I found a basic description from a variometer manufacturer: http://www.borgeltinstruments.com/BasicDefinitions.html But I guess you'll need something a bit more descriptive. 2. The sound bit can be coded in C++ into the variometer instrument module. I have one short word to describe this affair : Mess! :) Most of the instrument has to be coded into the aircraft config files (although none of it is aircraft model specific) and for every aircraft that I want to install the instrument in I would have to duplicate the sound, hot spots and nasal code. Is there not a better way of doing it? Also is there not a way to accept user input on a 3D instrument? I don't see the logic behind specifying hot spots using 2D panel *pixel* locations for a 3D model which is placed using 3D coordinates. Not to mention that as soon as I move my 3D instrument around in the cockpit the input is lost. Surely the input should be part and parcel of the instrument? You could include a small panel with every 3D instrument and make the hole panel a hotspot as described here: http://baron.flightgear.org/pipermail/flightgear-devel/2004-June/028820.html But this of course is a very ugly hack. I've wanted to make 3D instruments (objects) clickable for a long time, but I just don't have the skill to do it :-( The way I see it is an instrument should be able to have it's own set of animation, input and sound config files as well as nasal scripts. Then only a single include has to be done in an aircraft config file to load the instrument at the right location. Yes, I totally agree on this. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re:update_helper() getting hairy (was:Nav0/Nav1 course tracking and ILS approach)
On Saturday 12 February 2005 22:50, Hans-Georg Wunder wrote: Hi all, for the A320-200 2D-panel I tried to activate the course tracking with nav1. But it doesn't work. Then I checked the source and I found the following in src/Autopilot/xmlauto.cxx 874 // Calculate nav1 target heading error normalized to +/- 180.0 875 static SGPropertyNode *target_nav1 876 = fgGetNode( /instrumentation/nav[0]/radials/target-auto-hdg-deg, true ); When I replaced it with 876 = fgGetNode( /instrumentation/nav[1]/radials/target-auto-hdg-deg, true ); everything works: ...snip! Now I am able to follow the ILS. Is this a bug in flightgear, or do I have the wrong understanding and do I use the wrong properties I think that adding more helpers to the autopilot like this will grow into a big hairy mess. I say we move the helpers into the instruments where they belong: the heading bug into the heading indicator, the nav stuff into the navradio, etc. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cessna 172 problem in 9.8
On Friday 21 January 2005 11:06, Erik Hofman wrote: From c172-610x-null-set.xml panel pathAircraft/c172/Panels/c172-610x-panel.xml/path visibility archive=ytrue/visibility flip-xtrue/flip-x /panel Note the flip-xtrue/flip-x tag. -- Roy Vegard Ovesen ___ 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] Yet another blender modelling question...
On Thursday 06 January 2005 15:36, Matthew Law wrote: I googled around on the subject and I believe that the sub-surface version of the model is only a kind of visual thing done inside blender. The objects within the model itself remain in their lower poly form through out. I also thought that Bleder did the sub-surfacing in real-time. I've just thought that I might be able to get a really nice smooth but higher poly model by using nurbs surfaces to model half of the fuselage, say. Then I'll convert it to a mesh and duplicate, mirror and join it to make the whole thing. Does this sound reasonable? I just done what you describe here. One advantage of using nurbs surfaces is that you can set the resolution. So if you need a low poly model you just reset the resolution of you nurbs surface and reconvert it to a mesh. It's a good idea to keep your original nurbs surface and convert a duplicate of it. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] John: Church Fenton hangars need fixing?
On Thursday 06 January 2005 22:49, Vivian Meazza wrote: Jon Stockill Yes, they do need fixing - I can see terrain through the furthest hangar where you're looking through the mesh of the door runners. Anyone know how to fix this? Is it just an object ordering problem? Probably. I've sent you a modified version off-list with separate objects for the door gantries. You can try reordering them. If you look very closely at Dave's screenshot you will see that the hangar that the gantry belongs to is visible through it. It is only the other hangar that becomes invisible through the gantry. So there is nothing wrong with the hangar model, and hence no need to separate the gantries. The problem comes from the ordering of the individual hangars. Sadly reordering the individual hangars wont do any good because you'd have the same situation if you looked at the forground hangar through one of the background hangar's gantries. :-( -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] John: Church Fenton hangars need fixing?
On Thursday 06 January 2005 18:43, Jon Stockill wrote: Dave Martin wrote: I've just tried out your objects - specifically the hangars at Church Fenton. I think they may need fixing .after a 450kt knife-edge low pass between them in the Hunter http://www.cyfinity.com/fgfs/lowpass.jpg (sorry couldn't resist) ;-) Seriously, the hangars look great - the door runners are very good in the flesh. This is the sort of building, also, which is semi-generic (at MOD and EX-MOD airfields) in the UK so it should help with populating more airfields. Yes, they do need fixing - I can see terrain through the furthest hangar where you're looking through the mesh of the door runners. Also, if it is supposed to be able to taxi inside the hangar then the roof should be double sided and the back of the doors should be properly textured. If not then the walls don't need to be double sided and there is no need for a floor. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
Curt, See this discussion between David M. and me about setting property values in source code vs. setting them in config files. http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/031882.html After this I removed all set serviceable property to true from instrumentation and systems source code. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
On Wednesday 05 January 2005 15:26, David Megginson wrote:
On Wed, 05 Jan 2005 08:01:49 -0600, Curtis L. Olson
[EMAIL PROTECTED] wrote:
So what's the solution? We can't initialize any number of arbitrary
serviceable properties in the preferences.xml and I've always been
nervous about doing htat anyway. If we also can't do it in code, then
were are we supposed to initialize these properties so that the
instruments will work?
One option is to initialize only if the property is not set. There's
no problem having a C++ fallback, as long as it does not override any
user-specified value.
Something like this in the init() method of instrumentation and systems does
just that:
serviceableNode = node-getChild(serviceable, 0, false);
if( !(serviceableNode) )
{
cout serviceableNode doesn't exist\n;
serviceableNode = node-getChild(serviceable, 0, true);
serviceableNode-setBoolValue(true);
}
As you can see it only creates the serviceable property and initializes it if
it does not already exist.
I think that similar kind of checking should be applied to other input
properties as well. For example the altimeter instrumentation module needs a
static pressure input, usually taken from the static port system module. If
the property that the altimeter wants to use does not exist, then the
altimeter should not create that property (this is the way it works now), it
should rather complain about it not existing and consequently initialize the
altimeter's serviceable property to false. This would also make life a bit
easier for instrumentation/systems config file writers. If they try to use
nonexistant properties it complains rather that silently create a new (dummy)
property.
I'll add this idea to my TODO list, unless someone else already is busy
solving this issue.
--
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
On Wednesday 05 January 2005 01:47, Jim Wilson wrote: Jon Stockill said: Jim Wilson wrote: gzip extracts pkzip files. [EMAIL PROTECTED]:~$ gunzip test.zip gunzip: test.zip: unknown suffix -- ignored No it doesn't gunzip -S .zip test.zip Yes it does ;-) [EMAIL PROTECTED]:~ gunzip -S .zip su27.zip gunzip: su27.zip has more than one entry -- unchanged No it doesn't ;-)) I'd guess that the aircraft archives would have more than one entry as well. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hi res KX-155 texture?
On Friday 31 December 2004 11:35, Dave Martin wrote: Just wondering if anyone has a high-resolution version of the KX-155 navcom radio texture? (the one from CVS is tiny) When creating instrument textures I've used vector drawing programs with great success. One big advantage is that you can create arbitrary resolution raster images from your vector sources. I've used metapost, Adobe Illustrator and OpenOffice.org Draw. I export to .eps files and then import them in my favorite image editor (gimp), and select resolution. Metapost is great for scales, while I would use OpenOffice.org Draw for the KX-155. By now you should understand that I'm hinting that you should create the texture yourself ;-) Also creating it yourself ensures that you have complete legal control. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Saturday 25 December 2004 04:48, Jim Wilson wrote: Those using blender, what exactly (if anything) needs to be done to the ac file after exporting it to ac format now? All the models that I've created in blender work without any modifications. I've also tried to let blender export to various other formats that plib can read, with varying success. I don't remember the details but colors were more or less wrong and axes were not as expected. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz andrunways.dat.gz
On Thursday 23 December 2004 02:48, Innis Cunningham wrote: Does this work with Atlas now?.The last time I went to build the maps using Atlas I had to get the old default.nav files to get Atlas to work. The navaids parsing in Atlas was fixed (CVS) very recently. I guess that now the airport parsing needs to be changed too. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XML alias for 3d animaton config (Was:One animation code for multiple engines)
On Thursday 23 December 2004 05:01, Ampere K. Hardraade wrote: When I am modelling airliners, I always put the engines in a seperated model file. This way, I can swap out the engines without touching the main model. My question is: what should I do in order to have one animation code that works for all engines? For example: I have one XML file for the engine; how can I make it so that the same script will work on engine 1, 2, 3, and 4, all with different N1 and N2? For the 2d panel config there is an alias feature that addresses the kind of problem you are describing here. The navcom radio 2d instruments use it all the time. It allows you to make _one_ xml config file for an instrument, and tie it to arbitrary properties when you include it in you 2d panel config file. Take a look at the number two navcom radios and the number two vor gauges in 2d panel configs. This feature is of course great for 2d instrument reuseability, and would be equally great for 3d model (instrument) reuseability. I tried this for 3d models, but it did not work as expected: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028549.html I don't think my questions were answered back then. So I ask again: Is if impossible to use aliases in 3d model configs, or did I just use it incorrectly? If it's impossible, can someone point me in the right direction as to where it is implemented for the 2d code so that I might take a stab at implementing it for 3d too? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Panel now hacked
On Sunday 19 December 2004 02:08, Dave Martin wrote: I've done most of what I intended with the 172P now except for the landing/taxi lights on the wing (I'm having to learn a lot to get something looking good). I wanted everything to 'just work' so I re-added the alpha-layers to the textures which were transparent (you could see the panel thru the wings, seats, tail etc). Also added back the flap textures so you now see the ribs. In doing the interior texture I discovered that due to the panel sharing a texture with the interior, adding the alpha back made the panel invisible. So, I duplicated the interior texture with no alpha and applied that to just the panel and then applied the second texture to the interior with the alpha - This works fine, now the controls do not show the instruments behind. However - this is a bit of a 'hack' - is it acceptable? I guess that it's acceptable for now, but the proper thing to do would be to rearrange the object hierarchy so that they get drawn in the right order. I tried to do this, but it seems that you can not reference the included 2d panel by it's name tag. When you start up with the default C172 you get a warning that PanelInstruments and ControlsGroup objects are not found. PanelInstruments is of course the 2d panel, but when it's later used to group objects together it can not be found. Maybe it's time to make 3d instruments for the C172 instead of using the 2d panel hack? Also, I've reworked the panel instrument locations and controls so they are now proportionally correct compared to a real 172. Looking forward to try it out ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT:New autoreplay on the user list
When I posted on the user list I got an automatic replay from Mark Pate today. Are anyone else getting this too? BTW: I'm still getting replays from [EMAIL PROTECTED] when posting on the user list. Curt, could you remove this user from the list? It does not seem like he is following the discussions. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My 172P work for appraisal
On Sunday 19 December 2004 22:32, Dave Martin wrote: Also of note; the panel being too far out means that I've totally mucked up my geometries :-S Oh well, my own fault ;) Note that I'm talking about the 2d instrument panel that is included, _not_ the panel in the 3d model. It should be quite easy to get the x-coordinate right for the 2d instrument panel. Simply set it to the same as the x-coordinate for any vertex on the panel face. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..there _is_ Glut to be had off cvs or tarballs somewhere???
On Wednesday 15 December 2004 11:53, Arnt Karlsen wrote: Hi, ..as I'd like to try cvs FG remotely across my lan, I fired up an old 2xPIII-550 on Quantian-0.6.9.2 (clusterKnoppix derivative) off a ro dvd-image. /usr/local was copied and mounted --bind onto a disk, and the cvs dance thru cvs co ;autoconf ; ./configure ;make ;make install had plib, OpenAL and SimGear all home in /usr/local, on FG, make _stops_: [EMAIL PROTECTED] make Making all in tests make[1]: Entering directory `/mnt/sda2/local/src/FlightGear-0.9/source/tests' if gcc -DHAVE_CONFIG_H -I. -I. -I../src/Include -I/usr/local/include -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo \ -c -o est-epsilon.o `test -f 'est-epsilon.c' || echo './'`est-epsilon.c; \ then mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po; \ else rm -f .deps/est-epsilon.Tpo; exit 1; \ fi est-epsilon.c:13:19: GL/glut.h: No such file or directory ..this ofcourse means I don't have glut set up properly on this old server box running This means I need Glut off cvs or tarballs or somesuch, but from where??? Are you 100% sure that you don't have glut? I thought that plib and/or SimGear also needed glut. I guess that the configure script should also check if glut was present. http://freeglut.sourceforge.net/ or http://www.opengl.org/resources/libraries/glut.html -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530
On Tuesday 23 November 2004 14:54, Boris Koenig wrote: Well thanks for the pointer, I am going to contact Garmin yet another time anyway: Another FlightGear user informed me yesterday that there IS already an application that interfaces the original (software) simulator unit with MS FS 200x - this seems to be based on FSUIPC and is called FSGarmin. Indeed, said company did even SELL the interface for about $ 40 US, until they went out of business about 2 yrs ago (?) But before they went out of business they made their software freely available - there's also a support forum for that software at: http://forums.avsim.net/dcboard.php?az=show_topicsforum=178 What surprised me is that Garmin didn't seem to know about the project. So I will gather more information why Mr. Stone didn't mention said project ... This supports rumours that I could find on the web about Micro$oft swallowing the company ... after all they also support some garmin GPS devices ;-) Even more interesting: FSAvionics.com (SimSystems) did even provide an interface for X-Plane some time ago, so depending whether we will be able to get in touch with the original developers it might be interesting to learn about ways to revamp the interface to work with FG. - Boris Any news on this, Boris? I know that Honeywell (Bendix/King) also have demo software of some of their GPS devices. Perhaps they are more willing to cooperate. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 09:05, Chris Metzler wrote: Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), There is no electrical output to power the nav radio. Apply this patch to fix it: Index: c310-electrical.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c310/c310-electrical.xml,v retrieving revision 1.8 diff -p -u -r1.8 c310-electrical.xml --- c310-electrical.xml 22 Apr 2004 14:54:34 - 1.8 +++ c310-electrical.xml 12 Dec 2004 10:53:03 - @@ -144,6 +144,11 @@ prop/systems/electrical/outputs/gps/prop /output + output +nameNav Radio Power/name +prop/systems/electrical/outputs/nav/prop + /output + !-- connect in power sources -- connector @@ -317,4 +322,12 @@ /switch /connector + connector +inputBus Bar/input +outputNav Radio Power/output +switch + prop/controls/circuit-breakers/nav/prop +/switch + /connector + /PropertyList What puzzles me is that there was never a navcom output in the c310 electrical config, so how did it work before?? the pa28-161, I tried the pa28-161 and it seemed to work fine. and the beech99. The same problem as for the c310. The same patch can be applied to the beech99-electrical.xml file. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, turn, airspeed, ai) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 12:22, Roy Vegard Ovesen wrote: On Sunday 12 December 2004 09:05, Chris Metzler wrote: Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), There is no electrical output to power the nav radio. Apply this patch to fix it: Index: c310-electrical.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c310/c310-electrical.xml,v retrieving revision 1.8 diff -p -u -r1.8 c310-electrical.xml --- c310-electrical.xml 22 Apr 2004 14:54:34 - 1.8 +++ c310-electrical.xml 12 Dec 2004 10:53:03 - @@ -144,6 +144,11 @@ prop/systems/electrical/outputs/gps/prop /output + output +nameNav Radio Power/name +prop/systems/electrical/outputs/nav/prop + /output + !-- connect in power sources -- connector @@ -317,4 +322,12 @@ /switch /connector + connector +inputBus Bar/input +outputNav Radio Power/output +switch + prop/controls/circuit-breakers/nav/prop +/switch + /connector + /PropertyList What puzzles me is that there was never a navcom output in the c310 electrical config, so how did it work before?? the pa28-161, I tried the pa28-161 and it seemed to work fine. and the beech99. The same problem as for the c310. The same patch can be applied to the beech99-electrical.xml file. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, turn, airspeed, ai) Someone might want to commit these patches to CVS. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
On Sunday 12 December 2004 04:33, Arnt Karlsen wrote: ..naaah, just a coupla big drinks. Unless you goofed or changed the scenery path syntax recently, I tried various variants of this: fgfs --geometry=1280x1024--fov=75--httpd= --telnet=23 \ --start-date-lat=2004:12:11:12:00:00--airport=ENZV --runway=36 \ --fg-scenery=:/mnt/hdc5/FlightGearScenery/pub/fgfs/Scenery-0.9.5 \ --prop:draw-fps=1 ..no scenery at ENZV, KOSH or KSFO, and I do have the whole 0.9.5 planet. Nor could I get the fps from the command line, I had to use the menus in either the gui or the web server. The draw-fps property is supposed to be located in /sim/hud/, so your command line should read: --prop:/sim/hud/draw-fps=1 -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NAV radios still borked on three a/c
On Sunday 12 December 2004 14:02, Melchior FRANZ wrote: Thanks! We do not forget over those minor complaints how valuable and well done your instrument reorganization is! :-) Such words warm my heart, and give me inspiration, thanks! I welcome every minor and major complaint. They help us improve FlightGear. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 13:32, Chris Metzler wrote: I tried the pa28-161 and it seemed to work fine. Really? I just checked it again, and both NAV1 and NAV2 are dead for me. I'm running CVS, current as of last night. First thing to note is that both gauges of the pa28-161 are connected to the same nav radio. So they will always display the same values. And since they are 3d models, you can't click them with the mouse to change the OBS. You have to use the Radio settings dialog from the Equipment menu. Try to browse the property tree to /instrumentation/nav/radials. If the values here seem correct then at least the module (the c++ code) is working and is serviceable. If not then either the serviceable property is not set or the navradio does not get power. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV1 and NAV2 borked in CVS
On Saturday 04 December 2004 11:08, Chris Metzler wrote: NAV1 and NAV2 are broken in CVS, apparently independent of choice of aircraft. I've tried them on the c172, c310, and 737; Melchior checked the last two and found the same thing. Doesn't matter what frequency/radial you set or your distance from the transmitter -- the display is dead. Yes, that is because of the recent migration to /instrumentation from /radios. I forgot to update the generic instrumentation config and the generic electrical config. I sent the new files to Curt last night, so I hope they will be in CVS soon. In the mean time here are the diffs: Index: generic-electrical.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Generic/generic-electrical.xml,v retrieving revision 1.7 diff -p -u -r1.7 generic-electrical.xml --- generic-electrical.xml 2 Apr 2004 16:22:55 - 1.7 +++ generic-electrical.xml 4 Dec 2004 11:00:39 - @@ -45,10 +45,10 @@ prop/systems/electrical/outputs/gps-mfd/prop prop/systems/electrical/outputs/gps/prop prop/systems/electrical/outputs/hsi/prop -prop/systems/electrical/outputs/navcom[0]/prop +prop/systems/electrical/outputs/nav[0]/prop prop/systems/electrical/outputs/dme/prop prop/systems/electrical/outputs/audio-panel[0]/prop -prop/systems/electrical/outputs/navcom[1]/prop +prop/systems/electrical/outputs/nav[1]/prop prop/systems/electrical/outputs/audio-panel[1]/prop prop/systems/electrical/outputs/transponder/prop prop/systems/electrical/outputs/autopilot/prop Index: generic-instrumentation.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Generic/generic-instrumentation.xml,v retrieving revision 1.3 diff -p -u -r1.3 generic-instrumentation.xml --- generic-instrumentation.xml 19 Nov 2004 23:05:07 - 1.3 +++ generic-instrumentation.xml 4 Dec 2004 11:00:39 - @@ -92,10 +92,15 @@ file, these values will be used (they ar /magnetic-compass nav-radio -namenav-radio/name +namenav/name number0/number /nav-radio + nav-radio +namenav/name +number1/number + /nav-radio + slip-skid-ball nameslip-skid-ball/name number0/number -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NAV1 and NAV2 borked in CVS
On Saturday 04 December 2004 12:13, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Saturday 04 December 2004 12:02: I forgot to update the generic instrumentation config and the generic electrical config. There are also *numerous* occurrences of radios/ in *.nas files and in *.xml files, where they weren't precedeced by a slash and thus weren't replaced by the find/perl command line. You're right, thanks! Curt, here's more work for you, or anyone else with CVS submit privileges. The general idea is that every occurrence of radios/ should be replaced by instrumentation/. Use the find/perl command line in the CVS log message as a starting point. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 01:16, Alex Perry wrote:
From: Boris Koenig [EMAIL PROTECTED]
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family, friends, and
neighbours for wearing one.
LOL, that would indeed be very amusing ... must probably look very
similar to the BORG on Star Trek ;-)
There are two different things here.
Normally, for gaming, people want to keep their head stationary
(in linear dimensions) and look in different directions (angular).
What people are talking about here is wanting to keep their
direction of gaze (fixed object) but change their point of view.
The former is easily addressed with a simple magnetic compass module,
to figure out which way you're looking, and a head mount display so
that the screen is always located in the correct direction (in front).
The compass module is usually integrated into the HMD and so not really
a source of looking 'odd', at least compared to the HMD unit itself.
However, the compass module doesn't work when the user wants to be able
to move their head and still look in the same direction. For example,
to lean forward in order to read the tiny little numbers on the altimeter.
For that, you need to track the position of the head, not direction,
so you really want a different kind of sensor to address that need.
You don't need a HMD either, since the instrument panel doesn't move.
There are sensors for this, for example by putting ultrasonic ranging
transducers on your head and on the four corners of the monitor,
but nothing I'd really recommend to you as being a marvellous solution.
Assuming there is a network socket that is providing the 3D position
of the nose (for example) of the user with respect to the monitor,
how hard is it to get FGFS to slew the camera/viewport relationship ?
The properties for the camera/viewport
are: /sim/current-view/{x,y,z}-offset-m. So it should be quite easy.
I've attached a patch to mice.xml that lets you move the camera/viewport with
the middle mouse button pressed in mouse view mode. Useful for looking at the
compass head on.
--
Roy Vegard Ovesen
Index: mice.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/mice.xml,v
retrieving revision 1.16
diff -p -u -r1.16 mice.xml
--- mice.xml 24 Jun 2004 14:45:48 - 1.16
+++ mice.xml 23 Nov 2004 12:33:33 -
@@ -208,7 +208,7 @@ current mode for each mouse is held in t
!-- Mouse left/right motion --
x-axis
-!-- No buttons pressed: move the view position left or right --
+!-- No buttons pressed: rotate the view left or right --
binding
condition
and
@@ -228,6 +228,25 @@ current mode for each mouse is held in t
wrap type=booltrue/wrap
/binding
+
+!-- Middle button pressed: move the view position left or right --
+binding
+ condition
+ and
+ not
+property/devices/status/mice/mouse[0]/button[0]/property
+ /not
+ property/devices/status/mice/mouse[0]/button[1]/property
+ /and
+ /condition
+ commandproperty-adjust/command
+ property/sim/current-view/x-offset-m/property
+ factor type=double1/factor
+ min type=double-0.5/min
+ max type=double0.5/max
+ wrap type=boolfalse/wrap
+/binding
+
/x-axis
!-- Mouse up/down motion --
@@ -252,6 +271,25 @@ current mode for each mouse is held in t
max type=double90/max
wrap type=boolfalse/wrap
/binding
+
+!-- Middle button pressed: move the view up and down --
+binding
+ condition
+ and
+ not
+property/devices/status/mice/mouse[0]/button[0]/property
+ /not
+property/devices/status/mice/mouse[0]/button[1]/property
+ /and
+ /condition
+ commandproperty-adjust/command
+ property/sim/current-view/y-offset-m/property
+ factor type=double-1/factor
+ min type=double-0.5/min
+ max type=double0.5/max
+ wrap type=boolfalse/wrap
+/binding
+
/y-axis
/mode
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 14:18, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Tuesday 23 November 2004 13:41: I've attached a patch to mice.xml that lets you move the camera/viewport with the middle mouse button pressed in mouse view mode. Useful for looking at the compass head on. Very cool. There are two problems, though: I can move my 'head' down very far (below the bo105's floor), but I can hardly move it up. And the possibility to restore the original position on middle mouse click is lost. (I tend to keep that patch applied anyway. :-) I only tested it in the default cessna where max and min limits of 0.5 meters from the origin seemed reasonable, you can imagine what happened when I tried the A320 where the initial y-offset is way above 0.5 meters :-(. Perhaps the movement limits should be aircraft specific, any volunteers ;-) Restoring the original position with the _middle_ button? I'm only familiar with restoring the orientation with the _left_ button. I guess that it would be possible to also restore the position with the left button, but I think that restoring the orientation only is actually quite usefull. I've also noticed that the position sometimes jumps to it's min or max position, this seem to happen when the cursor wraps from from one edge of the screen to the opposite. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 16:30, Melchior FRANZ wrote: Should have tried the FA-18A. Completely unusable there. You immediately end up between the pilot's legs and there's no way to get back up. But can go further down and watch the scenery through the open front wheel bay. Resetting fgfs doesn't help either. But once fixed this feature will be very useful. Yes, that's what happened in the Airbus too, and it should also happen to any large aircraft. You can easily fix this by making the min and max values in mice.xml greater. I set them to -10 and 10 meters respectively for both x and y axes, I guess that should be enough for most aircraft. Setting these limits to reasonable values (inside the cockpit) for every aircraft would be, as you can imagine, quite a labourous job. Maybe someone over on the users list would be willing to have a go at it? Every so often I see users that ask how to contribute. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo (was: Re: Magnetic Compass)
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the /sim/current-view/{x,y,z}-offset-m properties.
You can apply the patch to $FG_ROOT/mice.xml attached to this posting.
http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/032316.html
What exactly would it make so
complex ?
Actually it is not complex at all, assuming that it is possible to configure
the mouse bindings individually for every aircraft. Then it would simply be a
matter of
* Run FlightGear
* Change the /sim/current-view/{x,y,z}-offset-m properties to find reasonable
values for the limits that the view should be allowed to move.
* Add a mouse binding to the aircraft *-set.xml (I assume) file with the found
min and max values.
* Repeat for every aircraft model. ;-)
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote: No, I take that back. Mouse properties are (like kbd * js bindings) fixed at the beginning. min/max can't easily be changed afterwards, and I don't feel like re-writing the whole input module. Better set the default to +/- 5m. You can include only the required axis bindings in your aircraft *-set.xml file, like this (for the default cessna): input mice mouse n=0 !-- Mode 2: view mode -- mode n=2 !-- Mouse left/right motion -- x-axis !-- No buttons pressed: rotate the view left or right -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not not property/devices/status/mice/mouse[0]/button[1]/property /not /and /condition commandproperty-adjust/command property/sim/current-view/heading-offset-deg/property factor type=double-360/factor min type=double0/min max type=double360/max wrap type=booltrue/wrap /binding !-- Middle button pressed: move the view position left or right -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not property/devices/status/mice/mouse[0]/button[1]/property /and /condition commandproperty-adjust/command property/sim/current-view/x-offset-m/property factor type=double0.75/factor min type=double-0.5/min max type=double0.5/max wrap type=boolfalse/wrap /binding /x-axis !-- Mouse up/down motion -- y-axis !-- No buttons pressed: tilt the view up and down -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not not property/devices/status/mice/mouse[0]/button[1]/property /not /and /condition commandproperty-adjust/command property/sim/current-view/pitch-offset-deg/property factor type=double-180/factor min type=double-90/min max type=double90/max wrap type=boolfalse/wrap /binding !-- Middle button pressed: move the view up and down -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not property/devices/status/mice/mouse[0]/button[1]/property /and /condition commandproperty-adjust/command property/sim/current-view/y-offset-m/property factor type=double-0.75/factor min type=double-0.4/min max type=double0.4/max wrap type=boolfalse/wrap /binding /y-axis /mode /mouse /mice /input This will override the settings in mice.xml, but it will only override the settings that are defined here, so all the existing modes in mice.xml are used. As I said earlier it will be a lot of work to do this to every aircraft model. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo
On Tuesday 23 November 2004 19:46, Boris Koenig wrote: I think it was Melchior who mentioned that the min/max values are specific to certain aircrafts or rather cockpits ? Taking into consideration that the a3c files are plain text and hence readable for simple shell scripting, I wonder now whether suitable min/max values can be derived from any *general* data that's preferably available in most *.ac files: that way one could use a shell script: - read in the corresponding data - determine suitable min/max values - automatically put the binding stuff into *-set.xml Again: I don't know anything about cockpit design or 3D design in general, I would simply *guess* that it should be possible to determine the dimensions of a cockpit based on the *.ac file ... The object names inside the *.ac files could be anything, so I guess it would be very hard to determine what objects and also what vertices that is supposed to be the cockpit. I think that a better approach is to look at the default position of the viewpoint. This is defined in the *-set.xml file like this: !-- position the pilot viewpoint and angle -- view internal archive=ytrue/internal config x-offset-m archive=y-0.18/x-offset-m y-offset-m archive=y0.30/y-offset-m z-offset-m archive=y0.36/z-offset-m pitch-offset-deg-12/pitch-offset-deg /config /view Now if we assume that a pilot is able to move his head say 0.5 meters in every direction, we simply add and subtract 0.5 to the default position, and there you have your limits. Of course you could argue that a pilot with his/her but on the seat is not able to move her/his head very much it the up direction. Maybe I am making things too simple, though ;-) Or too hard ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 19:55, Melchior FRANZ wrote: Sure, but that's yet another ugly hack. I'd prefer a *solution*. I don't use a standard mice.xml, and I would really hate if every aircraft designer messes with mouse settings and overwrites my stuff. What's next? Aircrafts overwriting my carefully chosen joystick settings? No wait, that's already done in (the otherwise beautifully) b1900d ... I really thought that overriding defaults from preferences.xml was a good solution. *-set.xml is used to override all kinds of other stuff, including keyboard and joystick settings, so why not override mouse settings too!? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
On Thursday 18 November 2004 01:33, Boris Koenig wrote: sure, right - but putting nasal scripts into module tags like in other PropertyList encoded XML files isn't yet supported natively. Also, I don't think Vance wanted to link the Nasal script to a particular action ? I don't want to lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
On Thursday 18 November 2004 00:06, Vance Souders wrote: I'm working on a new cockpit for the T6; the T6's altimeter displays barometric pressure in both inches HG and MB. I want to add a small amount of script that converts from the HG reading in the property tree to MB for the gauge (I need this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Yes you can put nasal scripts in the action tags of the gauge's xml file: action ... commandnasal/command script![CDATA[ # Your nasal script for converting from InHG to mBar. ]] /script /binding /action -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digital fonts
On Tuesday 16 November 2004 14:07, Innis Cunningham wrote: Hi All Does anyone know were I might be able to find digital number fonts for making instruments that require digital type numbers.I don't seem to have anything in my font library that will do digital. If you by digital fonts mean seven-segment fonts like the ones on digital wristwatches that looks something like this: _ |_| |_| Then the led font used for the radio instruments would be my best bet. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Beech 99
On Wednesday 10 November 2004 11:08, Antonio Pennino wrote: please verify the brakes and the dimension and visual definition of the cockpit at the 800x600 resolution. Wheel brakes are working as expected. The BRAKES indicator on the panel is not working. I think you should remove the ADF radio panel, since there is no instrument to display the adf bearing. Alternatively add an adf bearing indicator. Also (if you are using the latest CVS version) I think you should consider to add a second airspeed indicator and turn indicator module. I see that those two instruments are visible from the copilot's panel. Now, I'm guessing that the the airspeed indicator on both sides are tied to the same property, so both fail at the same time. If you add a second airspeed indicator module, you can make the two airspeed indicators independent of eachother. This also applies to the turn indicator. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Beech 99
On Wednesday 10 November 2004 13:01, Antonio Pennino wrote: I think you should remove the ADF radio panel, since there is no instrument to display the adf bearing. Alternatively add an adf bearing indicator. I use the 0.9.6 win32 binary. How i make it? This question forces me to rethink my previous assumption that you were the maintainer of the Beach 99. If you know nothing about panels, a good place to start would be README.xmlpanel in the Docs directory. It is also very helpful to look at existing panel configurations. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apr mode
On Wednesday 10 November 2004 15:09, Amit Gulati wrote: Does the autopilot apr mode work in version 0.9.6? If yes, then using which aircrafts? If you are talking about the thin autopilot panel with buttons for WL, HDG, NAV, APR, ALT, then no! This instrument used to be tied to the old hardcoded autopilot that was rewritten almost a year ago now. If you are talking about the autopilot GUI dialog available from the Autopilot menu, then no, again! :-( There is no explicit APR mode in the autopilot dialog, but you could activate the NAV1 CDI Course and the NAV1 Glideslope. Infortunetly the NAV1 CDI Course mode does not seem to work. The autopilot dialog is tied to the generic autopilot configuration that is available in all aircraft, unless they use a custom autopilot configuration. Since there are so many different aircraft in FligtGear it is close to impossible to design a generic autopilot that would work for all aircraft. Please try the autopilot in the default Cessna, it should have a working apr mode. But you have to know how to use it. A link to the pilot's guide was posted on the user list very recently. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Migration from cockpit to instrumentation
I'm migrating stuff from the cockpit directory to the instrumentation directory. Specifically I'm migration the stuff in the radio stack. My question is this: should I also move the properties from /radios/* to /instrumentation/*? I think this is a good idea, because - The adf and dme in the instrumentation directory have their properties in /instrumentation, and they are radios. - The stuff in the radio stack (navcom, kt70 transponder, market beacon and another older dme) have properties in both /radios and /instrumentation. The serviceable property is in /instrumentation. The downside is of course that all the radio instrument panels will be broken, but this can easily be fixed with a quick grep through the data/Aircrafts directory. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Monday 08 November 2004 00:22, David Megginson wrote: If the source code modules force the property to true, it will override any settings provided by the user at startup or in a configuration file. I see. It needs to be possible to start FlightGear with the mag compass U/S for some scenarios, just as we can start with the vacuum pump or alternator U/S. Yes, that makes sense. Making the compass serviceable should be part of that. If the setting is in preferences.xml (or a separate startup config file), it can be overridden on the command line; if it is hard-coded in the C++, it will be set after the options have been read, and cannot be overridden. I thought (or rather hoped) that preferences.xml, *-set.xml or command line would set properties after the source code did. IIRC I added this to most instrumentation modules and system modules, so that has to be removed then. I still feel that the setting of the serviceable property for instrumentation and systems should be removed from preferences.xml into the *-set.xml files. Consider the cub for example when it gets it's own instrumentation and systems configuration files, most likely the adf, dme, gps, dg, vsi, vacuum system, and probably more would be removed. Having preferences.xml set the serviceable property would then lead to cluttering of the property tree with lots of subdirs that would only contain the serviceable property. I assume that such cluttering is undesirable, or else my argument would fall apart ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
On Thursday 04 November 2004 12:21, Martin Spott wrote: Hello, with the default c172 I see this error: Reading autopilot configuration from /home/mas/CVS/FlightGear/data/Aircraft/c172p/Systems/KAP140.xml Unknown top level section: filter Detected an internal inconsistancy in the autopilot configuration. See earlier errors for details. Do you have the latest CVS? Filters were added to xmlauto.*xx mid October: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008703.html The KAP140 autopilot was updated a couple of days later: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008753.html So if you have a recent build it should recognize the filter tag in autopilot configurations. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
On Thursday 04 November 2004 15:21, Martin Spott wrote: Roy Vegard Ovesen wrote: Do you have the latest CVS? Filters were added to xmlauto.*xx mid October: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008 703.html That's it. I already removed anything with '*kap140*' in the filename and pulled a fresh version from CVS. After I did the same with the 'xmlauto*' files as well I managed to build a binary that doesn't crash. So... problem solved, or? Thanks, Martin. P.S.: I always find it interesting that it is not sufficient to maintain a source tree with 'cvs update' I have used 'cvs -z3 up -dPA' with great success when I update. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: autopilot error ?
On Thursday 04 November 2004 17:12, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Thursday 04 November 2004 16:53: I have used 'cvs -z3 up -dPA' with great success when I update. ... and I still hope that when people write things like that, they actually mean, that they created a ~/.cvsrc file and put the options there $ cat ~/.cvsrc cvs -z3 -q diff -up update -dP checkout -P rdiff -u and then really only use $ cvs up or, in this case $ cvs up -A m. :-} Now I do, thanks! :-] -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
On Wednesday 27 October 2004 04:08, David Culp wrote: My submodel config file is not getting read at startup (I'm getting file not found). Are you getting file not found or No systems model specified for this model!? Is anyone using CVS FlightGear and Linux having this problem also? Thought I'd check before I go over the config file for the fiftieth time looking for an error. Are you using the generic config or a custom made? If you are using a custom config, you must remember to override the generic one by including it in your aircraft *-set.xml file. like this: sim ... systems pathpath/to/your/file/path /systems ... sim -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
On Wednesday 27 October 2004 15:09, David Culp wrote: The submodel system has been moved away from the Systems code. It's now an independent subsystem of FG. Silly me! I must have confused submodels with systems. I thought you where talking about systems. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument/Panel Design (zooming instruments)
On Tuesday 26 October 2004 10:23, Boris Koenig wrote: Particularly, I wanted to optionally make certain instruments zoom when I either move the mouse over a specific region or upon clicking on a hotspot region. Simply because it's partially kind of hard to really READ the instruments/panel - that way I might not have such a bad time when trying to actually hit a hotspot ;-) I often use x/X to zoom in on the instruments/panel. This of course is only possible in the 3D cockpits. So, being able to optionally make instruments or panels zoom in would also increase the potential instrument density for the whole panel, while everything would still be comfortable to use ... If there is a way to zoom in on a certain event I'd like to get some pointers or even examples :-) I'm sure you could change the field of view (zoom) with a nasal script upon clicking a hotspot. Again, only for 3D cockpits. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Saturday 23 October 2004 21:14, Vivian Meazza wrote: I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found I also get these now and then. No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. However, it was before I updated. Checking, I find that /sim/systems/path contains 'Aircraft/Generic/generic-systems.xml' (unspecified). Correct, but should this be a string type? You could try to explicitly specify it as a string type: path type=stringAircraft/Generic/generic-systems.xml/path in preferences.xml. Are you absolutely 100% sure that '/Flightgear-cvs/data/Aircraft/Generic/generic-systems.xml' exists? A quick cout check in systems_mgr.cxx shows that path_n = 0, so there's the problem. Possibly a problem in simgear/misc/sg_path.hxx? Unlikely, that hasn't been changed in months. The autopilot uses the exact same coding technique (that's where I copied and pasted from). And the autopilot does not explicitly set the type to string, so I have little hopes for my tip :-( So, it's not a duh yet :-). Any advice on what to check next? Can any other Cygwin user confirm my findings, or tell me what they have done differently? You could try to insert a cout in xmlauto.cxx, in the init method of FGXMLAutopilot, at least to confirm that path_n != 0 there. Maybe '/sim/systems/path' does not exist in the property tree when instr_mgr is trying to read it. You could try to set this property in the command line, I forget how to, but I'm sure you'll figure it out. Try to step through the code with a debugger. IIRC 'insight' should be available on Cygwin. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 12:03, Vivian Meazza wrote: I have checked the path - I'm was the downloaded cvs data from 1522 Monday. I have re-downloaded cvs data and source this morning and recompiled. I've changed the hunter to use the generic files - it already has custom electrics and instrumentation - still the altimeter, ASI, climb-rate and turn and slip don't work. Hsi and directional gyro work, but they take their input from the 'wrong' place. In the property browser all the instrument values are undefined. The P51d instruments also don't work, in fact all the instruments I have tested don't work. I suspect the instruments generically don't work. Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? And did you change anything in the hunter files? I also updated from CVS this morning and all instruments still work, here. I guess that if all instruments and all systems in every aircraft were broken then a whole lot of other people would have noticed too. I have not changed anything in the hunter or any other aircraft. Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: No instrumentation model specified for this model! or Failed to load instrumentation model: , then something is wrong, obviously. When Flightgear is running try to browse to this property: /sim/instrumentation/path It should contain data/Aircraft/Generic/generic-instrumentation.xml if you are using the generic configuration, or if you are using a custom made configuration it should of course contain the path to that file. I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 15:09, Vivian Meazza wrote: Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: No instrumentation model specified for this model! or Failed to load instrumentation model: , then something is wrong, obviously. What is likely to be wrong? If you get No instrumentation ... then FG is not parsing the instrument configuration file at all. If you get Failed to load ... then parsing has failed. I think that one of these two might be the reason for your problems. Either the config files never get parsed, or parsing of them fails. I would try to use a debugger to step through the code to see exactly what is happening. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 09:47, Vivian Meazza wrote: What instruments are not working, and what inputs do they use? Hunter/Seahawk: Altimeter, IAS, Mach, rate-of-climb, and turn-and-slip When I checked the Hunter and Seahawk last night all these instruments worked. IIRC the Mach instrument is driven from velocities/mach, so it would _not_ be affected by the changes that I've made. Have you updated the base package? It includes changes to preferences.xml and the two generic systems and instrumentation configurations Spitfire: All of the above plus clock, attitude, and heading. Unfortunately I'm not familiar with the startup procedure of the Spitfire, so I haven't tried it. But again it looks like you forgot to update the base package. There is no vacuum system on these aircraft. However, I suppose we could try to drive one off N1. Are gyros driven by electrical engines then? If so it should be trivial to add a new instrumentation class where the gyro might be driven by an electrical engine. Some months ago I played around with a new gyro class that is driven from an arbitrary torque and uses air friction to slow it down. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 19:42, Vivian Meazza wrote: It's not obviously a path problem. My preferences.xml file was updated at 15:22 yesterday, and has the right paths to the new generic files. However, the properties relating to instruments are empty - hence broken instruments :-). But if they work for you, the problem must be local, so I'll keep looking. Since it's all the instruments the common factor is the electrical supply, so I'll start there. I would suggest that you try to create custom systems and instrumentation configuration files for your aircraft. Use the generic ones as a start. I think that you should remove the GPS instrument ;-) and maybe the nav radios. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). As a major user and part-author of the submodel system, I have no objections, A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. On Wednesday 08 September 2004 01:11, David Culp wrote: David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? Sounds OK to me. Dave I'm not that an experienced programmer, so I am wondering if the vector of submodels approach has superior preformace compared to my approach. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 00:10, Vivian Meazza wrote: OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? What instruments are not working, and what inputs do they use? I just tried the Hunter, and I noticed that some of the instrumentation properties where not as expected. They are all ok in the c172. I will look into this. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 01:00, Roy Vegard Ovesen wrote: On Tuesday 19 October 2004 00:10, Vivian Meazza wrote: OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? What instruments are not working, and what inputs do they use? I just tried the Hunter, and I noticed that some of the instrumentation properties where not as expected. They are all ok in the c172. I will look into this. I see that for the Hunter and the Seahawk the vacuum system is not working which leads to the attitude-indicator and the heading-indicator also not working. This is because the engines/engine[0]/rpm property is undefined for the engine on these aircraft. I would guess that this was also the case before systems and instrumentation became configureable. Back then the vacuum system was hardcoded to be driven by engines/engine[0]/rpm. Now that the vacuum system is configurable you might consider driving it with another property from engines/engine[0]/, so that you can use the instrumentation/attitude-indicator and instrumentation/heading-indicator insted of orientation/*. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiple instruments and systems, and configuration of these
This is now in CVS. I would like to encourage aircraft maintainers to take a look at the two generic configurations in Aircraft/Generic/, and add/remove systems and instrumentation to their aircraft. Override the generic configurations in the same way as you overrice the generic autopilot: Add these tags to your *-set.xml file systems pathpath/to/your/systems.xml/path /systems instrumentation pathpath/to/your/instrumentation.xml/path /instrumentation -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Submodels
Hi all! I've not touched the new submodel.*xx sources yet because I want your opinion on how I should implement it into the other configurable systems. The existing configurable systems are the pitot, static, and vacuum systems. These are configured in one configuration file defaulting to Aircraft/Generic/generic-systems.xml. I would like to include the configuration of submodels in this file also, since submodels might be classified as systems. The submodel is coded somewhat differently from the other systems (pitot, static and vacuum). The submodel class uses a vector of submodels to create several submodels. The other systems only have one system in it's class. The system manager (system_mgr.*xx) creates object instances of the system classes. So for the submodel one object instance is created and it contains all submodels, and for the others zero or more object instances are created. I am inclined to modify submodel.*xx to behave like the other systems, and to move the configuration of them from a separate file and into the systems configuration file. I can think of a few good reasons for doing this: * It makes sense to use the same philosophy for the systems. The instrumentation also uses this philosophy. * Fewer configuration files. * The submodels will become independent so you could for example make one not serviceable (jammed guns). If nobody has any objections I will of course go ahead and implement these changes as I have described. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Digital filters
Hi all! I've added some digital low-pass filters to the autopilot code. You can now define four different types of digital filters inside the autopilot configuration file. The outputs from these filters could then be used as inputs to PID controllers. I've sent a readme file to Erik that explains how to configure the filters. Hopefully it will be in CVS soon. I've also removed the hardcoded filtering of the helper value: /autopilot/internal/pressure-rate. I know that the KAP140 uses this helper value, so it might affect the pitch axis performance of the default c172 autopilot. A quick grep in the Aircrafts directory showed that nothing else uses pressure-rate. If anyone else uses pressure-rate locally... well you have been warned. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
On Thursday 30 September 2004 04:22 am, Lee Elliott wrote: The problem with my joystick seems to be related to the recent plib updates and it isn't being identified properly within FG. jstest jscal identify it ok but neither FG or js_demo see it properly. This was something that a few people wrote about recently but I'd like to confirm that other people are still having the same problem on Linux with the latest cvs versions of plib, SimGear and FlightGear. I also had this problem. My joystick was identifies as by Flightgear and js_demo. I found out that plib was using jsLinuxOld.cxx instead of jsLinux.cxx. To solve this I defined JS_NEW in js.h like this: #define JS_NEW 1 just below JS_TRUE and JS_FALSE. And rebuilt plib. A proper solution I guess would be to figure out why JS_NEW isn't defined by the configure script. I grep'ed the entire plib dir, but IIRC JS_NEW was only found in jsLinux.cxx and jsLinuxOld.cxx. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG users discussion on AVSIM.COM
On Saturday 25 September 2004 10:50 am, Boris Koenig wrote: does the python script for blender - ac3d meanwhile support removing the (unrecognized) 'crease' statement, or is plib patched to ignore it ? It never puts the crease statement in the *.ac file, so there is nothing to remove :-) I guess the script is based on the previous version (3) of ac3d that does not use the crease statement. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:00:09 +0200, skrev Roy Vegard Ovesen [EMAIL PROTECTED]: I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:02:34 -0500, skrev David Culp [EMAIL PROTECTED]: I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. Thanks Roy, it works better now, but still not enough to prevent crashing. It looks like I'll still need an external monitor to clamp the pitch angle. For instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, I need to keep the airplane from going straight down. 50 kts is quite a large change in reference, if you could change it gradually from 250 to 300, I'm sure that would be safer. It is not uncommon, in the process control world, to only let the reference change as a ramp. A gradual change at some appropriate rate, instead of a sudden change. If you feel that you absolutely have to control the pitch angle, I would suggest that you go for a cascade configuration. One controller to control pitch angle using the elevator and one to control airspeed using the (controlled) pitch angle. Now you can easily limit the pitch angle. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiple instruments and systems, and configuration of these
På Tue, 07 Sep 2004 00:22:12 +0200, skrev Roy Vegard Ovesen [EMAIL PROTECTED]: I've implemented this now, but because of the pendig new release it will not be put in CVS until after the release. I have a link to the changes if anyone is interested in trying. Not much to try really, it should be exactly as before, but you can add more instrument and system instances. Or remove some that should not be in your favourite aircraft. http://home.tiscali.no/rvovesen/instrSyst.tar.bz2 I've modified the Makefile.am files so I guess you have to rerun autogen.sh, at least in the Systems and Instrumentation subdirs before compiling. Add this inside the sim tag in yor aircraft's *-set.xml file to override the generic ones in preferences.xml (just like for the autopilot): systems pathpath/to/your/systems.xml/path /systems instrumentation pathpath/to/your/instrumentation.xml/path /instrumentation Take a look at Aircraft/Generic/generic-systems.xml and generic- instrumentation.xml for examples of how to configure the systems and instrumentation. It should be fairly obvious. David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiple instruments and systems, and configuration of these
På Sat, 07 Aug 2004 09:49:22 +0200, skrev Roy Vegard Ovesen [EMAIL PROTECTED]: Hi, I've looked through the TODO comments in the source code for the instrumentation and the systems, and would like to start implementing some/all/even more of them. That is unless someone else is already doing that. The two main things to add are: 1) Multiple instruments and systems, the ability to have several airspeed indicators, altimeters, pitot systems, static systems, etc. 2) XML configuration file to select what instruments and systems would be available for that particular aircraft. If someone else is already implementig these features, please let me know. Comments are welcome! I've implemented this now, but because of the pendig new release it will not be put in CVS until after the release. By using two configuration files, one for systems and one for instrumentation, one can configure the systems and instrumentation individually for every aircraft. One can have several instances of the same instrument or system. One can also give the instances an arbitrary name (the airspeed indicator could be called speedometer etc.). This of course has breakage of the instruments (and probably a bunch of other things) written all over it, so I've created two generic configuration files that configures the systems and instrumentation exactly as they were hardcoded. Here is an extract from generic-instrumentation.xml adf nameadf/name number0/number /adf airspeed-indicator nameairspeed-indicator/name number0/number pitot-port/systems/pitot/pitot-port static-port/systems/static/static-port /airspeed-indicator Notice that one can configure wich pitot-and static-port the airspeed- indicator uses. This of course has to correspond to a pitot-and static-port configured in the systems.xml configuration file. The number tag is to distinguish several instances with identical names. I've noticed some changes recently to the systems and the instrumentation. David Culp has created a new subsystem class and Melchior Franz has done some changes to the adf class in the instrumentation folder. To avoid doing duplicate work and potentially conflicting work, I strongly suggest that we synchronize our efforts. I believe David has mentioned that he wants to be able to have several subsystems. I think that should be simple to do now that I've done it to the other systems. Melchior seems to have started migrating stuff from the cockpit subdir to the instrumentation subdir. This should also be made configurable, just like the stuff that's already in instrumentation. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Multiple instruments and systems, and configuration of these
Hi, I've looked through the TODO comments in the source code for the instrumentation and the systems, and would like to start implementing some/all/even more of them. That is unless someone else is already doing that. The two main things to add are: 1) Multiple instruments and systems, the ability to have several airspeed indicators, altimeters, pitot systems, static systems, etc. 2) XML configuration file to select what instruments and systems would be available for that particular aircraft. If someone else is already implementig these features, please let me know. Comments are welcome! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Clickable 3d instruments
On Tuesday 15 June 2004 14:49, Jim Wilson wrote: I can probably answer your question, but I don't know what you mean by alias feature. Is that a 2d panel thing? Maybe that answers your question? ;-) Yes, the alias feature is a 2d panel thing. It is usefull when you have two identical instruments that should be connected to different properties, for example two nav radios or two CDIs. With aliases, one defines which properties to use, for that particular instrument instance, in the panel config file when including the instrument config file. This is a very usefull feature, and it would be just as usefull for 3d instruments for exactly the same reasons as it is for 2d instruments. Because of aliases apparently not being implemented, the Piper has two CDIs that are connected to the same nav radio, and consequently display the same information. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3d instruments
The Hunter and the Mustang has clickable 3d instruments. This is achieved by including a transparent 2d panel with action hotspots at select locations. The 2d panel is included in the top-level aircraft model xml config file, so the hotspots become aircraft-model-specific. I suspect that moving a 3d instrument would require moving the action hotspots as well. I tried to make the 2d panel with hotspots instrument-model-specific by including a 2d panel in the instrument model xml config file: PropertyList pathswitch.ac/path params switch-valswitch/test/switch-val /params !-- Include a panel with hotspots -- panel pathAircraft/king-air-200/Instruments/switch-hotspots.xml/path !-- It would be nice to include this in-line instead of in a separate file -- bottom-left x-m0/x-m y-m-0.005/y-m z-m-0.005/z-m /bottom-left bottom-right x-m0/x-m y-m 0.005/y-m z-m-0.005/z-m /bottom-right top-left x-m0/x-m y-m-0.005/y-m z-m 0.005/z-m /top-left /panel animation typerotate/type object-nameLever/object-name property alias=../../params/switch-val/ interpolation entryind1/inddep20/dep/entry entryind0/inddep-20/dep/entry /interpolation axis x0/x y1/y z0/z /axis /animation /PropertyList The switch-hotspots.xml file is a small (10x10) panel with one big instrument with one big hotspot. This worked as expected. I was also able to reuse the switch instrument at different locations in the cockpit, as expected. Is there perhaps a limit to how many 2d panels with hotspots one can include? This method adds instrument-specific hotspots to true 3d instruments. It's a bit ugly but it works and is more reusable than the Hunter and Mustang way of doing it. I would also like to redirect you attention to my post: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028549.html Thanks! Can anyone confirm that the alias feature can not be used for the 3d animation code?! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3d instruments
The Hunter and the Mustang has clickable 3d instruments. This is achieved by including a transparent 2d panel with action hotspots at select locations. The 2d panel is included in the top-level aircraft model xml config file, so the hotspots become aircraft-model-specific. I suspect that moving a 3d instrument would require moving the action hotspots as well. I tried to make the 2d panel with hotspots instrument-model-specific by including a 2d panel in the instrument model xml config file: PropertyList pathswitch.ac/path params switch-valswitch/test/switch-val /params !-- Include a panel with hotspots -- panel pathAircraft/king-air-200/Instruments/switch-hotspots.xml/path !-- It would be nice to include this in-line instead of in a separate file -- bottom-left x-m0/x-m y-m-0.005/y-m z-m-0.005/z-m /bottom-left bottom-right x-m0/x-m y-m 0.005/y-m z-m-0.005/z-m /bottom-right top-left x-m0/x-m y-m-0.005/y-m z-m 0.005/z-m /top-left /panel animation typerotate/type object-nameLever/object-name property alias=../../params/switch-val/ interpolation entryind1/inddep20/dep/entry entryind0/inddep-20/dep/entry /interpolation axis x0/x y1/y z0/z /axis /animation /PropertyList The switch-hotspots.xml file is a small (10x10) panel with one big instrument with one big hotspot. This worked as expected. I was also able to reuse the switch instrument at different locations in the cockpit, as expected. Is there perhaps a limit to how many 2d panels with hotspots one can include? This method adds instrument-specific hotspots to true 3d instruments. It's a bit ugly but it works and is more reusable than the Hunter and Mustang way of doing it. I would also like to redirect you attention to my post: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028549.html Thanks! Can anyone confirm that the alias feature can not be used for the 3d animation code?! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Tuesday 08 June 2004 01:44, Ampere K. Hardraade wrote: I've just find this out. Check out the Models/3ds folder in your home directory. There is a mesh of KingAir in there. I'm absolutely sure that I have looket through all the 3ds models at one point, but I must have forgotten that there was a King Air model there. That model is much more detailed than the model I'm currently working on. It has over 31 000 vertices while the one I'm vorking on has about 5 000. I'll continue with the one that I've benn using, and maybe move the cockpit interior into the detailed model when I'm done. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 00:25, Lee Elliott wrote: This might be due to the ordering of the transparent objects relative to the non-transparent parts. Is/are the model objects in .AC format? I use Blender, and export to .AC format. If so (I don't know if this also applies to other object formats such as .3DS) try moving the transparent parts to the bottom of the object hierarchy/list. How do I do that? Editing the .AC file with a text editor? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 04:08, Ampere K. Hardraade wrote: I don't know how things are done in other 3D modelling softwares, but in 3D Studio, each effect has a seperated mapping channel. For example, if you want transparency in certain areas of a texture, you need to assign a map to the transparency channel of that texture inorder for those certain portions of the latter to possess true transparency. Usually, the map can be the same file as the texture itself, though you have to play around with the options a bit so that the transparency is based on the Alpha instead of RGB. Check this out: http://waylon-art.com/uvw_tutorial/tut401_a.jpg Notice the various mapping channels: ambient, diffuse, specular color, specular level, glossiness, self illumination; the list is quite long. As I said, I don't know how things are done in other 3D modelling softwares. Your best bet will be looking for the dialog box that allows you to apply different effects to a texture in the 3D modelling software that you are using. In Blender one can select, at least, opaque or alpha, but I guess that this does not get carried through in the export to AC3D format. AC3D uses alpha. But as you can see from the screenshot the holes _are_ transparent because you can see the other panel texture through it.But you can't see the gauge face texture through it. The difference between the other panel texture and the gauge face texture is that the panel texture is part of the plane 3d model, and the gauge face texture is included to the model through the model xml config file. I suspect that this is what is causing the problem. Regards, Ampere On June 4, 2004 06:25 pm, Lee Elliott wrote: On Friday 04 June 2004 21:44, Roy Vegard Ovesen wrote: Here is a shot of the King Air cockpit i'm modeling: http://home.tiscali.no/rvovesen/king-air-cockpit.jpg Also I have a question: The fuel panel texture on the left has two semi circles that have alpha 0% (transparent) in order to show fuel level gauges that are supposed to be placed slightly behind the panel. The fuel level gauge that is visible on the right side of the fuel panel actually has a textured face, but it is not visible through the transparent semi circle. Note that the Fuel system circuit breakers panel texture is visible through the transparent semi circle. The fuel level gauge has been included in the model xml file as a model tag. Could this be the reason why the gauge face texture is not visible? I believe David Megginson's Piper cockpit uses the same technique: A panel texture with transparent holes and instruments behind those holes, so I guess it should be possible. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 14:16, Jim Wilson wrote: So far this cockpit is really looking great! Very nice work on the control box. Thanks. I found some very detailed close-up photos of a cockpit that I've recreated with a vector drawing program (OpenOffice Draw). Scanning the other responses, I don't think this has been answered yet (sorry if it has). If your fuel panel is part of the main model, then it should be lower on the stack and what you expect should be working. However, I think this might be affected by a select animation especially if the fuel panel is grouped with objects like the fuel guage models (or other animations, but I assume the only animation on a fuel panel would be select). In any case the problem isn't going to be solved by changing texture/polygon/color properties. That hole looks sufficiently transparent to me :-) Frederic's solution to change the order using select animation in the xml file worked great. I also think that that was by far the most attractive solution too. Thanks Fred. I suspect that moving the fuel panel all the way to the bottom of the of the AC model file would not have worked. When including the fuel level gauge as another AC model, it would be placed below everything else anyway, right? If none of this helps, then send your models and configs and I'll take a look. That wouldn't be until Sunday night at the earliest, because of a trip down to Portland. FWIW when modeling flat panels with bezeled guages I'm not sure there is any advantage to using this method unless there's something specific being modeled below the panel surface (e.g. certain mag compasses). For example on the p51d and the cub it isn't all that obvious that the faces aren't below the surface. On the other hand you may need this method for that side fuel panel, because it is so close...not sure. I guess I would always try it without the transparency to see what looks like first. Keep in mind that there is a performance cost to rendering things through a transparency. Is there perhaps a difference when using a perfectly transparent er... transparency and a semi-transparent transparency, performance wise?! I've also thought about using a textured needle instead of an object colored one. The textured one might look a lot better with variable alpha creating an anti-alias effect, but I'm concerned about performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
