Re: [Flightgear-devel] how to gray out autopilot menu?
On Thu, 2009-12-24 at 14:25 -0700, dave perry wrote:
> Hi,
>
> I have searched both the c172p and SenecaII folder for "autopilot" or
> "gui" or just "menu" and I can not find how these AC gray out the
> autopilot menu. What's the secret?
>
> Dave P.
In Nasal/gui.nas is this line:
menuEnable("autopilot", props.globals.getNode("/autopilot/KAP140/locks") ==
nil);
It disables the autopilot menu when /autopilot/KAP140/locks exists...
You could call menuEnable("autopilot", 0); for yourself if you don't
want the menu to appear for your aircraft...
Ron
--
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] how to gray out autopilot menu?
Hi, I have searched both the c172p and SenecaII folder for "autopilot" or "gui" or just "menu" and I can not find how these AC gray out the autopilot menu. What's the secret? 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] Some bugs
On Dec 24, 2009, at 11:37 AM, Peter Brown wrote: > > On Dec 24, 2009, at 5:14 AM, James Turner wrote: > >> >> On 24 Dec 2009, at 06:36, Peter Brown wrote: >> >>> -the route manager sometimes will open with 36000 feet in the hold altitude >>> box, and 7240 kts in the hold speed box. Any attempt to change them will >>> default back to these amounts. I am trying to see if relates to any >>> particular aircraft, but to date it's been pretty random. >> >> That is very odd, some uninitialized values or similar. Though 36000 is a >> bit specific. Is it always these exact values, each time? >> >> Anyone else ever seen this? >> >> Regards, >> James > > James, > > First off, (it was late last night) let me correct my statement. I am > referring to the generic autopilot, not the course manager. It does not seem > to have any correlation to the course manager. > > I'm finding it more specific. > Example A - > Aircraft : AD-6, F-4N, A-3D, RA-5 > Airport : KGFL > Runway : 30 > Heading bug : 130.94 > True Heading : unreadable due to it flipping. Click on the box and sometimes > I will get 116.835, the other times I can get 344.532 > Alt Hold : 18 - This is unchangable > Speed Hold : 120 - This is unchangable > > I'm not flying each model right now, but previously all other parameters > would work (wing leveler, pitch hold, VS hold, etc) > So I was thinking it was a jsb relation, but then I tried these same aircraft > at KPBG and they work fine. Can it be a navaid issue? > > The issue will carry forward with you. If you change airports using the > "location" menu, the issue will stay, but the numbers will change. > If you quit and restart at another airport (that doesn't have an issue such > as KPBG) then it works fine. > > I just tried Gary "Buckaroo" Neeley's new MD-81, which is a very good yasim > fdm but has no other interference as a test bed, and it displays the same > data issues in Autopilot. > > Seems like random airports where this shows up. KBGR and KPBG it works fine, > but KALB it's there. > KALB > Aircraft : dh2w, MD-81, 777-200ER > Heading bug : 114.421 > True Heading : 265.842, or 100.613, depending when you click the box. > Alt Hold : 18, unchangable > Speed hold : 120, unchangable > > So that's interesting - the Beaver and MD-81 has no autopilot, and while I > don't fly the 777, I assume it does(?). > > Hope that helps, > Peter > James, 3 more notes - At KJFK in either Gerard's Fouga Magister, or the Senecall - these are more typical numbers that I referred to initially. Heading Bug : 249.177 True Heading : 236.009, but every few seconds it jumps to something else and then comes back. Can't click it fast enough to catch the other heading. Alt hold : 36, unchangeable. This is the most common number - 36 or 36000. Speed hold : 8246. unchangeable. This is the most common number here - 7246 or 8246. At KJFK in the KC-135 Heading bug : 249.165 True heading : 235.997 or 275.767, this one jumps just long enough to click and catch the 275.767 - otherwise unchangeable. Alt hold : 36, unchangeable. Speed hold : 8245. unchangeable. Peter -- 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] Autopilot broken, Eric maybe?
> I already took a look into several times, but if I would able to use the > Bravo-flightdirector as an example I wouldn't have said this. Syd's > flightdirector seems to dependant on other things ( not always other > simlated systems) so I wasn't able yet to use this. > > I guess a short explanation of the flight director nasal code is this: It is more or less an autopilot controller , to manage modes like armed , then capture points, and handle pilot button presses... The autopilot in passive mode IS acting as a flight director , since it goes through the motions , but doesn't output the results to the control surfaces .Those outputs can be used to animate V-bars. That nasal code probably could use a serious cleaning up , its been a learn as i go project ... Its also adapted from Curt's original flight director code , which I probably trashed trying to be helpful :) Cheers and Merry Christmas -- 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] Some bugs
On Dec 24, 2009, at 5:14 AM, James Turner wrote: > > On 24 Dec 2009, at 06:36, Peter Brown wrote: > >> -the route manager sometimes will open with 36000 feet in the hold altitude >> box, and 7240 kts in the hold speed box. Any attempt to change them will >> default back to these amounts. I am trying to see if relates to any >> particular aircraft, but to date it's been pretty random. > > That is very odd, some uninitialized values or similar. Though 36000 is a bit > specific. Is it always these exact values, each time? > > Anyone else ever seen this? > > Regards, > James James, First off, (it was late last night) let me correct my statement. I am referring to the generic autopilot, not the course manager. It does not seem to have any correlation to the course manager. I'm finding it more specific. Example A - Aircraft : AD-6, F-4N, A-3D, RA-5 Airport : KGFL Runway : 30 Heading bug : 130.94 True Heading : unreadable due to it flipping. Click on the box and sometimes I will get 116.835, the other times I can get 344.532 Alt Hold : 18 - This is unchangable Speed Hold : 120 - This is unchangable I'm not flying each model right now, but previously all other parameters would work (wing leveler, pitch hold, VS hold, etc) So I was thinking it was a jsb relation, but then I tried these same aircraft at KPBG and they work fine. Can it be a navaid issue? The issue will carry forward with you. If you change airports using the "location" menu, the issue will stay, but the numbers will change. If you quit and restart at another airport (that doesn't have an issue such as KPBG) then it works fine. I just tried Gary "Buckaroo" Neeley's new MD-81, which is a very good yasim fdm but has no other interference as a test bed, and it displays the same data issues in Autopilot. Seems like random airports where this shows up. KBGR and KPBG it works fine, but KALB it's there. KALB Aircraft : dh2w, MD-81, 777-200ER Heading bug : 114.421 True Heading : 265.842, or 100.613, depending when you click the box. Alt Hold : 18, unchangable Speed hold : 120, unchangable So that's interesting - the Beaver and MD-81 has no autopilot, and while I don't fly the 777, I assume it does(?). Hope that helps, Peter -- 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] Some bugs
On Dec 24, 2009, at 4:33 AM, Erik Hofman wrote: > Peter Brown wrote: >> -the sound is fine in the cockpit and a few views, but from the tower >> viewpoint (listen to a flyby) and from the model viewpoint (I think there >> are 3 actually), the sound is corrupted. While I don't know why, what I did >> discover was if you moved your location one step in any direction (up or >> down, left or right), the sound returned to normal. This is one step from >> the default viewpoint, such as tower, model, fly-by, etc. > > I don't notice this behavior: what version of OpenAL are you using and > could you describe 'corrupted' some more? > > Erik > > Erik, if you point out a path to me I'll look, but I don't know where to look to check the version of OpenAL. The CVS I'm using was compiled by Tat on the Mac FG site he hosts. If I could describe more accurately I would say that it sounded like the hz was way off, so instead of a recognizable sound wav it is more of a ugly solid tone. If you are using the tower viewpoint and the a/c flys by, the tone still changes as it goes by, but from one "solid" tone to another. Thanks, Peter -- 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] Autopilot broken, Eric maybe?
Hi, > Okay, that's a useful data point, I'll take a look at that > in the next few days (in between eating too much...). I > assume all interactions with the system are occurring > through the radios and autopilot *dialogs* (F12 and F11), > not the cockpit panel? The cockpitpanel isn't working fully right now, as not yet completed, but the dialogs and the autopilot.xml are untouched by me. > Do other autopilot modes work? Do the VNAV modes work, > aside from NAV1-GS hold? VNAV seems to work. Only ILS-Approaches aren't possible right now. > > > Take a look at Syd's scripts? The core flightdirector.nas > scripts are pretty clear, though as always I wish less > copying of files into each aircraft went on. I already took a look into several times, but if I would able to use the Bravo-flightdirector as an example I wouldn't have said this. Syd's flightdirector seems to dependant on other things ( not always other simlated systems) so I wasn't able yet to use this. >If you want help understanding what the scripts do, and how they are > structured, I'm happy to (try to) help. (Actually I think > the scripts could be simplified quite a bit, but Syd may > disagree - he knows better than me!) That's another big point of it - still don't understand quite right waht's the script is doing, how it is structured. > > The flight-drector issue is complicated because the generic > autopilot doesn't provide anything in this area. I have > briefly wondered about writing a C++ generic flight > director, but I don't think it's a good idea - people who > want an accurate flight-drector for a real aircraft will > find it much easier to write a specific one in Nasal (to go > with a custom autopilot) than try to work with a generic C++ > one, I think. But a generic flightdirector with comments written in nasal could help much more. Like the generic systems, autopilot.xml etc... > I'd also be happy to start collecting an 'autopilot > internals' wiki page, to collect information about this kind > of thing in a proper place, and to go alongside my existing > route-manager and GPS/FMS internals documents. > That is a good idea! Merry Christmas HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- 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] Some bugs
James Turner wrote: > On 24 Dec 2009, at 06:36, Peter Brown wrote: > > >> -the route manager sometimes will open with 36000 feet in the hold altitude >> box, and 7240 kts in the hold speed box. Any attempt to change them will >> default back to these amounts. I am trying to see if relates to any >> particular aircraft, but to date it's been pretty random. >> > > That is very odd, some uninitialized values or similar. Though 36000 is a bit > specific. Is it always these exact values, each time? > > Anyone else ever seen this? > > Regards, > James > I have seen this, once - however i could edit the values, and i could not reproduce the 'error' i also saw a negative value for the altitude once (c.a. -1000ft) greets (& merry xmas ;-) ) Nathanael -- 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] Some bugs
On 24 Dec 2009, at 06:36, Peter Brown wrote: > -the route manager sometimes will open with 36000 feet in the hold altitude > box, and 7240 kts in the hold speed box. Any attempt to change them will > default back to these amounts. I am trying to see if relates to any > particular aircraft, but to date it's been pretty random. That is very odd, some uninitialized values or similar. Though 36000 is a bit specific. Is it always these exact values, each time? Anyone else ever seen this? Regards, James -- 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] Some bugs
Peter Brown wrote: > -the sound is fine in the cockpit and a few views, but from the tower > viewpoint (listen to a flyby) and from the model viewpoint (I think there are > 3 actually), the sound is corrupted. While I don't know why, what I did > discover was if you moved your location one step in any direction (up or > down, left or right), the sound returned to normal. This is one step from > the default viewpoint, such as tower, model, fly-by, etc. I don't notice this behavior: what version of OpenAL are you using and could you describe 'corrupted' some more? Erik -- 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
