Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Well right now there is no rascal specific dynamics model for any of our core fdm engines, so there's not really all that much to be curious about ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Martin. We went out and flew our Rascal today to collect some more video and data. I posted some pictures here: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ We had very light / calm winds so I'm hoping the position/attitude/velocity data comes out pretty clean. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 08:56 pm, Jon Berndt wrote: No. The VRP defines the location of an agreed-upon reference point in structural coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) in structural frame. ... That was my understanding of it, but it seemed to not work with ___'s Connie model. Upon further review it looks like ___'s Connie model has an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my investigation of it. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/Lockheed1049/Models
That was my understanding of it, but it seemed to not work with ___'s Connie model. Upon further review it looks like ___'s Connie model has an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my investigation of it. Dave :-) Once we get the new JSBSim FDM into FGFS CVS I'll have a look at it (there's always something _just_before_ the good stuff on my todo list). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote: Sets correctly the VRP at the nose : Yep, the VRP appears actually to be located at the nose, but the offset to the CG is still missing :-) Have a try, look at the aircraft from an outside view (chase view w/o yaw), activate the HUD and see where the center of the HUD points at: It points at the nose whereas it _should_ point at somewhere near the wing root, actually at the CG. Currently the FDM still 'thinks' the CG is at the nose. One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave No. The VRP defines the location of an agreed-upon reference point in structural coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) in structural frame. By convention, we've agreed that the nose is typically a good reference point, because it is (or should be obvious) to both the 3D model designer and the FDM designer. The CG generally cannot be used, because it moves - sometimes that movement could be profound. Think of it this way: the structural frame is a fixed, solid, coordinate frame that permeates the aircraft structure. The structural frame we use MUST have X positive out the back, and Y out the right wing. The Z axis completes the right-handed system positive upwards. The _origin_ is what is usually found to be confusing. Often, the origin is located by having the X axis be coincident with the fuselage centerline, with X=0 at the tip of the nose - but THAT IS NOT A REQUIREMENT. If the origin is 200 inches in front of the nose, then the VRP could be defined as (200, 0, 0). If the 3D model designer understands that, the aircraft model can be placed with the nose at the location pointed to by JSBSim. The VRP is the registration mark that relates what is reported by JSBSim and what part of the 3D model is placed at what location in the 3D world. Within JSBSim, the equations of motion are all done relative to the CG. However, JSBSim can send to FlightGear the lat/lon/alt of ANY desired point on the aircraft, at any time, in any orientation (it's not hard). We just have to agree on WHICH point is being sent. That's what the VRP is all about. I pray to God that explains it for the last time! :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Jon Berndt wrote: I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for noticing the VRP aspect. This aspect is my favourite one :-) Thanks for speaking up, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049 - New
The Constellation looks pretty nice, but has a significant drawback: The author has forgotten to implement the offset between FDM center and visual reference point. This means the aircraft rotates around it's nose which makes it almost impossible to accurately rotate for liftoff. Furtheron it looks really funny when the aircraft wags the whole body when you use the elevator ;-) Syd, I presume this is your work. Would you mind adding this offset ? Thanks, Martin. I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for noticing the VRP aspect. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
--- Martin Spott [EMAIL PROTECTED] wrote: I can't resist the suspicion that there's something wrong with the 3D model. At least I get the glider to see and I yet didn't find yout why. Several XML files and the AC file do have DOS line endings but this doesn't cause the trouble I've already removed all of them, Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Buchanan, Stuart wrote: Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. Oops, they hadn't. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Martin Spott wrote: I can't resist the suspicion that there's something wrong with the 3D model. At least I get the glider to see and I yet didn't find yout why. Several XML files and the AC file do have DOS line endings but this doesn't cause the trouble I've already removed all of them, Anyone still having problems with this, even after the most recent round of instrument commits? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Curtis L. Olson wrote: Martin Spott wrote: I can't resist the suspicion that there's something wrong with the 3D model. At least I get the glider to see and I yet didn't find yout why. Several XML files and the AC file do have DOS line endings but this doesn't cause the trouble I've already removed all of them, Anyone still having problems with this, even after the most recent round of instrument commits? Works perfectly now - as far as I can tell from a short test, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC
Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? Silly me: I set a Tag in my CVS tree last week Sorry, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Alex Romosan Vivian Meazza [EMAIL PROTECTED] writes: Alex Romosan asked: Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? Before I made the corrections cvs failed to compile. After I made the corrections (those in the diff) cvs compiled and ran. this is why i would've have liked to see the original error message. if the compiler didn't like those changes here it should've not liked them everywhere else. unfortunately i don't have cygwin installed to compile it myself. --alex-- A quick inspection of the diff should show you that the compiler didn't like 'string' in the .hxx file where 'const string' was used in the .cxx. I changed the .hxx file. Perhaps I should have changed the .cxx, but anyway it works. It is entirely possible that the fault lies in the cvs version that I have here, but I think I have the correct HEAD version. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza wrote: It is entirely possible that the fault lies in the cvs version that I have here, but I think I have the correct HEAD version. It looks like your src/AIModels/AIFlightPlanCreate.cxx isn't up to date. You might want to run cvs up -PdAC AIFlightPlanCreate.cxx Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIEntity.cxx, 1.12,
Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? I guess so, the CVS changelog was sent out to me by mail. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATC AIEntity.cxx, 1.12,
Erik Hofman Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? I guess so, the CVS changelog was sent out to me by mail. Erik I'd be more impressed if this extensive change to CVS compiled under Cygwin, so far I've found and corrected half a dozen errors, but now I think I've stuck on AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers SNAFU Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATC AIEntity.cxx, 1.12,
Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Andy Ross Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Cracked that one - I introduced it in correcting others. So all done now. Just preparing a diff of the changes that I had to apply to get Cygwin to compile. Thanks Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza wrote Andy Ross Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Cracked that one - I introduced it in correcting others. So all done now. Just preparing a diff of the changes that I had to apply to get Cygwin to compile. I attach a diff against CVS - HEAD which I applied to get CVS to compile under Cygwin. It may not be the best or preferred way to do it, but the patch works here, so far as I can see. Regards, Vivian CVS.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Alex Romosan asked
Vivian Meazza [EMAIL PROTECTED] writes:
I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.
diff -u -w -b -r1.11 AIFlightPlan.hxx
--- AIFlightPlan.hxx25 Oct 2005 13:49:56 - 1.11
+++ AIFlightPlan.hxx25 Oct 2005 19:17:09 -
@@ -77,14 +77,14 @@
time_t getStartTime() { return start_time; };
voidcreate(FGAirport *dep, FGAirport *arr, int leg, double alt,
double speed, double lat, double lon,
-bool firstLeg, double radius, const string fltType,
const string aircraftType, const string airline);
+bool firstLeg, double radius, string fltType, string
aircraftType, string airline);
void setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
int getGate() { return gateId; };
double getLeadInAngle() { return leadInAngle; };
- const string getRunway() { return rwy._rwy_no; };
- const string getRunwayId() { return rwy._id; };
+ string getRunway() { return rwy._rwy_no; };
+ string getRunwayId() { return rwy._id; };
void setRepeat(bool r) { repeat = r; };
bool getRepeat(void) { return repeat; };
void restart(void);
why do you need to do this?
Er ... because Cygwin wouldn't compile?
what was the error when trying to compile
the cvs version?
The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far
as the compiler was concerned.
It now compiles and runs OK
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Alex Romosan asked: Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? Before I made the corrections cvs failed to compile. After I made the corrections (those in the diff) cvs compiled and ran. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/sr20 sr20-set.xml, NONE, 1.1
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20 In directory baron:/tmp/cvs-serv4330/Aircraft/sr20 Added Files: sr20-set.xml Log Message: Add some missing files. I'd suggest these changes to get things going: Ehm, allright. Done. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Dave Culp wrote: This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. What would expect the HUD to display? I'm quite sure that the F-16 doesn't have a terrain database or an AGL radar. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Quoting Erik Hofman: Dave Culp wrote: This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. What would expect the HUD to display? I'm quite sure that the F-16 doesn't have a terrain database or an AGL radar. So the HUD is displaying the height for the last known QFE ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Frederic Bouvier wrote: So the HUD is displaying the height for the last known QFE ? I think so. I suppose it just a barometric instrument with a digital display. It is synchronized by ATC reports. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Curt,
Is on my todo list for tomorrow (friday) since I saw Melchior's patch.
Greetings
Mathias
On Dienstag 04 Oktober 2005 20:52, Curtis L. Olson wrote:
For what it's worth, I don't like this patch. It shouldn't make much
difference on 24/32 bit cards, which is probably most everyone now
anyway, but I think there is a different problem brewing somewhere.
I haven't had time to look into it, but the AGL reading on the HUD no
longer reads correctly. Somewhere along the lines we have introduced
some sort of height above ground bugs. I don't know if that is in the
ground cache code or elsewhere, but the HUD above ground display isn't
working right anymore.
If we get that problem fixed so the system knows the correct AGL, then
we wouldn't need to make this particular huge hack 5 times worse.
Somehow the gear still knows where the ground is, but I recall specific
patches to the individual FDM's. I've lost track of what is going on
with this section of code, but it's important and it really should get
fixed before we get too much further!
I'm going out of town on thursday and rushing to get a bunch of other
stuff done in the mean time, so I really can't look at this in the near
term, but someone really needs to volunteer to step up and track down
what is going on here.
Regards,
Curt.
Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv754
Modified Files:
renderer.cxx
Log Message:
prevent view through big hole in carrier deck
Index: renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/renderer.cxx,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -r1.27 -r1.28
*** renderer.cxx 1 Oct 2005 09:56:53 - 1.27
--- renderer.cxx 4 Oct 2005 18:01:45 - 1.28
***
*** 499,503
- cur_fdm_state-get_Runway_altitude_m();
! if ( agl 10.0 ) {
scene_nearplane = 10.0f;
scene_farplane = 12.0f;
--- 499,503
- cur_fdm_state-get_Runway_altitude_m();
! if ( agl 50.0 ) {
scene_nearplane = 10.0f;
scene_farplane = 12.0f;
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
2f585eeea02e2c79d7b1d8c4963bae2d
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
On Dienstag 04 Oktober 2005 22:17, Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:02: You've been granted CVS commit access so use your best judgement. Yes. I don't usually touch such things, because I don't understand much of this. I did it anyway, because: - this change was already in cvs since a great while, and only had been reverted recently - the commit log of the reverting patch didn't explain why this was reverted; it was part of a completely different change and looked like an accident Well, I reverted. Just because, as it was introduced the first time it was a workaround for something, at this time, hard to fix. At that time, the renderer had a different understanding of ground level than the gear code. I changed that at some time and removed the workaround. I thought that it was clear that it was a workaround, and I silently restored the old, more correct, behavour. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:22: Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. The bug was AFAIK there ever since we have helicopters. The same holes were on rooftops. Looking at the code (and only at the code) it looks more like a misunderstanding than a bug. What happens with the HUD is that it behaves like a normal instrument now (and not a perfect one) by that it specifies the AGL relative to the last known good elevation (the airport elevation). I assume it worked more like a radar that could precisely determine the AGL at the aircraft location. So what basically happens now is that at the (startup) airport the AGL would be reported correctly, but once the terrain elevation increases the reported AGL won't change (like in real life). Maybe we need a different naming for exact AGL (which is computed correctly BTW, but under a different name). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
So what basically happens now is that at the (startup) airport the AGL would be reported correctly, but once the terrain elevation increases the reported AGL won't change (like in real life). This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 20:52: For what it's worth, I don't like this patch. I find the hole more annoying. Unfortunately, I can't fix what you think is the real problem. Shall I revert for now? I'm not saying the hole isn't annoying, I'm just saying that there is a bug because for some reason, the sim thinks you are 10 meters AGL when you are sitting on the carrier deck. There is some ground intersection problem going on there. If the ground interesection was computed correctly, the system would think you are 10 meters AGL and everything would work the way it is intended. I'd really like for this to get fixed the right way. When we slap on bandaids without fixing the underlying problems, we end up with a system that has a lot of bandaids on top of a rotting infrastructure. Similarly whenever we see a stray crash or segfault we should pursue it with our utmost agression and stamp those out right away. Anytime we leave these sorts of crashes and problems for later, we end up with a system full of unexpected, unexplained, impossible to debug crashes. That kind of software is an incredible pain to operate. In the past I had more time to defend against these things, right now I don't. You've been granted CVS commit access so use your best judgement. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... It's not an easy problem, but slapping a bandaid ontop will probably mask it long enough so that the person who introduced the orignal problem will be long gone before we get bit again and no one will know how to fix it ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:02: You've been granted CVS commit access so use your best judgement. Yes. I don't usually touch such things, because I don't understand much of this. I did it anyway, because: - this change was already in cvs since a great while, and only had been reverted recently - the commit log of the reverting patch didn't explain why this was reverted; it was part of a completely different change and looked like an accident - I mentioned it in this message and got no reactions: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039285.html not that this is necessarily an agreement, but together with the other two reasons I though it would be OK, and better than the whole, which I consider a show-stopper. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... Andy (via IRC) has also looked at the code and suggested that the whole 'if' case is probably not needed any more. I just tested it, and indeed, with only scene_nearplane = groundlevel_nearplane-getDoubleValue(); scene_farplane = 12.0f; the hole doesn't occur any more. I'll be doing some more tests. But I won't touch that code again without explicit OK from an expert. :-) Just know that with the near plane set close in, there isn't enough depth buffer resolution on 16 bit cards to properly draw the terrain. If you look at mountains in the distance, you get lots of odd z-buffer fighting. This is on 16 bit cards. If we don't care about 16 bit cards any more (that used to be our only option in the old voodoo-1/2/3 days) then we could remove that whole if statement. For what it's worth, my laptop can only run FlightGear acceptably in 16 bit mode so I'm slightly worried about the ramifications of this change. Ultimately we *really* need to fix the above ground level calculations. Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. (And the AGL computations in the rest of the sim would start working correctly again.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: No such message as this one ? cc-1020 cc: ERROR File = arch/irix/iris.c, Line = 415 The identifier AL_FORMAT_QUAD8_LOKI is undefined. case AL_FORMAT_QUAD8_LOKI: Ah, yes, now that you mention it. You will need to add #include AL/alext.h right after AL/al.h Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95
Erik Hofman Martin Spott wrote: Hello Erik, Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear In directory baron:/tmp/cvs-serv29428 Modified Files: configure.ac Log Message: Prepare for OpenAL 1.1 and a separate alut lubrary. Er ... Erik are you about to break Cygwin again? Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95
Vivian Meazza wrote: Er ... Erik are you about to break Cygwin again? No, should I? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95
Vivian Meazza wrote: Er ... Erik are you about to break Cygwin again? BTW, form the openal (1.1) Changelog: * More fixes for Cygwin/MinGW compilation plus some #include cleanups. The linux subtree compiles now under Linux, MinGW/MSYS and Cygwin (with and without -mno-cygwin). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95
Erik Hofman Vivian Meazza wrote: Er ... Erik are you about to break Cygwin again? BTW, form the openal (1.1) Changelog: * More fixes for Cygwin/MinGW compilation plus some #include cleanups. The linux subtree compiles now under Linux, MinGW/MSYS and Cygwin (with and without -mno-cygwin). Erik That sounds like really good news, but I hardly dare try - cvs has been more or less broken under Cygwin since mid Aug. There are work-arounds but Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Erik Hofman wrote: You will need to add #include AL/alext.h right after AL/al.h Yep, looks good adding to that I suggest to replace alut.h with alext.h or simply remove it in simgear/sound/sample_openal.hxx, line 50, maybe line 47 as well as alut now lives in a separate tree in the OpenAL source, Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Yep, looks good adding to that I suggest to replace alut.h with alext.h or simply remove it in simgear/sound/sample_openal.hxx, line 50, maybe line 47 as well as alut now lives in a separate tree in the OpenAL source, O.k., I see, this is the wrong approach Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear configure.ac, 1.94, 1.95
Martin Spott wrote: Hello Erik, Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear In directory baron:/tmp/cvs-serv29428 Modified Files: configure.ac Log Message: Prepare for OpenAL 1.1 and a separate alut lubrary. Did you actually manage to compile current OpenAL CVS on IRIX ? Sure, just make sure there are no old headers (and library) installed somewhere and do a fresh make (dist)clean and make install. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Erik Hofman wrote: Martin Spott wrote: Did you actually manage to compile current OpenAL CVS on IRIX ? Sure, just make sure there are no old headers (and library) installed somewhere and do a fresh make (dist)clean and make install. No such message as this one ? cc-1020 cc: ERROR File = arch/irix/iris.c, Line = 415 The identifier AL_FORMAT_QUAD8_LOKI is undefined. case AL_FORMAT_QUAD8_LOKI: Maybe I need to do a fresh checkout Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
Martin Spott wrote: Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Does $(opengl_LIBS) work as well? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: Martin Spott wrote: Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Does $(opengl_LIBS) work as well? No, -lnsl and -lsocket are required, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: Erik Hofman wrote: Martin Spott wrote: Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Does $(opengl_LIBS) work as well? No, -lnsl and -lsocket are required, I already expected something like that, these are in network_LIBS I've updated the file. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth In directory baron:/tmp/cvs-serv8203 Modified Files: Makefile.am Log Message: IRIX fixes. Thanks - works, 'course it works, it's tested on IRIX :-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: 'course it works, it's tested on IRIX :-) Do you actually _run_ FG on IRIX recently or do you just use it for testing the build ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: Do you actually _run_ FG on IRIX recently or do you just use it for testing the build ? I can't exactly call it 'running FlightGear' but I do start it once in a while. If we can track down the Nasal problem it actually runs quite well with 3d clouds (first time for big-endian systems like IRIX machines) and shadows. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: docs/getstart/pdf FGShortRef.pdf, 1.8,
Martin Spott wrote: BTW, did we have a consensus on the use of EMAil addresses in The Manual ? Because the manual gets posted online, and because of the huge spam problem with any email addresses that are posted online, I'd recommend against putting email addresses into the manual. Perhaps an image of the email address, but these days, anything in clear text is immediately harvested and abused ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: docs/getstart/pdf
Curtis L. Olson wrote: Because the manual gets posted online, and because of the huge spam problem with any email addresses that are posted online, I'd recommend against putting email addresses into the manual. O.k., that's fine with me - I just wanted to get some feedback before removing all those addresses, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 08:50, Melchior FRANZ wrote: The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) That approach to have croase objects for intersection tests and detaild ones for views is really a ood one. May be one can have models for a very low level of detail for that case. Anyway, I am thinking and started playing with that ground cache being structured in an octree. That will make the lookup time about log(n) instead of n if n is the number of triangles in the cache. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 14:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Hmm, not really. The problem that cache solves is the lookup time when doing queries for altitude computations or in the future intersection tests with whatever (May be crashes with power lines?). If you do that test once for each timeframe and only at one place per aircraft, you can well, and you even have to, traverse the whole scenegraph to get that information. The time to traverse the whole scenegraph is too high if you want to know that information for many points and for different informations like the locations for the wires on the carrier. So the trick is to build a as small as possible subset of the scenegraph and do queries there. The smaller the cache is, the better are the response times. So for that reason, I don't think that this is usable for this task at the moment. What you will need for that will be more something similar like the groundcache covering a much bigger area. But instead of putting every surface into that cache, one could preselect the objects depending on the distance and its size, that is ignore too small ones. And additionally, one should simplyfy the surfaces to some bigger ones if they are far away. A structure like that might recycle and/or share some code with the groundcache. And such a structure can probably be well used for an improoved implementation of radar contacts. That problem is a typical LOD algorithm, I expect to find magnitudes of publications about such and fast algorithms. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. The groundcache/beacon interaction was only effecting the Yasim FDM, correct? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Dave Culp -- Monday 30 May 2005 09:27: The groundcache/beacon interaction was only effecting the Yasim FDM, correct? I've only tested it with YASim (bo105, b1900d) where I saw it before, but not after fixing it. I can't say if it happened with JSBSim, although I use both regularly. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Mon, 30 May 2005 08:50:43 +0200, Melchior wrote in message [EMAIL PROTECTED]: * Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) ..so we need it on the ground, and immediately before impact. ;o) ..if we disable it at altitude, how much time do we need to load it immediately before impact ? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE If you are using look-ahead algorithms for terrain following (i.e. modeling a LANTIRN pod or something) this should only be enabled when it is actually used - probably not many models need that. Certainly, the C-172 does not. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Martin Spott wrote: Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Airport In directory baron:/tmp/cvs-serv27845 Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? It's not in there. Though there are database entries for the objects in the base package just so everything ties up the model isn't actually stored in the database. So we've nothing to change unless the path or filename changes. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ a écrit : In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. The beacon has a lot of vertical, or near vertical, faces. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? Is the ground cache for the benefit of the FDM? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
From: Jon Berndt Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. Is this something that people should consider for any high poly structures then? Is the ground cache for the benefit of the FDM? In a way you could say that, but I think that these things get called an FDM issue, because any time the plane stops it is blamed on the FDM. More accurately, the above describes a situation where the program is getting hung up waiting for scenery related I/O and/or data crunching. To answer your question, the ground cache is for the benefit of the pilot. :-) Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 03:55, Jim Wilson wrote: To answer your question, the ground cache is for the benefit of the pilot. :-) I could not say that better!!! :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/AIModel AIAircraft.cxx,
Martin Spott wrote: Modified Files: AIAircraft.cxx Log Message: Solaris fixes ^^ + #elif defined(sun) || defined(sgi) + # include ieeefp.h ^^^ Hehe ;-) Thanks for applying these fixes ! So far for my hope to sneak it in ;-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Erik Hofman wrote: All these patches have been committed now. I still have to look into the -pthread issue. Oh, there's no hurry ! This weekend I replaced the Sparc20 on my internet gateway with an Ultra2. While I successfully renewed the whole OS core for the 64-bit architecture (kernel, kernel modules, core shared libs and system utilities, maintenance updates, patches) I somehow managed to break the development environment. As I slept very little the past two nights (I heavily mis-estimated the required effort) I feel I'd better leave the box as-is for at least few days :-/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Martin Spott wrote: I found a third location: Great, with the patches I posted these days and an additional '-lpthread' to the final linker run we're up to date with Solaris portability, All these patches have been committed now. I still have to look into the -pthread issue. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: I found a third location: Great, with the patches I posted these days and an additional '-lpthread' to the final linker run we're up to date with Solaris portability, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote: So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? I think you misunderstand, it's not an SDL bug: *FlightGear is relying on assumption about how OpenGL implementations work that does NOT hold on OS-X, and may not hold on some Windows drivers, but which happens to hold in the common case on Windows, and apparently always holds on Linux* There are plenty of SDL + GL applications on the Mac that do re-sizing just fine, but they have the ability to initiate a vid-restart (as they correctly should on *every* platform, strictly speaking) when re-sized. Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote: Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. I'm going to restate the problem, just to be very clear. - When a window is resized, SDL (or GLUT) need to re-allocate the GL context. The SDL documentation explicitly mentions that SDL_SetVideoMode will be called again with new size, so a new context will definitely get created on the Mac. I'm putting aside any platform specific ways to modify existing contexts. - There is nothing (absolutely nothing) in the OpenGL spec about the sharing or lifetime of texture objects or displays lists across different contexts - logically they are completely separate. - The current FlightGear code assumes that display lists and textures are preserved across a context switch. - This has not been noticed for the past X years because it *so happens* that the Linux and stock Win32 implementations happen to implement the sharing behaviour between contexts, while OS-X does not. Both behaviours are completely valid and compliant implementations of the OpenGL spec. - Most (if I'm being bitchy, *good*) scene-graph / engine libraries have some kind of 'invalidate' button you can kick that makes them delete all their display lists / textures and reload them. This is what Unreal / Quake / etc are doing which you change full-screen-ness or many other graphics settings while they running, i.e a vid restart. - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! - Until such a change is made, re-sizing the window is not going to work right on OS-X - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) Regards, James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker100/Models
Martin Spott wrote: The model looks very nice and the handling feels pretty easy. It's only Thanks. that I'm missing the cabin door being coupled to the parking brake as it was in your first version ;-) No, it's not ... :-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: Martin Spott wrote: that I'm missing the cabin door being coupled to the parking brake as it was in your first version ;-) No, it's not ... Hmmm, I don't understand: Did you decouple the cabin door from the parking brake intentionally because you thing the coupling is 'wrong' or does it actually work at your end ? At least I strongly believe the version that is in current CVS does _not_ have this coupling, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Erik
Well, reading this piece of code, I don't see how it could work. see
below :
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.115
retrieving revision 1.116
diff -C2 -r1.115 -r1.116
*** fg_init.cxx27 Dec 2004 17:35:22 -1.115
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
***
*** 344,347
--- 344,353
if ( !aircraft.empty() ) {
Aircraft not empty here, otherwise the test had failed
SG_LOG(SG_INPUT, SG_INFO, aircraft = aircraft );
This shouldn't change the aircraft variable
+ if ( aircraft.empty() ) {
useless test because aircraft is not empty ( see above )
+ // Check for $fg_root/system.fgfsrc
+ SGPath sysconf( globals-get_fg_root() );
+ sysconf.append( system.fgfsrc );
+ aircraft = fgScanForOption( --aircraft=, sysconf.str() );
+ }
So the block above is never executed This is dead code.
fgSetString(/sim/aircraft, aircraft.c_str() );
} else {
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the added block 3 lines upward ) :
cvs -z4 -q diff -u fg_init.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.116
diff -u -r1.116 fg_init.cxx
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
+++ fg_init.cxx29 Jan 2005 12:56:47 -
@@ -340,15 +340,15 @@
}
}
+if ( aircraft.empty() ) {
+// Check for $fg_root/system.fgfsrc
+SGPath sysconf( globals-get_fg_root() );
+sysconf.append( system.fgfsrc );
+aircraft = fgScanForOption( --aircraft=, sysconf.str() );
+}
// if an aircraft was specified, set the property name
if ( !aircraft.empty() ) {
SG_LOG(SG_INPUT, SG_INFO, aircraft = aircraft );
-if ( aircraft.empty() ) {
-// Check for $fg_root/system.fgfsrc
-SGPath sysconf( globals-get_fg_root() );
-sysconf.append( system.fgfsrc );
-aircraft = fgScanForOption( --aircraft=, sysconf.str() );
-}
fgSetString(/sim/aircraft, aircraft.c_str() );
} else {
SG_LOG(SG_INPUT, SG_INFO, No user specified aircraft, using
default );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier wrote: Frederic Bouvier a écrit : Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? This one seems better ( move the added block 3 lines upward ) : Ok thanks, it's committed now. Just a note to developers, only real patches are accepted from now on. All other suggestions on how to fix things will be silently ignored by me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, NONE,
On Monday 03 Jan 2005 16:11, Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Weather In directory baron:/tmp/cvs-serv28318/Models/Weather Added Files: rain.ac rain.rgb rain.xml Log Message: Add a basic model for rain. Test w. the pc-7 This looks quite interesting but I realize that this might result in a bigger task because rain looks very different depending on where your viewpoint is (inside/outside) and at which speed you are cruising. Your model matches the rain while sitting on the runway, waiting for clearance situation. Rain during flight in a small four-seater looks like the screen steaming up combined with heavy clouds which a changing weighting depending on your cruise speed. I can't tell how rain looks at 150 kts and more Martin. Heavy precip in a PA28 at 80-110kts looks rather like an upwards waterfall on the windscreen. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, NONE,
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Weather In directory baron:/tmp/cvs-serv28318/Models/Weather Added Files: rain.ac rain.rgb rain.xml Log Message: Add a basic model for rain. Test w. the pc-7 This looks quite interesting but I realize that this might result in a bigger task because rain looks very different depending on where your viewpoint is (inside/outside) and at which speed you are cruising. Your model matches the rain while sitting on the runway, waiting for clearance situation. Rain during flight in a small four-seater looks like the screen steaming up combined with heavy clouds which a changing weighting depending on your cruise speed. Well, this will only cover a part of the rain problem. But I noticed there is a huge difference in appearance with different frame rates. It looks as expected on my O2 but it's totally screwed on my PC. :-( Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, NONE,
On Monday 03 Jan 2005 17:32, Erik Hofman wrote: Well, this will only cover a part of the rain problem. I had an idea a while back that being able to change the specular material setting for runways / taxiways 'on the fly' could produce the sort of wet 'sheen' you get on asphalt when it rains. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, NONE,
Dave Martin wrote: On Monday 03 Jan 2005 17:32, Erik Hofman wrote: Well, this will only cover a part of the rain problem. I had an idea a while back that being able to change the specular material setting for runways / taxiways 'on the fly' could produce the sort of wet 'sheen' you get on asphalt when it rains. Good thinking! In the mean time I've updated the rain animation again and fixed several issues. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Curt wrote: As a project, FlightGear needs to depend on the stable releases of the stuff it depends on, not cvs development trees. That get's to be too big of a mess. Many distributions include the latest stable version of plib, and that is often easier to build. It's ok for developers to use cvs versions of our dependencies, as long as they don't break compatibility with the latest stable version. After about 1 second's consideration, I realized that of course this is the only reasonable policy. Unfortunately, now I remember why I changed to using crease: Martin Spott wrote: Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/releases In directory baron:/tmp/cvs-serv18174 Added Files: FlightGear-0.9.6.tar.gz Log Message: Official source release for v0.9.6 I'm asking just to find out: Do we all agree that it makes much sense to build the upcoming binary releases with a crease-patched version of current PLIB CVS ? I will Erik So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. We speak of Mathias' crease patch, but we should remember that it also produced around 40% increase in performance, certainly for Cygwin. I would not like to go back to the status quo ante, but I realize the very good rationale for it. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. The policy is not meant for the binary releases. A binary-release maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. The policy is to make it _work_ with the latest official plib release. We speak of Mathias' crease patch, but we should remember that it also produced around 40% increase in performance, certainly for Cygwin. I would not like to go back to the status quo ante, but I realize the very good rationale for it. The patch has been committed to plib CVS. Now we only (...) need to convince them to release a new stable version. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. Binary releases, by definition, are not meant to be rebuild, so the hassle of collecting patches and making all work is only supported by one volunteer, not the average user that want to compile from scratch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Erik Hofman wrote: Vivian Meazza wrote: So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. The policy is not meant for the binary releases. A binary-release maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. The policy is to make it _work_ with the latest official plib release. Now I'm confused. Make what work? We speak of Mathias' crease patch, but we should remember that it also produced around 40% increase in performance, certainly for Cygwin. I would not like to go back to the status quo ante, but I realize the very good rationale for it. The patch has been committed to plib CVS. Now we only (...) need to convince them to release a new stable version. Excellent news, what about the joystick problem? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: Erik Hofman wrote: The policy is not meant for the binary releases. A binary-release maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. The policy is to make it _work_ with the latest official plib release. Now I'm confused. Make what work? Sorry, I meant: ... make sure FlightGear will work at least with ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Quoting Vivian Meazza : The patch has been committed to plib CVS. Now we only (...) need to convince them to release a new stable version. Excellent news, what about the joystick problem? not committed yet, but I just asked again on the plib list. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. More importantly, FlightGear still tries to load the Nimitz even when I'm starting at an airport thousands of miles from KSFO. Is there any way to bind those AI's to a specific area, the way we do with static scenery? All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
David Megginson wrote: On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Melchior FRANZ * Jon Stockill -- Tuesday 30 November 2004 16:39: At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) Yes, and at ... um ... right *now*: $ cd $FG_ROOT/Models/Geometry/Nimitz/ $ find -name \*.ac|xargs grep crease|wc -l 248 so today's Nimitz has all the creases again. And FWIW: $ cd $FG_ROOT/Aircraft/ $ find -name \*.ac|xargs grep crease|wc -l 890 Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza [EMAIL PROTECTED] wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. By the way, are you certain now that the crease patch is in the plib CVS? Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
David Megginson On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza [EMAIL PROTECTED] wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. Absolutely right, but here we are talking FG cvs with plib cvs (or not as the case might be) By the way, are you certain now that the crease patch is in the plib CVS? No, I'm not. I know Mathias forwarded it, and, as I said, I thought that Wolfram had uploaded it. I'm using one of our patched versions because plib cvs doesn't work with Cygwin, or at least didn't when I last looked a week or so ago (joystick problems). Hence my question. Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. In effect we are. I use the plib version provided on Martin Spott's site. Very satisfactory and stable it is too, but of course it has to be maintained. If plib has a problem with accepting patches, then perhaps this is the way to go. Nice to get this one sorted. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
Vivian Meazza wrote: Absolutely right, but here we are talking FG cvs with plib cvs (or not as the case might be) Right, but if we depend on plib cvs, we could never again make a stable release until plib rolls the current cvs version into a stable release ... that puts us in a bad position. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. As a project, FlightGear needs to depend on the stable releases of the stuff it depends on, not cvs development trees. That get's to be too big of a mess. Many distributions include the latest stable version of plib, and that is often easier to build. It's ok for developers to use cvs versions of our dependencies, as long as they don't break compatibility with the latest stable version. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: datapreferences.xml, 1.161, 1.162
Melchior FRANZ wrote: * Martin Spott -- Tuesday 30 November 2004 15:55: Erik Hofman wrote: Comment out the nimitz for now. Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? Yes, he did. But Vivian's changes from today refer to a file nimitz- complex.ac, which isn't in CVS, and was apparently not sent to Erik. This made fgfs abort for me: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex There are other things to fix as well. While landing the FA-18A on the carrier worked beautifully after applying Mathias' patches directly, the recent changes to cvs don't allow carrier landings at all. The aircraft falls through the deck, even though I have the alternative carrier-enabled JSBSim version still installed. Yes - that doesn't seem to work. I've tried going back to a date before Mathias' patch, and the patch doesn't apply properly. We appear to have got out of set somewhere along the line. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
David Megginson wrote: On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Martin Spott No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) So it is, and it works with Cygwin. [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, As I thought - NIH. I'm underwhelmed. So where do we go from here - do our own loaders? Maintain our own version of PLIB? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
Melchior FRANZ wrote: * Vivian Meazza -- Tuesday 30 November 2004 20:47: Melchior FRANZ wrote: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex Sure. I know how to fix trivial problems like these. I made a link instead. But this does still not wholly solve the problem, because now we are lacking a couple of textures that were removed. No problem, as long as the carrier is disabled, anyway. Of course you can. I'll check the textures. Disabled - do you mean broken? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Vivian Meazza wrote: Martin Spott No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) So it is, and it works with Cygwin. [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, As I thought - NIH. I'm underwhelmed. So where do we go from here - do our own loaders? Maintain our own version of PLIB? Don't forget we are all open-source developers here. The plib guys are volunteers just like us. It's pretty easy to be critical and jump ship (so to speak.) It's harder to live with each other and work towards the common good of everyone ... especially with the weird characters that show up on the open-source scene. We all are busy. Steve is extremely busy. It doesn't hurt to follow up on these things (more than once if needed.) If done in a sensitive way, you can usually accomplish reasonable things with reasonable people. Just keep in mind that we are all volunteers, all have day jobs, many of us have families, we can't all sit and monitor the FG or plib mailing lists 24/7 and drop everything to address every issue that comes up immediately when it comes up. And also, please be aware that with the volume of mail that most of us get, if we can't do something right away (which is often/usually the case) the email quickly gets buried beneath a flood of newer requests and problems. I'm always waiting for that lull in the action which would allow me to go back through my inbox(s) and address some of the backlog, but such a lull never (or rarely) happens. Perhaps as a direct suggestion to the immediate issue of the crease patch, we should get more FG people onboard as plib contributors with cvs access so we can make direct contributions and get this fixed? Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Curtis L. Olson wrote: We all are busy. Steve is extremely busy. It doesn't hurt to follow up on these things (more than once if needed.) If done in a sensitive way, you can usually accomplish reasonable things with reasonable people. I don't think anyone here is attempting to blame Steve for being extremely busy. The simple question is - trying to get back to the starting point - if it makes sense to hold back valuable improvement in FlightGear just because you rely on a scene graph library where you have to wait several months until 1.) someone is convenient with having a look at your submission and 2.) this submission _might_ show up in a release. I created my private PLIB packages in an attempt to circumvent this 'lock' - until some better solution comes up. These packages carry a 'time stamp' and everyone is free to reference these. Perhaps as a direct suggestion to the immediate issue of the crease patch, we should get more FG people onboard as plib contributors with cvs access so we can make direct contributions and get this fixed? This might be the ultimate solution. Until you/we are there, feel free to rely on the 'intermediate', 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 2f585eeea02e2c79d7b1d8c4963bae2d
