[Flightgear-devel] RFC: Aircraft *-set.xml files reorg
Currently, there's a problem with our *-set.xml system for aircraft selection. If I want to fly the YASim DC-3, say (I love that plane), then I invoke FlightGear like this: fgfs --aircraft=dc3-yasim So far, so good. Now, let's say that someone prefers another 3D model to my modest effort, or simply hates Canadians and doesn't want to fly a plane with Trans Canada Airlines livery. She can start FlightGear like this to get the different model: fgfs --aircraft=dc3-yasim --prop:/sim/model/path=Aircraft/Models/dc3-usa.ac That works, but it's annoying. She'll be tempted, then, to put the second argument into her .fgfsrc so that she gets the right DC-3 model automatically. Unfortunately, that means that she'll also get that DC-3 model for the C-172, C-182, C-310, Harrier, and so on, since it overrides the value in any of the *-set.xml files. My proposed solution is to add a layer of abstraction to every *-set.xml file. It will be annoying for John and me, but will make things simpler for everyone else. What we do is add a new root level, something like /config/aircraft and then put all the configuration properties under that, so that we have /config/aircraft/dc3-dpm/ /config/aircraft/c172-vfr/ and so on. This all happens in the *-set.xml file. Then we include the top-level properties as aliases: config aircraft dc3-dpm sim model pathAircraft/dc3/Models/dc3-dpm.ac/path /model /sim /dc3-dpm /aircraft /config sim model path alias=/config/aircraft/dc3-dpm/sim/model/path/ /model /sim This is a little ugly, but ordinary users should never have to see it. Now, the user can put -prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac in her .fgfsrc and get a different 3D model for the DC-3 without screwing up the default configurations for any other aircraft. No C++ code changes are required, and I cannot think of any backward-incompatibilities. This will work for *any* property specified in the *-set.xml files, including default control positions, starting altitudes, etc. Comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David Megginson writes: My proposed solution is to add a layer of abstraction to every *-set.xml file. It will be annoying for John and me, but will make things simpler for everyone else. Hmm. On further reflection, this might cause trouble for properties that are tied, like /position/altitude, so it would have to be limited to things like the 3D model and input bindings. Perhaps a cleaner solution would be to extend FlightGear to use multiple root paths. For example, if I had FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/ then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties overriding some or all default values from /usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David, It seems to me like it would be *much* simpler to just make a copy of the dc3-yasim-set.xml file. Say I wanted an American Airlines DC-3: http://dfw.citysearch.com/E/V/DALTX/0213/06/66/cs1.html I could make a dc3-aa-yasim-set.xml and repaint your model. This means one -set.xml file for each permutation but it seems simpler and more intuitive than having a different property name for each model. Let's say I wanted several different dc3's around with the ability to easily select between them. I'm not sure if your proposed scheme would handle that without creating new -set.xml files anyway. One -set.xml file per aircraft also makes it easier to distribute my new version to others. Regards, Curt. David Megginson writes: Currently, there's a problem with our *-set.xml system for aircraft selection. If I want to fly the YASim DC-3, say (I love that plane), then I invoke FlightGear like this: fgfs --aircraft=dc3-yasim So far, so good. Now, let's say that someone prefers another 3D model to my modest effort, or simply hates Canadians and doesn't want to fly a plane with Trans Canada Airlines livery. She can start FlightGear like this to get the different model: fgfs --aircraft=dc3-yasim --prop:/sim/model/path=Aircraft/Models/dc3-usa.ac That works, but it's annoying. She'll be tempted, then, to put the second argument into her .fgfsrc so that she gets the right DC-3 model automatically. Unfortunately, that means that she'll also get that DC-3 model for the C-172, C-182, C-310, Harrier, and so on, since it overrides the value in any of the *-set.xml files. My proposed solution is to add a layer of abstraction to every *-set.xml file. It will be annoying for John and me, but will make things simpler for everyone else. What we do is add a new root level, something like /config/aircraft and then put all the configuration properties under that, so that we have /config/aircraft/dc3-dpm/ /config/aircraft/c172-vfr/ and so on. This all happens in the *-set.xml file. Then we include the top-level properties as aliases: config aircraft dc3-dpm sim model pathAircraft/dc3/Models/dc3-dpm.ac/path /model /sim /dc3-dpm /aircraft /config sim model path alias=/config/aircraft/dc3-dpm/sim/model/path/ /model /sim This is a little ugly, but ordinary users should never have to see it. Now, the user can put -prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac in her .fgfsrc and get a different 3D model for the DC-3 without screwing up the default configurations for any other aircraft. No C++ code changes are required, and I cannot think of any backward-incompatibilities. This will work for *any* property specified in the *-set.xml files, including default control positions, starting altitudes, etc. Comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ 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] Re: RFC: Aircraft *-set.xml files reorg
* David Megginson -- Thursday 21 February 2002 15:26: [...] This is a little ugly, but ordinary users should never have to see it. Now, the user can put -prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac in her .fgfsrc and get a different 3D model for the DC-3 without screwing up the default configurations for any other aircraft. Wouldn't it be simpler (and more elegant), if fgfs would always look for a local config file that would take precedence over the system config as follows: fgfs --aircraft=dc3-yasim-set.xml Now fgfs would =first= look if there's a file ~/.fgfs/dc3-yasim-set.xml and load this file, completely ignoring the system wide file with the same name. The local file could now define pretty much the same as the system config with a few modifications, or (preferably) explicitly load the system wide config first and just add the modifications: !-- ~/.fgfs/dc-yasim-set.xml !-- load the system config ... -- Include $FGROOT/Aircraft/dc-yasim-set.xml !--- ... but change the model -- PropertyList model pathAircraft/dc3/Models/dc3-dpm.ac/path /model PropertyList This would IMHO be a lot cleaner. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] plane banks to left side
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with 0.7.9 base package and today's CVS, I tried different airports but the 'feature' is still there: Several models tend to bank to the left when the stick is in the middle: c172-larcsim does not c172 does c182 does c310 does c172-yasim does not c310-yasim does dc3-yasim does not Is this a 'feature' or is this a bug ? This 'feature' is rather new to me, so I'm wondering heavily. These are the parameters I'm running FlightGear with: foehn: 16:29:36 ~ grep -v ^# .fgfsrc | grep -v ^\$ --fg-root=/home/mas/src/FlightGear/fgfsbase --fg-scenery=/home/fgScenery --disable-splash-screen --disable-intro-music --control=mouse --enable-auto-coordination --enable-hud --disable-panel --disable-sound --enable-anti-alias-hud --start-date-lat=2002:04:11:11:11:11 --prop:/controls/magnetos[0]=3 --prop:/controls/magnetos[1]=3 --enable-fuel-freeze --aircraft=c172-larcsim --airport-id=KSFO This appears to be related to the interpretation of input values, as the plane already starts drifting to the left side of the runway during takeoff. Can anyone confirm ? I can't confirm this using a joystick cos' I don't have one, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with 0.7.9 base package and today's CVS, I tried different airports but the 'feature' is still there: Several models tend to bank to the left when the stick is in the middle: c172-larcsim does not c172 does c182 does c310 does c172-yasim does not c310-yasim does dc3-yasim does not Is this a 'feature' or is this a bug ? This 'feature' is rather new to me, so I'm wondering heavily. These are the parameters I'm running FlightGear with: Feature. Perhaps implemented incorrectly. Perhaps not. At high power in a steep climb torque will roll you left and P-Factor will yaw the aircraft left. If you reach standard cruise conditions the aircraft should fly straight and level. The logic to model these things is pretty straightforward, but the config file may contain values that cause the effect to be modeled too strongly. We'll need some inputs form the real pilots and also some of our own test and analysis to determine if this is right or how far off we are. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
Is this a 'feature' or is this a bug ? This 'feature' is rather new to me, Feature. Perhaps implemented incorrectly. Perhaps not. On the ones that pull to the left, it's a feature. On the ones that don't, yet, it's a bug. Does that help ? At high power in a steep climb torque will roll you left and P-Factor will yaw the aircraft left. If you reach standard cruise conditions the aircraft should fly straight and level. The logic to model these things is pretty straightforward, but the config file may contain values that cause the effect to be modeled too strongly. We'll need some inputs form the real pilots and also some of our own test and analysis to determine if this is right or how far off we are. I'll go do some measurements during climb sometime and let you know; we can use the results in the model regression testing [wicked grin]. Everything Jon says is true. Some specific examples: At very low airspeed and high power settings, such as during initial takeoff roll or during slow flight, the prop slipstream and torque are strong forces compared to the relatively weak general aero, giving you a left _roll_. I need two notches of right rudder during initial takeoff roll. As the aircraft accelerates, the spiral of the prop wash reduces and the aero correction built into the airframe starts to counteract it. In the later takeoff roll, I need less than one (keyboard) notch of rudder. When the aircraft is at high angle of attack, the descending prop blade on the right bites more air than the one on the left, giving a strong yaw torque turning the aircraft to the left. Since angle of attack scales inverse quadratically with airspeed, this is _really_ noticable at slow speed, eg during Vx climb (59 kias) or slow flight (60 kias). I need about four notches for Vx and only about two for Vy in JSBsim. If you take off properly, the effect is much less noticable. This means rotating a couple of degrees to unload the nose wheel at 55 kias, then climbing into ground effect (1 ft altitude) sometime after 65 kias, and starting the climbout at Vy of 73 kias. That's what the aircraft is designed to do and what the airframe tweaks are optimized for. Hope that helps ... ... we probably need to put that (or similar) text into the getting started guide, for all the new user non-pilots out there. Having some links to the web articles on P-factor, prop wash, torque effect and gyro effect would allow the technically oriented people to understand it quickly and easily. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Crossing runways
Some time ago I recall a dicussion on the correct way to handle the markings when runways crossed, which I don't recall ever being definitively decided. The images at: http://www.spaceimaging.com/gallery/ioweek/archive/iow093001/iow 093001.htm clearly show that our present way of simply overlaying one runway with another seems to be correct, at least in the US. All we are lacking is some logic as to the order of importance of the runways. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
From: Alex Perry [EMAIL PROTECTED] Is this a 'feature' or is this a bug ? This 'feature' is rather new to me, Feature. Perhaps implemented incorrectly. Perhaps not. On the ones that pull to the left, it's a feature. On the ones that don't, yet, it's a bug. Does that help ? Sort of ;-) I experience this phenomenon also at 50 % thust - it's quite pulling as much as at full power. Is this still a 'feature' !? If you take off properly, the effect is much less noticable. This means [...] This is a really useful explanation. I'll save this as a useful template for the manual. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
Martin Spott wrote: I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with 0.7.9 base package and today's CVS, I tried different airports but the 'feature' is still there: Several models tend to bank to the left when the stick is in the middle: c172-larcsim does not c172 does c182 does c310 does c172-yasim does not c310-yasim does dc3-yasim does not Is this a 'feature' or is this a bug ? This 'feature' is rather new to me, so I'm wondering heavily. These are the parameters I'm running FlightGear with: It's a feature. The engine is spinning in one direction, thus causing a torque that gets delivered to the airframe as a rolling moment in the other direction. Real aircraft counteract this in the cruise condition via non-zero neutral trim conditions. LaRCSim doesn't model this effect, while JSBSim and YASim do. The DC-3 has counter-rotating propellers, so doesn't exhibit the effect (the two engines cancel each other out). I'm a little confused why the YASim 172 doesn't; it certainly should. I'll have to take a look. 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] RFC: Aircraft *-set.xml files reorg
Curtis L. Olson writes: It seems to me like it would be *much* simpler to just make a copy of the dc3-yasim-set.xml file. Say I wanted an American Airlines DC-3: http://dfw.citysearch.com/E/V/DALTX/0213/06/66/cs1.html I could make a dc3-aa-yasim-set.xml and repaint your model. Yes, but then where do you put the *-set.xml file? Not every user will have write access to the base package, even on their home system, and it's easy to blow away customizations there anyway during updates. This is where my second suggestion -- multiple paths -- might come in handy. This means one -set.xml file for each permutation but it seems simpler and more intuitive than having a different property name for each model. I wasn't trying to avoid multiple -set files; instead, I'm trying to think of a user-level solution. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
Martin Spott writes: I experience this phenomenon also at 50 % thust - it's quite pulling as much as at full power. Is this still a 'feature' !? Angle-of-attack will matter as much as, if not more than thrust. In fact, if you're using less throttle, you're probably keeping the nose pretty high, exacerbating the effect. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David Megginson [EMAIL PROTECTED] said: David Megginson writes: My proposed solution is to add a layer of abstraction to every *-set.xml file. It will be annoying for John and me, but will make things simpler for everyone else. Hmm. On further reflection, this might cause trouble for properties that are tied, like /position/altitude, so it would have to be limited to things like the 3D model and input bindings. Perhaps a cleaner solution would be to extend FlightGear to use multiple root paths. For example, if I had FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/ then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties overriding some or all default values from /usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml. This same question occured to me when working on the panel stuff. It seems as though the -set.xml files are used to select fdm and aircraft type. On the other hand panels and skin models are similar by aircraft type but not across fdm's. So why not have a -model.xml file that defined the panel and skins parameters and locate it in the Aircraft/(aircraft model) directory? (e.g. $FGROOT/Aircraft/dc3/dc3-model.xml) By modularizing a little bit, the multi-root concept work quite nicely. The only potential idea this would not address is the possibility of having multiple skin models and panels in the distribution that we want to be able to choose from the PUI menu or by key binding. It would be nice to be able to change the skins on the fly, and I'm thinking that a list of available skins could be stored and then copied in to the model/path property. If these were listed in the -model.xml file, the first one in the list could be considered the default. Then the question would be should the secondary root (eg $HOME/.fgfs) be considered a complete override, insert in front or add on to the back of the list. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Athlon MP and Flightgear
On Wednesday 20 February 2002 09:03, you wrote: Also what video are you use and version of drivers Geforce2 with NVIDIA_kernel-1.0-2314 compiled locally. Running Debian 2.2 updated to Woody and a custom 2.4.17 kernel from source. Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crossing runways
On Thu, 21 Feb 2002 16:13:16 -, D Luff [EMAIL PROTECTED] wrote: Some time ago I recall a dicussion on the correct way to handle the markings when runways crossed, which I don't recall ever being definitively decided. The images at: http://www.spaceimaging.com/gallery/ioweek/archive/iow093001/iow093001.htm clearly show that our present way of simply overlaying one runway with another seems to be correct, at least in the US. All we are lacking is some logic as to the order of importance of the runways. The official word for the UK is in para 4.2.1 of http://www.srg.caa.co.uk/publications/CAP_168_the_licensing_of_aerodromes.pdf This is perhaps more readable but gives less detail: http://www.srg.caa.co.uk/publications/cap637_visual_aids_handbook.pdf These cover the US regulations: http://www.faa.gov/arp/pdf/5340-1h.pdf http://www.faa.gov/arp/pdf/Fig1.pdf http://www.faa.gov/arp/pdf/Fig2.pdf http://www.faa.gov/arp/pdf/append1.pdf http://www.faa.gov/arp/pdf/5340-1h1.pdf Note para 9.d.2, the US is transitioning to 'configuration B' for complete implementation by 1 Jan 2008 These are from; http://www.faa.gov/arp/150acs.htm where there is lots of good stuff A simpler summary can be found at http://www.nw.faa.gov/airports/Presentations/ASOS_School/Scott/ Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
Curt, Thanks, this has been very helpful. Been playing around with ssg a little bit and trying to gleen some sort of understanding from the documentation, which is very good but in some cases terse. It looks like the panel graphic objects will need to all be ssgTransform nodes so that they can be rotated, etc. Somehow I need to come up with a system for keeping track of which nodes belong with which instruments so the coordinates can be manipulated. I'm assuming that I will need a node for each individual part of each instrument (ie several nodes for some individual instruments). It's not clear how I can group together the components that make up a given instrument (or even if I should!), so that say a major branch (if there is such a thing) would have multiple ssgTransform nodes on it all belonging to the same instrument...e.g. HSI. Anyway, what I'm trying to do here is outline where my thinking is going so that I can get this fairly right the first time. Mostly I'm interested in whether anyone else has ideas on organizing the scene graph tree. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: Jim Wilson writes: And the question that brings to mind is, how will we be able to set the z axis in a way that it can handle the panel? In other words, the scale is so large now that it'll disappear just like airplane model components do when viewed too closely. Can we have two different scales in the same tree/graph? Actually, I'm not sure -- any advice from the PLIB gurus? I'm not sure about your definition of the z axis ... in this case your question makes sense if we define the z axis to be along the center of projection. This really is more of an opengl issue than a plib issue. Opengl defines the view volume to be a frustum (just like a pyramid with a bit of the top lopped off.) You can refer to the picture here for an example: http://www.cs.ucf.edu/~moshell/CAP5725/CAP5725.week4.html So if a portion of the scene is closer to us than the near clip plane, it will be clipped out. That is what happens when you get the external view point too close to the aircraft. Similar wierdness if you set the far clip plane too far away and then get too close to the ground. The good news is that you can reset the clip planes at any time during the rendering process meaning you can render a portion of the scene, then move one or both clip planes, and redraw another portion of the scene, continuing this as much as needed. The bad news is that certain driver optimizations can get screwed up if you move the clip planes (ie. the fog tables in some versions of mesa). Or the driver may be forced to recompute things like fog tables and other values when you change the position of the clip planes. Thus, there can be visual artifact and or performance implications with moving the clip planes. Also, be aware that the precision of the depth buffer is *very* sensitive to the position of the near clip plane: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html The conclusion is that for best depth buffer precision we want to push out the near clip plane as far as possible. The position of the far clip plane is mostly irrelevant, although it has to be beyond the furthest object we want to see. :-) So the point of all this is that we can draw the world, then move the near clip plane in, and then draw the panel. This would work best if we put the panel into a different scene graph from everything else: setclipplanesforworld(); ssgCullAndDraw(world); setclipplanesforpanel(); ssgCullAndDraw(panel); Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Thu, 21 Feb 2002, Curtis L. Olson wrote: Just like we have competing FDM's with different focus, strengths and weaknesses, I don't think it is bad to have competing weather/environment management systems with different focus, strengths and weaknesses. When you say weather/environment management system what do you mean? Do you mean something that includes the following? 1. weather data retrieval mechanism 2. conversion from raw form to a source independent format stored either in memory, or a persistent format 3. logical analysis of the code to isolate relevant data 4. code to render the visible aspects of the weather If so, that's cool, but to me it seems like this is sort of slicing the pie the wrong way. I would hate to think that any alternate weather/environment management system would have to duplicate functionality across so many layers of code. It just seems to me that it would make sense to isolate the steps so that each one could be replaced individually. Also, are there any goals regarding weather in FG? If someone were to rewrite the weather subsystem, would it be more appropriate to simply do another system like what we have or would it be more appropriate to plan for the day when we move beyond flat plane cloud layers? It seems that the current FG weather system is a lot like X-Plane's. With the exception of ATIS reading the string appropriate for its location, the weather for the entire world is identical to the weather at the aircraft's current location. If one wanted to simulate approaching a line of thunderstorms, the weather model would need to manage the data in such a way that that different geographic areas could have different weather. Forgive me if I stepped on anyone's toes. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FG/OpenGC Bug
Hi, If anyone has tried running the FG/OpenGC displays across a network of mixed platforms you might experience a problem with the sizeof() function used to determine the size of the network data packet. Linux and cygwin calculate the value differently in aligning the bits in memory. the result will be garbage at the output end A quick solution is to add a dummy variable of type int at the preamble of the data packet on both sides of the interface as noted below. This results in a structure size where modulus 8 is zero and the bits align, In the file opengc_data.hxx // at the start of the public definition in the class ogcFGData unsigned int version_id; unsigned int msg_type; unsigned intmsg_content unsigned intdummy; /// add this to make the bits line up between linux and cygwin Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
