Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
snip a lot of good reasons for using an fdm/autopilot combination for AI traffic from David Megginson and Alex Perry (Following an OS re-install I can reply now!) OK, I can see the point of wanting a proper simulation when within reasonably close visual distance of the target. My concern was that if there were a lot of traffic being simulated, a lot of it known to the pilot only through the radio communication, then using an fdm thats updating at 120Hz and simulating right down to the exhaust gas temperature is overkill, and that using a greately simplified model with basically a look-up table of typical speeds and climb/descent rates would allow the additional traffic to be updated in a queue with, say, only one plane updated per timestep if far enough away from the viewer. My concern was that updating a number of fdms per timestep could possibly introduce a noticable delay. I can accept the fact that when reasonably close the realistic behaviour of other aircraft provides useful piloting cues - I hadn't recognised the full significance of that. I personally think that a switch from a full autopilot/fdm combination to a greatly simplified where-to-fly/how-to-fly logic when beyond a certain distance/direction from the user is probably eventually justified (IMHO). Still, regardless of how much get ripped out and rewritten eventually, its still progress for now... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
On 10/7/02 at 5:50 AM ace project wrote: I want to know how you guys want the property list to be organised. Do we use something like: /network/pilot[n]/callsign /network/pilot[n]/position/ (lat,alt, etc) /network/pilot[n]/[network-module-name]/ (module specific stuff) I will need this soon(3 weeks tops), as my little coding is getting close to completion. ATM, I'm completing the sequence handlers and debugging some minor stuff. After that I will make the code compliant with the FGSubsystem system and synchronise to the property tree. I most interrested in people working on the AI module, since this is the closest area of development to mine. ACE multiplayer engine project. leon Hi Leon, Looks fine to me, and given that no-one else has complained I'd go ahead and use what you want :-) At the moment the one AI plane implemented has no logic to avoid other traffic anyway, so for now it dosen't really matter. Eventually as AI and ATC evolve then we'll have to find some way of making sure they can take multiplayer traffic into account as well as the primary user, and the multiplayer stuff will have to supply a bit more information through the property tree, for instance ATC will need to know the rough class of plane (light/heavy etc) in order to have an idea of how to sensibly fit it into the approach pattern etc. We can cross these bridges if and when we come to them... Once you get this working we all ought to have a communal virtual fly-in at David M or Alex's local airports sometime :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightgear scenery editor?
I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
David Luff writes: OK, I can see the point of wanting a proper simulation when within reasonably close visual distance of the target. My concern was that if there were a lot of traffic being simulated, a lot of it known to the pilot only through the radio communication, then using an fdm thats updating at 120Hz and simulating right down to the exhaust gas temperature is overkill, and that using a greately simplified model with basically a look-up table of typical speeds and climb/descent rates would allow the additional traffic to be updated in a queue with, say, only one plane updated per timestep if far enough away from the viewer. That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz? 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] Flightgear scenery editor?
David Luff wrote: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. Didn't someone use PPE for this? You could also use the magic carpet mode and place yourself in FGFS directly over the special scenery part and read your exact position from the properties. Or you could try Atlas. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
David Megginson writes: That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz? you can easily experiment for yourself by playing with the /sim/model-hz value good luck ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Flightgear scenery editor?
David Megginson writes: David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud There was a time when if you paused the sim, it would dump the local lon, lat, elev to the console so you could copy/paste that into some other file you were working on, but I don't think that feature has survived the peer review process. 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
Re: [Flightgear-devel] multiplayer / AI property tree - questions
On 10/7/02 at 5:50 AM ace project wrote: /network/pilot[n]/callsign /network/pilot[n]/position/ (lat,alt, etc) /network/pilot[n]/[network-module-name]/ (module specific stuff) I think that is fine, but ... * I recommend you explicitly state that the 'n' for the same callsign is likely to be different on different computers in the group, and * The instance corresponding to pilot[0] is the local human's aircraft, and therefore is probably just a soft link to the top of the prop tree * So, in consequence, all the non network-module-specific properties should have relative names to match the local aircraft's absolute names Once you get this working we all ought to have a communal virtual fly-in at David M or Alex's local airports sometime :-) If we manage to get the COM radios to pass voice messages between the people, and provide a fairly usable tower view, I suspect that one of the local controllers would volunteer (be talked into) operating the airspace for us. It might be for KSEE (the one with a hill _inside_ the airport pattern) instead of KMYF (the one with military airspace a fraction of a mile away) or KSDM (the one right next to the mexican border) or KRNM (the one that has fire fighting aircraft getting priority handling), or ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
Norman Vine writes: David Megginson writes: That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz? you can easily experiment for yourself by playing with the /sim/model-hz value Also consider that as you run the autopilot at a slower and slower rate, you will likely go unstable in one axis before the other depending on things like the nature of the aircraft, it's current speed, etc. etc. 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
Re: [Flightgear-devel] Flightgear scenery editor?
David Megginson David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud --fdm=ufo Its nice to have reverse Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
Still, regardless of how much get ripped out and rewritten eventually, its still progress for now... Definitely. If one of the computers taking part in the multiplayer network has generated a bunch of AI aircraft, will they all be propagated to the rest of the multiplayer members ? If so, you might be able to dodge the processor load of full aircraft simulations, by having two computers with one having the human and a graphics display and the other having all the AI and no graphics display. Just a thought. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
Curtis L. Olson writes: David Megginson writes: David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud There was a time when if you paused the sim, it would dump the local lon, lat, elev to the console so you could copy/paste that into some other file you were working on, but I don't think that feature has survived the peer review process. re-Invention-is-a-wonderful-thing-to-behold'ly yrs norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
Norman Vine writes: David Megginson David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud --fdm=ufo Its nice to have reverse Yes, and everyone knows that there is no such thing as magic carpets, so running with the ufo FDM is a lot more realistic since the ufo is based on real world data and uses actual real life sound samples. We had to fudge the pilot eye point quite a bit for human use and Erik is still working on 3d cockpit since there were several items that just weren't implimented right, but even so, it's still a pretty good rendition. 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] Re: Flightgear scenery editor?
* Norman Vine -- Thursday 10 October 2002 17:36: --fdm=ufo Its nice to have reverse Both the ufo and the carpet have reverse mode. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
On Thu, 10 Oct 2002, David Luff wrote: Once you get this working we all ought to have a communal virtual fly-in at David M or Alex's local airports sometime :-) Now *THAT* would be truly impressive. (No laughing when I bounce the landing!) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Flightgear scenery editor?
Curtis L. Olson writes: There was a time when if you paused the sim, it would dump the local lon, lat, elev to the console so you could copy/paste that into some other file you were working on, but I don't think that feature has survived the peer review process. You can get that now by saving the flight. 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] FWIW
Curtis L. Olson writes: For what it's worth, I will be out of town Friday through Monday, likely with minimal net access (if any.) So, please don't panic if you email me and don't get a reponse back before next week. :-) In Canada, this is Thanksgiving weekend coming up. 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
[Flightgear-devel] Airport Database Model
I've been pulling information out of the DAFIF in different shapes and trying to decide how we should model our own airport database. For the external representation, we want something flexible enough that we can add new types of data easily -- fixed-length records with fixed-width fields just don't cut it. Any XML or INI files with airport data will be huge, of course, but they don't have to be part of the core base package -- we can include only precompiled binary files of some sort, and make the source XML available as a separate download. Getting on to the data model, there are some obvious relationships. For example, there is a one-to-many relationship between airports and runways, and another between airports and comm frequencies. We could model things purely relationally like this: airport id=CYOW ... /airport runway ident04/22/ident airport-refCYOW/airport-ref ... /runway runway ident07/25/ident airport-refCYOW/airport-ref ... /runway runway ident14/32/ident airport-refCYOW/airport-ref ... /runway comm typetower/type freq-mhz118.8/freq-mhz airport-refCYOW/airport-ref ... /comm But that kind of thing is a major pain to process. Personally, I prefer to model relationships by embedding when the relationship is one-to-many rather than many-to-many (i.e. no runway belongs to more than one airport): airport id=CYOW nameMacDonald-Cartier International/name short-nameOttawa/short-name lat../lat lon../lon elev../elev ... runways runway ident04/22/ident airport-refCYOW/airport-ref ... /runway runway ident07/25/ident airport-refCYOW/airport-ref ... /runway runway ident14/32/ident airport-refCYOW/airport-ref ... /runway /runways comms comm typetower/type freq-mhz118.8/freq-mhz airport-refCYOW/airport-ref ... /comm /comms /airport We can continue to add to a format like this to help with AI ATC and planes. For example, we can specify the location of the control tower, state when the lights are turned on and off (if not ARCAL) and what hours the tower is open, specify preferred runways for different types of aircraft (i.e. CYOW generally has 04 or 22 for light aircraft operating together with 07, 14, 25, or 32) and for noise-abatement, control-zone limits (when ATC hands you off), etc. etc. Comments? 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] multiplayer / AI property tree - questions
Jon Stockill writes: (No laughing when I bounce the landing!) Why not? People laugh at me when I do it, so it's quite realistic. It's even worse nowadays since the smokers have to go outside even when it's not sunny and warm. All the best, David (who hasn't bounced for a few weeks now) -- 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] multiplayer / AI property tree - questions
David (who hasn't bounced for a few weeks now) Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. I've been pulling information out of the DAFIF in different shapes and trying to decide how we should model our own airport database. For the external representation, we want something flexible enough that we can add new types of data easily -- fixed-length records with fixed-width fields just don't cut it. Any XML or INI files with airport data will be huge, of course, but they don't have to be part of the core base package -- we can include only precompiled binary files of some sort, and make the source XML available as a separate download. Getting on to the data model, there are some obvious relationships. For example, there is a one-to-many relationship between airports and runways, and another between airports and comm frequencies. We could model things purely relationally like this: airport id=CYOW ... /airport runway ident04/22/ident airport-refCYOW/airport-ref ... /runway runway ident07/25/ident airport-refCYOW/airport-ref ... /runway runway ident14/32/ident airport-refCYOW/airport-ref ... /runway comm typetower/type freq-mhz118.8/freq-mhz airport-refCYOW/airport-ref ... /comm But that kind of thing is a major pain to process. Personally, I prefer to model relationships by embedding when the relationship is one-to-many rather than many-to-many (i.e. no runway belongs to more than one airport): airport id=CYOW nameMacDonald-Cartier International/name short-nameOttawa/short-name lat../lat lon../lon elev../elev ... runways runway ident04/22/ident airport-refCYOW/airport-ref ... /runway runway ident07/25/ident airport-refCYOW/airport-ref ... /runway runway ident14/32/ident airport-refCYOW/airport-ref ... /runway /runways comms comm typetower/type freq-mhz118.8/freq-mhz airport-refCYOW/airport-ref ... /comm /comms /airport We can continue to add to a format like this to help with AI ATC and planes. For example, we can specify the location of the control tower, state when the lights are turned on and off (if not ARCAL) and what hours the tower is open, specify preferred runways for different types of aircraft (i.e. CYOW generally has 04 or 22 for light aircraft operating together with 07, 14, 25, or 32) and for noise-abatement, control-zone limits (when ATC hands you off), etc. etc. Comments? 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
Alex Perry writes: David (who hasn't bounced for a few weeks now) Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! Would you like to buy a pair of slightly used C172 wing tip scuff guards? Protects the paint and the red/green lights, guaranteed not to break off before the wing. Now available in a trendy neon color assortment. :-) 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
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. That's nasty, because the resulting airspeed is still correct under regular conditions. Thanks again for catching it -- the patch is now in CVS. I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. 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] defaults
Norman Vine writes: Hmm... maybe this would help untested - but it 'looks' like this will fix 'this' problem, don't thin it will cause any new ones It won't work because the properties in the *-set file will override anything specified on the command line. I'm going to go in today and try to find something that will work. 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
[Flightgear-devel] Re: Airport Database Model
* Alex Perry -- Thursday 10 October 2002 20:10: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. But then you couldn't teleport to arbitrary airports, n'est ce que pas? Storing the airport data in some precompiled form may be necessary, but having to cvs-up the whole, still quite big binary file after single-line changes in the database is no fun either. What about storing the data in a gzipped XML file and reading-in a small, uncompressed XML file afterwards, that is able to override some of the data in the big file. So little changes and additions could be made to the small patch file, which would only be merged into the big database once in a while. (Once every year? Every release?) ... I'm just thinking of people with slow dial-up connections, like me ... :-] m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
Alex Perry writes: David (who hasn't bounced for a few weeks now) Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! Actually, I passed the ultimate test yesterday -- going back in the plane with my instructor a month and a half after finishing my PPL. We went up for an hour of instrument work under the hood (my first partial-panel work, including recovery from unusual attitudes, and a lot of VOR work; he's promised me an ILS approach next time). The instrument stuff didn't make me nervous, but the visual landing at the end did. My flare fluctuated up and down by a foot or two, but fortunately the wheels came down gently enough. After facing that, I wouldn't be afraid of a stadium full of spectators. 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] Airport Database Model
Alex Perry writes: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. It's not a bad idea, except that FlightGear needs to be able to search all the airports at once to find the one the user wants to jump to. 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] Airspeed indicator and pitot system
David Megginson writes: Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. That's nasty, because the resulting airspeed is still correct under regular conditions. Thanks again for catching it -- the patch is now in CVS. I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Instrument modeling is a good point ... quite often we get bug reports that things don't work right, when in reality they are working too much like real life. :-) For instance, people may notice the correctly placed sun and moon, but the moon also has correct phase, is textured. We also have the top several hundred stars placed correctly with proper magnitude as well as the planets placed correctly with proper magnitude. All of course correct for time of day, season, location on the earth, etc. Airports can be non-flat, runway and approach lighting is/will be directional. There is a ton of internal infrastructure stuff that is useful in the geek sense ... property system, interfacing to external programs. The ability to build instrument panels, electrical systems, 3d models, animation, with absolutely no coding or plugins. Many features are setable via the property system, command line options, or preferences.xml which might not be immediately obvious to a new comer. 3D instrument panels are visible and fully live and working even when viewed from external chase views. The world is round, well wgs-84 round. You can fly correct great circle routes, there are no map-maker distortions that foul up ILS alignment or vor intersection locations. I'm sure there are plenty other things we could add to the list. It would be interesting to put together a web page that showed how to start up flightgear to high light these various options. Then as people run through the program in every day use, they'll notice and have a much better appreciation of some of the finer details. Regards, 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
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. Once again: This wouldn't have happend if we'd use real units like SI... thinking of song=WHERE HAVE ALL THE FLOWERS GONE When will we ever learn? /thinking CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Init-order problem fixed for *-set.xml files
David Megginson writes: I just checked in changed to fix the init-order problem for *-set.xml files. My solution was blunt but effective. I simply parse all of the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice -- once before loading the *-set.xml file, to make sure the correct aircraft is picked up, and once afterwards, to allow the command-line to override anything that was changed. The problem manifested itself when other aircraft (such as the 747) picked up the default aileron trim setting for the JSBSim 172. By the way, does anyone still use a system.fgfsrc, or can I remove that old code? I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. Regards, 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
Re: [Flightgear-devel] Airport Database Model
David Megginson wrote: Alex Perry writes: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. It's not a bad idea, except that FlightGear needs to be able to search all the airports at once to find the one the user wants to jump to. It seems to me like the airport database is only searched on two keys: location and ID. Storing an index on location is trivial, as Alex points out -- store it with the location-specific data structure that is already indexed. So all we need is an index on name. Not to be too glib, but the OS already provides a rather nice index on named objects -- the filesystem. So in Scenery/w130n30/airports.xml you will find a simple list of airport ID's: airports idKSFO/id idKOAK/id ... /airports And look up the airport data itself under Airports/KSFO.xml: airport idKSFO/id nameSan Francisco Intl./name alt.../alt lat.../lat lon.../lon runway name11/name lat.../lat lon.../lon direction.../direction length.../length width.../width /runway runway ... /runway /airport The astute will point out that not all filesystems actually store indices on filenames (ext2 and FAT among them, sadly -- NTFS and reiserfs do have indices). With only a few thousand files, this isn't likely to be a real performance problem. Nonetheless, storing them sorted into directories is possible. Use Airports/K/KSFO.xml, for example, or even Airports/K/S/F/O.xml if you really want. :) This strikes me as easy to implement and much easier to maintain than the current metakit stuff. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On 10/10/02 at 12:02 PM Alex Perry wrote: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... 8-) That was one of my absolutely most favourite bits of Flightgear. I got a second hand pilots tuition hand-book from an old book shop some time ago, and was gobsmacked at the bit about the compass over and under-shooting in turns - I'd never even conceived of anything like that, and MSFS95 certainly never did it! When I fired up Flightgear and found it acted *exactly* like the book described I was ecstatic. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Curtis L. Olson writes: There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Why not post a version of this message to the Web site, with a title like FlightGear: What's Under the Hood? 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] Airspeed indicator and pitot system
David Megginson writes: Curtis L. Olson writes: There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Why not post a version of this message to the Web site, with a title like FlightGear: What's Under the Hood? Today is flying away from me, but this is a great idea. Remind me when I get back next week or if in the meantime some one else wants to use that message as a starting point for compiling and organizing a list of key features, that would be very much appreciated. 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
Re: [Flightgear-devel] Flightgear scenery editor?
David Luff wrote: On 10/10/02 at 10:42 AM Curtis L. Olson wrote: Yes, and everyone knows that there is no such thing as magic carpets, so running with the ufo FDM is a lot more realistic since the ufo is based on real world data and uses actual real life sound samples. Yes, and non-Americans know that there's no such thing as ufos and that we have actually been to the moon :-) We've been to the moon?!? I allway thought this was a very good fraud by the NASA to convince everybody that the US has the superior technology... ;-) CU, Christian PS: There are actually people around who try to proof that it's impossible that the NASA was on the moon... PPS: There are actually people around who try to proof that the German town Bielefeld doesn't exist... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Christian Mayer writes: Once again: This wouldn't have happend if we'd use real units like SI... I live in a (mostly) SI country and went through school learning SI units -- I have to convert Fahrenheit to Celsius to know how cold it is, for example. Still, converting to new units has its cost, including the near crash of an Air Canada 767 a while back (as posted previously): http://www.cadetworld.com/rgs/story2a.html 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] Airspeed indicator and pitot system
Alex Perry writes: That's true, but now I wonder ... When we are in multiplayer mode, and I fly up behind some unsuspecting pilot who is plugging along on autopilot, slightly above and at his five o-clock position, can I pick up a pair of electronic binoculars (what used to be the Z key?) and put mouse clicks onto his 3D panel ? Vicious grin ... No, that's unlikely -- only your own plane model will have hotspots. 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] Init-order problem fixed for *-set.xml files
Curtis L. Olson writes: David Megginson writes: I just checked in changed to fix the init-order problem for *-set.xml files. My solution was blunt but effective. I simply parse all of the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice -- once before loading the *-set.xml file, to make sure the correct aircraft is picked up, and once afterwards, to allow the command-line to override anything that was changed. The problem manifested itself when other aircraft (such as the 747) picked up the default aileron trim setting for the JSBSim 172. By the way, does anyone still use a system.fgfsrc, or can I remove that old code? I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold FWIW - I put a LOT of effort into getting the navigational parts of FGFS working this included a lot of 'gentle nudging' and a lot of code and I RESENT having been force to used COOKED variables when I might not always always want to. FYI there was a time when Curt and I were probably the only two people that understood at least 90% of the code and we spent a LOT of energy and time trying to teach and/or explain to others how it all worked. I certainly didn't do that expecting those whom we 'enlightned' to change the code such that it was nigh onto impossible to use it in ways that I wanted too. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross Curtis L. Olson wrote: Just a couple thoughts to consider. We are looking at 16-20,000 airports so we couldn't stuff them all in a single directory. Even splitting them into subdirectories by first letter probably isn't enough. There are 17073 airports in the current database. Splitting on first letter only, the largest is (no surprise) 'K', with 2161 airports. On a lark, I created such a directory containing all the US airports. The creation process was relatively slow -- 20 seconds or so. But once the files are there, access to them is very fast (a few tenths of a second). This was true even after I was careful to flush the buffer cache by cat'ing a different disk to /dev/null, if the stuff is in the cache, of course, access is milliseconds at most. If you think about it, 2000 is about the same number as the number of device files in /dev, and no is complaining about performance issues there. And remember, we can split on the first two bytes (K/S/KSFO.xml) without any more difficulty (one extra line of code) and the whole problem goes away. Also, consider that with zillions of tiny files, much space is wasted on the file system which hits people in the windows land the hardest it seems because they often have a very large minimum file size. This is a good point, actually. Almost all the Linux filesystems use a 4k block as the minimum allocation unit*, and I presume NTFS is similar. Still, though, 4k per airport is still a tiny fraction of the size of the scenery. Remember that with a file per airport, there is no need to have the whole airport database in the base package. You can download the airports along with the scenery. The windows issue is, I think, true only on very old FAT32 variants. I'm pretty sure the block size limitation went away at the same time the 2G limit did, no? Everything from Win98SE on should be fine, I believe. Any windows users want to comment? Certainly anyone running XP won't have this problem. For the Index I reccomend making a single trie on the airport name that stores the bucket of the actual airport data file which lives in the same spot as it currently does. Then In each 10x10 degree directory I propose that we have a KD-tree spatial index of the positions of each airport in that block. This 2 tiered approach should give lighning fast lookups to both airport by name and what airports are near by. The indexes should be binary and we should distribute the tools that rebuild them when they change which won't be that often nor take very long. The indexes chould be able to dump themselves as XML files to facilitate rebuilding them and for easy inspection. With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Init-order problem fixed for *-set.xml files
Norman Vine writes: Curtis L. Olson writes: David Megginson writes: I just checked in changed to fix the init-order problem for *-set.xml files. My solution was blunt but effective. I simply parse all of the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice -- once before loading the *-set.xml file, to make sure the correct aircraft is picked up, and once afterwards, to allow the command-line to override anything that was changed. The problem manifested itself when other aircraft (such as the 747) picked up the default aileron trim setting for the JSBSim 172. By the way, does anyone still use a system.fgfsrc, or can I remove that old code? I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' Definitely, if for no other reason, I need support for the ~/.fgfsrc and ~/.fgfsrc.machine files. Regards, 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
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On Thu, 10 Oct 2002, David Luff wrote: Possibly true. Still, however the ai aircraft eventually end up getting stored in the property tree and rendered, the actual logic of when to appear, where to fly and how to communicate and interact with other traffic will still be needed and won't be wasted. Yes - you still need the pilot logic however it's done. It certainly won't be wasted. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't I have advocated, all along, that both the correct and the cooked values should be available through the property system. I also think that all panel instruments, and panel autopilots, should use the appropriate level of cooked-ness in accordance with realistic aircraft by embedding property pointers as created by David. I also personally think that the HUD should, again by default, use completely uncooked values for convenience and partial realism. If you don't want this behavior on _your_ system, feel free to hack away at the config files. My local config isn't exactly unmodified compared to CVS, but I think my changes are wrong for the general end-user population and don't recommend them. If you don't want the full realism on the public CVS configuration then I'll hereby respectfully disagree with you. This is especially true for the autopilot. Currently, it is far too easy to use and thus (in several ways) trivializes some of the IFR dangers. One of the reasons I rarely use autopilots in real small aircraft is that they use the same data sources as I have on my instruments, with all the errors. It thus takes non-trivial effort to make them do what I actually want and it is often easier to be manual. This is the very real difference between an autopilot and a FMS. Johnny. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On Thu, 10 Oct 2002, Andy Ross wrote: And remember, we can split on the first two bytes (K/S/KSFO.xml) without any more difficulty (one extra line of code) and the whole problem goes away. From a processing point of view this makes sense - you don't need to store extra information about the location of the airfields, wher if as was suggested before it's broken down by state, then presumably you need to store the state for each and every airfield too, or is there some other method of telling which state each one is in that I've missed? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Norman wrote: [ ... indexing scheme involving spacial partitions and trees ... ] With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least True, but performance really isn't the goal here. The existing metakit stuff performs great. It's problem is that it's essentially unmaintainable without regenerating a megabyte of data*. Replacing one complicated binary data structure with another really doesn't address that need. My point was that a really simple one-file-per-airport scheme (you basically can't get any more maintainable than that) would work with adequate performance for typical usage. The airports in the current tile set could be kept in memory easily; arbitrary airports could be looked up quickly (under the UI definition of quick) by their ID; and the set of all airports would still be trivially searchable in a linear walk (looking for a match by name, for example) for cases where that capability was needed. Andy * Well, and that it involves a 3rd party C++ library that insists on installing itself as a shared library. My guess is that metakit version skew is the single biggest FAQable problem with new developers. It's a very real, very significant barrier to people who want to run the cool new stuff in CVS. This is my peeve, anyway. -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FWIW
Doh, and I am flying to Minneapolis again this weekend! Not sure if I am going to ANE or MIC yet. Need to get the charts tomorrow. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Thursday, October 10, 2002 10:45 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] FWIW For what it's worth, I will be out of town Friday through Monday, likely with minimal net access (if any.) So, please don't panic if you email me and don't get a reponse back before next week. :-) 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross writes: Norman wrote: [ ... indexing scheme involving spacial partitions and trees ... ] With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least My point was that a really simple one-file-per-airport scheme (you basically can't get any more maintainable than that) would work with adequate performance for typical usage. My scheme also uses one file per airport PLUS two fairly advanced yet relatively simple indexes for lightning quick seaches. I hope you note that I used a trie which is just a binary implementation of the individual file basd method that you proposed http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Trie.html And there is a performance issue here with searching radio frequencies for stations within range hence the spatial index for each 10x10 degree block. I believe that my proposal is a 'Dr Pangloss' type solution * Well, and that it involves a 3rd party C++ library that insists on installing itself as a shared library % cd $metakit % ../unix/configure --disable-shared % make core % make install best-of-both-worlds'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross writes: [* Geeky aside: reiserfs doesn't. It has a unique tail folding feature where the last sub-block of files gets folded into a single block with the tails of other files, so small files take space proportional to their actual size. Very cool, although apparently not used much.] Not true. It's not the default for RedHat, but I understand that it's better used in the European distros and I notice a fair number of users elsewhere. For scenery data like DEMs, ReiserFS gives me an extremely large improvement, sometimes taking only 25% of the disk space of the same data under E2FS (I didn't check E3FS, but it should be similar). I strongly recommend Reiser for anyone working with scenery data. 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] Init-order problem fixed for *-set.xml files
Norman Vine writes: I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' I have not suggested doing so; I'm suggesting only system.fgfsrc. 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] multiplayer / AI property tree - questions
On Thu, 2002-10-10 at 11:54, David Megginson wrote: Curtis L. Olson writes: Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! Would you like to buy a pair of slightly used C172 wing tip scuff guards? Protects the paint and the red/green lights, guaranteed not to break off before the wing. Now available in a trendy neon color assortment. Fortunately, I've never seen a landing where the wingtips even came close to touching the ground -- the excursions are usually pitch or yaw rather than roll. The danger to wingtips is hangar rash (i.e. fender benders) from other aircraft taxiing around the parking area. In real life, it's also much harder to do a tail strike than it is with the JSBSim 172 -- it's quite safe to pull all the way back on the yoke to keep the weight off the nosewheel. Hmm, downwash (or, more precisely, the lack thereof) 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold I have no objection to a new autopilot module if someone wants to build it; the current one is fine but it's showing its age a bit. That said, it shouldn't be hard to make it configurable to use different property sources for specialized applications like your (Norm's) GIS work. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. 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] Airspeed indicator and pitot system
On Thu, 2002-10-10 at 12:02, Alex Perry wrote: David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... Not to mention all the confusion we get now from the rolling tendencies due to the propulsion system ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Thu, 2002-10-10 at 11:59, Christian Mayer wrote: Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. Once again: This wouldn't have happend if we'd use real units like SI... thinking of song=WHERE HAVE ALL THE FLOWERS GONE When will we ever learn? /thinking SI is a technically superior system, but as David's example points out, technical issues aren't the only things that need to be considered when making such a switch. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Jon Stockill writes: Is there any sort of master database from which all this can be generated? Or should we create one? No and yes. Note that I'm discussing only the external format, not the internal format someone might use in a SQL master repository (or whatever). That said, these are *small* data tables from a DBMS point of view -- they fit into memory trivially easily on most PCs, so an RDBMS isn't strictly necessary to manage and process them; it's just a convenience. Obviously, once we have the information in a managable format producing data files in any required format is a lot easier. It'd also make updates much simpler - I know one of my local strips actually consists of 1 closed surfaced runway, and a selection of grass strips - currently the database only has the surfaced runway in (EGCJ if anyone's *that* interested). My idea earlier today should allow faster updates. Instead of having one single master file, we have a separate one for each country or (in the case of the US and possible Canada and other airport-heavy countries) a separate file for each state or province. If you wanted to add to or update a UK airport, you could simply send your update to the UK file maintainer, and she or he could test it, merge it, and check it in. Right now, I'm almost a month behind on most of the patches in my Inbox, and I don't know if Curt's much better. You don't want anyone like us delaying updates. 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] Airport Database Model
Jon Stockill writes: From a processing point of view this makes sense - you don't need to store extra information about the location of the airfields, wher if as was suggested before it's broken down by state, then presumably you need to store the state for each and every airfield too, or is there some other method of telling which state each one is in that I've missed? We're going to want to store that anyway, though, if only for the user pick-an-airport interface. Besides, it makes a lot more sense to pick a maintainer for all California airports than it does to pick a maintainer for all airports with an ICAO code starting with KB. 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] multiplayer / AI property tree - questions
Tony Peden writes: In real life, it's also much harder to do a tail strike than it is with the JSBSim 172 -- it's quite safe to pull all the way back on the yoke to keep the weight off the nosewheel. Hmm, downwash (or, more precisely, the lack thereof) I cannot say. One thing we're not modelling yet is nosewheel shimmy: on the 172s I fly, the nosewheel starts to vibrate very unpleasantly at around 50kt if it still has weight on it, so raising it is the only way to have a smooth takeoff roll. On landing, it's just as noticeable; by around 40kt, I often have the yoke pulled back all the way (gradually, of course), both to take weight off the nosewheel and to put more weight on the mains to improve braking -- besides, it just looks cool rolling down the runway with the nosewheel six inches up in the air. All the best, David n.b. My airport is near sea level; at higher elevations, the indicated airspeed would be lower to give the same ground speed. -- 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] FWIW
Ryan Larson writes: Doh, and I am flying to Minneapolis again this weekend! Not sure if I am going to ANE or MIC yet. Need to get the charts tomorrow. Well if you go to KANE and happen to be about 3 miles east of the airport, and happen to look down and see a big high school complex with a track and soccer/baseball fields wave at my house which is just west of that. Otherwise feel free to swing by Denver/Colorado Springs and pick up a couple more hours for your log book. :-) 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
Re: [Flightgear-devel] Init-order problem fixed for *-set.xml files
David Megginson Norman Vine writes: I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' I have not suggested doing so; I'm suggesting only system.fgfsrc Apoplogies, I should have said system.fgfsrc also FYI - is the the equivalent thing as ~/.fgfsrc for Windows users Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson writes: Norman Vine wrote: To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. Yes thank you for finally making doable but it did take a lot of simulated aluminium just _raining_ out of the sky ... and a lot of rewriting code that just plainly ignored the the 'true' values that were there but enough cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
David Megginson wrote: I cannot say. One thing we're not modelling yet is nosewheel shimmy: Does this really have to be modeled, per se? Until we get support for force-feedback rudder pedals and seat cushions, the only thing we can reasonably do is play a sound. That can be done already with some fancy thresholding (gating with /gear[0]/wow and groundspeed) using the existing sound mechanism. I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
Andy Ross writes: Does this really have to be modeled, per se? Until we get support for force-feedback rudder pedals and seat cushions, the only thing we can reasonably do is play a sound. That can be done already with some fancy thresholding (gating with /gear[0]/wow and groundspeed) using the existing sound mechanism. I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. I've been fortunate enough to see the inside of a real A-320 sim. One pretty cool thing they modelled in ground taxiing is that if you crank the nose wheel too far in a tight turn, it starts to bounce (perpendicularly relative to the tire, forward relative the aircraft) and it shakes the whole plane and the passengers stiffen up probably more than just a bit. 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
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold I have no objection to a new autopilot module if someone wants to build it; the current one is fine but it's showing its age a bit. That said, it shouldn't be hard to make it configurable to use different property sources for specialized applications like your (Norm's) GIS work. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: Yes thank you for finally making doable but it did take a lot of simulated aluminium just _raining_ out of the sky ... and a lot of rewriting code that just plainly ignored the the 'true' values that were there I'm pretty sure that the true values were accessible through the property tree before the steam values were, but I'd have to look back through old e-mail. 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] multiplayer / AI property tree - questions
Andy Ross writes: I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. If it's bad enough, the whole plane shakes (we've had trouble with the nose strut on C-GPMR at the Ottawa Flying Club, and it had to be rebuilt); of course, since I'm holding the yoke, I feel it through that first. 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
[Flightgear-devel] starting the c310u3a-3d
I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, 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
Re: [Flightgear-devel] starting the c310u3a-3d
On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote: I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, Curt. The 2d 310 is the same, but the yasim one starts. JSBsim related perhaps? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote: I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, Curt. Okay, the fuel tanks appear to be dry. Add some fuel and they fire up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FWIW
Cameron Moore writes:
Dang. I was going to have you man the list admin duties. :-) I will
be away Friday and Saturday, so Sunday you guys may see some delayed
posts if I have to approve any.
Also while I'm here, I wanted to mention that I get around 3 spams per
day to the flightgear lists that noone ever sees (I'm the primary
moderator if you haven't picked that up yet). The moderating is working
out pretty well I think.
trying_to_make_myself_seem_more_useful('ly yours');
I for one, *very highly* appreciate your willing to cover the bulk of
the list admin tasks.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
RE: [Flightgear-devel] starting the c310u3a-3d
Who emptied the fuel tanks? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Check Sent: Thursday, October 10, 2002 10:43 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] starting the c310u3a-3d On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote: I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, Curt. Okay, the fuel tanks appear to be dry. Add some fuel and they fire up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 12:05 am, Jon Berndt wrote: Who emptied the fuel tanks? Dunno. I checked a few revisions back and didn't see anything. I'm committing wet tanks shortly. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Check Sent: Thursday, October 10, 2002 10:43 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] starting the c310u3a-3d On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote: I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, Curt. Okay, the fuel tanks appear to be dry. Add some fuel and they fire up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 12:08 am, John Check wrote: On Friday 11 October 2002 12:05 am, Jon Berndt wrote: Who emptied the fuel tanks? Dunno. I checked a few revisions back and didn't see anything. I'm committing wet tanks shortly. I forgot to put it in the log message, but I also moved markup defining state to the head of the c310*-set.xml for consistencies sake. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Is this a side effect of no longer getting the C172 defaults? Jon Berndt writes: Who emptied the fuel tanks? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Check Sent: Thursday, October 10, 2002 10:43 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] starting the c310u3a-3d On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote: I'm not sure what changed, but I can no longer start the c310u3a-3d engines. They will fire and turn over, but as soon as I disengage the starter, they spin back down and refuse to run. Also, they no longer come up running by default. Regards, Curt. Okay, the fuel tanks appear to be dry. Add some fuel and they fire up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 12:15 am, Curtis L. Olson wrote: Is this a side effect of no longer getting the C172 defaults? That sounds like a reasonable deduction. I'm checking the rest of the planes to see if we need to gas up. I noticed the yasim planes have thier own definition for fuel inside the sim node. Also, what happened to the runway lighting? I'm a little out of touch since I've spent the last week (at least) installing Gentoo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
John Check writes: Also, what happened to the runway lighting? I'm a little out of touch since I've spent the last week (at least) installing Gentoo It should still be there, isn't it? I have been working on building more infrastructure for doing runway/approach lighting and working on using environment mapping to simulate directional lights which (except for VASI/PAPI) is working out very well. 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
RE: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 12:15 am, Curtis L. Olson wrote: Is this a side effect of no longer getting the C172 defaults? That sounds like a reasonable deduction. I'm checking the rest of the planes to see if we need to gas up. I noticed the yasim planes have thier own definition for fuel inside the sim node. Well, the JSBSim planes have fuel tanks that specify capacity and fullness. We don't deliver planes with no fuel, far as I know. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Whats the deal with the x24b fuel wise? That's missing a consumables section as are the shuttle and x15 ?? The JSBSim config files have fuel loaded for the X15, the X24B, the C310, the C172, etc. But NOT the shuttle (we just use it as a glider). I don't know what this consumables thing it, but JSBSim loads its aircraft with fuel in the JSBSim config files. If it has no fuel, the FlightGear is screwing around with the fuel, after the aircraft is already loaded by us. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] spot landings
This coming Saturday is the annual safety competition for San Diego and, as one of the organizers, I've been thinking about the spot landings task. It occurs to me that FGFS should be able to do that really well, except the touchdown report is minimal. How much hassle would it be, to have the existing gear message (to console) report the (u,v) and name of the texture which the wheel hit, or some other relative-to-runway numbers ? That would enable sim pilots to fly TnG series, with automatic scoring. PS. Anybody interested in turning up at KRNM with an airplane is welcome; feel free to contact me for details of the actual event and competition. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] c172-larcsim -why?
I was going through the c172 variants and adding the electrical system and I fired up the c172-larcsim. It's got a major problem. It just sits on the runway no matter how much throttle you give it. I took a quick look at the xml file in case it was something obvious. I gave comparative analysis a shot, but the only other planes that use larcsim are the UIUC planes. Now, the part that confused me is the aero section. On the c172-larcsim it's defined as c172, on the UIUC lanes it's defined as uiuc with an additional tag to define the location of the FDM config. There does not appear to be a larcsim c172.dat anymore, except for in the Aircraft-uiuc tree. To use that, I have to set aerouiuc/aero and define aircraft-dir. This has the starting below the runway bug. So the question is, is aerolarcsim/aero deprecated? Should we make this a UIUC plane, or drop it or what? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-larcsim -why?
John Check wrote: I was going through the c172 variants and adding the electrical system and I fired up the c172-larcsim. It's got a major problem. It just sits on the runway no matter how much throttle you give it. I took a quick look at the xml file in case it was something obvious. I gave comparative analysis a shot, but the only other planes that use larcsim are the UIUC planes. We used to have a Navion. Have we lost it on the way? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
Curtis L. Olson writes: Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! Would you like to buy a pair of slightly used C172 wing tip scuff guards? Protects the paint and the red/green lights, guaranteed not to break off before the wing. Now available in a trendy neon color assortment. Fortunately, I've never seen a landing where the wingtips even came close to touching the ground -- the excursions are usually pitch or yaw rather than roll. The danger to wingtips is hangar rash (i.e. fender benders) from other aircraft taxiing around the parking area. In real life, it's also much harder to do a tail strike than it is with the JSBSim 172 -- it's quite safe to pull all the way back on the yoke to keep the weight off the nosewheel. 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] Airspeed indicator and pitot system
David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Airport Database Model
Alex Perry writes: * Alex Perry -- Thursday 10 October 2002 20:10: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. But then you couldn't teleport to arbitrary airports, n'est ce que pas? Oh, sorry, let me elaborate ... 1. I'm assuming we keep the airport database (but maybe omit runways etc) Then someone will want to teleport to a specific runway at a specific airport. :-) 2. Given an airport ID, FGFS must priority load the relevant file above 3. The remaining files (between zero and about 300) are defer loaded 4. When the scenery loader thread has no tiles to do, it does one file 5. Thus, we can put huge amounts of information into each airport record I think it's reasonable to consider saving the same data in more than one form in order to suit different needs of different sections of the code. 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
Re: [Flightgear-devel] Flightgear scenery editor?
On 10/10/02 at 5:42 PM Frederic BOUVIER wrote: David Luff [EMAIL PROTECTED] wrote : I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the There is fgsd ( for FlightGear Scenery Designer ) at http://fgsd.sourceforge.net/ Thats the one I was looking for! Thanks - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Airport Database Model
1. I'm assuming we keep the airport database (but maybe omit runways etc) Then someone will want to teleport to a specific runway at a specific airport. :-) Yeah, but the runway-based user request is precisely why I stated that the file is priority loaded ... so we get the runway position details. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Curtis L. Olson wrote: There is a ton of internal infrastructure stuff that is useful in the geek sense ... property system, interfacing to external programs. The ability to build instrument panels, electrical systems, 3d models, animation, with absolutely no coding or plugins. Many features are setable via the property system, command line options, or preferences.xml which might not be immediately obvious to a new comer. Most of the geeks that I told that you can telnet into FGFS and have a shell there didn't believe me until I showed them... :) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On 10/10/02 at 8:38 AM Alex Perry wrote: Definitely. If one of the computers taking part in the multiplayer network has generated a bunch of AI aircraft, will they all be propagated to the rest of the multiplayer members ? Now theres a scary thought! What happens if one multiplayer has --disable-ai and one has it enabled? Who's computer is in charge of ATC? Things could get very interesting rapidly... If so, you might be able to dodge the processor load of full aircraft simulations, by having two computers with one having the human and a graphics display and the other having all the AI and no graphics display. Just a thought. So thats what old PC's without hardware acceleration capability are for!! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
In real life, it's also much harder to do a tail strike than it is with the JSBSim 172 -- it's quite safe to pull all the way back on the yoke to keep the weight off the nosewheel. Try playing with your CG in JSBsim; I routinely see aircraft with their tail tiedown heavily abraded due to excessive back pressure with aft CG. I've also seen people flare, balloon, stall, and hit _tail_ first. Amazingly, they then apply power for the touch-and-go without worries (as though they do it all the time) instead of finding a mechanic to have a quick look at the airframe for buckling and/or crack formation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
On 10/10/02 at 10:42 AM Curtis L. Olson wrote: Yes, and everyone knows that there is no such thing as magic carpets, so running with the ufo FDM is a lot more realistic since the ufo is based on real world data and uses actual real life sound samples. Yes, and non-Americans know that there's no such thing as ufos and that we have actually been to the moon :-) I'll-get-me-coat-and-leave-now'ly yrs Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On 10/10/02 at 6:13 PM Jon Stockill wrote: Indeed - it'll be nice to have a quick and easy way of getting other aircraft in the sky, however, I think from a long term point of view automated traffic would be best managed by simply being a task which appears as another remote user (yes, I know the multi user stuff isn't ready quite yet, but it strikes me as being the most obvious way to implement it. Possibly true. Still, however the ai aircraft eventually end up getting stored in the property tree and rendered, the actual logic of when to appear, where to fly and how to communicate and interact with other traffic will still be needed and won't be wasted. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
