Re: [Flightgear-devel] a few more bugs
John Denker wrote: One guy says not to report bugs in the old FGPiston, because it has been fixed upstream. Another guy say snot to report bugs in the new FGPiston, because it is not committed code. I guess that's one way to make sure there are no reported bugs. Fair enough, but make sure that all the files are in sync then. Looking at the progress of FlightGear 1.9.1 it will be a short time inconvenience anyhow. Erik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
I quote from http://www.av8n.com/fly/fgfs/htm/bug-list.htm 80::As of mid-January 2008, there is a “new” version of FGPiston.cpp floating around. It has not yet been committed to FlightGear CVS. It gets rid of the specific problems mentioned in bug 79, replacing them with new and different unrealistic behaviors. For one thing, it causes many FG aircraft – including the c172p – to idle at very low revs, or stall completely. It is not realistic at high throttle settings either. In the FG flagship c172p for example, on the runway at KSFO, full throttle, standard say, it develops 1205368 ft density altitude, standard day, full throttle, it develops 104 Unlike the “old” version mentioned in bug 79, the “new” version pretends to model the physics of the throttle. Alas, it is a very thin pretense. It uses physicsy-sounding words like ThrottleAngle and throttle_area, but these are only words. The code that computes them bears no discernible relationship to real physics. This is particularly odd, since the physics was worked out some time ago and shows remarkably good agreement between the model and Real World data. This is explained at ../../engine.htm. Code to implement a reasonable physics-based throttle model exists. It does not fix all the bugs in FGPiston.cpp, but it is a step in the right direction. 81::The FlightGear interface to the festival text-to-speech server is documented in section 5.6.2 of the getstart manual. I observe that it doesn’t work (even though the festival server itself works fine when FG is not running). It hasn’t worked for years. I have never heard of anyone actually using it. The TTS idea would be a lot more useful if it were integrated via the c++ API as documented at http://www.speech.cs.cmu.edu/festival/manual-1.4.1/festival_28.html 82::Choppy video and sound. I observe that things work fine when the FlightGear window is the default size, 800x600. The frame rate is in the range 45 to 50. However, if I enlarge the window even slightly, e.g. 1000x750, things go to pot. The reported frame rate (as given by the orange number in the lower-right corner) drops to around 30, which wouldn’t be so bad except that the actual frame rate drops to around 5. That is to say, the video becomes horribly choppy. The sound also becomes horribly choppy, to the point where the ATIS and IDENT features are unusable. No error messages, no warnings, just choppy video and sound. I observe that things work much better using the command-line option –prop:/sim/frame-rate-throttle-hz=30. This is observed using an ATI RV350 [Mobility Radeon 9600] and the proprietary fglrx driver. (The last time I checked, the xorg radeon driver was not an option, since it lacked some required capabilities.) 83::The Environment system is in need of some TLC. For one thing, FlightGear appears to have several different models of the atmosphere. 0) The FDM has its own model, but this is sometimes turned off and the FDM is slaved to the FG model, so maybe this one shouldn’t even count. 1) The popup GUI has its own model of the atmosphere. It is a very complicated model with approximately seven layers just within the troposphere. This GUI has been used, with some success, to specify multiple layers of clouds. However, the GUI imparts the distinct impression that users can independently set the temperature and pressure in each layer, which is a wild violation of the laws of physics. The backend performs complex calculations based on the pressure and temperature numbers provided by the GUI, but this is all in vain. The results of almost all these calculations are ignored. 2) There also exists an inchoate METAR interface. The relationship between this and the popup GUI is complex and buggy. This holds out some hope of a future interface that makes sense, i.e. multiple layers of clouds plus a two-parameter model of the atmosphere. 3) The code that calculates the actual static pressure seen by the airplane ignores almost all of the many numbers provided by the GUI. I can’t decide whether this is one-parameter model or a two-parameter model. It purports to be a two-parameter model, but it ignores one of them. Specifically, it ignores the temperature when calculating the pressure-versus-height profile, in defiance of the laws of physics. This is a bug. This model is tabulated, and ends abruptly at around 100,000 feet. Some modelers find this limitation to be a problem. What’s more, it takes the “zero AGL” number from the GUI and uses it as if it were the “zero MSL” number. This is another bug. 4) The altimeter has its own model. This is a highly accurate algebraic (not tabulated) model. It is currently valid to the top of the stratosphere, but could easily be extended to the top of the mesosphere. (A patch to do this exists.) Code exists to provide FlightGear with a highly accurate two-parameter model of the atmosphere, valid up to 262,467 feet, i.e. 80 kilometers, i.e. the top of the mesosphere.
Re: [Flightgear-devel] a few more bugs
John Denker wrote: I quote from http://www.av8n.com/fly/fgfs/htm/bug-list.htm 80::As of mid-January 2008, there is a “new” version of FGPiston.cpp floating around. It has not yet been committed to FlightGear CVS. It gets rid of the specific problems mentioned in bug 79, replacing them with new and different unrealistic behaviors. For one thing, it causes many FG aircraft – including the c172p – to idle at very low revs, or stall completely. This is fixed by using the corresponding engine configurtion file. It is not realistic at high throttle settings either. In the FG flagship c172p for example, on the runway at KSFO, full throttle, standard say, it develops 1205368 ft density altitude, standard day, full throttle, it develops 104 This might be the same, please report bug for committed code only. Erik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
* John Denker -- Friday 23 January 2009: 81::The FlightGear interface to the festival text-to-speech server [...] doesn’t work [...] It hasn’t worked for years. I have never heard of anyone actually using it. Works for me since years. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
Melchior FRANZ wrote: * John Denker -- Friday 23 January 2009: 81::The FlightGear interface to the festival text-to-speech server [...] doesn???t work [...] It hasn???t worked for years. I have never heard of anyone actually using it. Works for me since years. Someone who's using this feature might check if chapter 5.6 of The Manual is still up to date and, if this is not the case, provide fixes, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
One guy says not to report bugs in the old FGPiston, because it has been fixed upstream. Another guy say snot to report bugs in the new FGPiston, because it is not committed code. I guess that's one way to make sure there are no reported bugs. = If anybody is interested in a throttle model that actually works right, please let me know. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On Fri, 23 Jan 2009 07:29:25 -0700, John wrote in message 4979d445.3070...@av8n.com: 82::Choppy video and sound. I observe that things work fine when the FlightGear window is the default size, 800x600. The frame rate is in the range 45 to 50. However, if I enlarge the window even slightly, e.g. 1000x750, things go to pot. The reported frame rate (as given by the orange number in the lower-right corner) drops to around 30, which wouldn’t be so bad except that the actual frame rate drops to around 5. That is to say, the video becomes horribly choppy. The sound also becomes horribly choppy, to the point where the ATIS and IDENT features are unusable. No error messages, no warnings, just choppy video and sound. I observe that things work much better using the command-line option –prop:/sim/frame-rate-throttle-hz=30. This is observed using an ATI RV350 [Mobility Radeon 9600] and the proprietary fglrx driver. (The last time I checked, the xorg radeon driver was not an option, since it lacked some required capabilities.) ..tried http://www.phoronix.com/forums/showthread.php?t=10181 ? ..my understanding is AMD/ATI's proprietary fglrx driver is dropping support of old cards to make people buy new cards. Novell's and AMD/ATI's radeonhd xorg driver has similar problems, not supporting old cards at all, and is even straggling behind X.org's radeon on AMD/ATI's new cards: http://www.x.org/wiki/RadeonFeature http://www.x.org/wiki/RadeonProgram http://www.phoronix.com/scan.php?page=news_itempx=NjgwMA ..further background: http://www.phoronix.com/scan.php?page=articleitem=radeon_vs_radeonhdnum=1 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On Jan 23, 2009, at 6:29 AM, John Denker wrote: I quote from 81::The FlightGear interface to the festival text-to-speech server is documented in section 5.6.2 of the getstart manual. I observe that it doesn’t work (even though the festival server itself works fine when FG is not running). It hasn’t worked for years. I have never heard of anyone actually using it. Well John... it happens for the best of us! and today is then the day you are 100% wrong .i use festival all the time ... although in a different way... it is a script that takes the speech from the variables and sends it out too a script and from that over in my sheech thingie. I wont go in to details on how it works but im blind so take my word for it ... speech works IIRC Anders tried festival out It did not work to our pleasure so we gone other ways. If you can clinically explain to me what you are trying too do i will be happy to help out however if it is jsut your usual rambling dont waste my time. A short list of what i have speech on. heading throttle vsi bank/roll pitch vor ils-instrument and a few more is not important for you at the time of speaking. Back too your festival problem. I know others have it running but since i need the speech to talk... very fast over 200 words a minute i gave it up... As i said. Anders tried it out on his box when we looked in too what could be done about speech and responsiveness. a few words on the setup i have. Espeak which is a opensource synth is taking care of the sound... a perlscript is taking care of the redirection of the sound too the speech. Since you are a sighted person i would not recomment a speech as espeak for your use... I would use say for mac I dont know what there is of synth's for linux i dont have a working box that can run flightgear on linux. The TTS idea would be a lot more useful if it were integrated via the c++ API as documented at http://www.speech.cs.cmu.edu/festival/manual-1.4.1/festival_28.html I have not seen it but i believe the tts idea is fine as it is. It just need to get changed in the manual. /sandi 82::Choppy video and sound. I observe that things work fine when the FlightGear window is the default size, 800x600. The frame rate is in the range 45 to 50. However, if I enlarge the window even slightly, e.g. 1000x750, things go to pot. The reported frame rate (as given by the orange number in the lower-right corner) drops to around 30, which wouldn’t be so bad except that the actual frame rate drops to around 5. That is to say, the video becomes horribly choppy. The sound also becomes horribly choppy, to the point where the ATIS and IDENT features are unusable. No error messages, no warnings, just choppy video and sound. I observe that things work much better using the command-line option –prop:/sim/frame-rate-throttle-hz=30. This is observed using an ATI RV350 [Mobility Radeon 9600] and the proprietary fglrx driver. (The last time I checked, the xorg radeon driver was not an option, since it lacked some required capabilities.) 83::The Environment system is in need of some TLC. For one thing, FlightGear appears to have several different models of the atmosphere. 0) The FDM has its own model, but this is sometimes turned off and the FDM is slaved to the FG model, so maybe this one shouldn’t even count. 1) The popup GUI has its own model of the atmosphere. It is a very complicated model with approximately seven layers just within the troposphere. This GUI has been used, with some success, to specify multiple layers of clouds. However, the GUI imparts the distinct impression that users can independently set the temperature and pressure in each layer, which is a wild violation of the laws of physics. The backend performs complex calculations based on the pressure and temperature numbers provided by the GUI, but this is all in vain. The results of almost all these calculations are ignored. 2) There also exists an inchoate METAR interface. The relationship between this and the popup GUI is complex and buggy. This holds out some hope of a future interface that makes sense, i.e. multiple layers of clouds plus a two-parameter model of the atmosphere. 3) The code that calculates the actual static pressure seen by the airplane ignores almost all of the many numbers provided by the GUI. I can’t decide whether this is one-parameter model or a two-parameter model. It purports to be a two-parameter model, but it ignores one of them. Specifically, it ignores the temperature when calculating the pressure-versus-height profile, in defiance of the laws of physics. This is a bug. This model is tabulated, and ends abruptly at around 100,000 feet. Some modelers find this limitation to be a problem. What’s more, it takes the “zero AGL” number from the GUI and uses it as if it were the “zero MSL” number. This is another bug. 4) The altimeter has its own model.
Re: [Flightgear-devel] a few more bugs
Ron == Ron Jensen writes: 81:: Consider the case where FlightGear is run with the --disable-ai-models command line option. It appears that some of the ai-related code continues to run. You can easily verify by turning on log-level=info, in which case you will see screen after screen of ?scheduling? messages. The messages refer to ?scheduling? events many days in the future. I reckon they shouldn't be scheduled at all when the ai-models feature is turned off. Ron This is not a bug. ai-models refers explicitly to the 3D Ron models, which are used by scenarios, multiplayer and AI Ron traffic. AI traffic scheduling is done by the Ron traffic-manager. You want Ron --prop:/sim/traffic-manager/enabled=0 I've noticed that with AI traffic turned on, there is a constant setting and resetting of the time accessed by globals-get_time_params(), presumably as a result of events scheduled many days in the future that John mentioned in his post. This doesn't seem to cause any obvious problems in FlightGear, but this does cause Atlas to get horribly confused when connected to FlightGear - the time-stamped messages it receives jump all over the place. With AI traffic turned off, the problem goes away. Assuming that AI traffic is indeed the source of the problem, is there any way to tell the AI aircraft not to reset the clock? Or, alternatively, is there a pristine time source that the atlas.cxx code can use, instead of globals-get_time_params()? Brian -- Brian Schack 19 Xǔchāng Street 2Fphone: 2381 4727 Taipei 100 fax:2381 2145 TAIWAN -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
Brian Schack wrote: I've noticed that with AI traffic turned on, there is a constant setting and resetting of the time accessed by globals-get_time_params() This sounds like a misplaced leading slash in a property for AI models to me. Erik -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
79::Let’s do an ordinary preflight runup in the c182rg. With the prop control full forward, advance the throttle to 1700 rpm in accordance with the POH checklist. Now pull the prop control full back. In the Sim World as of 1.9.0, I observe the RPM drops from 1700 to 1400. This is highly unrealistic, because in the Real World, the drop is much greater; I estimate the low RPM is down around 900 or so. As a related observation, with the SW throttle all the way back, the property tree says that the governor is regulating the propeller at 900 rpm. That is, the propeller pitch is not on the fine-pitch stop, even with the throttle all the way back, with the engine developing only 10% of its rated shaft horsepower. This is highly unrealistic. As previously mentioned, 900 RPM is about the right number, but the prop really should be on the fine-pitch stop. Advancing the throttle a tiny bit above idle causes the prop to hit the coarse-pitch stop. This suggests there is something wrong with the propeller model. There is no chance that this problem is related to bug 80. The propeller is misbehaving as a function of shaft power, and if you know the shaft power, it doesn’t matter what throttle setting or other settings produced that power. 80::As of 1.9.0, in the c182rg on the runway at KSFO, I observe that with the throttle wide open the MAP is 29.97. With the throttle pulled back to 0.6, the MAP is still 29.97. This is wildly unrealistic. Similar problems in the c172p model have been reported. In the Real World, the throttle is a butterfly valve; flowing a large amount of air through a half-closed butterfly valve causes a large pressure drop. Any RW pilot would notice this before takeoff, and would conclude that the throttle (or throttle linkage) was broken. This problem almost certainly results from an unphysical model embodied in the .cxx code. The code does not model the throttle as a valve. As a consequence, no amount of fiddling with the engine configuration .xml files will fix this problem. There is no chance that this problem is related to bug 79. 81::Consider the case where FlightGear is run with the --disable-ai-models command line option. It appears that some of the ai-related code continues to run. You can easily verify by turning on log-level=info, in which case you will see screen after screen of “scheduling” messages. The messages refer to “scheduling” events many days in the future. I reckon they shouldn't be scheduled at all when the ai-models feature is turned off. For additional details, see http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-ai-scheduling -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On Thu, 2009-01-08 at 13:49 -0700, John Denker wrote: 80::As of 1.9.0, in the c182rg on the runway at KSFO, I observe that with the throttle wide open the MAP is 29.97. With the throttle pulled back to 0.6, the MAP is still 29.97. This is wildly unrealistic. Similar problems in the c172p model have been reported. In the Real World, the throttle is a butterfly valve; flowing a large amount of air through a half-closed butterfly valve causes a large pressure drop. Any RW pilot would notice this before takeoff, and would conclude that the throttle (or throttle linkage) was broken. Since you don't list an RPM, let me suggest at 0 rpm this is the desired behavior :). You're suggesting we're flowing a large amount of air through a half closed valve, but without an RPM I can't verify this. Also, you don't mention what the ambient pressure at KSFO is. Its been running about 30+ inHg of late if you have real weather turned on. Please don't duplicate your bug reports, especially as this has been fixed up stream, you are just generating noise here. 81::Consider the case where FlightGear is run with the --disable-ai-models command line option. It appears that some of the ai-related code continues to run. You can easily verify by turning on log-level=info, in which case you will see screen after screen of “scheduling” messages. The messages refer to “scheduling” events many days in the future. I reckon they shouldn't be scheduled at all when the ai-models feature is turned off. This is not a bug. ai-models refers explicitly to the 3D models, which are used by scenarios, multiplayer and AI traffic. AI traffic scheduling is done by the traffic-manager. You want --prop:/sim/traffic-manager/enabled=0 For additional details, see http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-ai-scheduling -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On 01/08/2009 04:59 PM, Ron Jensen wrote: this has been fixed up stream, Wow. That's great. Perhaps I overlooked the announcement. Will the fix be coming downstream anytime soon? Is there any other news we should know about. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
75:: As of 1.9.0, in the c182, the altimeter is not self-consistent. There is an analog scale and a digital readout. It takes 10 clicks of the Kollsman setting knob to move the digital readout ten hundredths of an inch. It takes 14 or 15 clicks to rotate the analog scale the corresponding amount. Neither readout appears to produce entirely accurate altimetry, although the analog scale is clearly worse. This is highly unrealistic. There exist other altimeter models that are both prettier and more functional. 76:: Newton’s laws are still being violated by environment.cxx. The pressure profile (P versus h) is incorrect. This has many consequences. It greatly affects altimetery, but also affects engine performance, airfoil performance, et cetera. In particular it means the simulator fails to exhibit the HALT phenomenon (high altimeter because of low temperature). For quantitative details on this, see http://www.av8n.com/fly/fgfs/htm/bug-list.htm This bug has been known for years. The code to fix it was written years ago, but not incorporated. 77:: In the default c172p model, sitting on the runway at KSFO, at full power the engine consumes about 78 pph of fuel. So far, so good. Now stop the engine by pulling the mixture to cutoff. I observe that the fuel flow, as reported by the FDM via the property tree, settles above 8 pph. That’s more than a gallon per hour, with no mixture and no revs. That seems like rather a large leak. Similar phenomena have been observed in other aircraft models. 78:: As of 1.9.0, in the c182rg, I observe that the menu item reload panel doesn’t reload the panel. Shift-F3 doesn’t reload the panel either. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On Wed, 2009-01-07 at 17:34 -0700, John Denker wrote: 77:: In the default c172p model, sitting on the runway at KSFO, at full power the engine consumes about 78 pph of fuel. So far, so good. Now stop the engine by pulling the mixture to cutoff. I observe that the fuel flow, as reported by the FDM via the property tree, settles above 8 pph. That’s more than a gallon per hour, with no mixture and no revs. That seems like rather a large leak. Similar phenomena have been observed in other aircraft models. In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only calculated when we actually consume fuel. Slamming the mixture to 0 at a high fuel flow rate causes consumption to stop leaving the FuelFlow_pph value unable to update and stuck indicating a high value. If you'll notice, fuel is not actually flowing, its just an incorrect indication. Ron -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only calculated when we actually consume fuel. Slamming the mixture to 0 at a high fuel flow rate causes consumption to stop leaving the FuelFlow_pph value unable to update and stuck indicating a high value. If you'll notice, fuel is not actually flowing, its just an incorrect indication. Ron Still, this sounds like a code bug. I'll take a look. Jon -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
Additional JSBsim FDM initialization-related bugs: 62:: I observe that in a JSBsim aircraft e.g. c182rg, after departing the runway via the location-in-air menu item, there remains weight on wheels. That is, the gear/wow property remains true. It appears to remain true forever, long after the model aircraft is airborne. This is significant because it prevents the gear from retracting. This is an old bug that was fixed for a while but has now returned. This bug is *not* observed in non-JSBsim aircraft such as the pa24-250. 63:: The command-line options --roll-deg and --pitch-deg are documented to exist according to --help --verbose, and are accepted by the CLI parser ... but in JSBsim aircraft (such as the default c172p) they are not observed to have any effect on the aircraft. As previously reported, the corresponding presets have no effect during a re-init, e.g. via fgcommand(presets-commit). -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
57:: Core feature: As of CVS 26 Dec 2008 I observe that at (say) KJFK the Tower view and the Tower Look From view are conspicuously broken. Other airports are broken, just less conspicuously so. This appears to be the same problem previously discussed on the devel list under the heading nearcamera still not rendering ... i.e. users can see through the ground and discover that short buildings are really just tall buildings sunk deep into the ground. Previously the remedy was to upgrade to OSG 2.7.3 or higher ... but it appears the problem still exists with OSG 2.7.7. Also in the Helicopter view, there is some weird flickering that may be the flickering gap previously attributed to nearcamera problems. 58:: Instrument backend: As of CVS 26 Dec 2008, adf.cxx was doing a number of conspicuously unrealistic things, including continuing to drive the needle even after the tuner had been turned off. A patch is available. 59:: Instrument: As of CVS 26 Dec 2008 it appears that the 2D ADF front-end (as installed in e.g. the c182 and c182rg) lacks an on/off switch. What's worse, it appears to lack any kind of test function ... which is sometimes rather important when using an ADF in the Real World. In contrast, the 3D ADF front end in the c172p does implement these features (although it still needs to get its hotspots lined up with its buttons; see bug #12). 60:: c172p: several instruments: As of CVS 26 Dec 2008, several instruments including the ADF and the VHF navcomms as installed in the c172p have the following property: When the electrical power is cut off, their front-end displays continue to glow merrily (even though the VOR CDI needles stop working). This is unrealistic. As discussed on the list, it would be straightforward to fix this bug plus the previous bug (and bug #12 too) by patching the private copies of these instruments associated with the c172p, but it would be a much better use of resources, in the short run and super-especially in the long run, to un-fork the code and teach the c172p to use instruments e.g. from the pa24-250 where these bugs have long since been fixed. A patch to do this is available. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] a few more bugs
Remark: Not all of these bug reports are orignal with me. Some were pointed out to me off-list. 47:: c172p, dhc2, and a tiny bit of SenecaII: As of 1.9.0, apparently neither the c172p nor the dhc2 have have an outside air temperature gauge. An OAT gauge is factory-standard equipment for these aircraft in the Real World, although it is apparently not absolutely mandatory in the US. In any case, trying to fly without an OAT gauge could be mighty unpleasant, in a wide range of practical situations, including hot weather or cold weather, especially at night and/or IFR, especially in mountainous terrain. As of 1.9.0, the SW SenecaII has a 3D OAT that looks great to viewers inside the cockpit, but mysteriously disappears when the viewer is outside looking in. 48:: dhc2: As of 1.9.0, the mixture cannot be controlled using a joystick. A patch is available. 49:: dhc2: As of 1.9.0, there are multiple fuel pressure bugs. Example 1: no contribution from the engine-driven fuel pump; in the Real World this would be an obvious no-go condition. Example 2: sometimes a low fuel pressure condition can force the mixture to be /richer/ than it otherwise should have been. Example 3: the behavior is improperly sensitive to the frame-rate of the sim. A patch is available. 50:: YASIM engine, as installed on the dhc2 (but not on the pa24-250): As of 1.9.0, while cranking the starter with less than full throttle, the MAP exhibits dramatic, unrealistic fluctuations. MAP behavior during shutdown is also a bit odd. 51:: Radio: navcom-kx155.xml as installed in the c172p and presumably elsewhere: As of 1.9.0, the kHz digits unrealistically carry into the MHz digits. 52:: Core feature: Nav: Reversible ILS: Consider the following scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R approach. You are at an altitude of 180 feet, centered on the glideslope, about 1/2 mile from touchdown, i.e. just about to cross over RWY 22L. All indications are stable. So far so good. Then suddenly the localizer CDI needle switches from half a dot right of center to full-scale left of center, through no fault of your own. Evidently, the simulator has just switched the ILS transmitter from 31R to 13L, as you can confirm by listening to the ident. It does this every time, as a function of aircraft position. This means that in the 1.9.0 Sim World, the KJFK ILS RWY 31R is not flyable under low-IFR conditions. I reckon the same problem arises at every airport where there is a reversible ILS. This is not good. This is an old bug. In the Real World, the active runway is determined based on wind conditions (etc.) and the reversible ILS is set accordingly, independent of aircraft position. 53:: In real life, there are many circumstances where airport lights, including approach lights, are turned on during the day. At tower airports, the lights are turned on during conditions of low visibility and/or low ceiling, and also turned on if requested by the pilot. For details, see FAA Order 7110.65p. As of 1.9.0, runway and taxiway lights are turned on during the hours of darkness, as determined by the angle of the sun. So far so good. As of 1.9.0, runway lights and taxiway lights are turned on automatically if visibility less than 5000 meters, day or night. Apparently this is based on flight visibility (not on surface visibility as they would be in the Real World). Consequently, as the sim descends through a haze layer into improving visibility, you can watch the Sim World lights turn themselves off, which is dramatically unrealistic. Also: apparently the code treats a subset of approach lights as part of the runway lights, so that subset has the same dependence on time-of-day and visibility. The remaining approach lights appear to be permanently off. As of 1.9.0, there is apparently no dependence on ceiling. For example, under a 150ft overcast ceiling, the lights are off during the day. This is unrealistic i.e. inconsistent with FAA Order 7110.65p. It is important to get the lighting right, because it affects both the legality and the practicality of performing instrument approaches in marginal conditions. This bug has been known for a long time. Suggestion: (DCL? Vivian?) -- As others have suggested, it sure would be nice to have an AI tower that would correctly control the airport lighting (including pilot-controlled lighting) and correctly determine the runway in use (for ATIS, and for the reversible ILS, et cetera). For some users -- not all, but some -- having a properly-behaved ILS transmitter and properly-behaved lights is far more valuable than having an AI wingman or having an AI Local Controller generating radio traffic. It would be especially nice for the AI tower to make these decisions in a way that was consistent across all aircraft in the local multiuser environment. Lighting control and ILS control seem like policy decisions, the sort
Re: [Flightgear-devel] a few more bugs
On 25 Dec 2008, at 10:54, John Denker wrote: 52:: Core feature: Nav: Reversible ILS: Consider the following scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R snip In the Real World, the active runway is determined based on wind conditions (etc.) and the reversible ILS is set accordingly, independent of aircraft position. 53:: In real life, there are many circumstances where airport lights, including approach lights, are turned on during the day. At tower airports, the lights are turned on during conditions of low visibility and/or low ceiling, and also turned on if requested by the pilot. For details, see FAA Order 7110.65p. snip Both of these are related to airport dynamics, which is an area Durk has been working on, and which I intend to get into in the medium- (definitely not short-) term. Durk's code already tracks active runways, but it's not hooked up to the rest of the code, i.e lighting, ILS enables and so on. All of these things are doable and worthwhile. PCL should also fall out of such a system. At some point I hope to have a discussion about sorting out the division of labour between FGAirport and FGAirportDynamics, since most of the code only wants to deal with FGAirport, but would like some dynamic information to be queried (transparently) from the dynamic information. As you note, most of these decisions are high-level, so I hope that most of this work will be Nasal, not C++, once some more APIs are exposed to the scripting layer. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
