Re: [Flightgear-devel] P-38L-Lightning
Hello Gerard, very nice Aircraft indeed Am Freitag, den 29.06.2007, 23:07 +0200 schrieb gh.robin: On Fri 29 June 2007 21:55, Martin Spott wrote: gh.robin wrote: On Fri 29 June 2007 19:02, Martin Spott wrote: Woohooo, did anyone try putting this baby into a low-speed stall ? Make sure to gain enough altitude before ! yes it is given to stall at 91 kt, the model with that crude FDM [...] I didn't intend to blame the FDM for doing wrong, I was just a bit surprised how this beast behaves at stall and how difficult stall recovery might become It would be nice to know if this is actually similar to the 'real' one, Martin. Diff icult to answer, just this, which has been written : =About the only significant short coming of the Lightning was spin/.stall recovery, which could be a bear, especially at low altitude. That's is why this film cautions strongly against entering a spin below 10,000'= the manual states: As stalling speed is approached, the center section stalls first with noticeable shaking of the airplane, however, the ailerons remain effective. In either power-on or power-off stalls with flaps and landing gear up, the airplane mushes straight forward in a well-controlled stall. With flaps and landing gear down, there appears to be a slight tendency for one wing to drop. There is, however, no tendency to spin. Under these conditions, the nose drops slightly and, as the speed increases, the wing will come up. SPINS. Deliberate spinning is prohibited because the spin tends to flatten out after two or three turns. When this occurs, the control column is forced back and engine power must be used to help get the control column forward. Before flattening out, normal recovery may be made without power. Recovery is made' by applying full opposite rudder and easing the control column forward. If you don't already have it, I will send it to you. Greetings Detlef you can read that here. http://zenoswarbirdvideos.com/P38.html?gclid=CM3ixPSXgo0CFQNNZwodE3aoPA In addition to when i tried to tune the FDM i was surprised by that high value wing loading: 53 lb/sq-ft given with an average weight loaded 17500 lbs (empty weight 12500 lbs). cheers - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft design idea: Cirrus Jet
Ampere K. Hardraade wrote: On June 29, 2007 01:44:27 pm Curtis Olson wrote: I got to see it a day earlier, even before the folks that have plunked down $100k to get on the waiting list got to see it ... but all the employees got to see it before me. I'm more interested in those guys who plunked down $100k just to see it than the actual plane itself. :P I guess Curt's been talking about those people who had to pay a first chunk because they've been ordering such an aircraft, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fun with nasal ai
* Melchior FRANZ -- Friday 29 June 2007: http://members.aon.at/mfranz/ai.nas [1.7 kB] It's a bit faster, too, although 8.7 seconds for EHAM/parking.xml is still a lot (was 12.8 before). And that comes from bad Nasal code, not from the c(++) expat/EasyXML parser code, which is very fast. Fixed in $FG_ROOT/Nasal/io.nas. Reading EHAM/parking.xml, parsing and converting to property tree: Before -- 9.015211 s Now-- 0.619772 s Placing the models still takes several seconds, and I'm afraid I can't do much here. We'll see ... What the bad Nasal code was, you ask? Using size(n.getChildren(foo)) to determine the index of the next foo node to generate. That's the standard way of doing it, but in a case like mine where I don't add to an unknown node dir, but generate *all* of the nodes myself, anyway, I can just count them. A lot faster. :-) What we learn: don't use props.Node.getChildren() if avoidable. m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] P-38L-Lightning
On Saturday 30 June 2007 09:11:36 Detlef Faber wrote: very nice Aircraft indeed Speaking of which, here is a very interesting story: http://news.bbc.co.uk/1/low/scotland/highlands_and_islands/6245802.stm Nick -- Free Software Foundation Associate Member 5508 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control lockingbyautopilot
An airliner some years ago crashed into the Everglades in Florida because the autopilot was unknowingly disengaged by accidental knee pressure on the Yoke as the pilot was getting out of his seat. Specs showed that the minimum 45 pounds pressure required was faulty. The aircraft had been in a holding pattern pending confirmation that the gear was down, since the indicator lamp was burned out and the spare broke upon attempted removal from its recessed location. Unknowingly the aircraft was slowly descending and the last thing on the voice recorder ws the co-pilot Hey, there's something wrong with the instruments when he noticed the altimeter showed just above ground level. If I understand the FG issue correctly, then I would think that a sudden movement of the Yoke could be used to disengage the autopilot. Tom Markowitz - Original Message - From: Ampere K. Hardraade To: FlightGear developers discussions Sent: Saturday, June 30, 2007 12:12 AM Subject: Re: [Flightgear-devel] [off list] patch for control lockingbyautopilot On June 28, 2007 09:44:54 am Roy Vegard Ovesen wrote: On Wednesday 27 June 2007 23:05, woodyst wrote: The diffs are at http://www.eurogaran.com/fgfs/fgfs_ap_joy_locking.diff and http://www.eurogaran.com/fgfs/kap140_locking_controls_capable.diff AFAIK real life autopilots can be overpowered by the pilot. Wheter this is done by brute force or if the servos can sense that they are being overpowered and then let go, I don't know. Since we don't have any force feedback support in Flightgear, we'll have to make the autopilot sense that it is being overpowered. The hard part will be how to decide that the pilot is trying to overpower the autopilot. One possibility is to press a button to tell that you are overpowering. My guess is that it probably monitors the integrated term in a PID controller, and disengages when the value reaches a certain threshold. Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] automake test
In the plib branch,
diff -r 131a68f9fb0c autogen.sh
--- a/autogen.shFri Jun 29 15:34:40 2007 +
+++ b/autogen.shSat Jun 30 07:50:40 2007 -0600
@@ -2,7 +2,7 @@
OSTYPE=`uname -s`
MACHINE=`uname -m`
-AUTO_MAKE_VERSION=`automake --version | head -1 | awk '{print $4}' |
sed -e 's/\.\([0-9]*\).*/\1/' | cut -c1,2`
+AUTO_MAKE_VERSION=`automake --version | head -1 | awk '{print $4}' |
sed -e 's/\.\([0-9]*\).*/\1/'`
if test $AUTO_MAKE_VERSION -lt 15; then
echo
echo You need to upgrade to automake version 1.5 or greater.
The cut bit is unnecessary and wrong - it doesn't work with automake
version 1.10, which is version 1.5 or greater.
--
Hans Fugal
Fugal Computing
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control lockingbyautopilot
On 06/30/2007 09:52 AM, [EMAIL PROTECTED] wrote: An airliner some years ago crashed into the Everglades in Florida because the autopilot was unknowingly disengaged by accidental knee pressure on the Yoke as the pilot was getting out of his seat. Specs showed that the minimum 45 pounds pressure required was faulty. The aircraft had been in a holding pattern pending confirmation that the gear was down, since the indicator lamp was burned out and the spare broke upon attempted removal from its recessed location. Unknowingly the aircraft was slowly descending and the last thing on the voice recorder ws the co-pilot Hey, there's something wrong with the instruments when he noticed the altimeter showed just above ground level. If I understand the FG issue correctly, then I would think that a sudden movement of the Yoke could be used to disengage the autopilot. This is a tricky issue. One case that has to be considered is what happens when you are /engaging/ the autopilot. In particular, suppose you are in a long-winged glider in a steep turn, holding tons of outside aileron to compensate for the overbanking tendency. You engage the autopilot, desiring that it will maintain the turn. Then -- in the real aircraft, you let go of the yoke and it stays where it is. No problem. -- in FG, you let go of the yoke and it springs back to the center. That's a problem. On the other side of the same coin, suppose you want to disengage the autopilot while the ailerons are deflected. You really ought to deflect the joystick so that it matches what the autopilot is doing with the yoke, before hitting the autopilot disengage button. Similar considerations apply to the pitch axis and yaw axis. Keep in mind the pilot who inadvertently snap-rolled a 747, seriously injuring a couple of passengers, by disengaging the autopilot without noticing that the autopilot was holding one of the rudder pedals to the floor. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 and references therein. Note that there are four stages of sophistication among FG users: a) Using the keyboard for primary flight control; b) Using the mouse for primary flight control; c) Using a plain old joystick for primary flight control; or d) Using a joystick with force-feedback (or position servos) for primary flight control. It is slightly peculiar that the problem is only serious in stage (c). It does not arise in stage (b) because we can warp the mouse to the desired position; we let the user deal with the side effects of such warpage. Arguably the theoretically-ideal solution would be for everybody to skip stage (c) and go directly to fully position-servoed joysticks ... but that is not likely to happen anytime soon, so for now we are still facing nontrivial problems at stage (c). Note that the problems are compounded by the fact that the naive user does not know what to expect ... and indeed doesn't even understand what he's seeing when a war breaks out between the autopilot and the joystick. It just looks like something is broken. Disabling the joystick when the autopilot is active ends the war, but doesn't really solve the user's problem; he just sees it as a different kind of brokenness. One half-baked idea I've been toying with involves animating a /hand/ which is normally gripping the yoke. The joystick moves the hand. When the autopilot is engaged, the joystick still moves the hand, but the hand is not gripping the yoke. I'm not sure how hard this would be to implement. In any case, it has some conceptual value, providing a way to visualize the nature of the problem, to some extent. This is an important topic to be discussing. Some of the recent suggestions are commendable steps in the right direction, but I reckon we are still one breakthrough removed from a complete solution to the problem. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot
Those are complex issues about disengaging autopilot. Your comments helped me to understand why the FG aircraft sometimes does gyrations when disengaging the VOR NAV setting Ctrl-N. I'll try setting the controls to neutral before hitting Ctrl-N to disengage. Tom - Original Message - From: John Denker To: FlightGear developers discussions Sent: Saturday, June 30, 2007 12:15 PM Subject: Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot On 06/30/2007 09:52 AM, [EMAIL PROTECTED] wrote: An airliner some years ago crashed into the Everglades in Florida because the autopilot was unknowingly disengaged by accidental knee pressure on the Yoke as the pilot was getting out of his seat. Specs showed that the minimum 45 pounds pressure required was faulty. The aircraft had been in a holding pattern pending confirmation that the gear was down, since the indicator lamp was burned out and the spare broke upon attempted removal from its recessed location. Unknowingly the aircraft was slowly descending and the last thing on the voice recorder ws the co-pilot Hey, there's something wrong with the instruments when he noticed the altimeter showed just above ground level. If I understand the FG issue correctly, then I would think that a sudden movement of the Yoke could be used to disengage the autopilot. This is a tricky issue. One case that has to be considered is what happens when you are /engaging/ the autopilot. In particular, suppose you are in a long-winged glider in a steep turn, holding tons of outside aileron to compensate for the overbanking tendency. You engage the autopilot, desiring that it will maintain the turn. Then -- in the real aircraft, you let go of the yoke and it stays where it is. No problem. -- in FG, you let go of the yoke and it springs back to the center. That's a problem. On the other side of the same coin, suppose you want to disengage the autopilot while the ailerons are deflected. You really ought to deflect the joystick so that it matches what the autopilot is doing with the yoke, before hitting the autopilot disengage button. Similar considerations apply to the pitch axis and yaw axis. Keep in mind the pilot who inadvertently snap-rolled a 747, seriously injuring a couple of passengers, by disengaging the autopilot without noticing that the autopilot was holding one of the rudder pedals to the floor. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 and references therein. Note that there are four stages of sophistication among FG users: a) Using the keyboard for primary flight control; b) Using the mouse for primary flight control; c) Using a plain old joystick for primary flight control; or d) Using a joystick with force-feedback (or position servos) for primary flight control. It is slightly peculiar that the problem is only serious in stage (c). It does not arise in stage (b) because we can warp the mouse to the desired position; we let the user deal with the side effects of such warpage. Arguably the theoretically-ideal solution would be for everybody to skip stage (c) and go directly to fully position-servoed joysticks ... but that is not likely to happen anytime soon, so for now we are still facing nontrivial problems at stage (c). Note that the problems are compounded by the fact that the naive user does not know what to expect ... and indeed doesn't even understand what he's seeing when a war breaks out between the autopilot and the joystick. It just looks like something is broken. Disabling the joystick when the autopilot is active ends the war, but doesn't really solve the user's problem; he just sees it as a different kind of brokenness. One half-baked idea I've been toying with involves animating a /hand/ which is normally gripping the yoke. The joystick moves the hand. When the autopilot is engaged, the joystick still moves the hand, but the hand is not gripping the yoke. I'm not sure how hard this would be to implement. In any case, it has some conceptual value, providing a way to visualize the nature of the problem, to some extent. This is an important topic to be discussing. Some of the recent suggestions are commendable steps in the right direction, but I reckon we are still one breakthrough removed from a complete solution to the problem. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] [off list] patch for control lockingbyautopilot
Nice explanation. As a non-novice non-expert with a plain old joystick, I would prefer that when I engage the autopilot that the autopilot does its thing and my (untouched) joystick doesn't fight with it. Otherwise the autopilot is useless. So ignoring the joystick seems like the right thing to do. Still, it'd be nice to be able to, for example, turn the plane for a few seconds to adjust heading while the wing leveler is on. i.e. overpower the autopilot temporarily. What would happen if the yoke movements were additive to the autopilot, similar to how they are additive to the current trim settings (and indeed the autopilot changes trim settings). Then even a slightly noisy joystick would only cause a tiny war between the user and autopilot. On 6/30/07, John Denker [EMAIL PROTECTED] wrote: On 06/30/2007 09:52 AM, [EMAIL PROTECTED] wrote: An airliner some years ago crashed into the Everglades in Florida because the autopilot was unknowingly disengaged by accidental knee pressure on the Yoke as the pilot was getting out of his seat. Specs showed that the minimum 45 pounds pressure required was faulty. The aircraft had been in a holding pattern pending confirmation that the gear was down, since the indicator lamp was burned out and the spare broke upon attempted removal from its recessed location. Unknowingly the aircraft was slowly descending and the last thing on the voice recorder ws the co-pilot Hey, there's something wrong with the instruments when he noticed the altimeter showed just above ground level. If I understand the FG issue correctly, then I would think that a sudden movement of the Yoke could be used to disengage the autopilot. This is a tricky issue. One case that has to be considered is what happens when you are /engaging/ the autopilot. In particular, suppose you are in a long-winged glider in a steep turn, holding tons of outside aileron to compensate for the overbanking tendency. You engage the autopilot, desiring that it will maintain the turn. Then -- in the real aircraft, you let go of the yoke and it stays where it is. No problem. -- in FG, you let go of the yoke and it springs back to the center. That's a problem. On the other side of the same coin, suppose you want to disengage the autopilot while the ailerons are deflected. You really ought to deflect the joystick so that it matches what the autopilot is doing with the yoke, before hitting the autopilot disengage button. Similar considerations apply to the pitch axis and yaw axis. Keep in mind the pilot who inadvertently snap-rolled a 747, seriously injuring a couple of passengers, by disengaging the autopilot without noticing that the autopilot was holding one of the rudder pedals to the floor. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 and references therein. Note that there are four stages of sophistication among FG users: a) Using the keyboard for primary flight control; b) Using the mouse for primary flight control; c) Using a plain old joystick for primary flight control; or d) Using a joystick with force-feedback (or position servos) for primary flight control. It is slightly peculiar that the problem is only serious in stage (c). It does not arise in stage (b) because we can warp the mouse to the desired position; we let the user deal with the side effects of such warpage. Arguably the theoretically-ideal solution would be for everybody to skip stage (c) and go directly to fully position-servoed joysticks ... but that is not likely to happen anytime soon, so for now we are still facing nontrivial problems at stage (c). Note that the problems are compounded by the fact that the naive user does not know what to expect ... and indeed doesn't even understand what he's seeing when a war breaks out between the autopilot and the joystick. It just looks like something is broken. Disabling the joystick when the autopilot is active ends the war, but doesn't really solve the user's problem; he just sees it as a different kind of brokenness. One half-baked idea I've been toying with involves animating a /hand/ which is normally gripping the yoke. The joystick moves the hand. When the autopilot is engaged, the joystick still moves the hand, but the hand is not gripping the yoke. I'm not sure how hard this would be to implement. In any case, it has some conceptual value, providing a way to visualize the nature of the problem, to some extent. This is an important topic to be discussing. Some of the recent suggestions are commendable steps in the right direction, but I reckon we are still one breakthrough removed from a complete solution to the problem. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just
Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot
John Denker Sent: 30 June 2007 17:16 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot Note that there are four stages of sophistication among FG users: a) Using the keyboard for primary flight control; b) Using the mouse for primary flight control; c) Using a plain old joystick for primary flight control; or d) Using a joystick with force-feedback (or position servos) for primary flight control. Must have missed the implementation of force-feedback in FG. Last I remember it had been disregarded on realism grounds. Did someone change this? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch for control locking by autopilot
On 06/30/2007 02:21 PM, Hans Fugal wrote: Nice explanation. :-) What would happen if the yoke movements were additive to the autopilot, similar to how they are additive to the current trim settings Interesting question; see below. (and indeed the autopilot changes trim settings). Well, some autopilots do and some don't. The KAP140 for example may ask /you/ to move the trim, but it won't (and can't) move the trim by itself. There are reasons to prefer autopilots that don't mess with the trim; it limits the amount of damage they can do when something goes haywire. Then even a slightly noisy joystick would only cause a tiny war between the user and autopilot. Agreed. But we need to continue the analysis to cover other scenarios. 1) In particular, what happens (and/or what should happen :-) when the user deflects the joystick a goodly amount to (say) the left and holds it? If the autopilot's opinion is simply additive, it will soon track out the perturbation in the usual feedback-loopy way. Now the user is in a situation where the joystick is deflected one way, while the aircraft yoke is deflected the other way. Ick. 2) Then things get really weird when the user lets go of the left- deflected joystick. The system will see this as a user command for a goodly amount of /right/ aileron (in effect, in the additive sense) ... even though the naive user probably didn't think of it that way; all he wanted to do was let go. This gets back to the fundamental problem mentioned in my previous note: The semantics of joysticks is just plain different from the semantics of real aircraft yokes. As you learned in high-school physics class, force is not position, and position is not force. In the real aircraft, the force on the yoke is nowhere near being in a one-to-one relationship with the position of the yoke; you can zero the force (by letting go) without coercing the position to go to zero. Alas the joystick knows nothing of this; its force is proportional to position, since all it has is a dumb little spring. The aforementioned hand+yoke model may help here. The hand has two modes -- gripping and not gripping -- which have to do with force, in the sense that ungripping the yoke zeros the force, without necessarily zeroing the position. Meanwhile the joystick can control the position of the hand. So the hand+yoke model allows the beginnings of a separation between force and position. I'm not saying this would be easy to implement, or worth implementing, but it has value as a conceptual model, to illustrate just how deep the problems lie. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for auto-apation of scenery object elevation to ground level
Hello.
As a very first attempt to contribute to the flightgear source code, I
have tried to write a patch that automatically sets a scenery model's
elevation to ground level at the object's site if an elevation is
defined in the .stg file.
At this point, many thanks to Melchior, who gave me a short description
of how to do this more than a year ago (I just didn't find the time to
do it until now... ;))
It seems to work, but I'm not sure if it is done well. It affects the
following files:
Scenery/tilemgr.hxx
Scenery/tilemgr.cxx
Scenery/tileentry.hxx
Scenery/tileentry.cxx
And it works the following way:
I extended FGDeferredModel to hold lat, lon, elev and hdg as double
attributes additionally to the transform matrix. When
FGTileEntry::load() pushes an object onto the model load queue, it sets
these attributes.
Later, when FGTileMgr::update_queues() loads the models, it checks if a
model's elev is , and if yes, it gets the ground elevation at the
model's coordinates, recalculates the transform matrix for the model and
updates it. One surely ugly thing with this is that at the moment, I've
simply copied the function WorldCoordinates() from tileentry.cxx to
tilemgr.cxx. This way the function code is duplicated, but I didn't want
to remove something or change dependencies.
I made a patch file and attached it to the message. It would be nice if
someone of you guys could take a look at it, give tips about how to
improve it (if neccessary) and/or put it into the cvs code.
Best regards,
Sebastian
Index: tilemgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/tilemgr.cxx,v
retrieving revision 1.60
diff -r1.60 tilemgr.cxx
56a57,108
static void WorldCoordinate2( osg::Matrix obj_pos, double lat,
double lon, double elev, double hdg )
{
double lon_rad = lon * SGD_DEGREES_TO_RADIANS;
double lat_rad = lat * SGD_DEGREES_TO_RADIANS;
double hdg_rad = hdg * SGD_DEGREES_TO_RADIANS;
// setup transforms
Point3D geod( lon_rad, lat_rad, elev );
Point3D world_pos = sgGeodToCart( geod );
Point3D offset = world_pos;
sgdMat4 mat;
double sin_lat = sin( lat_rad );
double cos_lat = cos( lat_rad );
double cos_lon = cos( lon_rad );
double sin_lon = sin( lon_rad );
double sin_hdg = sin( hdg_rad ) ;
double cos_hdg = cos( hdg_rad ) ;
mat[0][0] = cos_hdg * sin_lat * cos_lon - sin_hdg * sin_lon;
mat[0][1] = cos_hdg * sin_lat * sin_lon + sin_hdg * cos_lon;
mat[0][2] = -cos_hdg * cos_lat;
mat[0][3] = SG_ZERO;
mat[1][0] = -sin_hdg * sin_lat * cos_lon - cos_hdg * sin_lon;
mat[1][1] = -sin_hdg * sin_lat * sin_lon + cos_hdg * cos_lon;
mat[1][2] = sin_hdg * cos_lat;
mat[1][3] = SG_ZERO;
mat[2][0] = cos_lat * cos_lon;
mat[2][1] = cos_lat * sin_lon;
mat[2][2] = sin_lat;
mat[2][3] = SG_ZERO;
mat[3][0] = offset.x();
mat[3][1] = offset.y();
mat[3][2] = offset.z();
mat[3][3] = SG_ONE ;
for (unsigned i = 0; i 4; ++i)
for (unsigned j = 0; j 4; ++j)
obj_pos(i, j) = mat[i][j];
}
309c361,400
try {
---
try {
/* AUTO-ADAPT OBJECT ELEVATION TO GROUND LEVEL
*
/* if the defined elevation is . This feature
allows
* us to define objects without having to know the exact
* ground elevation (of the scenery and/or in reality).
*
* There are two reasons why I wanted to implement this:
*
* First, I didn't understand why I always had to find
* out the ground elevation at the site of some scenery
* object just to place it -on the ground- while the
* simulator already knows this value.
*
* Second, specifying the real world elevation too often
* results in objects floating over or sticking in the
* ground by a few meters because the ground elevation
* in the scenery is practically never the same as the
* real (or somewhere denoted) elevation.
*/
if (dm-get_elev() -) {
const SGMaterial *mat;
double newElev;
if
(globals-get_scenery()-get_elevation_m(dm-get_lat(), dm-get_lon(),
3.0,
newElev, mat)) {
osg::Matrix obj_pos;
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_10:29:45 (mfranz) /var/cvs/SimGear-0.3/source/simgear/environment/visual_enviro.cxx /var/cvs/SimGear-0.3/source/simgear/environment/visual_enviro.hxx revert last change (part of the radar patch). It changed the interface for no good reason and didn't make that much sense for the general case. (It had added a flag with the meaning this-cloud-is-an-aircraft. sg isn't only used for fgfs. :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-29_05:46:53 (mfranz) /var/cvs/SimGear-0.3/source/simgear/xml/easyxml.cxx /var/cvs/SimGear-0.3/source/simgear/xml/testEasyXML.cxx easyxml.cxx: add missing endXML visitor call testEasyXML.cxx: beef it up 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_03:05:30 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx fix the most horrible indentation crimes :-} =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_03:30:56 (mfranz) /var/cvs/FlightGear-0.9/source/src/Scenery/tilemgr.cxx degrade Warning: catching up on tile delete queue from SG_ALERT to SG_WARN. * it says it's a warning (while in fact it's just saying what it's doing) * the user can't do much here (yes, flying slower, but it doesn't say that :-) * scrolling those countless messages in the terminal puts stress on the CPU in a time when it's apparently already struggling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_12:15:52 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx - don't mix /instrumentation/radar and /instrumentation/wxradar wildly together -- there's only *one* instrument node now - don't take random tacan, but tacan-source from the instrumentation config (or /instrumentation/tacan[0] by default) - don't take random display-controls from /instrumentation/tacan[0] - default name is now radar (formerly wxradar) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_14:18:25 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx don't check for view angles/internal view. This is the wrong place It breaks if the radar is on a side panel, like in the Concorde. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_14:50:17 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/instrument_mgr.cxx the former weather radar is now a generic radar (weather and aircraft), so rename the instrument from wxradar to radar =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_17:13:27 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/instrument_mgr.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx make update interval configurable, even though the default 1.0 is supposed to be a realistic value =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_10:33:00 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx - don't depend on change to simgear/environment/visual_environ.[ch]xx - more abstraction: extract various jobs from the huge update() function into separate function (not finished -- more to clean up!) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_14:17:18 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx fix tacan (got broken by the last patch) ... there may still be a clouds bug =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_14:49:00 (mfranz) /var/cvs/FlightGear-0.9/source/src/Main/main.cxx Maik JUSTUS: 'implement' Doppler in fg/plib mf: D'oh! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_14:57:15 (mfranz) /var/cvs/FlightGear-0.9/source/src/Main/main.cxx sound: forgot the check for zero =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_17:27:16 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx Vivian MEAZZA: fix cloud rendering bug mf: more cleanup, but still more to come =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-26_10:25:40 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx - fix lightning display - Cleanup Of The Day[TM] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-26_16:30:59 (curt) /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.cxx Fix a long standing bug in a code path that is probably executed very rarely in standard FG autopilots. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_10:28:25 (mfranz) /var/cvs/FlightGear-0.9/source/src/FDM/UFO.cxx set north/east/down speed to make radar map mode work =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_11:52:41 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx more cleanup, and fixing a lot of things that I've broken: arc map mode. There's still a problem with tacan. (In case you wondered: of course I'll port all changes to fg/osg when I'm done.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_14:46:46 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx release early, release often ... - fix radar echo orientation - make container iterations faster (don't call end() every time) - only
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_10:23:36 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/puff-impact.ac /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/puff-new.rgb /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/smoke-impact.xml /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/subsubmodels.xml Alexis BORY: fixed engine start cycle, added bleed air system, impact animation to the gun (thanks Vivian), fixed AoA indexer, tuned engine sound. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_10:25:06 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/A-10-chronometer.xml /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/chronometer.ac Alexis BORY: fixed engine start cycle, added bleed air system, impact animation to the gun (thanks Vivian), fixed AoA indexer, tuned engine sound. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_14:38:39 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/ehsi.xml /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/empty.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/instrumentation.xml /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/panel.xml New panel that consists of a radar screen only (activate with Shift-p). At the moment only the range can be changed via panel click action (click on the range numbers). Weather radar can be turned on in /instrumentation/radar/display-controls/WX. ai/mp display to come. For those who miss the old 2D panel, just use an aircraft with a decent panel and add --fdm=ufo for the same effect. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_14:52:12 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/instrumentation.xml s/wxradar/radar/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_14:58:24 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/Spitfire/Systems/instrumentation.xml s/wxradar/radar/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-24_17:45:10 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/instrumentation.xml - shorter update intervals (ufo technology!) - only update the radar when the panel is actually visible =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_13:48:34 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/bocian-sound.xml /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/ground_roll2.wav /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/ground_roll3.wav /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/whoosh.wav /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/winch_release.wav /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/winch_tow.wav AJ MacLEOD: new sound (GPL compatible) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_16:23:29 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/ufo/Instruments/ehsi.xml add wx-toggle, data-toggle, echo-toggle hotspots to the radar. (Same order as on the 737 panel, but no labels yet. Aliens don't need that stuff.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-25_17:10:59 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/a4/Models/radar.nas Base the nav-display on the new radar code =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-26_15:56:45 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/a4/Systems/instrumentation.xml Don't use the generic file =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_07:24:13 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Lightning/Instruments/radar_display.xml Add radar display =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_07:24:48 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Lightning/Panels/radar-panel.xml Add radar display =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_14:10:14 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/A-10-radios-2.rgb Alexis BORY: add missing radio texture =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_15:35:18 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/Stores/README.stores Alexis BORY: Added slats animation and a missing texture =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_15:35:19 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/Stores/LAU-68/Attic/LAU-68-left.ac /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/Stores/LAU-68/lau68.rgb Alexis BORY: Added slats animation and a missing texture =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-06-27_16:37:15 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Dialogs/variometer.xml /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/bocian-sound.xml /var/cvs/FlightGear-0.9/data/Aircraft/bocian/Sounds/vario.wav AJ MacLEOD: add variometer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [Flightgear-devel] CVS on OS X
Hi Hans, Now I'm working on building both 0.9.11-pre1 and cvs head. I had some errors in linking osgViewer (when building fgfs cvs-head/ OSG-svn head) OSG-2.0 seems OK so I'll go with it for cvs-head for a while. By the way, do you know which revision/tag is suitable for building 0.9.11-pre1? I was able to build and run the 0.9.11-pre1 tarball without any changes at all (using the 0.9.11-pre1 SimGear and macports plib). I don't recall for sure, but I probably already had the alut.h fix in place. I see, it's maybe because I have kept the source updated so I haven't noticed the changes. otherwise the plib from MacProrts fixed the problem. I'll check this later. Anyway, I successfully compiled the fgfs-cvs with OSG 2.0 using Xcode project. I'm going to build 0.9.11-pre1 soon with my Xcode project. Tat - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
