Re: [Flightgear-devel] Shader switches
On Fri, Mar 19, 2010 at 8:40 PM, Martin Spott martin.sp...@mgras.netwrote: Martin Spott wrote: do I understand correctly, that the former /sim/rendering/shader-experimental property has now been completely superseded by: /sim/rendering/crop-shader /sim/rendering/landmass-shader /sim/rendering/urban-shader /sim/rendering/water-shader No. shader-experimental controls the use of shaders on all geometry, including terrain and models. It's a general use shaders knob. The crop effect, landmass effect, etc. require shader-experimental and their own property to both be true in order to be enabled. I'm not sure if this is the best scheme, but it does allow us to say disable shaders when someone reports a funky problem. No response at all as is quite illuminative as well :-) Apparently these four don't accept 'true' as a value, just '1' in order to enable the feature. Am I correct to assume that this is a mishap, or is it a feature by design ? Should I file a bug for this one ? That's a mishap. Feel free. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help needed with multi-screen
On Fri, Mar 19, 2010 at 8:28 PM, Curtis Olson curtol...@gmail.com wrote: On Fri, Mar 19, 2010 at 2:21 PM, Martin Spott wrote: Curtis Olson wrote: I think you have just summarized all the limitations of the FlightGear multi-camera/view/display system. Tim Moore is the person who developed this feature (nothing existed before his efforts) [...] except from the multi-screen system which formerly had been introduced by Mathias Froehlich and which has done a great job, at least for not too complex display setups ;-) Sorry Mathias if I mis-attributed that effort. I know you did most of the original OSG port! It's true. I provided a patch to use the osgViewer class to set up windows, manage the main camera, etc. Mathias used the slave camera feature of osgViewer to provide a video wall style of multiple displays that was demonstrated at LinuxTag for 2 years, (I think!). I later generalized this to support general monitor arrangements (like a panoramic arc) and general combinations of screens and graphics cards. I don't know if the LinuxTag demo team uses the original video wall feature (still supported) or the new stuff. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help needed with multi-screen
On Fri, Mar 19, 2010 at 3:41 AM, Kavya Meyyappan kavya.meyyap...@gmail.comwrote: Dear FG members, I have just been trying out the multiple screen feature in FG. I found that the GUI camera (including the menu bar, hud and 2D panel) appears in only one of the windows. Is there any way I can make the GUI to appear in all the windows? Actually I want to be able to view the hud and 2D panel in all the windows. No, there's a limitation in Plib that forces the GUI to be drawn on one window. Also when I change the view in any one of the windows, the view changes in the other windows as well. Is it possible to make the windows independent of each other. I want to display the cockpit in one window at all times, in the second window I want to be able to shuttle between helicopter / chase or model views. Also I have observed that in the second screen where I'm displaying lets say the Helicopter view the aircraft remains static while the environment moves. This is because the cockpit view in my Master screen is defined as 'lookfrom'. Can I define 'lookfrom' for one screen and 'lookat' for the other screen. Neither of these are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need a complete overhaul to use the PagedLOD scheme of OSG, and the Flightgear view manager would need to be aware multiple active views. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader switches
Le 20/03/2010 08:54, Tim Moore a écrit : On Fri, Mar 19, 2010 at 8:40 PM, Martin Spott wrote: Martin Spott wrote: do I understand correctly, that the former /sim/rendering/shader-experimental property has now been completely superseded by: /sim/rendering/crop-shader /sim/rendering/landmass-shader /sim/rendering/urban-shader /sim/rendering/water-shader No. shader-experimental controls the use of shaders on all geometry, including terrain and models. It's a general use shaders knob. The crop effect, landmass effect, etc. require shader-experimental and their own property to both be true in order to be enabled. It looks like /sim/rendering/shader-experimental is not use anymore and was replaced by /sim/rendering/shader-effects as the global shader switch. -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader switches
On Sat, Mar 20, 2010 at 9:40 AM, Frederic Bouvier fredfgf...@free.frwrote: Le 20/03/2010 08:54, Tim Moore a écrit : On Fri, Mar 19, 2010 at 8:40 PM, Martin Spott wrote: Martin Spott wrote: do I understand correctly, that the former /sim/rendering/shader-experimental property has now been completely superseded by: /sim/rendering/crop-shader /sim/rendering/landmass-shader /sim/rendering/urban-shader /sim/rendering/water-shader No. shader-experimental controls the use of shaders on all geometry, including terrain and models. It's a general use shaders knob. The crop effect, landmass effect, etc. require shader-experimental and their own property to both be true in order to be enabled. It looks like /sim/rendering/shader-experimental is not use anymore and was replaced by /sim/rendering/shader-effects as the global shader switch. Whoops! Yes, that's correct. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bounce at startup.
I am (trying) to develop a model with JSBSim. At the moment the aircraft jumps violently into the air at startup and then bounces around on the runway until it sorts itself out. Is there a way of setting the initial height so that it is more or less in balance or is there something else that I need to look at? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bounce at startup.
Alan Teeder wrote: I am (trying) to develop a model with JSBSim. At the moment the aircraft jumps violently into the air at startup and then bounces around on the runway until it sorts itself out. Is there a way of setting the initial height so that it is more or less in balance or is there something else that I need to look at? This normally happens when the gear spring coefficients are not set properly. Try looking at a configuration for a similar aircraft that sits steady at the runway and adjust spring_coeff and damping_coeff accordingly to see if it solves the problem. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bounce at startup.
-- From: Erik Hofman e...@ehofman.com Sent: Saturday, March 20, 2010 10:04 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bounce at startup. Alan Teeder wrote: I am (trying) to develop a model with JSBSim. At the moment the aircraft jumps violently into the air at startup and then bounces around on the runway until it sorts itself out. Is there a way of setting the initial height so that it is more or less in balance or is there something else that I need to look at? This normally happens when the gear spring coefficients are not set properly. Try looking at a configuration for a similar aircraft that sits steady at the runway and adjust spring_coeff and damping_coeff accordingly to see if it solves the problem. Erik Thanks Eric, but the U/C (numbers from aeromatic) seems stable. It looks like an initialisation problem. If I start and switch immediately to rear view, the gear extends, and when it reaches down the plane is thrown upwards! Most times it lands back on the wheels and settles down, other times the airframe is first to touch down and then .. Is there a recommended way of initialising all the systems which copes with both on ground and in-air start-ups. ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bounce at startup.
On Sat, 2010-03-20 at 12:32 +, Alan Teeder wrote: -- From: Erik Hofman e...@ehofman.com Sent: Saturday, March 20, 2010 10:04 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bounce at startup. Alan Teeder wrote: I am (trying) to develop a model with JSBSim. At the moment the aircraft jumps violently into the air at startup and then bounces around on the runway until it sorts itself out. Is there a way of setting the initial height so that it is more or less in balance or is there something else that I need to look at? This normally happens when the gear spring coefficients are not set properly. Try looking at a configuration for a similar aircraft that sits steady at the runway and adjust spring_coeff and damping_coeff accordingly to see if it solves the problem. Erik Thanks Eric, but the U/C (numbers from aeromatic) seems stable. It looks like an initialisation problem. I have to agree with both of you. At initialization the aircraft is not perfectly positioned in respect to the ground so it gets dropped/lifted by the ground contacts. However, if the ground contacts are properly set these reactions will be minimal. Its really hard to make a specific recommendation without seeing the FDM in question, or at least a minimal FDM that demonstrates the problem. If I start and switch immediately to rear view, the gear extends, and when it reaches down the plane is thrown upwards! By design a gear doesn't support weight until it reaches 0.99 of extension. This was done so the gear would collapse rapidly if it was retracted on the ground. In FGLGear code the gear is initialized to down In Aircraft/controls.cxx gear is initialized to down In preferences.xml gear is initialized to down As near as I can tell the gear is always down on the c182rg model during initialization. I verified this by adding a line to source/src/FDM/JSBSim/models/FGLGear.cpp FGLGear::GetBodyForces if (t30.) cout Gear is down : GearDown endl; Cheers, Ron -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bounce at startup.
-- From: Ron Jensen w...@jentronics.com Sent: Saturday, March 20, 2010 5:28 PM By design a gear doesn't support weight until it reaches 0.99 of extension. This was done so the gear would collapse rapidly if it was retracted on the ground. In FGLGear code the gear is initialized to down In Aircraft/controls.cxx gear is initialized to down In preferences.xml gear is initialized to down As near as I can tell the gear is always down on the c182rg model during initialization. I verified this by adding a line to source/src/FDM/JSBSim/models/FGLGear.cpp FGLGear::GetBodyForces if (t30.) cout Gear is down : GearDown endl; Cheers, Ron Ron I added your test line to FGLGear.cpp, and with my model GearDown is 0 for 3 frames and then 1 for 4 frames. This is not so for aircraft that do not exhibit the bounce fault, so it looks as if I have go through the spaghetti code that is my FDM and model. Thanks for the help. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Messy properties for nav radios
I'd like to encourage everyone to put properties where they would belong in real life -- I took a look at the properties for the nav radio, and they gave me a bit of a headache. Think of what a nav radio and indicator do and don't know in real life: Does know: - what frequency is tuned in on the radio (and the alternate) - what radial the pilot has selected on the indicator - whether it's receiving a VOR/localizer - whether it's receiving a GS - whether the TO or FROM flag is showing - whether the ident volume is turned up - the GS and CDI deviation etc. Doesn't know: - the true heading/bearing of the VOR radial - the time to intercept the VOR or radial - the VOR's error - distance to the VOR etc. I understand that these properties are convenient for other systems, but they should go somewhere they would be in real life, like a DME, GPS database or FMS, not in the (relatively dumb) nav radio itself under /instrumentation/nav/. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bounce at startup.
-- From: Alan Teeder ajtee...@v-twin.org.uk Sent: Saturday, March 20, 2010 6:55 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bounce at startup. -- From: Ron Jensen w...@jentronics.com Sent: Saturday, March 20, 2010 5:28 PM By design a gear doesn't support weight until it reaches 0.99 of extension. This was done so the gear would collapse rapidly if it was retracted on the ground. In FGLGear code the gear is initialized to down In Aircraft/controls.cxx gear is initialized to down In preferences.xml gear is initialized to down As near as I can tell the gear is always down on the c182rg model during initialization. I verified this by adding a line to source/src/FDM/JSBSim/models/FGLGear.cpp FGLGear::GetBodyForces if (t30.) cout Gear is down : GearDown endl; Cheers, Ron Ron I added your test line to FGLGear.cpp, and with my model GearDown is 0 for 3 frames and then 1 for 4 frames. This is not so for aircraft that do not exhibit the bounce fault, so it looks as if I have go through the spaghetti code that is my FDM and model. Thanks for the help. Alan Thanks Ron , your patch pointed me to the problem, which is now fixed. I had bits of code stolen/borrowed from various aircraft and they were fighting each other. On to the next problem Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug: nav[12] selected radial
There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. Curt. On Sat, Mar 20, 2010 at 5:09 PM, David Megginson wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
It's actually even more confusing than that: the initial value seems to depend on whether the --vor option is selected, what the heading is, etc. All the best, David On Sat, Mar 20, 2010 at 6:09 PM, David Megginson david.meggin...@gmail.com wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 6:19 PM, Curtis Olson curtol...@gmail.com wrote: Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. All the best, David Curt. On Sat, Mar 20, 2010 at 5:09 PM, David Megginson wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Messy properties for nav radios
On 20 Mar 2010, at 21:05, David Megginson wrote: I understand that these properties are convenient for other systems, but they should go somewhere they would be in real life, like a DME, GPS database or FMS, not in the (relatively dumb) nav radio itself under /instrumentation/nav/. Yep, this has got very messy, I have a plan I'm discussing to clean this up, and fix up a GPS bug I introduced where where nav radial gets over-written, but any clean-up has to be predicated on not breaking the enormous number of aircraft, instruments, autopilots and so on that assume /instrumentation/nav[0] does this huge range of messy, non-realistic-for-a-physical-VOR-receiver stuff. One thing I've already done is refactor the code so that 'updateReceiver' does the real VOR stuff, and other updateFoo methods do logic which should move elsewhere. I do want to move this forwards, but it needs to be done rather carefully to avoid some pretty major aircraft breakage. Suggestions are welcome, and I'll try to write up some wiki pages on how I propose to move the tangle forwards. James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On 20 Mar 2010, at 22:24, David Megginson wrote: It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. It would help to explicitly define what the desired behaviour of the options is - and obviously, the nav-radio should work entirely in magnetic headings. As the person most recently hacking the navradio code, I think that's still more-or-less the case, but some bugs have presumably crept in along the way. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Hi James, The nav radio does not work in magnetic headings. It works in which ever alignment the station was setup in. In the 60's when GEP was installed, it was aligned with magnetic north at that time. In the subsequent years, the actual magnetic north has shifted several degrees, but the FAA does not go in and adjust the orientation of the station radials every few months. This would cause all kinds of cascading changes with radials, victor highways, intersection points, etc. Instead, they just leave it where it is. So it's key to align the vor station with the defined offset, not the current magnetic offset ... Regards, Curt. On Sat, Mar 20, 2010 at 6:22 PM, James Turner wrote: On 20 Mar 2010, at 22:24, David Megginson wrote: It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. It would help to explicitly define what the desired behaviour of the options is - and obviously, the nav-radio should work entirely in magnetic headings. As the person most recently hacking the navradio code, I think that's still more-or-less the case, but some bugs have presumably crept in along the way. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 7:22 PM, James Turner zakal...@mac.com wrote: There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. Actually, I think that might be it. It's hard to experiment right now, because I'm in Lucid with the slow open source driver until the ATI proprietary drivers come out, so start-up time takes forever. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) We're around 14W here -- just enough to notice. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On 03/20/2010 03:09 PM, David Megginson wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. I am unable to reproduce this issue in the default c172p. I just did an in-flight VOR receiver check, using standard pilot procedures in accordance with FAR 91.171. I went to SUTRO intersection, dialed up the 287 radial of the SFO VOR, and verified that the needle was (a) properly centered and (b) properly sensitive to OBS changes. I used: --fix=STINS --nav1=287:115.8 --nav2=287:115.8 and I verified that the OBS cards did in fact get set to 287. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. There was a bug reported under the Subject: [Flightgear-devel] Setting OBS on command line/.fgfsrc a couple of weeks ago ... but it only affected nav1 IIRC. And it had nothing to do with magnetic variation IIRC. There are some creepy bugs associated with navradio.cxx and with command-line processing ... but this magnetic variation issue is not easily reproducible chez moi. This is with freshly pulled and compiled sources from a few minutes ago. The issue was equally non-observed using sources from two weeks ago. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Operating System
Hi, I'm planning to buy a new PC with operating system. Is there any OS that is not supported by FlightGear? I want to be sure I'll be able to compile and run FlightGear. Is Windows 7 64-bit supported? Or should I better stay with Windows 7 32-bit. Please Linux people don't laugh at me :( Thank you! Fabian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Operating System
Make sure you get an install Windows7 CD and create a dual boot, that's what I,ve got , although I rarely use m$ wind. pete Leonardo Fabian Grodek wrote: Hi, I'm planning to buy a new PC with operating system. Is there any OS that is not supported by FlightGear? I want to be sure I'll be able to compile and run FlightGear. Is Windows 7 64-bit supported? Or should I better stay with Windows 7 32-bit. Please Linux people don't laugh at me :( Thank you! Fabian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Operating System
I see no reason why 64 bit wouldn't work, but I haven't used Windows in ages(nor have I compiled anything on it). Make sure you get an install Windows7 CD and create a dual boot, that's what I,ve got , although I rarely use m$ wind. pete Leonardo Fabian Grodek wrote: Hi, I'm planning to buy a new PC with operating system. Is there any OS that is not supported by FlightGear? I want to be sure I'll be able to compile and run FlightGear. Is Windows 7 64-bit supported? Or should I better stay with Windows 7 32-bit. Please Linux people don't laugh at me :( Thank you! Fabian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
SInce this is related , I'll ask here . I've got a 2 pointer RMI well under way , and according to the few documents I found , the RMI gets its input from the ADF and Nav receiver ... it doesn't do the calculations itself. So is better to NOT to use the /nav/heading-deg ? Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
