[Flightgear-devel] Balloon Controls
Moving sidewards (e.g. due to wind) is possible and the direction and amount is calculated, but I don't know the correct API calls to convert the linear movement to a change in lat/lon. During my balloon flight I noticed that the controls were much more complex that just a burner. This particular balloon had 3 separate burners, two of which could be plumbed together with a cross flow valve, which enabled both to be operated by one action. Each burner could produce two types of flame, hot and loud, or not quite so hot, but softer. The softer flame being used close the ground, especially over livestock. And of course the amount of flame was user controllable. There were also several climbing type ropes hanging down into the basket from the envelope. They appeared to control flaps (as in doors) in the side of the envelope that could be opened to obtain rotation of the balloon, one to open a vent at the top, and one that was used to deflate the balloon. This last control was a surprisingly simple control. The top of the balloon was a separate circle of fabric. It was attached to the rest of the envelope by radial ribbons, and velcro to hold the edge of the circle to the top edge of the rest of the envelope. When you want to let all the hot air out (on the ground only I presume), you pull the rope and the top parts company with the sides and leaves a 2 foot gap all around the top. Voila - deflated balloon in about 5 minutes. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
David Megginson wrote:
Julian Foad writes:
No - we have that in some places, but I was thinking recently that it's
not the right way to go. I think the only practical purpose is to
reduce clutter in the browser; but the property browser could and should
do this for us if we want it to.
It also makes life easier for programmers, since we can pass around
one node containing engine settings and nothing else.
Hmm ... I was about to agree with that ... but why is that useful? Think about how
you then use that node controls/engines that you are passing around: you assume that
it contains sub-nodes called engine[n], and you access them. If instead you pass
around the node controls, the exact same functions can access the engine[n]
children in the same way. They won't be confused or hampered by the fact that that
node also has other sub-nodes that it isn't interested in ... will they? (OK, they
must access the children as 'children(engine)' rather than as 'children()'.)
Also, consider the generality of the way the property manager implicitly allows every
node to be indexed. This allows us to add each new feature in the singular:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
and then later to add more of them without changing the existing one:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
/instruments/altimeter[1]/{datum,serviceable,altitude-ft,...}
This is a really nice feature of the property manager. If there is a policy of
putting plural properties under a singular parent node, it doesn't accord with this
convenient practice. As you are considering moving the engine controls to a new place
in the tree anyway, you have the freedom to arrange them any way you like. That is,
it is not going to be backward-compatible anyway, and we already handle more than one
engine, so this particular case won't suffer additionally from a switch from singular
to plural. But consider that very many of the existing singular properties will
probably be pluralised at some time in the future.
I think I don't like mixing both ways. If we want each node to contain EITHER a list
of differently-name sub-nodes OR an indexed array (but not a mixture of both), then it
would make sense to make the property manager support this syntax directly - like
perhaps engine/n or engine/[n].
To me, in the existing property manager the notation engine[n] is the correct
syntax to describe the n'th engine and duplication of the name engine seems
logically wrong.
- Julian
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: I don't know where the navigation lights are powered from in real life. I'm guessing maybe this is the same thing as the beacon (?) I don't see a specific reference to navigation lights power in the C172 electrical diagram. Here's a quick overview of the external lights in a 172: navigation lights: A red light on the left wing tip and green light on the right wingtip, visible from the front and (relevant) sides, and a white light pointing backwards from the tail. Required for night flight. beacon: Big flashing/rotating red light extending above the vertical tail and visible from every direction. Optional for night flight, and not on every aircraft, but pretty commonly used. Note: at our flying club, the policy is always to leave the beacon switched on; that way, you can tell from a distance if someone's forgotten to turn off the masters after shutting down the plane. strobes: Flashing lights on the wingtips (and other places for bigger planes). Optional for night flight, and not on every aircraft. Note: pilots usually turn the strobes off on the ground or in cloud or fog, for obvious reasons. landing light: Bright spotlight in the nose or left wing, aimed a bit forward of the plane. Required for night flight with passengers, optional otherwise (I've already done practice landings without it). Note: pilots often leave the landing light on continuously night and day for visibility, except when taxiing facing a plane making an approach (to avoid confusing the pilot). taxi light: Bright light usually located right beside the landing light on the nose or left wing. Optional for night flight, and not on every aircraft. There is a separate switch for each of these on the control panel. 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] Parachute for C172
Curtis L. Olson writes: The opposite is also a problem ... pilots not pulling the chute because they think they can save the plane or successfully land it and then getting themselves hurt. I recall some time back a Cirrus pilot being critically injured and totalling his plane when he crash landed in a corn field. Made me wonder why he didn't pull the chute, but he probably thought he could save a few bucks (the parachutes are one shot only I believe) if he just glided it in. Was it a crash landing (structural damage and loss of control) or just a forced landing (engine failure)? A forced landing in a cornfield should be pretty routine; when pilots die after an engine failure in VMC, it's usually because they a) try to turn back to the airport immediately after takeoff (it didn't work for the last 2,000 pilots who tried it, but maybe it will work for me...); or b) try to stretch the glide to make a runway (ditto). I spend more time reading accident reports than is healthy, and I haven't noticed many reports of fatalities (if any) when the pilot simply set the plane down in a nearby field instead of trying to make an airport; sometimes the plane is wrecked up (i.e. nosewheel goes down a gopher hole or into a ditch and the plane flips over), but the crops and the airframe usually absorb most of the energy. Note that the SR22 pilot who did use the BRS damaged his plane pretty badly as well, and he had no control over where he landed (at a very high descent rate). If it had hit high trees rather than low ones before it nosed over, he might have been badly injured as well. If I had an engine failure around Ottawa in good VMC, I'd certainly choose a routine forced landing in a field over a 2000fpm vertical descent, possibly onto the edge of a tall building, a power line, 100ft trees, the railway tracks, the middle of a freeway, etc. etc. If I was in a midair and the plane was not controllable, or perhaps if I had an engine failure in IMC over hostile terrain with high obstacles, then I might take my chances with a BRS. 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] Aircraft lights: navigation lights and beacon
David, I'm not disagreeing with you, but in the electrical system diagram in the C172S Information Manual I can't find any mention of where the navigation lights are fed. Perhaps I'm misreading something? The manual does describe the navigation lights as part of the exterior lighting system consisting of lights on the wing tips and on top of the rudder. Later it says that the lights are all controlled by breakers/switches on the lower left instrument panel. So I'm probably miss reading something in the diagram. I assume you have a similar C172 manual ... perhaps you could find where the navigation lights are powered from on your model and we could work from that. Thanks, Curt. David Megginson writes: Here's a quick overview of the external lights in a 172: navigation lights: A red light on the left wing tip and green light on the right wingtip, visible from the front and (relevant) sides, and a white light pointing backwards from the tail. Required for night flight. beacon: Big flashing/rotating red light extending above the vertical tail and visible from every direction. Optional for night flight, and not on every aircraft, but pretty commonly used. Note: at our flying club, the policy is always to leave the beacon switched on; that way, you can tell from a distance if someone's forgotten to turn off the masters after shutting down the plane. strobes: Flashing lights on the wingtips (and other places for bigger planes). Optional for night flight, and not on every aircraft. Note: pilots usually turn the strobes off on the ground or in cloud or fog, for obvious reasons. landing light: Bright spotlight in the nose or left wing, aimed a bit forward of the plane. Required for night flight with passengers, optional otherwise (I've already done practice landings without it). Note: pilots often leave the landing light on continuously night and day for visibility, except when taxiing facing a plane making an approach (to avoid confusing the pilot). taxi light: Bright light usually located right beside the landing light on the nose or left wing. Optional for night flight, and not on every aircraft. There is a separate switch for each of these on the control panel. David -- 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] Parachute for C172
Disclaimer, I only saw the 14 second blurb on the news; so the following is based on an event filtered through some TV news reporter who's aviation experience probably ended with the in flight magazine, then filtered through my own head, and now we are talking about the fading distant memories of that ... David Megginson writes: Was it a crash landing (structural damage and loss of control) or just a forced landing (engine failure)? A forced landing in a cornfield should be pretty routine; My impression was that it looked like a routine forced landing in a corn field due to engine failure. Thus I was surprised by the amount of damage to the aircraft and the severity of the injuries. In my head I thought, if things were that bad, why didn't they just pull the chute? My guess at the time was that it was a routine forced landing in the corn which is why they chose not to pull the chute, but perhaps they tried to stretch the glide out too far, or misjudged something, and ended up hitting *much* harder than they should have. 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 when pilots die after an engine failure in VMC, it's usually because they a) try to turn back to the airport immediately after takeoff (it didn't work for the last 2,000 pilots who tried it, but maybe it will work for me...); or b) try to stretch the glide to make a runway (ditto). I spend more time reading accident reports than is healthy, and I haven't noticed many reports of fatalities (if any) when the pilot simply set the plane down in a nearby field instead of trying to make an airport; sometimes the plane is wrecked up (i.e. nosewheel goes down a gopher hole or into a ditch and the plane flips over), but the crops and the airframe usually absorb most of the energy. Note that the SR22 pilot who did use the BRS damaged his plane pretty badly as well, and he had no control over where he landed (at a very high descent rate). If it had hit high trees rather than low ones before it nosed over, he might have been badly injured as well. If I had an engine failure around Ottawa in good VMC, I'd certainly choose a routine forced landing in a field over a 2000fpm vertical descent, possibly onto the edge of a tall building, a power line, 100ft trees, the railway tracks, the middle of a freeway, etc. etc. If I was in a midair and the plane was not controllable, or perhaps if I had an engine failure in IMC over hostile terrain with high obstacles, then I might take my chances with a BRS. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson wrote: David, I'm not disagreeing with you, but in the electrical system diagram in the C172S Information Manual I can't find any mention of where the navigation lights are fed. Perhaps I'm misreading something? The manual does describe the navigation lights as part of the exterior lighting system consisting of lights on the wing tips and on top of the rudder. Later it says that the lights are all controlled by breakers/switches on the lower left instrument panel. So I'm probably miss reading something in the diagram. I assume you have a similar C172 manual ... perhaps you could find where the navigation lights are powered from on your model and we could work from that. Thanks, Curt. David Megginson writes: Here's a quick overview of the external lights in a 172: navigation lights: A red light on the left wing tip and green light on the right wingtip, visible from the front and (relevant) sides, and a white light pointing backwards from the tail. Required for night flight. beacon: Big flashing/rotating red light extending above the vertical tail and visible from every direction. Optional for night flight, and not on every aircraft, but pretty commonly used. Note: at our flying club, the policy is always to leave the beacon switched on; that way, you can tell from a distance if someone's forgotten to turn off the masters after shutting down the plane. strobes: Flashing lights on the wingtips (and other places for bigger planes). Optional for night flight, and not on every aircraft. Note: pilots usually turn the strobes off on the ground or in cloud or fog, for obvious reasons. landing light: Bright spotlight in the nose or left wing, aimed a bit forward of the plane. Required for night flight with passengers, optional otherwise (I've already done practice landings without it). Note: pilots often leave the landing light on continuously night and day for visibility, except when taxiing facing a plane making an approach (to avoid confusing the pilot). taxi light: Bright light usually located right beside the landing light on the nose or left wing. Optional for night flight, and not on every aircraft. There is a separate switch for each of these on the control panel. David Hello, Checked a manual (and cockpit) of a C172N, so expect some differences. Below the left yoke on the panel are 2 rows of push-reset thermal breakers. At the right end of the bottom row are 3 white rocker switches. The last 6 items at the right end of bottom row are: 1. Beacon breaker. 2. Nav. lights breaker. 3. Pitot heater breaker. 4. Pitot heater switch. 5. Nav light switch. 6. Beacon switch. The Nav light breaker is 10 Amp. rating. They have several of the 172N at the local flight school. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Bill, Is there anything in theh electrical diagram that shows how they are fed (i.e. from what bus) Curt. William Earnest writes: Curtis L. Olson wrote: David, I'm not disagreeing with you, but in the electrical system diagram in the C172S Information Manual I can't find any mention of where the navigation lights are fed. Perhaps I'm misreading something? The manual does describe the navigation lights as part of the exterior lighting system consisting of lights on the wing tips and on top of the rudder. Later it says that the lights are all controlled by breakers/switches on the lower left instrument panel. So I'm probably miss reading something in the diagram. I assume you have a similar C172 manual ... perhaps you could find where the navigation lights are powered from on your model and we could work from that. Thanks, Curt. David Megginson writes: Here's a quick overview of the external lights in a 172: navigation lights: A red light on the left wing tip and green light on the right wingtip, visible from the front and (relevant) sides, and a white light pointing backwards from the tail. Required for night flight. beacon: Big flashing/rotating red light extending above the vertical tail and visible from every direction. Optional for night flight, and not on every aircraft, but pretty commonly used. Note: at our flying club, the policy is always to leave the beacon switched on; that way, you can tell from a distance if someone's forgotten to turn off the masters after shutting down the plane. strobes: Flashing lights on the wingtips (and other places for bigger planes). Optional for night flight, and not on every aircraft. Note: pilots usually turn the strobes off on the ground or in cloud or fog, for obvious reasons. landing light: Bright spotlight in the nose or left wing, aimed a bit forward of the plane. Required for night flight with passengers, optional otherwise (I've already done practice landings without it). Note: pilots often leave the landing light on continuously night and day for visibility, except when taxiing facing a plane making an approach (to avoid confusing the pilot). taxi light: Bright light usually located right beside the landing light on the nose or left wing. Optional for night flight, and not on every aircraft. There is a separate switch for each of these on the control panel. David Hello, Checked a manual (and cockpit) of a C172N, so expect some differences. Below the left yoke on the panel are 2 rows of push-reset thermal breakers. At the right end of the bottom row are 3 white rocker switches. The last 6 items at the right end of bottom row are: 1. Beacon breaker. 2. Nav. lights breaker. 3. Pitot heater breaker. 4. Pitot heater switch. 5. Nav light switch. 6. Beacon switch. The Nav light breaker is 10 Amp. rating. They have several of the 172N at the local flight school. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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] Nav. light feed.
Hello, Forgot to mention the Nav. light breaker is fed directly from the primary bus, second item from bottom of page. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: So I'm probably miss reading something in the diagram. I assume you have a similar C172 manual ... perhaps you could find where the navigation lights are powered from on your model and we could work from that. In the 1981 C172P, there is a circuit breaker off the primary bus labelled NAV LT that goes to the navigation lights, control wheel map light, and audio muting relay. Here's the complete list of breakers: Primary Bus --- AIR COND CIR FAN - to air conditioning system or circulation fan system ALT FIELD - to master switch FLAP - to wing flap system PITOT HEAT - to pitot heat system INST - to ignition switch - to oil temperature gauge - to low-voltage warning light - to fuel quantity indicators and carburetor air temperature gauge INT LT - to door post map light - to dome and courtesy lights - to instrument, radio, magnetic compass, and post post lighting NAV LT - to audio muting relay - to navigation lights and control wheel map light BCN LT - to flashing beacon [cigar lighter has a direct connection to the primary bus] LAND LT - to taxi and landing lights STROBE AVN FAN - to strobe lights - to avionics cooling fan TURN COORD - to turn coordinator Avionics Bus [connected to primary bus through avionics master switch] RADIO 1 - to radio RADIO 2 - to radio RADIO 3 - to radio RADIO 4 - to radio or transponder and encoding altimeter RADIO 5 - to radio AUTO PILOT - to autopilot Note that many of the components, like the strobes, autopilot, and air conditioning, are optional extras. 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] Parachute for C172
Curtis L. Olson writes: My impression was that it looked like a routine forced landing in a corn field due to engine failure. Thus I was surprised by the amount of damage to the aircraft and the severity of the injuries. In my head I thought, if things were that bad, why didn't they just pull the chute? My guess at the time was that it was a routine forced landing in the corn which is why they chose not to pull the chute, but perhaps they tried to stretch the glide out too far, or misjudged something, and ended up hitting *much* harder than they should have. What was the date of the accident? We might be able to find a preliminary NTSB report. 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] Parachute for C172
David Megginson writes: My impression was that it looked like a routine forced landing in a corn field due to engine failure. Thus I was surprised by the amount of damage to the aircraft and the severity of the injuries. In my head I thought, if things were that bad, why didn't they just pull the chute? My guess at the time was that it was a routine forced landing in the corn which is why they chose not to pull the chute, but perhaps they tried to stretch the glide out too far, or misjudged something, and ended up hitting *much* harder than they should have. What was the date of the accident? We might be able to find a preliminary NTSB report. Here's another one involving the BRS where it failed to deploy in IMC: http://www.ntsb.gov/NTSB/brief.asp?ev_id=20020326X00393key=1 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] SR-20 in a corn field
This looks like it might be the one: http://www.ntsb.gov/NTSB/brief2.asp?ev_id=20010921X01977ntsbno=CHI01LA318akey=1 The problem was that he had only seconds to pick a landing site and set up a final approach once he broke out of IMC, and given those constraints, it's quite impressive that he managed to put it down in a field at all without doing something stupid like spinning out or a controlled flight into terrain. 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] No rule to make target `new_gui.cxx'
Hello, am I the only one seeing this with the recent CVS checkout: Making all in GUI make[2]: Entering directory `/usr/local/src/FlightGear/src/GUI' source='apt_dlg.cxx' object='apt_dlg.o' libtool=no \ depfile='.deps/apt_dlg.Po' tmpdepfile='.deps/apt_dlg.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/opt/gnu/include -I/usr/local/include -I/usr/local/FlightGear/include -I/usr/X11R6/include -O3 -D_REENTRANT -c -o apt_dlg.o `test -f 'apt_dlg.cxx' || echo './'`apt_dlg.cxx make[2]: *** No rule to make target `new_gui.cxx', needed by `new_gui.o'. Stop. make[2]: Leaving directory `/usr/local/src/FlightGear/src/GUI' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1 Probably someting's missing in Makefile.in ? I didn't find the missing bit - for me everything appears to be in the right place, Martin. P.S.: SuSE-8.1/gcc-3.2/glibc-2.2.5/autoconf-2.53/automake-1.6.3/libtool-1.4.2 -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] No rule to make target `new_gui.cxx'
Martin Spott writes: make[2]: *** No rule to make target `new_gui.cxx', needed by `new_gui.o'. Stop. Somethings not rebuilding properly. Make sure you have a fresh CVS checkout, then touch src/GUI/Makefile.am and do a new make. If that doesn't work, try sh autogen.sh from the root first, then a new ./configure. 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] interesting ...
On Fri, 8 Nov 2002, Curtis L. Olson wrote: Too bad they aren't using FlightGear for their software component, but it still looks like a lot of fun ... They're intending linking to this: http://www.vatsim.net/ So they have virtual ATC as they fly. Is it possible to feed out flight data in the same format so that flightgear will work with this network? If not, is it something we should consider? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote:
[about making the panel hot spots visible]
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property.
That is excellent! So simple, and in conjunction with David's recent
zoom in/out/normal (+/-/=) bindings, it immediately makes clear what's
going on with the hot spots, and shows up the existing mistakes.
Everyone designing clickable instruments will benefit from this, so I
think your patch should go into CVS permanently.
I was just trying to sort some hot spots out by editing the numbers,
when I remembered that you'd just sent this patch. What a powerful tool
visualisation is!
- Julian
Index: panel.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.hxx,v
retrieving revision 1.2
diff -u -r1.2 panel.hxx
--- panel.hxx 29 Oct 2002 19:44:03 - 1.2
+++ panel.hxx 5 Nov 2002 21:38:59 -
-370,6 +370,7
virtual ~FGPanelInstrument ();
virtual void draw () = 0;
+ virtual void drawHotspots();
virtual void setPosition(int x, int y);
virtual void setSize(int w, int h);
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.3
diff -u -r1.3 panel.cxx
--- panel.cxx 29 Oct 2002 19:44:03 - 1.3
+++ panel.cxx 5 Nov 2002 21:38:59 -
-436,6 +436,21
glPopMatrix();
}
+ // Draw yellow hotspots if directed to. This is a panel authoring
+ // feature; not intended to be high performance or to look good.
+ if(fgGetBool(/sim/panel-hotspots)) {
+glPushAttrib(GL_ALL_ATTRIB_BITS);
+glDisable(GL_DEPTH_TEST);
+glDisable(GL_TEXTURE_2D);
+glColor3f(1, 1, 0);
+
+for(int i=0; i_instruments.size(); i++)
+ _instruments[i]-drawHotspots();
+
+glPopAttrib();
+ }
+
+
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
-647,6 +662,25
it++) {
delete *it;
*it = 0;
+ }
+}
+
+void
+FGPanelInstrument::drawHotspots()
+{
+ for(int i=0; i_actions.size(); i++) {
+FGPanelAction* a = _actions[i];
+float x1 = getXPos() + a-getX();
+float x2 = x1 + a-getWidth();
+float y1 = getYPos() + a-getY();
+float y2 = y1 + a-getHeight();
+
+glBegin(GL_LINE_LOOP);
+glVertex2f(x1, y1);
+glVertex2f(x1, y2);
+glVertex2f(x2, y2);
+glVertex2f(x2, y1);
+glEnd();
}
}
Re: [Flightgear-devel] re: ANN: starting the XML GUI; early implementors needed
David Megginson writes: Norman Vine writes: you have seen $PLIB / demos / p-guide esp. LoadSave.cxx Is that the GUI builder? Yes I was thinking that If we could build a version of the property viewer that would attach property nodes into the 'builder's' callback slots It might just 'come alive' :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] data logging
O.K. I've got a couple of new FDMs. 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). I have no clue how to check them in. Mark -Original Message- From: David Megginson [mailto:david;megginson.com] Sent: Thursday, November 07, 2002 10:36 AM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] data logging Boslough, Mark B writes: I wrote my own little playback routine (so I can replay flights from a .csv file). Do you all have plans to incorporate such a thing in FlightGear? I can run forward or backward using the joystick to control the speed. That sounds great -- we'd probably want to add it as an FDM. 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] re: ANN: starting the XML GUI; early implementors needed
Norman Vine writes: If we could build a version of the property viewer that would attach property nodes into the 'builder's' callback slots It might just 'come alive' :-) I'd love for FlightGear to be runtime configurable through a GUI -- just drag and drop a property onto a drop-down menu, a keyboard diagram, etc., and build new dialogs while the plane is flying. We probably need someone very committed to build that, though. 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] data logging
Boslough, Mark B writes: 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). I have no clue how to check them in. Sounds great -- send them to me and I'll take a look. I prefer patches against the current CVS from the top-level source directory, i.e. cvs diff -u new-fdms.dif I'm with extended family this weekend, so delays are possible. 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] Wright Flyer progress
It's looking good! (I look forward to flying or crashing it as the case may be). Chris On Sat, 2002-11-09 at 01:41, Jim Wilson wrote: Progress has been slow, mostly because of real work getting in the way, but the Wright Flyer is getting much closer to completion. Most of the detail and animation is done. Here's a shot from the front with the elevator mechanism tilted up for initial ascent.: http://www.spiderbark.com/fgfs/wrightflyer-starting.png From the earlier discussion and pictures available I took a guess on the wing warping. For now the animation is pretty crude (only three positions), but better than nothing. This is a shot from behind showing the wings warped for a roll toward the left: http://www.spiderbark.com/fgfs/wrightflyer-warp.png This is the startup line I'm using. The location and heading is based on a best guess from various accounts. Pictures of the Wright National Monument and a scan of a guide brochure from the Park helped a lot in at least matching reasonably close to the best guess that was arrived at in 1928 by a contingent of witnesses to the original event: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc --lat=36.020247 --lon=-75.669041 --heading=5 --disable-random-objects --enable-auto-coordination Crazy details left on my todo list: - Adding control cables/chains and blocks for all the control surfaces. - Animating Orville's hips and the cradle. - As soon as I figure out the exact shape, adding the foot stop that kept Orville from sliding off the back of the wing at startup. - As soon as I get some more information (a good picture or diagram), modeling the instrument cluster that was mounted just to the right of Orville's right arm. - Correct the elevator animation once information on its actual range is learned (anyone know this?) - Modeling the rail. - Modeling the rear skid (this is tricky because it gets dropped and left behind when the aircraft becomes airborn). I'm really not up to speed on scenery modeling, but if someone wants to it'd be great to have a tiny bit of territory covering just Kill Devil Hills, NC and the Outer Banks, that was simply covered with a nice beach sand texture as it was back in 1903. Another idea: if we had that little chunk of sandy scenery we might want to put together a special release (that included a binary and a tiny subset of the base package) for school teachers and whoever else to download during the centennial year. Might be kind of cool to release it next month on December 17th, the 99th aniversary of the first flight. Sounds like a potential promotional thing for the FlightGear project too, I'd think. Best, Jim ___ 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] Airwave Xtreme 150 hang glider updates
I have just updated the Airwave Xtreme 150 hang glider on the fgfs cvs to include the external model from Captain Slug! He has granted permission for us to use and release these with FlightGear under the GNU GPL. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Aircraft lights: navigation lights and beacon
The lights look great! The rear facing white light on the rudder is switched on with the red and green wing tip lights as the nav lights. Is there a RearNavLightOn and RearNav LightOFF object name? - Dave P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright Flyer progress
It's looking really good! On the aero side, I have few tweaks that I want to make before it's announced in whatever fashion. It should not take me too much longer to get to that. As for the elevator animation, I have use +-20 deg deflection on my model, but from pictures it looks like more elevator throw was possible. The update will include the wide elevator range w/ particulars to be determined. Regards, Michael At 11/9/02, Jim Wilson wrote: Progress has been slow, mostly because of real work getting in the way, but the Wright Flyer is getting much closer to completion. Most of the detail and animation is done. Here's a shot from the front with the elevator mechanism tilted up for initial ascent.: http://www.spiderbark.com/fgfs/wrightflyer-starting.png From the earlier discussion and pictures available I took a guess on the wing warping. For now the animation is pretty crude (only three positions), but better than nothing. This is a shot from behind showing the wings warped for a roll toward the left: http://www.spiderbark.com/fgfs/wrightflyer-warp.png This is the startup line I'm using. The location and heading is based on a best guess from various accounts. Pictures of the Wright National Monument and a scan of a guide brochure from the Park helped a lot in at least matching reasonably close to the best guess that was arrived at in 1928 by a contingent of witnesses to the original event: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc --lat=36.020247 --lon=-75.669041 --heading=5 --disable-random-objects --enable-auto-coordination Crazy details left on my todo list: - Adding control cables/chains and blocks for all the control surfaces. - Animating Orville's hips and the cradle. - As soon as I figure out the exact shape, adding the foot stop that kept Orville from sliding off the back of the wing at startup. - As soon as I get some more information (a good picture or diagram), modeling the instrument cluster that was mounted just to the right of Orville's right arm. - Correct the elevator animation once information on its actual range is learned (anyone know this?) - Modeling the rail. - Modeling the rear skid (this is tricky because it gets dropped and left behind when the aircraft becomes airborn). I'm really not up to speed on scenery modeling, but if someone wants to it'd be great to have a tiny bit of territory covering just Kill Devil Hills, NC and the Outer Banks, that was simply covered with a nice beach sand texture as it was back in 1903. Another idea: if we had that little chunk of sandy scenery we might want to put together a special release (that included a binary and a tiny subset of the base package) for school teachers and whoever else to download during the centennial year. Might be kind of cool to release it next month on December 17th, the 99th aniversary of the first flight. Sounds like a potential promotional thing for the FlightGear project too, I'd think. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airwave Xtreme 150 hang glider updates
On Friday 08 November 2002 9:43 pm, Michael Selig wrote: I have just updated the Airwave Xtreme 150 hang glider on the fgfs cvs to include the external model from Captain Slug! He has granted permission for us to use and release these with FlightGear under the GNU GPL. Regards, Michael Rock on! Please include a README with the contents of the email documenting his approval. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airwave Xtreme 150 hang glider updates
At 11/9/02, John Check wrote: On Friday 08 November 2002 9:43 pm, Michael Selig wrote: I have just updated the Airwave Xtreme 150 hang glider on the fgfs cvs to include the external model from Captain Slug! He has granted permission for us to use and release these with FlightGear under the GNU GPL. Regards, Michael Rock on! Please include a README with the contents of the email documenting his approval. Done. The file is here: ~/fgfsbase/Aircraft/airwaveXtreme150/Models/uiuc/hgldr-cs/readme.txt Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ASW 20 model added
I have just add an ASW 20 to the CVS. Not only does it include the flight dynamics model, but also there's an external model from Roland Stuck! He has granted permission for us to use and release these with FlightGear under the GNU GPL. Taken together, this is one really neat airplane in FGFS. There's a readme file on the external model from Roland Stuck in: ~/fgfsbase/Aircraft/asw20/Models/uiuc/asw20-stuck/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. Regards, Michael == = ASW 20 = = 15-meter class sailplane = = for FlightGear with LaRCsim and the UIUC Aeromodel = == = Flight model by: = = Michael Selig, et al. ([EMAIL PROTECTED]) = = http://www.aae.uiuc.edu/m-selig/apasim.html= == = External model by: = = Roland Stuck ([EMAIL PROTECTED]) = == To run, try: fgfs --aircraft=asw20-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: asw20-v1-nl-uiuc-set.xml asw20/Models/uiuc/asw20-stuck/asw20-stuck-model.xml asw20/Models/uiuc/asw20-stuck/asw20.mdl asw20/Models/uiuc/asw20-stuck/asw20mp_.0af asw20/Models/uiuc/asw20-stuck/asw20mp_.1af asw20/Models/uiuc/asw20-stuck/asw20mp_.2af asw20/Models/uiuc/asw20-stuck/asw20mp_.3af asw20/Models/uiuc/asw20-stuck/asw20mp_.4af asw20/Models/uiuc/asw20-stuck/asw20mp_.5af asw20/Models/uiuc/asw20-stuck/asw20mp_.6af asw20/Models/uiuc/asw20-stuck/asw20mp_.7af asw20/Models/uiuc/asw20-stuck/asw20mp_.8af asw20/Models/uiuc/asw20-stuck/asw20mp_.9af asw20/Models/uiuc/asw20-stuck/asw20mp_.aaf asw20/Models/uiuc/asw20-stuck/asw20mp_.baf asw20/Models/uiuc/asw20-stuck/asw20mp_.caf asw20/Models/uiuc/asw20-stuck/asw20mp_.daf asw20/Models/uiuc/asw20-stuck/asw20mp_.eaf asw20/Sounds/uiuc/asw20-sound.xml UIUC/asw20-v1-nl/CDfa-01.dat UIUC/asw20-v1-nl/CLfa-01.dat UIUC/asw20-v1-nl/Cmfa-01.dat UIUC/asw20-v1-nl/Cmfade-01.dat UIUC/asw20-v1-nl/aircraft.dat These files above come with the FlightGear base package. ~~ Model description and updates: 11/8/2002 - First release: v1-nl * Roland Struck ([EMAIL PROTECTED]) has granted FlightGear permission to use and release the external model files with FlightGear under the GNU GPL. * This flight dynamics model simulates an ASW 20 15-meter sailplane. * A weights and balance was performed to arrive at an allowable c.g. location and from that data, mass moments of inertia were calculated. * Lift, drag and pitching moment data is modeled from -180 to +180 deg. In general, the aerodynamics are modeled using various sources too numerous to mention here. * Apparent mass effects are modeled. * The simulation starts on the ground. To simulate being tow, the throttle can be used. The thrust was tuned to simulate a reasonable line tension and max rate of climb while on tow. Alternatively, Ctrl-U can be used to jump up in 1000-ft increments. * Interesting flight characteristics to note: - When starting out, quickly change views to see the external aircraft. The wings will start out level, and then one side will drop. For whatever reason, the left wing drops first even though the data in the model is symmetrical. - Taking off requires careful control of the rudder and ailerons. Use rudder to line up with the runway and ailerons to level the wings. It is easy to over correct (especially without a headwind), and the consequences should be reminiscent of being towed in a real sailplane. [I am speaking from experience, being a sailplane pilot and having part owned a Pegasus (~ASW 19)]. - The max lift-to-drag ratio is approx 42:1. This means that from a height of 1 mile, the gliding distance is 42 miles. This efficiency is most readily apparent when flying and landing. Adding spoilers is a high priority for the next update. - The long wings produce an over banking tendency when circling as would be done in thermals. Top aileron is required to keep the wings from over-banking. In addition extra rudder is then required to stay coordinated. - Tail slides and hammer heads appear to be quite realistic. This is one bonus that comes from modeling key aerodynamic data from +-180 deg. * What is not yet simulated: water ballast, flaps, spoilers. * Drag due to rudder deflection, aileron deflection, and side slip are not yet added. When these are added, slipping on landing will be more realistic. ~~ ** Prof. Michael S. Selig
