[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] Output communication problem
Hello, finally I had time to try it, and it works fine with the native-ctrls protocol. Thank you very much for your help. Best regards Jan On Fri, Dec 19, 2008 at 9:48 PM, Alex Buzin buzin6...@hotmail.com wrote: Hi! As I understand you want to get controls in Matlab from FG. But FG do not run any useable FDM and if you are trying to send data to Mathlab as FGNetFDM it can be zeros or loopback (data was sending from MathLab to FG). What protocol you are using for this connection? If data to FG is sending via native-fdm then FG mast send controls via native-ctrls protocol. With respect, Alex _ Drag n' drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/photos.aspx -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Hi there, I'm very happy that we finally released 1.9.0. According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) Reliability: - NaN things must be eliminated - SIGSEGV must be avoided when: + no osg plugins are found + a sound file is missing + there are some other missing xml / ac files Usability: - to be determined (T.B.D.) Effifiency: - T.B.D. Maintainability: - T.B.D. Portability: - T.B.D. [2.1.0 and further versions ] - T.B.D. :-p We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas I believe that these milestones don't prevent the developers from implementing their new ideas at all. we can freely add new features even these are not listed in the milestones. Moreover, if we cannot implement some of the must-achieve items due to lack of time, then we will carry these over the next release, and make the current release published. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. Any comments, better idea? Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
On 25 Dec 2008, at 18:38, Tatsuhiro Nishioka wrote: 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug- fix releases between two releases. It's not quite the number system I first guessed at, and I think the odds of ever *doing* a bug-fix release are quite low, but it sounds reasonable. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). snip Overall I agree, coming from a commercial software development side, I'd prefer people to think in terms of features, and committing to delivering them for a certain release. Where a feature means the kind of thing we'd put in a 'new for this release' bullet point list. Then we can decide whether to delay a release because feature X will take an extra two weeks, or postpone feature Y from release 2.n to 2.n+1 because it would delay it too much. OGRE create a wiki page for each release - initially it's a blue-sky page, then it becomes 'live' when the release is being worked on, and finally it becomes the release notes for that release, with a list of completed features. That seems pretty logical to me. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think in practice, the odds of ever doing a release *branch* for a project like FG is very low. I'd rather just stabilise trunk and tag. If we ever needed to do a x.y.1 release, it's trivial to branch from the tag and fix the bug. In general, back-merging from a release branch to a trunk is a horrible, thankless task, so avoiding it seems like a win to me. James -- ___ 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 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
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Tat wrote: I'm very happy that we finally released 1.9.0. Thanks for your hard work in making it happen! According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. For example, I think we've had 3D clouds in CVS for 3 months at least, and we certainly haven't ironed out all the bugs yet. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I'd prefer to name something 2.0 or 3.0 when we think we are producing a major release, with significant new features. Producing 3.0 simply because the last release was 2.9 will set false expectations for users - they will be expecting significant feature improvements. Much better would be 2.01, 2.02 ... that gives us much more leeway before the next major release. I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. That's certainly sensible. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. Regarding 3D clouds: - There are significant ordering issues, quite apart from the challenge posed by creating stratus layers. Frankly, unless someone else is intending to spend significant time writing 3D clouds _code_, I don't think 3 months is going to be enough time for me to fix all the issues. I made myself enough of a hostage to fortune last time by saying I'd have them ready by Christmas - I'm not making that mistake again ;) I believe Tim has spent some time working on Shadows (don't know about landing lights). He's much more sensible than me and hasn't said when he'll have any code ready ;) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. [We'll gloss over the fact I'd be a bit disgruntled being told when to have something ready. That's far to close to work, and FG dev is pretty close already ;) ] Reliability: - NaN things must be eliminated I completely agree on this one. We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas As far as I am aware, none of those documents is up to date, or reflects current development. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. snip 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
On 25 Dec 2008, at 22:46, Stuart Buchanan wrote: As far as I am aware, none of those documents is up to date, or reflects current development. Yep - that's partly why I created a personal 'plan' page - so I can say what I *am* working on, and what I intend to work on, and hence hopefully avoid people getting upset when work is duplicated. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. Could work, though CVS isn't terribly visible, so this is a two-edged sword. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation adf.cxx, 1.19, 1.20 dme.cxx, 1.19, 1.20 kr_87.cxx, 1.9, 1.10 marker_beacon.cxx, 1.14, 1.15 navradio.cxx, 1.30, 1.31 tacan.cx
On 25 Dec 2008, at 23:11, James Turner wrote: Remove all name and spatial queries from FGNavList. All remaining queries are by frequency (which makes sense), and use the FGPositioned spatial data if required. I just committed a slightly large re-factoring of the FGNavList code, which means we're well and truly using FGPositioned now. I've tested most things locally, and everything seems to be working as expected, but please be vigilant for regressions or strange behaviours in the next few weeks. If you think something isn't right (and has got worse since 1.9.0!) please let me know and I'll look into it ASAP. I spent ages yesterday testing the marker beacon code, before realising that the problem was data, not code - I was under the impression that *every* ILS/LOC approach defined all three beacons - I couldn't have been more wrong! What's the real-world situation here? James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation adf.cxx, 1.19, 1.20 dme.cxx, 1.19, 1.20 kr_87.cxx, 1.9, 1.10 marker_beacon.cxx, 1.14, 1.15 navradio.cxx, 1.30, 1.31 tacan.cx
On 12/25/2008 04:21 PM, James Turner asked: I was under the impression that *every* ILS/LOC approach defined all three beacons - I couldn't have been more wrong! What's the real-world situation here? Please ask a more specific question. Do you need to know something that's not in apt.dat? (Categories 7, 8, and 9.) Are there isolated disagreements between apt.dat and the ground truth? Or systematic disagreements? -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation adf.cxx, 1.19, 1.20 dme.cxx, 1.19, 1.20 kr_87.cxx, 1.9, 1.10 marker_beacon.cxx, 1.14, 1.15 navradio.cxx, 1.30, 1.31 tacan.cx
On 25 Dec 2008, at 23:49, John Denker wrote: Please ask a more specific question. Do you need to know something that's not in apt.dat? (Categories 7, 8, and 9.) Are there isolated disagreements between apt.dat and the ground truth? Or systematic disagreements? Apologies for being vague. What I mean is, for example, EGPH has two ILS-equipped runways - 06 and 24, but no marker beacons defined at all. KSFO has some, but for example, 28L has an OM, while 2R has MM and IM, but no outer. (in nav.dat) I've just checked my SimCharts, and apparently neither EGPH approach plate includes any markers, so presumably the data is right, and the issue is entirely my fault, for thinking that marker beacons were a mandatory part of an ILS setup, when they are apparently installed on a case-by-case basis, and not necessarily as complete sets of OM/MM/ IM, which again I had naively assumed. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ILS +- markers
On 12/25/2008 05:07 PM, James Turner wrote: What I mean is, for example, EGPH has two ILS-equipped runways - 06 and 24, but no marker beacons defined at all. KSFO has some, but for example, 28L has an OM, while 2R has MM and IM, but no outer. (in nav.dat) I've just checked my SimCharts, and apparently neither EGPH approach plate includes any markers, so presumably the data is right, and the issue is entirely my fault, for thinking that marker beacons were a mandatory part of an ILS setup, when they are apparently installed on a case-by-case basis, and not necessarily as complete sets of OM/MM/ IM, which again I had naively assumed. IM is not a required part of a standard ILS in the US or Europe, and has not been for a very long time (if ever). It is used for Category II ILS ... which is rather rare. MM is normally part of a standard ILS, but there is no penalty for a missing MM in the US since circa 1990, and in Europe even longer. OM is normally a required part of a standard ILS ... but there are lots of exceptions. A point-out from airport surveillance radar is an acceptable substitute. An NDB (compass locator) is a an acceptable substitute. DME is an acceptable substitute ... and since both approaches to EGPH are ILS/DME/NDB approaches, we see that DME is the normal way of flying these approaches, and is a 100% reasonable explanation for the lack of markers. The fine print on the approach plates says ATC will give you radar ranges if you don't have DME. So I don't see anything wrong with the approach plates or with nav.dat in this example. The percentage error rate in nav.dat is not zero, but it is pretty small. My suggestion is that the code should trust nav.dat as to the existence and location of markers et cetera. If nav.dat is wrong, the best way to fix it is to distribute an updated and corrected nav.dat ... not to build second-guessing into the code. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
