Re: [Flightgear-devel] right mouse click with pick animation
Hi, indeed my patch doesn't offer a solution as it has a bad side-effect... I forgot to mention that the problem is not limited to the right button, but to *all* buttons. And it is quite annoying when you see that buttons 3 and 4 (mouswheel) are unusuable. The list of aircrafts and instruments using these buttons is impressive, with many aircrafts included in the usual released base-package: a little `grep -rlI 'button3' $FG_ROOT/Aircraft` should show you many many lines. seb Sébastien MARQUE a écrit : I couldn't find the cause in simgear/scene/model/animation.cxx because the solution is in $FG_SRC/src/Input/FGMouseInput.cxx :). Attached a patch to get the old behaviour back. Can it be commited please? Thank you for interest. regards seb Sébastien MARQUE wrote : Hi, I've tried different solutions with the source into simgear/scene/model/animation.cxx (mostly reverting some changes), even if I haven't found anything that I was able to clearly identify as the origin of my problem. So I'm now using a workaround: I add a binding in each involved action section: binding commandproperty-assign/command property type=bool/devices/status/mice/mouse[0]/freezed/property value type=booltrue/value /binding and I've modified $FGROOT/mice.xml in mode n=0 section (see conditions) button n=2 binding condition not property type=bool/devices/status/mice/mouse[0]/freezed/property /not /condition commandnasal/command script setprop(/devices/status/mice/mouse[0]/mode, props.globals.getNode(/input/joysticks/js/id) == nil ? 1 : 2); /script /binding binding condition property/devices/status/mice/mouse[0]/freezed/property /condition commandproperty-assign/command property type=bool/devices/status/mice/mouse[0]/freezed/property value type=boolfalse/value /binding /button It works fine here (even better than before the new behaviour). But I still think that it is a tricky solution. regards seb Sébastien MARQUE wrote : Hi all, I've noticed that using right click on a pick animation doesn't only grab the correct animation's binding, but also the mouse button n=2 binding (default: changing to mouse mode 1)... which can have some disastrous consequences. Some instruments use the right-click as the zkv series (turning knobs right), the F16 hsi, Lionceau on some instruments, Long-EZ magnetos, G-164 altimeter, ch53e in many places over the front panel, and the Seneca II (flaps control). I haven't used FG from last June 09 until November 09, and I remember that right-click on pick animation was known to work fine here in June 09. I'm using FG/CVS, SG/CVS, plib/svn and OSG/svn all of them regularly compiled. I've also tried with plib 1.8.5 and osg 2.8.1 from debian/sid repos, with the same behaviour. Is this a bug or a new feature? Best regards seb -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel --
Re: [Flightgear-devel] nan-a-palooza
On Tue, Dec 15, 2009 at 2:11 AM, Csaba Halász csaba.hal...@gmail.com wrote: That may be the nasal bug Jacob is seeing. I could reproduce it and also made a little test case that I am gonna submit as a gcc bug report. It is clearly accessing the double member of the union before it has been established as valid. Even though there is a related gcc bug, we must realize that the current implementation of naRef is not standard C, it is relying on undefined behaviour: With one exception, if the value of a member of a union object is used when the most recent store to the object was to a different member, the behavior is implementation-defined. That is, setting the num member of a naRef and then examining the ref member (which IS_NUM is doing) is undefined. I believe simply expecting the two members to overlay each other is also relying on undefined behaviour. The best way would be to make naRef bigger by adding a separate tag and not mess with nonstandard stuff. I have also tested making naRef a char[8] and memcpy-ing the relevant bytes out. That still relies on the actual memory layout of a double but should otherwise be standard compliant while keeping the current size. GCC optimized away the memcpy-s for me. Thoughts? -- Csaba/Jester -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
Relying on undefined behavior is definitely no good...might work fine for a long time, but it will come back to bite you eventually. If you can find a way to do it in a compliant way without increasing the size would be ideal I guess, but if you need to increase the size so be it. Nasal is an integral part of flightgear and is so widely spread through every part of the sim it needs to be done properly and reliably. I'll be happy to test whatever you come up with. I personally will be very disappointed if all these nan issues continue into the next release... cheers! -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Thursday 17 Dec 2009, Curtis Olson wrote: I had a squawk here from a (real) King Air pilot because on an ILS approach, our glideslope indicator doesn't become active/in-range until about 7-8 miles out. Beyond this range the indicator just stays centered at zero. With a standard 3 degree glide slope, 7 miles out equates to about 2000' AGL, outside of this range the FlightGear glideslope does nothing. I see our database lists the GS ranges at 10nm usually. However, our code seems to be clamping the range to something significantly less than that. I've been poking around in navdb.cxx and navradio.cxx but haven't been able to connect all the dots yet. I don't have personal knowledge of what is correct, but this change to glideslope range impacts our ability to practice ILS approaches and I have a current King Air pilot complaining about the behavior. Pulling out some old approach plates for KMSP here I see a 14nm distance and 5000' MSL entry altitude (4000'+ AGL) referenced in the approach to 30R. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Thanks, Curt. I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. The occasional AN-124s I've seen come in seem to be already on the glideslope quite a bit further out though - I'd estimate they're on the glideslope by the time they're about 10 nm out (I checked the distances using Google Earth). Iirc, when I last simulated these two types of approach at EGSS I was between 2500-3000ft asl (over ground that's about 200ft asl) as I turned in above my home for the more typical airliner approach, and around 4000ft when I got on the glideslope for a straight in approach using the AN-225 to mimic the AN-124s. In view of what seems to happen at EGSS, I would say that the 14nm range 5000ft altitude seem about right. LeeE -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Braking Power - rate of deceleration
Hey all. Does anyone know of a way to provide more realistic braking power? The deceleration rate seems to be an across-the-board-standard between all aircraft, and from a user point of view I'm not sure it takes weight, mass, or any other physical attribute into account. All I know is if you pushed your toes into the firewall hard enough to slow down that fast, the tires would either shred or catch on fire. I've looked around for a way to apply partial brakes, even such as bindings for b to apply 50% brakes, and Ctrl b can apply 100% brakes. But with my limited knowledge I can't find what provides the brakes to begin with. Has this been discussed before? Thanks, Peter Peter Brown FG Farmboy -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 12:30 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. Turn point? Lined up? I thought the topic of this thread was GS range. GS is not the same as LOC. Anecdotes about turning or lining up don't tell us much about the GS. In view of what seems to happen at EGSS, I would say that the 14nm range 5000ft altitude seem about right. According to the authoritative NATS charts, the final approach fix is at 6.6DME which is about 5.5nm from the touchdown zone, and occurs at an altitude of 2500 feet, no higher, no lower. For this approach, GS intercept should occur at the FAF, no earlier, no later. The turn onto the localizer, for a no-vector approach, is 3 or 4 nm farther out than that. The altitude should be 2500 although 3000 might arguably be tolerated. Radar-vector procedures will be somewhat more variable, but not wildly different. Bottom line: The standard 10nm GS service volume should be more than plenty for the EGSS RWY 04 approach. More generally: Limiting the GS service volume to 10nm or thereabouts is a significant departure (if you'll pardon the expression) from previous FGFS behavior, but it is not wrong. It is a feature, not a bug. References: http://www.nats-uk.ead-it.com/aip/current/ad/EGSS/EG_AD_2_EGSS_7-14_en.pdf http://www.nats-uk.ead-it.com/aip/current/ad/EGSS/EG_AD_2_EGSS_8-1_en.pdf = Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? Thanks, Peter Peter Brown FG Farmboy -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 02:53 PM, John Denker wrote: More generally: Limiting the GS service volume to 10nm or thereabouts is a significant departure (if you'll pardon the expression) from previous FGFS behavior, but it is not wrong. It is a feature, not a bug. Agreed. I often do the ILS rwy 33 approach into KFNL for real for currency maintenance. Often in the procedure turn, the GS flag will activate indicating no usable GS signal. The GS flag may stay until (sometimes after) I start the 45 deg turn to 328 deg inbound on the LOC. This pretty well matches the fgfs GS flag behavior for this approach. Dave P. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Fri, Dec 18, 2009 at 4:33 PM, Peter Brown pe...@smoothwatersports.comwrote: Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? In this particular case we are building a twin turbo prop simulator (Beech 1900) with a full cockpit, dual controls, and wrap around visual system (based largely on FlightGear.) Glide slope range is something the customer commented on, so that pushes it up my priority queue a bit. There are times when it makes sense to debate the customer's perceptions (gently show them why they are incorrect) but in this case I think 10nm is borderline, although upon further discussion, there were other aspects of what was going on that were indeed more important. So no, this isn't a drop dead issue, but at some point if we boost the default service volumes up by a few percent hopefully people won't get too bent out of shape? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] --config nav.dat
Extended LOC volumes are fairly common. Extended GS volumes are not so common, but definitely exist. If anybody wants an example of an approach that does require an extended service volume for the GS (and LOC) ... take a look at KIAH ILS RWY 26R http://204.108.4.16/d-tpp/0912/05461IL26R.PDF === The interesting wrinkle is that the current FG apt.dat does not know that these navaids have extended service volumes. 4 30.00716100 -095.36220300 91 11155 18 269.949 IOND KIAH 26R ILS-cat-III 6 30.00828100 -095.33396100 91 11155 10 300269.949 IOND KIAH 26R GS 12 30.00599400 -095.36231900 84 11155 18 1.700 IOND KIAH 26R DME-ILS From time to time I hear someone recommend let Robin take care of it upstream. That's fine as a long-term strategy, but it doesn't work in the short term, especially given how rarely FG updates its copy. Also it is inconsistent with the way FG handles other things, notably the very powerful --config option that can be used on the command line or in the .fgfsrc file. AFAICT the --config option is presently not, alas, powerful enough to update the navaid database. Suggestion: It would be nice to have a configurable _list_ of filenames to scan for navaid data: nav.dat nav-2.dat et cetera. That way users could maintain short supplemental files that would a) tide them over during the oh-so-long time that it takes to get updates into the official nav.dat b) preserve the supplemental information across updates of the official file. c) not require the user to unpack and edit the big official file. Conventional patch utilities do not perform well on this task. Some cleverness needs to be applied to distinguish the case where a navaid is being _replaced_ versus the case where a navaid with a similar name is being simply _added_. A simple + and - convention should suffice. Similar remarks apply to apt.dat but that's more complicated. I haven't thought about the details. Adding and subtracting on an airport-by-airport basis (as opposed to line-by-line) would be better than nothing. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Friday 18 Dec 2009, John Denker wrote: On 12/18/2009 12:30 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ Just reporting the number that's painted on it. and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. Turn point? Lined up? Pretty obvious, I thought, unless you really want to be pernickty, but you'll have to be pernickty on your own. Unlike you, I'm not trying to make any particular point or criticise anyone... I thought the topic of this thread was GS range. GS is not the same as LOC. Anecdotes about turning or lining up don't tell us much about the GS. ...I'm just offering observational data from real life. Funnily enough, I did so because I thought it might be of help. You just seem to be trying to get your kicks from belittling people though. Hmm... your problem, not mine. LeeE -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 04:22 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ Just reporting the number that's painted on it. The number actually painted on it is 04. It's been that way for several months. I know the Google satellite photo says 05. The photo is out of date. I was reporting the correct information in the hope that it would be helpful. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --config nav.dat
Maybe we could add a KSFO.dat , KHAF.dat, etc, somewhere in the Scenery/ section as a start... Its something I've always hoped for , anyway :) Cheers On 12/18/09, John Denker j...@av8n.com wrote: Extended LOC volumes are fairly common. Extended GS volumes are not so common, but definitely exist. If anybody wants an example of an approach that does require an extended service volume for the GS (and LOC) ... take a look at KIAH ILS RWY 26R http://204.108.4.16/d-tpp/0912/05461IL26R.PDF === The interesting wrinkle is that the current FG apt.dat does not know that these navaids have extended service volumes. 4 30.00716100 -095.36220300 91 11155 18 269.949 IOND KIAH 26R ILS-cat-III 6 30.00828100 -095.33396100 91 11155 10 300269.949 IOND KIAH 26R GS 12 30.00599400 -095.36231900 84 11155 18 1.700 IOND KIAH 26R DME-ILS From time to time I hear someone recommend let Robin take care of it upstream. That's fine as a long-term strategy, but it doesn't work in the short term, especially given how rarely FG updates its copy. Also it is inconsistent with the way FG handles other things, notably the very powerful --config option that can be used on the command line or in the .fgfsrc file. AFAICT the --config option is presently not, alas, powerful enough to update the navaid database. Suggestion: It would be nice to have a configurable _list_ of filenames to scan for navaid data: nav.dat nav-2.dat et cetera. That way users could maintain short supplemental files that would a) tide them over during the oh-so-long time that it takes to get updates into the official nav.dat b) preserve the supplemental information across updates of the official file. c) not require the user to unpack and edit the big official file. Conventional patch utilities do not perform well on this task. Some cleverness needs to be applied to distinguish the case where a navaid is being _replaced_ versus the case where a navaid with a similar name is being simply _added_. A simple + and - convention should suffice. Similar remarks apply to apt.dat but that's more complicated. I haven't thought about the details. Adding and subtracting on an airport-by-airport basis (as opposed to line-by-line) would be better than nothing. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --config nav.dat
To further that thought, I'd like to request dates added above the first line of airport data in each apt.dat file. I've tested info lines added to my apt.dat file and CVS FG has not had any issue reading the data. I do need to verify older versions will be able to still access it correctly. !--Updated layout 12/18/09, Peter Brown -- In revising taxiways and layouts I find it to be helpful, and feel it may be in this case as well. Thanks, Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: syd adams adams@gmail.com Date: Fri, 18 Dec 2009 16:42:45 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] --config nav.dat Maybe we could add a KSFO.dat , KHAF.dat, etc, somewhere in the Scenery/ section as a start... Its something I've always hoped for , anyway :) Cheers On 12/18/09, John Denker j...@av8n.com wrote: Extended LOC volumes are fairly common. Extended GS volumes are not so common, but definitely exist. If anybody wants an example of an approach that does require an extended service volume for the GS (and LOC) ... take a look at KIAH ILS RWY 26R http://204.108.4.16/d-tpp/0912/05461IL26R.PDF === The interesting wrinkle is that the current FG apt.dat does not know that these navaids have extended service volumes. 4 30.00716100 -095.36220300 91 11155 18 269.949 IOND KIAH 26R ILS-cat-III 6 30.00828100 -095.33396100 91 11155 10 300269.949 IOND KIAH 26R GS 12 30.00599400 -095.36231900 84 11155 18 1.700 IOND KIAH 26R DME-ILS From time to time I hear someone recommend let Robin take care of it upstream. That's fine as a long-term strategy, but it doesn't work in the short term, especially given how rarely FG updates its copy. Also it is inconsistent with the way FG handles other things, notably the very powerful --config option that can be used on the command line or in the .fgfsrc file. AFAICT the --config option is presently not, alas, powerful enough to update the navaid database. Suggestion: It would be nice to have a configurable _list_ of filenames to scan for navaid data: nav.dat nav-2.dat et cetera. That way users could maintain short supplemental files that would a) tide them over during the oh-so-long time that it takes to get updates into the official nav.dat b) preserve the supplemental information across updates of the official file. c) not require the user to unpack and edit the big official file. Conventional patch utilities do not perform well on this task. Some cleverness needs to be applied to distinguish the case where a navaid is being _replaced_ versus the case where a navaid with a similar name is being simply _added_. A simple + and - convention should suffice. Similar remarks apply to apt.dat but that's more complicated. I haven't thought about the details. Adding and subtracting on an airport-by-airport basis (as opposed to line-by-line) would be better than nothing. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
