[Flightgear-devel] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear'
On 12/30/02 at 7:47 PM [EMAIL PROTECTED] wrote: >Date: Mon Dec 30 14:47:23 EST 2002 >Author: cvsroot > >Update of /home/cvsroot/FlightGear/FlightGear >In directory bitless:/tmp/cvs-serv15423 > >Modified Files: > preferences.xml >Log Message: >Changed default frequencies. KSFO ATIS is not on standby on COM1, and >KOAK ATIS is on standby on COM2 (this one doesn't seem to work, though). > Currently only comm1 is considered in the ATC frequency search code. I'll fix it... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear/Aircraft/Instruments'
On 12/28/02 at 7:10 PM [EMAIL PROTECTED] wrote: >Date: Sat Dec 28 14:10:41 EST 2002 >Author: cvsroot > >Update of /home/cvsroot/FlightGear/FlightGear/Aircraft/Instruments >In directory bitless:/tmp/cvs-serv31667/Instruments > >Modified Files: > single-magneto-switch.xml >Log Message: >Changed to use the new mod-up support for panel mouse actions. Now, >you simply click with the left mouse button to advance to 'both'; >after that, if you click again, the start engages until you let go of >the mouse button, at which point the knob snaps back to 'both'. > This is fantastic and works beautifully! Unfortunately the default startup at the moment leaves the magneto switch stuck in the starter position, and the only way to get it back so the above can work properly if required is to hit the space bar as before. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear'
David Luff writes: > On 12/30/02 at 7:47 PM [EMAIL PROTECTED] wrote: > > >Date: Mon Dec 30 14:47:23 EST 2002 > >Author: cvsroot > > > >Update of /home/cvsroot/FlightGear/FlightGear > >In directory bitless:/tmp/cvs-serv15423 > > > >Modified Files: > > preferences.xml > >Log Message: > >Changed default frequencies. KSFO ATIS is not on standby on COM1, and > >KOAK ATIS is on standby on COM2 (this one doesn't seem to work, though). > > > > Currently only comm1 is considered in the ATC frequency search code. I'll > fix it... David, Another feature request would be to create a volume and on/off switch property and honor them. Volume could go from 0.0 - 1.0 scaled appropriately, and on/off is pretty self explanitory. It would also be nice to have a "servicable" property so we can fail comm1 or comm2. Then if anyone is trying to hook flightgear up to real hardware, the comm audio knobs and on/off switch will work as expected. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem: unrealistic YASim stalls
[Sorry for the delay. I was out of town last week.] David Megginson wrote: > What can we do to prevent the over-eager wing drop in YASim? Is > there something we can change in the config files, or is it a C++ > code problem? Barring bugs, this is a pure configuration problem. It sounds like there are two issues with the model. The first is that the asymmetry in wing stalls is too high, and that the stalls themselves are too viscious. The second is that it is too easy to put the aircraft into a stall in the first place. The second is the easiest to explain. From your description, it sounds like full elevator in the real plane puts the aircraft at an AoA just barely past the stall -- you feel the buffet, but don't lose much lift. This makes an awful lot of design sense to me, I'm sure they intended it that way. My guess is that the YASim elevator is capable of pulling the AoA well past stall, so you get nastier behavior. Try modifying the "flap" setting on the hstab (the effectiveness of the stabilizor flaps) until full elevator is just barely enough to acheive stall AoA. You are helped in this because (I think) the "approach" configuration in the file actually represents a stall. The solver prints out the elevator required to trim for approach in the solution report, make this as close to 1.0 as you can. This might be enough to fix your problem -- you could still get a viscious asymettric stall with violent control input, but gentle motion of the yoke wouldn't be able to pull the nose high enough. The problem with the stalls themselves should be fixeable with the stall subtag on the wing. There is a "width" parameter that controls the sharpness of the lift curve peak. It's roughly twice the radius of curvature of the top of the peak, in degrees (not exactly, because I'm using a cubic interpolant, but close enough). It's currently set to six, which I would think would be pretty gentle. But you could try a higher value and see what you get. Is it possible I have a unit bug in there? Another tunable you could play with is the "peak" number. This controls how high the "normal" lift peak is in relation to the more fundamental one at 45° generated by the underlying surface model. Setting this value higher results in a sharper lift drop past the stall. Lower values produce more gentle curves. I have *no* idea what the right value for this is; I haven't seen any data on wing lift though the full 360° of AoA. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear'
On 1/2/03 at 11:52 AM Curtis L. Olson wrote: >David, > >Another feature request would be to create a volume and on/off switch >property and honor them. Volume could go from 0.0 - 1.0 scaled >appropriately, and on/off is pretty self explanitory. It would also >be nice to have a "servicable" property so we can fail comm1 or comm2. > >Then if anyone is trying to hook flightgear up to real hardware, the >comm audio knobs and on/off switch will work as expected. :-) > OK. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear'
On 1/2/03 at 11:52 AM Curtis L. Olson wrote: >Another feature request would be to create a volume and on/off switch >property and honor them. Volume could go from 0.0 - 1.0 scaled BTW, can you hear the audio ATIS OK on your Linux box? There have been a few problems reported with it over Christmas which I can't reproduce. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear'
David Luff writes: > On 1/2/03 at 11:52 AM Curtis L. Olson wrote: > > >Another feature request would be to create a volume and on/off switch > >property and honor them. Volume could go from 0.0 - 1.0 scaled > > BTW, can you hear the audio ATIS OK on your Linux box? There have been a > few problems reported with it over Christmas which I can't reproduce. Personally, I can hear it ok, but a volume control would be really nice. This is really simple to impliment too ... we do it already for the morse code audio idents. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem: unrealistic YASim stalls
On Thu, 2003-01-02 at 13:35, Andy Ross wrote: > This might be enough to fix your problem -- you could still get a > viscious asymettric stall with violent control input, but gentle > motion of the yoke wouldn't be able to pull the nose high enough. That sounds about right to me. In the Cessna 172 that I fly, you can get some exciting nose-drop behavior in a power-on stall, or with a more abrupt control movement. But, if the aircraft is lightly loaded (200lb pilot, 30gal fuel) and you do a power-off stall gently, you just hear it go in and out of the buffet every few second while you descend smoothly. I've flown several incipient spins (with an instructor, un/cross-coordinated power-on stall) in the Cessna 172 and they were quite exciting. :-) -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear/Aircraft/Instruments'
David Luff writes: > This is fantastic and works beautifully! Unfortunately the default startup > at the moment leaves the magneto switch stuck in the starter position, and > the only way to get it back so the above can work properly if required is > to hit the space bar as before. Can you find what's causing that? I took a quick look but couldn't figure it out. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem: unrealistic YASim stalls
Andy: Thanks for the suggestions -- I will try them all out, especially the elevator adjustments. It is worth noting, however, that even when I have succeeded in getting a sharp nose drop in a power-off stall on a 172, I have not seen a wing drop. You get a bit of roll with a power-on stall, and you can get a strong wing drop sometimes in a departure (banked) stall, but even when the nose drops like a roller coaster in a 172, the wings stay pretty-much level. I know that in a real plane the wing root stalls first because it has a higher incidence angle than the wing tips -- would that account for the roll stability in a stall, even with the sharp pitching down? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Question on YASim ....
Andy, is it technically possible to fiddle with the model parameters in real-time? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
Gene Buckle wrote: > Andy, is it technically possible to fiddle with the model parameters > in real-time? Not easily. Changing the parameters requires a re-solution, which can take a second or two for aircraft with lots of elements like the 747. So it would have to be done a little bit at a time over many frames, and probably involve a throttler gadget to keep the frame rate high enough. On an SMP system, you could just spawn a thread to do it and it would work great, of course. But on a uniprocessor, even threading would take half the CPU and performance would drop by 50% for a few seconds while the solution popped out. Is there something in particular you want to control at runtime? Support could probably be added per-device. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
> Gene Buckle wrote: > > Andy, is it technically possible to fiddle with the model parameters > > in real-time? > > Not easily. Changing the parameters requires a re-solution, which can > take a second or two for aircraft with lots of elements like the 747. > So it would have to be done a little bit at a time over many frames, > and probably involve a throttler gadget to keep the frame rate high > enough. > > On an SMP system, you could just spawn a thread to do it and it would > work great, of course. But on a uniprocessor, even threading would > take half the CPU and performance would drop by 50% for a few seconds > while the solution popped out. > > Is there something in particular you want to control at runtime? > Support could probably be added per-device. > (thanks for the quick response) My thought is that a real-time "model wrench" might make it easier for people to develop or improve aircraft models. I imagine it would save a _lot_ of time if the "edit parameter file, run fgfs, test, re-edit" cycle could be reduced to "run fgfs, tweak in-flight, dump new parameter file". I've got _way_ too many irons in the fire to try to tackle this myself, but if YASim could listen on a TCP port for "model wrench" commands, an external tool could be written (gui or text) that would allow a user to tweak the currently running model in-flight and then have the tool dump the changed version of the parameter file to disk after the session was complete. YASim itself wouldn't have to do much work other than update the requested parameter and "re-solve"(?) the model. The 1 or 2 second pause wouldn't be any big deal (I wouldn't think) because it would be an expected part of the design phase. If you wanted to add some kind of temporary solver, you could do a "test" solve and then send an error code to the model wrench and go back to the original (or prior) if the solver dies. I don't know of any other simulator that could do this, but I don't know if it's practical either. I think it would be fantastic if it was possible. Is this too far afield? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
Off the top of my head, I believe selecting reinit from the file menu causes the instance of the FDM class to be deleted and re-created. This means that it reloads the parameter file and recomputes a solution. That seems like a decent middle of the road solution. You make your fdm changes in a separate window/editor and then do "reset" to reload them. You have to start again from the ground, but at least you skip the overhead of having to reload flightgear from scratch. This appears to work right now. Regards, Curt. Gene Buckle writes: > (thanks for the quick response) > > My thought is that a real-time "model wrench" might make it easier for > people to develop or improve aircraft models. > > I imagine it would save a _lot_ of time if the "edit parameter file, run > fgfs, test, re-edit" cycle could be reduced to "run fgfs, tweak in-flight, > dump new parameter file". > > I've got _way_ too many irons in the fire to try to tackle this myself, > but if YASim could listen on a TCP port for "model wrench" commands, an > external tool could be written (gui or text) that would allow a user to > tweak the currently running model in-flight and then have the tool dump > the changed version of the parameter file to disk after the session was > complete. > > YASim itself wouldn't have to do much work other than update the requested > parameter and "re-solve"(?) the model. The 1 or 2 second pause wouldn't > be any big deal (I wouldn't think) because it would be an expected part of > the design phase. If you wanted to add some kind of temporary solver, you > could do a "test" solve and then send an error code to the model wrench > and go back to the original (or prior) if the solver dies. > > I don't know of any other simulator that could do this, but I don't know > if it's practical either. I think it would be fantastic if it was > possible. > > Is this too far afield? > > g. > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
On Thu, 2 Jan 2003 14:54:15 -0800 (PST) Gene Buckle <[EMAIL PROTECTED]> wrote: My thought is that a real-time "model wrench" might make it easier for people to develop or improve aircraft models. I don't know of any other simulator that could do this, but I don't know if it's practical either. I think it would be fantastic if it was possible. Hmmm. Cool idea. Of course, it would be sort of hard to modify table lookups for a complex coefficient, but if you start with a simple model you could play with coefficients in real time I think by using a property browser. Hmm. Hmm. Hmm. Tony? Jon Coordinator [EMAIL PROTECTED] JSBSim Project www.JSBSim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
On Thu, 2 Jan 2003, Jon S Berndt wrote: > On Thu, 2 Jan 2003 14:54:15 -0800 (PST) > Gene Buckle <[EMAIL PROTECTED]> wrote: > >My thought is that a real-time "model wrench" might make it easier for > >people to develop or improve aircraft models. > > > >I don't know of any other simulator that could do this, but I don't know > >if it's practical either. I think it would be fantastic if it was > >possible. > > Hmmm. Cool idea. Of course, it would be sort of hard to > modify table lookups for a complex coefficient, but if you > start with a simple model you could play with coefficients > in real time I think by using a property browser. Hmm. > Hmm. Hmm. > If the table is in the parameter file, there shouldn't be any reason why a designer couldn't change it. Whether or not they know what they're doing of course is an exercise left to the reader. :) With a flexible client, anything should be possible if the FDM can handle it. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
Jon S Berndt writes: > > Of course, it would be sort of hard to > modify table lookups for a complex coefficient, Not to hard to do if you think of the table as being samples along a curve and have a gui manipulated spline based curve editor. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
Gene Buckle wrote: > My thought is that a real-time "model wrench" might make it easier for > people to develop or improve aircraft models. > > I imagine it would save a _lot_ of time if the "edit parameter file, > run fgfs, test, re-edit" cycle could be reduced to "run fgfs, tweak > in-flight, dump new parameter file". Ah, got it. Actually, that feature could be expressed as simply as "make YASim load its configuration out of the property tree like everything else does". Then you'd just change the properties using whatever interface you want and select "reset" from the menu. This is definitely the way it should work. I've been slow to do it only out of laziness. Re-writing the existing aircraft definitions in "property XML" would be a pain. You're right, the N second pause for the solver would be just fine for this application. I was thinking you wanted to do something like variable-camber wings or whatnot and needed realtime control over things that are currently constants to the solver. Although it's worth pointing out that the command line "yasim" program goes a long way toward reducing the tedium involved with getting an aircraft in the air. Most of the big configuration bugs can be found and fixed before you ever run fgfs, although admittedly interpreting the solution report takes a little practice. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
On Thu, 2 Jan 2003, Norman Vine wrote: > Jon S Berndt writes: > > > > Of course, it would be sort of hard to > > modify table lookups for a complex coefficient, > > Not to hard to do if you think of the table as being > samples along a curve and have a gui manipulated > spline based curve editor. > Now THAT would be cool. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on YASim ....
> Although it's worth pointing out that the command line "yasim" program > goes a long way toward reducing the tedium involved with getting an > aircraft in the air. Most of the big configuration bugs can be found > and fixed before you ever run fgfs, although admittedly interpreting > the solution report takes a little practice. > I just thought it would be easier for folks to have some kind of graphic tool to develop with. Kind of a FlightGear equivalent to X-Plane's Plane Maker. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote: Julian Foad writes: > I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. > freq. 0 to 140; this should be 118 to 140. But while playing with that > I noticed that the wrapping is a bit unpredictable. With (min=118, > max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips > 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK > Pooley's Flight Guide confirms that the range is 108.00 to 117.95 > inclusive. But the current implementation that specifies (min=108.00, > max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, > 108.00, 108.05) skipping 117.95. Yes, it was a mess. I've done some refactoring of the built-in property-adjust and property-multiply commands, and things work better now. I added a 'mask' argument that can take a value "decimal" to modify only the decimal part or "integer" to modify only the integer part. That means that the radio tunes more like a real KX-155 (or similar), at least if your panel is using navcom-radio.xml -- the left button adjusts the decimal part and the right button adjusts the integer part. I've also fixed the COM radio frequency range in that file. That's good to hear. Wrapping should also be simpler and more predictable. Ah, well ... It's good to see it factored out into a single place (limit_value). But I don't think it's predictable because floating-point imprecision can still break it (118.025 - 0.025 is sometimes a bit less than 118.000 and therefore becomes 135.975). Also, different kinds of "wrap" are wanted in different situations: (1) A circular value (e.g. heading, 0 to 360 degrees). The "min" value is considered to have the same meaning as the max value (both mean "North"). In this case the old behaviour, addition modulo 360, was correct and appropriate (so that 358 degrees plus a step of 5 becomes 003 degrees), giving a smooth rotation. Floating-point imprecision is not a problem: it doesn't matter whether 359 + 1 becomes 359.9 or wraps to 000.1, because they mean the same thing. In case (1) it is appropriate for the controlled range to be "min <= x < max" (not "min <= x <= max"), so that the specified "min" and "max" values are independent of the adjustment step size. Otherwise you would have to specify max=359 when step=1 but max=355 when step=5, and what when the step isn't known until run time? (2) A range where the bottom and top values do not mean the same. E.g. radio frequency whole MHz, 118 <= x < 136, which could also be stated as 118 <= x <= 135 when the step size is 1. It is important that the boundary values are stable in the presence of floating-point imprecision: 117.99 must not wrap to 135.something. The precision limit must be taken into account. In case (2) I can imagine wanting (in different situations) several different wrapping sequences. E.g. on an arbitrary control range of 100 to 200, step size 10: - Circular:190-100-110 / 193-103-113 / 103-193-183 / 110-100-190 - Hit first limit: 190-200-110 / 193-200-110 / 103-100-190 / 110-100-190 - Hit both limits: 190-200-100 / 193-200-100 / 103-100-200 / 110-100-200 - etc. In the case of an analogue value these all have ambiguities or "flickering" behaviour at their limits and I can think of no realistic requirement for any of them. In the case of a discrete value, I consider that all such sequences could be desirable in some situations, but the "circular" mode with "min <= x < max" covers the present (radio tuning) requirement well and can cover other requirements and is semantically simple. Discrete Values and Precision These definitions work for analogue and discrete values. However, when dealing with a property that takes only discrete values (e.g. the comm. radio frequency, usually at a resolution of 0.025 MHz) one could wish that at every step the value would be rounded off. Indeed, that will probably be necessary to prevent cumulative error from becoming larger than the floating-point precision limit "epsilon" and thus messing up the wrapping behaviour. One could always round values in the range (min +/- epsilon) to exactly min, and (max +/- epsilon) to exactly max. But that is only effective when the user takes the value to its limits, which might be never, so I don't think that's worth implementing. To avoid accumulating error, and also to round off grossly-wrong values (like 118.02 up to 118.025) would require the resolution to be specified separately: you can't say the value must be a multiple of the step size, because a control is often adjusted in steps of 5 or 10 times its resolution. Do we need to handle grossly-wrong values? Not when adjusting by pre-programmed increments as we do at present, but if we were to drag an analogue adjuster we would probably want it to click into place. Therefore I think that this method (snapping to (min + N*resolution)) will be necessar
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
I (Julian Foad) wrote: and, unless it is tackled, I'm pretty sure floating-point imprecision will result in users sometimes being unable to set an end-point value like 118.000 MHz. Not actually unable to, because they can go back to 135.975 and then forward to 118.000. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] main.cxx: glXGetProcAddressARB undeclared, and warnings
Can anybody help with this error? Anyone care to fix the warnings? Making all in Main In file included from main.cxx:91: ../../src/ATC/ATCmgr.hxx:201: warning: extra qualification `FGATCMgr::' on member `FindInList' ignored main.cxx: In function `void fgRenderFrame()': main.cxx:443: warning: unused variable `const SGPropertyNode*longitude' main.cxx:445: warning: unused variable `const SGPropertyNode*latitude' main.cxx:447: warning: unused variable `const SGPropertyNode*altitude' main.cxx: In function `bool fgMainInit(int, char**)': main.cxx:1608: `glXGetProcAddressARB' undeclared (first use this function) main.cxx:1608: (Each undeclared identifier is reported only once for each function it appears in.) main.cxx: In function `void fgLoadDCS()': main.cxx:1906: warning: unused variable `ssgVertexArray*lights' make[2]: *** [main.o] Error 1 SuSE 8.1, GCC 3.2. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > > I don't like to add more configuration and code, I like to pare things > down to the simplest correct implementation. But I think this "snap to > valid value" behaviour will be necessary. Sounds like this could make a useful addition FWIW - I have tried to keep some common tools in Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] main.cxx: glXGetProcAddressARB undeclared, and warnings
Julian Foad writes: > main.cxx: In function `bool fgMainInit(int, char**)': > main.cxx:1608: `glXGetProcAddressARB' undeclared (first use this function) Looking at the Mesa headers it seems as if GLX_GLXEXT_PROTOTYPES needs to be defined Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC Build Problems in src/Main/main.cxx
For those who may care, I fixed the MacOS problems. It turns out that the OpenGL Extension that FlightGear are referencing have ARB extensions rather than EXT. I.e., glPointParameterfvEXT glPointParameterfEXT becomes glPointParameterfvARB glPointParameterfARB Jonathan Polley Here is the CVS diff. Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.53 diff -r1.53 main.cxx 53a54,58 > #if defined (__APPLE__) > #define GL_SGIS_point_parameters 1 > #include > #endif > 748a754,757 > #if defined (__APPLE__) > glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, quadratic); > glPointParameterfARB(GL_POINT_SIZE_MIN_EXT, 1.0); > #else 750c759,760 < glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); --- > glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); > #endif 792a803,806 > #if defined (__APPLE__) > glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, > default_attenuation); > #else 794a809 > #endif ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC Build Problems in src/Main/main.cxx
- Original Message - From: "Jonathan Polley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 9:13 PM Subject: Re: [Flightgear-devel] MSVC Build Problems in src/Main/main.cxx > For those who may care, I fixed the MacOS problems. It turns out that > the OpenGL Extension that FlightGear are referencing have ARB > extensions rather than EXT. I.e., > > glPointParameterfvEXT > glPointParameterfEXT > > becomes > > glPointParameterfvARB > glPointParameterfARB > > Jonathan Polley > > > Here is the CVS diff. > > Index: main.cxx > === > RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v > retrieving revision 1.53 > diff -r1.53 main.cxx > 53a54,58 > > #if defined (__APPLE__) > > #define GL_SGIS_point_parameters 1 > > #include > > #endif > > > 748a754,757 > > #if defined (__APPLE__) > > glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, > quadratic); > > glPointParameterfARB(GL_POINT_SIZE_MIN_EXT, 1.0); > > #else > 750c759,760 > < glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); > --- > > glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); > > #endif > 792a803,806 > > #if defined (__APPLE__) > > glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, > > default_attenuation); > > #else > 794a809 > > #endif > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Good aircraft pic site
FYI, Have a look at this pic: http://tinyurl.com/412x This site is great. Go here: http://www.airliners.net/ Then click on one of the links under "Most Popular". Good way to waste a little time ... Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Question on YASim ....
On Thu, 2003-01-02 at 14:58, Jon S Berndt wrote: > On Thu, 2 Jan 2003 14:54:15 -0800 (PST) > Gene Buckle <[EMAIL PROTECTED]> wrote: > >My thought is that a real-time "model wrench" might make it easier for > >people to develop or improve aircraft models. > > > >I don't know of any other simulator that could do this, but I don't know > >if it's practical either. I think it would be fantastic if it was > >possible. > > Hmmm. Cool idea. Of course, it would be sort of hard to > modify table lookups for a complex coefficient, but if you > start with a simple model you could play with coefficients > in real time I think by using a property browser. Hmm. > Hmm. Hmm. > > Tony? They are modifiable now to a certain extent. Each coefficient has a gain and bias term that is applied like: actual coefficient = gain*( file coefficient ) + bias If the coefficient is given as a table in the file, then the "file coefficient" value above is the result of the table lookup. These can be modified on the fly via the property tree, go to: /fdm/jsbsim/aero/buildup// This is a very effective method for tweaking one or two coeff's. There is currently no way to dump the gain and bias values or rewrite the config file though so you wouldn't want tweak too many at once. > > Jon > Coordinator > [EMAIL PROTECTED] > > JSBSim Project > www.JSBSim.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
