[Flightgear-devel] Comments on new Scenery
Hello all, Pulled down the local 10 degree block for a quick look, and the overall impression is a great improvement. Before anyone (especially Curt) has to order a larger hat, here are a few specific problems I spotted in my area (eastern PA). First, the majority of the taxiways are on the opposite side from reality. 1N9, KUKT, KSEG are fully reversed. KABE has taxi for 6-24 correct, but the one for 13-31 is on the wrong side. This airport also shows a database problem, with a major highway trying to cross 13-31. The highway near 1N9 is also displaced by about a mile, putting it on the wrong side of the airport. At KLNS, the taxiways are roughly correct, but one runway (8-26) and its taxi is only a long white rectangle. I note a lot of windsocks by the runway ends. I assume this is a default when no location is available. Likewise, several beacons are far from their real locations, with some uncomfortably near the runways. Don't let these nits slow down the progress. Add them to the pile of items for a rainy day. -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on new Scenery
Thanks for the comments, let me respond to a few of these ... William Earnest wrote: Pulled down the local 10 degree block for a quick look, and the overall impression is a great improvement. Before anyone (especially Curt) has to order a larger hat, here are a few specific problems I spotted in my area (eastern PA). First, the majority of the taxiways are on the opposite side from reality. 1N9, KUKT, KSEG are fully reversed. KABE has taxi for 6-24 correct, but the one for 13-31 is on the wrong side. Robin Peel has generated default taxiways for all airports that haven't had specific taxiways defined for them. The default taxiways are intended to look plausible but have no real connection with reality. The fix for this is to define correct taxiways for each individual airport. Lot's of tedius work which is probably why it hasn't been done yet for most of the smaller airports. However, once we get a way to output x-plane format taxiway information, then people from the FlightGear project could really help Robin push his database forward. This airport also shows a database problem, with a major highway trying to cross 13-31. The highway near 1N9 is also displaced by about a mile, putting it on the wrong side of the airport. This is due to the very low resolution of our road data base. This issue has been discussed before, but at the moment there doesn't seem to be any good solution short of manually repositioning the roads. But before we can do that, we need some mechanism to store and coordinate all the fixes ... that will be some substantial effort for someone, unless some kind company or government releases better data for us to use. At KLNS, the taxiways are roughly correct, but one runway (8-26) and its taxi is only a long white rectangle. This is a problem with Robin's database. For some airports he ended up with two airport entries with half the runways assigned to the first and half the runways assigned to the second. The airport generator tools can't handle this and the result is some missing runways or holes. I am very hopeful that these bugs will be fixed in Robin's next database release (which should happen in a week or two or three.) I note a lot of windsocks by the runway ends. I assume this is a default when no location is available. Likewise, several beacons are far from their real locations, with some uncomfortably near the runways. Yes, for all airports that don't have windsocks or beacons, Robin generates some default objects ... you'll probably see the pattern if you look at a few runways and airports. His code doesn't account for runway overlaps so you get some wierdness here and there. Again, the good news is that when we spot these problems and can find correct data for the airports we can submit it to Robin and hopefully get it fixed in the next release. I trust our buddies in the X-Plane camp are seeing the same issues and doing the same thing to help fix up the database. Don't let these nits slow down the progress. Add them to the pile of items for a rainy day. Yup, I already have a big list of things I hope to look at for upcoming scenery builds. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Comments
I just want to make a very brief statement with respect to what going on in the world right now. I don't think we should trivialize current world events here in the FlightGear forums by pretending they aren't happening. I'm certain that most of us have strong feelings and are very concerned about what is going on. However, our mailing lists are intended for discussing FlightGear development and usage, and there are many other much more appropriate forums for discussing world events. I think we all would acknowledge that collectively we are very concerned right now. We are a large group with a large diversity of opinions; but we have all come together on a single point, on which I believe we all can agree: we want to make FlightGear the best it can be. So please, let's stay focused on FlightGear here in the FlightGear forums. Let's continue to keep our collaboration positive and as reasonably on track as it usually is. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] comments
[Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 Previous message: [Flightgear-devel] patch and screenshot Next message: [Flightgear-devel] Fwd: Re: preferences.xml change Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Thursday 12 December 2002 4:45 pm, paul mccann wrote: I put a patch at my webserver for the hsi and rmi on the c310, if any one wants to try it. Maybe fix it up too. I was using fgfs version 9.1 for this. http://members.verizon.net/~vze3b42n/patch9.1.tar.gz This looks good. Do we have any objections to using this, or should we add this and keep the old one too? Comments? John Thanks for response and If it works correctly I set it up so it loads the old c310-vfr panel, with the changes I made. I renamed it c310-ifr and it loads from comand line with that. That way I did not mess up any of the other c310s'. I did it on the current 9.1 version of flightgear. Seems to work ok in the other aircraft too but the 3d cockpits were it border seems to wiggle a little. Don't know why that is? Paul Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] comments
On Saturday 14 December 2002 1:06 pm, paul mccann wrote: [Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 Previous message: [Flightgear-devel] patch and screenshot Next message: [Flightgear-devel] Fwd: Re: preferences.xml change Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Thursday 12 December 2002 4:45 pm, paul mccann wrote: I put a patch at my webserver for the hsi and rmi on the c310, if any one wants to try it. Maybe fix it up too. I was using fgfs version 9.1 for this. http://members.verizon.net/~vze3b42n/patch9.1.tar.gz This looks good. Do we have any objections to using this, or should we add this and keep the old one too? Comments? John Thanks for response and If it works correctly I set it up so it loads the old c310-vfr panel, with the changes I made. I renamed it c310-ifr and it loads from comand line with that. That way I did not mess up any of the other c310s'. I did it on the current 9.1 version of flightgear. Seems to work ok in the other aircraft too but the 3d cockpits were it border seems to wiggle a little. Don't know why that is? It has to do with precision, when the location is straddling the border of two pixels, the image jitters. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] comments
John Check [EMAIL PROTECTED] Sat, 14 Dec 2002 13:52:27 -0500 Previous message: [Flightgear-devel] comments Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Saturday 14 December 2002 1:06 pm, paul mccann wrote: [Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 It has to do with precision, when the location is straddling the border of two pixels, the image jitters. OK Thanks, I noticed the other instruments don't jitter as much in the 3d cockpits as the hsi I was working on. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Curtis L. Olson writes: - There is a severe proplem going to first notch of flaps. Extreme pitch up. You need *full* down trip to fly level with any flaps at all. It is speed range dependent. If you follow the recommended profile of speeds and flap selections, the pitching effects are fairly minor. However, there is a disproportionately larger pitch impact when moving flaps at much higher (or slower) speeds than those. I already reflexively (i.e. involuntarily) push forward on the yoke whenever I lower any flaps, without waiting for the pitching to start Yup, I do the same, but only for a fraction of a second. Immediately after hitting the flap switch, I reach for the trim wheel. -- perhaps Alex Perry can let us know whether this is common for C172 pilots or I'm just developing a bad habit. I've no idea. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Comments on FGFS review summary
From: Melchior FRANZ [EMAIL PROTECTED] OK, let's sort the items and add a few: - Old-fashioned overall appearance Yep. Our photographic fidelity is deprecated wrt functional representation. 2001-era flight simulators have inherited a lot of the visual artistry of the 3D combat video games, thereby providing a much more intensive impression of being present inside the simulation. The difference is similar to comparing a photograph of a landscape and an oil painting. The latter, if well done, appears to be a more realistic and faithful of the scene even though the color palette is narrower and the pixel pixel count is generally an order of magnitude lower than the former. The work, changing from a purely technically accurate rendering of the visual scene to an engaging and realistic image, requires good art skills to modify the textures we use and optionally add a few vertices in models. Although this is ongoing, it isn't complete and certainly not released. - (4 screenshots delivered, including KSFO + C172 panel) The CVS detail visual content is greatly improved compared to the Gallery, but the limitations implied by the previous point are still present. It is interesting to compare our primary screenshots with the equivalent ones for other simulators, note the inferior elements and figure out how to generate a better screenshot (and any simulator hooks that are needed). The San Jose scenery method is a good example of such an underlying hook. - not to be compared with state-of-the art simulators This can be a good thing, for all their associated features that we hate. However, this is intended to be a negative comment. Obvious differences are (a) we don't have an integrated capability for an intro video sequence. (b) We don't have a pulldown menu for selecting scenarios and similar. We can make (a) a hook that is attached to (b), with a fallback to showing a static image (like our existing splash) when unable to play the video. Then we provide a default scenario that calls up the video and has a voiceover that provides context for the initial simulation state. - Very few functions compared to other simulators[1] Many of our function set are selected only at startup on the command line and the reviewer was probably not aware of some of our power and flexibility. This is bad and we _intend_ the problem go away at some point in the future. Meanwhile, it would be a nice upgrade to have a menu item that brings up a dialog which contains _every_ command line parameter that is not otherwise represented in the existing set of run-time accessible menu items. The exit buttons are accept and restart or cancel; if the former is selected, the existing command line is extended with the chosen options and then the application exec()s itself so that they take effect. Over time, as those features become run-time configurable, the dialog will shrink. I seriously doubt whether it will ever become empty, so I think the dialog will be a long term capability (especially on the CVS tree). - Cockpits from yesterday This can either mean that most of our cockpits are steam-gauge based, which is true for the reviewed version that doesn't have OpenGC integration, or that it looks flat like the 1999 era simulation programs, which is true for the reviewed version and may be true by default for current release too. I think the 3D cockpit wasn't default due to lacking mouse interaction ? I doubt this is the point of the critique, but we also have a lack of secondary indicators and controls that are irrelevant to a working simulation. The stuff that would be used for a procedures trainer. When the C172 panel has every control, light and fuse mounted into it, it will be worth writing the python scripting to tie things together (such as turning off radios when the avionics circuit breaker is tripped). On another side note; it would be handy to have tooltips on the 3D panel, so that mouseover can tell the user what real-life action will occur when a mouseclick is generated. That helps with the learning curve. For example, the door latch would have open door while the door handle would have close door ... ideally with 3D model door motion tie-in. - Bad flight characteristics (sometimes planes react too sensitive, sometimes too sluggish), much worse than X-Plane This puzzles me; real planes have huge changes in control sensitivity over the operational speed range, which we (and to a lesser extent) X-Plane try to model. Perhaps the chap is used to playing video games where effectiveness is not context sensitive ? Maybe not a GA pilot ? We certainly have limitations on control realism, but not to the extent that I'd critique us in the same breath as our other limitations. - Weather + Scenery disappointing The former is an active area of development (again, and again, and again). The latter is limited by our data sources and by our huge file sizes. My long term goal of doing streaming scenery
Re: [Flightgear-devel] Comments on FGFS review summary
On Sat, 01 Jun 2002 14:24:45 -0700 Alex Perry [EMAIL PROTECTED] wrote: Meanwhile, it would be a nice upgrade to have a menu item that brings up a dialog which contains _every_ command line parameter that is not otherwise represented in the existing set of run-time accessible menu items. The exit buttons are accept and restart or cancel; if the former is selected, the existing command line is extended with the chosen options and then the application exec()s itself so that they take effect. Over time, as those features become run-time configurable, the dialog will shrink. I seriously doubt whether it will ever become empty, so I think the dialog will be a long term capability (especially on the CVS tree). Actually, I'm working on such a GUI. (I need it for my personnal use of FlightGear). It's a python set of scripts which use wxPython (wxWindows wrap) and pyxml to SAX-interact with the preferences.xml file. It should help to choose your aircraft (with a nice photo), your airport (by re processing the default.apt) and with a screenshot too (if available), your environment conditions : time, weather, ..., the ability to launch Atlas at the same time on the right port, and some additional stuff. At the moment it is only experimentation, but as soon as I have a working script, I put it under GPL, put it online and give a link to try it. All the best, Olivier ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Comments on FGFS review summary
Alex Perry writes: - not to be compared with state-of-the art simulators This can be a good thing, for all their associated features that we hate. When I started my flying lessons, and the JSBSim and YASim 172's were both having problems, I decided not to be prejudiced and to go back and practice some maneuvers in the FLY! 172, which has been praised extensively for its panel and aero. Well, the panel had all the right gauges and switches (except a working thermometer on the air vent), but it updated at such a low rate that it was basically worthless -- cross-checking with the panel actually made me fly worse. Likewise for the aero modelling -- it just didn't feel like a 172 (and I have flown a 172R a couple of times). I have found both the JSBSim and the YASim 172s much, much more useful for practice than FLY!'s; in fact, I plan simply to delete FLY! the next time I boot into Windows (which happens every 2-4 months). This can either mean that most of our cockpits are steam-gauge based, which is true for the reviewed version that doesn't have OpenGC integration, or that it looks flat like the 1999 era simulation programs, which is true for the reviewed version and may be true by default for current release too. I think the 3D cockpit wasn't default due to lacking mouse interaction ? Yes, that's a big TODO item -- we cannot use the 3D cockpit for IFR until it is interactive. - Bad flight characteristics (sometimes planes react too sensitive, sometimes too sluggish), much worse than X-Plane This puzzles me; real planes have huge changes in control sensitivity over the operational speed range, which we (and to a lesser extent) X-Plane try to model. Perhaps the chap is used to playing video games where effectiveness is not context sensitive ? Maybe not a GA pilot ? We certainly have limitations on control realism, but not to the extent that I'd critique us in the same breath as our other limitations. I'm amazed at how close it is now, given the limitations of the environment. I still find FlightGear harder to hold in the flare than the real thing, but that's probably because of the lack of peripheral vision and motion cues. I also find that the viewpoint in the 3D cockpit is still slightly too low for me. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Arnt Karlsen writes: ..IMHO, we should have more oddball EAA planes than spam cans and airliners. BlomVoss 141, Me 323, Me 163, and the Horten Vings, Howard Hughes Spruce Goose, Van's RV3-4-5-6-7-8-9, Rutans Vari-Viggen, VariEze, Defiant, Lancair IV, Colomban Cri-Cri, Zenair CH-801, Ryan Spirit of St Louis, Leza AirCam, the Hummelbird, the Volksplane etc. Sure, but I'm also interested in getting FlightGear set up as a decent general-aviation FTD -- some of the stuff in the flight schools is ancient, and FTD's are way overpriced. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Curtis L. Olson writes: - There is a severe proplem going to first notch of flaps. Extreme pitch up. You need *full* down trip to fly level with any flaps at all. Lowering flaps does cause a very nasty pitching moment during low-speed maneuvers on a C172 (i.e. approach, when you're too close to stall-speed and too close to the ground already) -- not as nasty as what you describe, but perhaps a little nastier than what JSBSim currently models. Even with my limited experience, I already reflexively (i.e. involuntarily) push forward on the yoke whenever I lower any flaps, without waiting for the pitching to start -- perhaps Alex Perry can let us know whether this is common for C172 pilots or I'm just developing a bad habit. Last week, my first time in a C172M (which has an annoying rocker switch instead of a sliding flap-position switch), I accidentally lowered 40 degrees of flaps on the base leg -- I descended a little too far, and ended up needing full throttle just to level my descent briefly at 70 KIAS. It's like dragging a parachute. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
On Thu, 6 Jun 2002 14:48:49 -0400 David Megginson [EMAIL PROTECTED] wrote: Lowering flaps does cause a very nasty pitching moment during low-speed maneuvers on a C172 (i.e. approach, when you're too close to stall-speed and too close to the ground already) -- not as nasty as what you describe, but perhaps a little nastier than what JSBSim currently models. Tony: Should we make it nastier? Is there a human factors scale anywhere that has Nasty on it? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Jon S Berndt wrote: On Thu, 6 Jun 2002 14:48:49 -0400 David Megginson [EMAIL PROTECTED] wrote: Lowering flaps does cause a very nasty pitching moment during low-speed maneuvers on a C172 (i.e. approach, when you're too close to stall-speed and too close to the ground already) -- not as nasty as what you describe, but perhaps a little nastier than what JSBSim currently models. Tony: Should we make it nastier? Is there a human factors scale anywhere that has Nasty on it? :-) Hmm, nasty enough? Eff = (16*h / b)*(16*h / b) Oe = Eff*Eff/(1 + Eff*Eff)(where 0 = Oe = 1) D = q_infinite * S * (CDo + 0e * ( (CL*CL)/(pi * e * A * r) ) ) D: decrease in drag h: height of the wing above the ground b: wingspan :-0 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Tony: Should we make it nastier? Is there a human factors scale anywhere that has Nasty on it? :-) Hmm, nasty enough? Eff = (16*h / b)*(16*h / b) Oe = Eff*Eff/(1 + Eff*Eff)(where 0 = Oe = 1) D = q_infinite * S * (CDo + 0e * ( (CL*CL)/(pi * e * A * r) ) ) D: decrease in drag h: height of the wing above the ground b: wingspan :-0 ...and thus begat the FlightGear Smackdown flap system... g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Jon S Berndt writes: Should we make it nastier? Is there a human factors scale anywhere that has Nasty on it? :-) One American Nasty unit =~ 0.789 Metric Paris Cabbies. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
For what it's worth, I'm involved in a side project that is using FlightGear + a commercial C172 flight dynamics model + cockpit hardware to hopefully achieve an FAA (and JAR) certified sim by late summer / early fall. The commercial fdm will run as a seperate program [...] Hmm, _this_ is what I'm waiting for. Will there be any documentation on how the network protocol will look like ? I'm recognizing that you have checked in several patches to the ExternalNet interface over the time. I would love to profit from this. Imagine being able to run with the default stable JSBSim, or the previous stable version, or the one you are currently hacking on, just by restarting the desired fdm process. maybe with FlightGear getting run from 'inetd', if the FDM sits on a remote machine !? O.k., this might be difficult because of X server write permissions, but I'd like to take care of that if times come, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
On Thu, 6 Jun 2002 13:35:47 -0400, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen writes: ..IMHO, we should have more oddball EAA planes than spam cans and airliners. BlomVoss 141, Me 323, Me 163, and the Horten Vings, Howard Hughes Spruce Goose, Van's RV3-4-5-6-7-8-9, Rutans Vari-Viggen, VariEze, Defiant, Lancair IV, Colomban Cri-Cri, Zenair CH-801, Ryan Spirit of St Louis, Leza AirCam, the Hummelbird, the Volksplane etc. Sure, but I'm also interested in getting FlightGear set up as a decent general-aviation FTD -- some of the stuff in the flight schools is ancient, and FTD's are way overpriced. ..a market and a tool. I agree. GA is mainly built on volonteered efforts, like in aero clubs. Also add to the geek factor as in 'done the right way', as GA is not mainstream, either. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
