Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 01:17 am, Jon Berndt wrote: > > Whats the deal with the x24b fuel wise? That's missing a > > 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 > It's where the amount of fuel is published to drive the guages, or so I thought.. j4strngs@araka c310u3a $ cvs log c310u3a.xml revision 1.5 date: 2002/09/24 12:56:05; author: tony; state: Exp; lines: +76 -84 Updated all JSBSim aircraft config files to new file format Hmm... that section is a comment about the gear section... So the question is, is the cfg file parsing broken or are the values getting overwritten. Well... they're getting overwritten now that I added a section to the *set.xml files for the 310. poking around. Okay I see the c182-set has a consumables section as well and the last time that file was molested was 8/28: revision 1.10 date: 2002/08/28 15:00:26; author: curt; state: Exp; lines: +2 -0 Add a brief description to each *-set.xml file. Yow, I bet list traffic will be high tomorrow. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-larcsim -why?
On Friday 11 October 2002 02:23 am, Christian Mayer wrote: > 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 I don't see a config for it, but I thought it was hardcoded. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] starter value
Where is the initial true coming from? It's set to off in preferences.xml and generally not defined in the set files. As it stands, switching off the magnetos leaves the engine cranking. Also, the switch is drawn in the start position. It should suffice to set engine/running=true correct? I have to say, preferences.xml is looking right nasty about now. There is a lot of stuff that shouldn't be in there IMO. I'm out of touch with whats going on at the moment so no flames please. I expect to be doing some clean up and maybe wiring up some switches at the weekend. TTYL J ___ 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
[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 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 uiuc and define . This has the starting below the runway bug. So the question is, is larcsim 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
[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
RE: [Flightgear-devel] starting the c310u3a-3d
> Whats the deal with the x24b fuel wise? That's missing a > 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
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 12:41 am, Jon Berndt wrote: > 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 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 > Ya, I just said about that because when I started up all the available 310's and the dc3, only the yasim planes started up. Whats the deal with the x24b fuel wise? That's missing a section as are the shuttle and x15 I'm also seeing that on most planes, nightlighting is non existant. Should we use the '172 electrical system as a default or what? ___ 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 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
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 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
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: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
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
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] 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
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] 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] FWIW
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.10.10 10:45]:
> 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. :-)
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');
--
Cameron Moore
__END__
___
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] 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
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] 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/, 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] 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] 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] 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] 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] 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] 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] 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] 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] 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... > > > When will we ever learn? > 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] 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
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/, 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] 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] 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] 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] 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] 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
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] 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
On Thu, 10 Oct 2002, David Luff wrote: > I personally much prefer the second (embedded example). There's also > taxiway data needed as well - the thing could get *very* big by the time > its finished. Is there any sort of "master" database from which all this can be generated? Or should we create one? 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). -- 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] 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] 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. 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] 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] 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] 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] Airport Database Model
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. Airports aren't
very useful without scenery, anyway.
[* 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.]
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.
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] Airport Database Model
Curtis L. Olson writes: > 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. 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. Splitting by country could be interesting (possibly by country and state for the US): Airports/airport-index.xml Airports/AU/airports.xml Airports/CA/airports.xml Airports/UK/airports.xml Airports/US/CA/airports.xml Airports/US/NY/airports.xml Airports/US/MI/airports.xml and so on. airport-index.xml would have minimum info on each airport: CYOW .. .. CA/airports.xml Unfortunately, we don't currently have nationality information in default.apt.gz, but it is in the DAFIF, so we can add most of it automatically. This is also nice because we can assign different national files to different maintainers (one might want to handle AU and NZ, another might want to handle UK, FR, DE, ES, and NL, and so on). 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
David Luff writes: > I personally much prefer the second (embedded example). There's also > taxiway data needed as well - the thing could get *very* big by the time > its finished. Right. We'll probably want to split it into several files, possibly with an index as Alex and Andy have suggested. In the most extreme case, we could have one file for each airport. 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] 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] 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
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] 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] 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
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] 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] 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] 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] 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
> 3D instrument panels are visible and fully live and working even when > viewed from external chase views. 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 ... ___ 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
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] 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] Airport Database Model
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. 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. Yeah I know, but just don't look at the scenery database structure or the author of this message which you read the above caution. :-) Curt. Andy Ross writes: > 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: > > >KSFO >KOAK >... > > > And look up the airport data itself under Airports/KSFO.xml: > > > KSFO > San Francisco Intl. > ... > ... > ... > >11 >... >... >... >... >... > > > ... > > > > 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 -- 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
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
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] 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: KSFO KOAK ... And look up the airport data itself under Airports/KSFO.xml: KSFO San Francisco Intl. ... ... ... 11 ... ... ... ... ... ... 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] Airport Database Model
On 10/10/02 at 1:59 PM David Megginson wrote: >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: > > > ... > > > > 04/22 > CYOW > ... > > > > 07/25 > CYOW > ... > > > > 14/32 > CYOW > ... > > > > tower > 118.8 > CYOW > ... > > >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): > > > MacDonald-Cartier International > Ottawa > .. > .. > .. > ... > > > 04/22 > CYOW > ... > > > 07/25 > CYOW > ... > > > 14/32 > CYOW > ... > > > > > tower > 118.8 > CYOW > ... > > > > >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? I personally much prefer the second (embedded example). There's also taxiway data needed as well - the thing could get *very* big by the time its finished. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [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? Oh, sorry, let me elaborate ... 1. I'm assuming we keep the airport database (but maybe omit runways etc) 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 ___ 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] 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... When will we ever learn? 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] 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] Re: Airport Database Model
Melchior FRANZ writes: > 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. That's not a bad idea, if we design a way to remove information rather than just overwriting it. 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] 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
[Flightgear-devel] Init-order problem fixed for *-set.xml files
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? 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] 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
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] 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] 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: > > >... > > > >04/22 >CYOW >... > > > >07/25 >CYOW >... > > > >14/32 >CYOW >... > > > >tower >118.8 >CYOW >... > > > 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): > > >MacDonald-Cartier International >Ottawa >.. >.. >.. >... > > > 04/22 > CYOW > ... > > > 07/25 > CYOW > ... > > > 14/32 > CYOW > ... > > > > > tower > 118.8 > CYOW > ... > > > > > 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
> 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] 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
[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: ... 04/22 CYOW ... 07/25 CYOW ... 14/32 CYOW ... tower 118.8 CYOW ... 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): MacDonald-Cartier International Ottawa .. .. .. ... 04/22 CYOW ... 07/25 CYOW ... 14/32 CYOW ... tower 118.8 CYOW ... 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] 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
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] 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] ANN: AI traffic from Dave Luff
On Thu, 10 Oct 2002, David Luff wrote: > logic when beyond a certain distance/direction from the user is probably > eventually justified (IMHO). The problem here is when there are multiple users. > Still, regardless of how much get ripped out and rewritten eventually, its > still progress for now... 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. -- Jon Stockill [EMAIL PROTECTED] ___ 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
[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
Re: [Flightgear-devel] Flightgear scenery editor?
Norman Vine 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. > > re-Invention-is-a-wonderful-thing-to-behold'ly yrs Fortunately this is only a one line add if I ever need it again ... :-) 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 <[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 > 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. There is fgsd ( for FlightGear Scenery Designer ) at http://fgsd.sourceforge.net/ Cheers, -Fred ___ 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
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] 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?
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
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
