Re: [Flightgear-devel] A little "emergency" encountered inside FlightGear
On September 28, 2005 04:02 am, Erik Hofman wrote: > Looking at a patch commit to simgear/scene/model at Sept. 25th I see > there was a patch to set the factor to 0.0 by default which doesn't seem > such a great idea after all. > > I've backed out that patch again, could you test it for me? > > Erik I have updated my copy of SimGear and FlightGear again, but the problem is still there. Does anyone have this problem as well? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] macflightgear info
> From: Arthur Wiebe > > There are some other mac fgfs guys on this list. I figured I'd let everyone > know exactly what the MacOSX port of FGFS is up to. > > http://artooro.blogspot.com/2005/09/mac-flightgear-project-report.html > > (NOTE:) > The Flight starter (fgrun equiv) is referred to as MacFlightGear and the rest > is obvious (I hope). > We're not using fgrun because first, it won't compile at all on OSX without > major changes, and second, even if it did work it would look ugly because it > uses FLTK so a port isn't worthwhile. While I wouldn't care, a lot of mac > users would care about how it looks. > MacFlightGear uses the wxWidgets framework. > > Also a note to you mac developers, if you would be interested in helping make > fgfs more user-friendly drop me a line. I would love to have more guys join. > We're reaching 4 downloads in the next week or so by the way. Probably > nothing compared to others but to me it means, get to work! > http://macflightgear.sourceforge.net The wxWidgets/gtk apps I've used seem to work pretty well, so it might actually be possible to have a version easily portable to linux. I'm not able to do any development at the moment, but if you need a tester before releasing, I'm willing to mess around with it for a while on the little ibook. I wonder what kind of performance hit you are talking about using the "universal binary" mode? Anyway, thanks for the update. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
I hope, this description is not to long, but I think it is very
important to have a working controller code
First the test results, at the end you will find the test decription for
the test controller and a little nasal script for logging.
o Behaviour with delta_u_n = 0 and an input jump function of 0.2 No
saturation at the beginning.
Time, reference,input,output
21:59:17,0,0,0
21:59:18,0,0,0
21:59:19,0,0.2,0.2008 Here I changed the input value
from 0 to 0.2 and we see the proportionel gain of -1 (P-part)
21:59:20,0,0.2,0.22116665 Here the integrator part is added.
21:59:21,0,0.2,0.24149997
21:59:22,0,0.2,0.26183332
21:59:23,0,0.2,0.2822
21:59:24,0,0.2,0.30250005
21:59:25,0,0.2,0.32283342
21:59:26,0,0.2,0.34283345
21:59:27,0,0.2,0.36316682
21:59:28,0,0.2,0.38350018
21:59:29,0,0.2,0.40383355
21:59:30,0,0.2,0.42433358
21:59:31,0,0.2,0.44466694
21:59:32,0,0.2,0.46500031
21:59:33,0,0.2,0.48533367
21:59:34,0,0.2,0.49950036 Here the windup logic limits the
output value to 0.5
21:59:35,0,0.2,0.49950036
21:59:36,0,0.2,0.49950036
21:59:37,0,0.2,0.49950036
21:59:38,0,0.2,0.49950036
21:59:39,0,0.2,0.49950036
21:59:40,0,0.2,0.49950036
21:59:41,0,0.2,0.49950036
21:59:42,0,0.2,0.49950036
21:59:43,0,0.2,0.49950036
21:59:44,0,0.2,0.49950036
21:59:45,0,0.2,0.49950036
Everything is fine !
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
21:57:00,0,0.6,0.08803
21:57:01,0,0.6,0.15050001
21:57:02,0,0.6,0.2131
21:57:03,0,0.6,0.2732
21:57:04,0,0.6,0.33350002
21:57:05,0,0.6,0.39350003
21:57:06,0,0.6,0.4533
21:57:07,0,0.6,0.49950004
Kind regards
Hans-Georg
P.S.: The test result for delta_u_n = u_max - U
Test controller:
Test controller
false
/autopilot/test/status
go
/autopilot/test/input
/autopilot/test/reference
/autopilot/test/output
-1
1
1
0.0
1
0
-0.5
0.5
For logging puposes I wrote a little nasal script:
#
# Function to log
#
print_test = func {
ref_log= getprop("/autopilot/test/reference");
input_log = getprop("/autopilot/test/input");
output_log = getprop("/autopilot/test/output");
time_log = getprop("/sim/time/gmt-string");
print(time_log,",",ref_log,",", input_log,",",output_log);
# Re-schedule the next call
if(getprop("/autopilot/test/status") != "go") {
print("Log disabled");
} else {
#print("Set timer");
settimer(print_test,1);
}
}
Kind regards
Hans-Georg
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
Roy Vegard Ovesen wrote: 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 do not talk about a P only controller and about the steady state error of a P only controller. The error happens, when the input value is a step function, which drives the controller directly into the windup logic. Then the output value is zero. All other cases are working fine. I found a site with a good explanation of the PID equation: http://bestune.50megs.com/typeABC.htm There is no windup logic in these equations. 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. First of all I will do some tests to clarify my problem and my solution. Thank you for your detailed answer Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
See below... On 9/28/05, Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: > 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: But in some cases, such as when Kp*e is greater than u_max-u_n, the output is not changed. It isn't that the proportional output is not enough to get rid of the error, it is that the proportional output is being ignored because it would put the output past the user set limit. The correct behaviour should be to move the output to the user limit. > > 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 > Good site! > > 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. I can see your problem with it. In fact, I think it may be technically wrong because it assumes that the proportional component is the only thing contributing to the saturation of the controller. But something must be done to correctly handle saturation. One possibility would be to internally track the actual PID output when it goes past saturation (but limit the output value). This does not provide any anti-windup protection though, so some kind of anti-windup would need to be added. One method I have found referenced at several sites uses the amount of saturation as a feedback to the integral term: v_n : PID calculated output u_n : Control output (u_n = v_n except in saturation, when it equals u_max or u_min) s_n : saturation (s_n = u_n - v_n) Then the integral contribution would be I = Ki*e_n + Ks*s_n (Ks defines how tightly windup is controlled). > > Roy Vegard Ovesen > -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim 200x aircraft?
> From: "Mike Kopack" > > Hey gang, > > > Second, while investigating some stuff for another project, I ran across a > reference where somebody used a MS Flight Sim aircraft model for a Predator > UAV and used it on Flight Gear. Unfortunately, it didn't explain how they > did it. How would I go about doing this (since my project is to control a > UAV, it would be a lot more credible to show the customer a Predator on the > screen than a Piper Cub!) > Gosh I don't know, a Piper Cub UAV would be pretty impressive. :-) Michael Selig has a screenshot of one on his web page, so he might know where you can get yourself a UAV 3D model. Google "uiuc selig flightgear" Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
> From: Andy Ross > > Hans-Georg Wunder wrote: > > In the package there is a GPL-license. > > If this is enough, then everything is OK regarding the panel. > > Unfortunately, due to clear evidence of (minor, admittedly) copyright > violation, this is not enough. The issue isn't license compatibility, > it is copyright ownership. John Carty cannot legally grant a license > to artwork he does not own. We need to be 100% sure that the people > granting the license (GPL or otherwise) own the copyright. > > > I wrote John a mail and told him, what Iam going to do, > > but I got no answer. > > At this point, I think a statement from Mr. Carty is really the only > thing that will be acceptable. It's possible he didn't understand the > rules, and generated some of the artwork via screenshots of other > aircraft in MSFS. That's a showstopper for us. > > Obviously Innis's model and FDM configuration are fine. But my strong > suggestion is not to commit the panel until we can trace the history > of every image in it. > Andy's view on this is the same as my own. If OSS developers learned a lesson from SCO it is this. Although it is hard to see now, some day FGFS or a derivative is likely to be a real threat to whatever is left of the future MSFS desktop market and the last thing we want to do is give some bunch of copyright lawyers a toehold. Best, Jim ___ 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] Microsoft artwork (!) in the 707 panel
Hans-Georg Wunder wrote: > In the package there is a GPL-license. > If this is enough, then everything is OK regarding the panel. Unfortunately, due to clear evidence of (minor, admittedly) copyright violation, this is not enough. The issue isn't license compatibility, it is copyright ownership. John Carty cannot legally grant a license to artwork he does not own. We need to be 100% sure that the people granting the license (GPL or otherwise) own the copyright. > I wrote John a mail and told him, what Iam going to do, > but I got no answer. At this point, I think a statement from Mr. Carty is really the only thing that will be acceptable. It's possible he didn't understand the rules, and generated some of the artwork via screenshots of other aircraft in MSFS. That's a showstopper for us. Obviously Innis's model and FDM configuration are fine. But my strong suggestion is not to commit the panel until we can trace the history of every image in it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Thank you for the tips I understand your concerns. I took the panel from the package b707-436v2.zip from John Carty. In the package there is a GPL-license. If this is enough, then everything is OK regarding the panel. I wrote John a mail and told him, what Iam going to do, but I got no answer. If this is not enough, then the base package is the wrong place. I can't check, if there is copyright infringement in b707-436v2.zip Addionally I removed the Microsoft-Artwork The 3d-model and flightmodel is from Innis Cunnigham. From him I got the following anwser on the Flightgear-userlist Hello Hans-Georg I guess the 707 and flightmodel comes under the GPL so I guess you can modify it as you wish maintaining the terms of the GPL. Hans-Georg Wunder writes > > Hi all, > > I have a question for Innis Cunningham: > I found a wonderful package of a 707 from [EMAIL PROTECTED] I want to merge his package with the 3D-model and flightmodel of the 707 of Innis Cunningham. But I need to know, if the 707-package of Innis > is also licensed under GPL. > > Thanks for an answer > > > Kind regards > > Hans-Georg Cheers Innis Kind regards Hans-Georg Andy Ross wrote: Karsten Krispin wrote: roy.vegard.ovesen wrote: Those icons at the top, just right of the menu bar. I'm pretty sure that they come from MSFS, and thus are probably under a license uncompatible with GPL. I suggest that Hans-Georg simply remove them, there probably are no such buttons in a real 707 anyway. Yes, that are MSFS icons and it's true that the 707 does not have such icons, but: your screen never will have the dimensions to show up a whole cockpit at once. Yikes. Folks, we have to be really, REALLY careful about this kind of thing. Are we absolutely, 100% sure we know the authorship and copyright ownership on this thing? All of it? If not, it just can't go into the base package. My fear is that other parts will turn out to be screenshots from MSFS too... At a mimimum, I'd suggest getting documents frmo Hans-Georg and George Carty attesting to ownership and including them in the Aircraft directory. Copyright infringement, even unintentional, is no joke. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
Hans-Georg Wunder wrote: It would be great, if you also test the code. This PID code has been working well (and untouched for quite some time now.) What bug/problem are we trying to fix here? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
It would be great, if you also test the code. Hans-Georg Jeff McBride wrote: Ahh, yes. I see your point. Since the change in output is based on change in error (not current error), if the amount of output shift is altered but the last error (ep_n_1) is not the two will effectively become out of sync. In fact, the same thing must have been happening when delta_u_n was being set to 0 when saturation occurred. But, the integral component should correct for this after a little bit. I am not convinced that you need to adjust edf_n, or that you should. IMHO, there is no reason that the rate of change information cannot be used when the controller is in saturation, and there is no way for the derivative error to "wind-up". But I agree with your scaling of ep_n to match the change in output. Good call. It looks like Erik did commit a patch, and it looks like it does not include your adjustment to ep_n. So, it is still broken (though, I think it may be an improvement). I don't currently have a linux box to compile FG on, and I have not tackled the problem of compiling on Visual Studio, so I am unable to test this code at the moment (though I will have a linux box for development soon!). I appreciate all the development everyone has done, as I have found FG to be a great tool for both work and play. Hopefully I can find some way to contribute myself in the near future. -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
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. I think, my solution solves the problem, but it would be great, if Jeff is also able to test it. Hans-Georg Curtis L. Olson wrote: I seem to recall Erik commited a change to the autopilot code in the last week or so. Does that fix something? Did that introduce a new problem? This is pretty subtle, complex code so people shouldn't be messing with it too much unless they are really sure they know what's going on with it. Curt. snip-- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Karsten Krispin wrote: > roy.vegard.ovesen wrote: > > Those icons at the top, just right of the menu bar. I'm pretty sure > > that they come from MSFS, and thus are probably under a license > > uncompatible with GPL. I suggest that Hans-Georg simply remove them, > > there probably are no such buttons in a real 707 anyway. > > Yes, that are MSFS icons and it's true that the 707 does not have > such icons, but: your screen never will have the dimensions to show > up a whole cockpit at once. Yikes. Folks, we have to be really, REALLY careful about this kind of thing. Are we absolutely, 100% sure we know the authorship and copyright ownership on this thing? All of it? If not, it just can't go into the base package. My fear is that other parts will turn out to be screenshots from MSFS too... At a mimimum, I'd suggest getting documents frmo Hans-Georg and George Carty attesting to ownership and including them in the Aircraft directory. Copyright infringement, even unintentional, is no joke. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2D-Panel for the 707
Am Mittwoch, 28. September 2005 08:46 schrieb roy.vegard.ovesen: > Those icons at the top, just right of the menu bar. I'm pretty sure that > they come from MSFS, and thus are probably under a license uncompatible > with GPL. I suggest that Hans-Georg simply remove them, there probably are > no such buttons in a real 707 anyway. Yes, that are MSFS icons and it's true that the 707 does not have such icons, but: your screen never will have the dimensions to show up a whole cockpit at once. So replacing the icons with some self-made ones would be rather a good idea. Greetings, Karsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] irc.flightgear.org down: alternative server
Hi all, irc.flightgear.org is currently down (the machine is there but the irc service isn't) so I have set up a channel #flightgear on freenode.net to use untill the offical server comes back up. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little "emergency" encountered inside FlightGear
Ampere K. Hardraade wrote: As a side note, I made it safely back to the airport, braked, and taxied to the tarmac. Those who have had trouble braking on large jets may want to hold Shift+B on touch down. Provided that Caps-Lock is off, holding Shift+B will toggle the brake between on and off states, thus preventing the nose wheel from sinking into the runway. Enabling Caps-Lock and hold B alone will also work. Antilock brakes simulated with key repeat - I like it :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2D-Panel for the 707
På 28.09.2005 10:05 CEST skrev Erik Hofman >Hans-Georg Wunder wrote: >> Hi all, >> >> I adapted the 2D-panel of a 707 from George Carty for FlightGear and >> merged it with the 3D-Model of Innis Cunningham. >> >> Here are the results: >> >> http://wunderhg.homepage.t-online.de/707-KSFO.jpg > >Ow, nice! Is it ready to be included in the base package? Those icons at the top, just right of the menu bar. I'm pretty sure that they come from MSFS, and thus are probably under a license uncompatible with GPL. I suggest that Hans-Georg simply remove them, there probably are no such buttons in a real 707 anyway. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2D-Panel for the 707
Hans-Georg Wunder wrote: Hi all, I adapted the 2D-panel of a 707 from George Carty for FlightGear and merged it with the 3D-Model of Innis Cunningham. Here are the results: http://wunderhg.homepage.t-online.de/707-KSFO.jpg Ow, nice! Is it ready to be included in the base package? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little "emergency" encountered inside FlightGear
Ampere K. Hardraade wrote: As you can see, there is a problem with the main landing gears on the 747. The bug appears again after I restarted FlightGear. I have never seen this happening until I updated my CVS version of SimGear and FlightGear yesterday. I haven't touched anything in the data directory, so I think this might be FlightGear/SimGear related. Looking at a patch commit to simgear/scene/model at Sept. 25th I see there was a patch to set the factor to 0.0 by default which doesn't seem such a great idea after all. I've backed out that patch again, could you test it for me? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little "emergency" encountered inside FlightGear
[EMAIL PROTECTED] wrote: well, I hacked the code not to show those dialogs any more... could supply a "patch" if someone wants it :-) Please? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
