[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Hello Curt, Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal In directory baron:/tmp/cvs-serv29111 Added Files: README.Rascal Rascal110-set.xml Rascal110.xml rascal-electrical.xml thumbnail.jpg [...] flight-modelyasim/flight-model aeroRascal110/aero fuel-fraction0.8/fuel-fraction 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. -- 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049/Models In directory baron:/tmp/cvs-serv7950/Models Modified Files: Lockheed1049_twa.xml Log Message: Thierry: 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. Don't get me wrong, I don't want to hurt anyone, I just want to remind that the issue hasn't been solved yet. Cheers, 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049 - New
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049 In directory baron:/tmp/cvs-serv14998/Lockheed1049 Log Message: Directory /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049 added to the repository 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. -- 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
[Flightgear-devel] Re: [Flightgear-cvslogs]
Hello Gerard, Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/F-8E/Engine In directory baron:/tmp/cvs-serv1607/Engine Removed Files: PW-J57P.xml direct.xml Log Message: Gerard Robin requests that his work not be included in FlightGear's CVS. will this aircraft model still be available at some other location ? Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/c182 In directory baron:/tmp/cvs-serv2788 Modified Files: c182-set.xml 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, 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza wrote: Vivian and Erik, I did not have any problems building (unmodified CVS co) yesterday about 19:30 gmt on recent cygwin on win2k sp3, except that src/flightgear/utils/GPSsmooth/gps.cxx and and MIDG-II.cxx both require Dave's #ifdef HAVE_CONFIG_H # include config.h #endif fix before the includes in order to build. Sorry don't have a diff (doing from memory, but I think that's right)... 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 I am using gcc 3.4.4, if that makes a difference Thanks! Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIEntity.cxx, 1.12,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC In directory baron:/tmp/cvs-serv30924/src/ATC [...] * Use const string rather than string in function calls when appropriate. [...] 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 ? Cheers, 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 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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? what was the error when trying to compile
the cvs version?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Systems vacuum.cxx, 1.7,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/source/src/Systems In directory baron:/tmp/cvs-serv25673 Modified Files: vacuum.cxx vacuum.hxx Log Message: Allow a single vacuum system to be driven by multiple pumps. That's fine. This topic becomes even more interesting when you think of the newer PA28's which have a electrically driven backup vacuum pump, operated by a switch at the left panel boundary, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/sr20 sr20-set.xml, NONE, 1.1
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: --- data/Aircraft/sr20/sr20-set.xml~Sat Oct 8 14:21:13 2005 +++ data/Aircraft/sr20/sr20-set.xml Sun Oct 9 16:02:09 2005 @@ -15,7 +15,7 @@ authorErik Hofman (3D)/author flight-modelyasim/flight-model - aeropa28-161/aero + aero../pa28-161/pa28-161/aero fuel-fraction0.8/fuel-fraction systems --- data/Aircraft/sr20/Models/sr20.ac~ Sun Oct 9 13:18:48 2005 +++ data/Aircraft/sr20/Models/sr20.ac Sun Oct 9 16:00:54 2005 @@ -14017,7 +14017,7 @@ OBJECT poly name cylinder loc 0.00206628 -0.224544 -0.521943 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 0.123811 0.143539 -0.0281066 0.0373752 0.187383 @@ -14313,7 +14313,7 @@ OBJECT poly name cylinder loc 0.00194556 -0.343595 0.456208 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 0.062403 -0.178993 -0.0281067 0.143591 -0.12606 @@ -14609,7 +14609,7 @@ OBJECT poly name cylinder loc -0.0040119 0.568139 0.0657347 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 -0.186214 0.0354541 -0.0281067 -0.180966 -0.0613237 Cheers, 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
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.cxx1 Oct 2005 09:56:53 - 1.27
--- renderer.cxx4 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
--
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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? 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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. :-) 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c150/Models/Vintage
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/c150/Models/Vintage In directory baron:/tmp/cvs-serv14308/Models/Vintage Added Files: README.TXT c150-01.rgb c150-02.rgb c150-int.rgb c150-int2.rgb Log Message: Add Mark Miller's c150 vintage look livery. (See http://home.maine.rr.com/millerdesigns/) Oh great, call this aircraft D-EENE and you have the aircraft that I used during most of my training ! Cheers, 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear configure.ac, 1.94, 1.95
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 ? Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.6,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/b1900d In directory baron:/tmp/cvs-serv4749 Modified Files: b1900d-set.xml b1900d-sound.xml b1900d.xml Log Message: Syd Adams: Here are some updates to the b1900d: The panel looks pretty nice it's just that I failed to deliver appropriate operation. In simple words: May I find a readme which tells me how to start the engines ? I remember someone made such a readme for the Beaver, which I couldn't operate without. Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/BAC-TSR2/Models
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/BAC-TSR2/Models In directory baron:/tmp/cvs-serv26968/Models Modified Files: BAC-TSR2-model.xml [...] I really like this aircraft - it spreads some sort of 'charisma', very much like the Concorde ! 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Citation/Panel
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Citation/Panel In directory baron:/tmp/cvs-serv18501/Panel Added Files: Citation-II-panel.xml adf-radio.xml dme-40.xml radios.xml transparent-bg.rgb Log Message: Syd Adams: Changes to the Citation II: BTW, did you notice that the yoke, which apparently is to be connected to the stick, doesn't move fore and aft when you push/pull the stick ? This looks funny: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Citation_01.jpg Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/gui style.xml, 1.2, 1.3
Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/gui In directory baron:/tmp/cvs-serv29971 Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der Zwischenzeit den halben FlightGear um :-) Tschuess, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/gui style.xml, 1.2, 1.3
* Martin Spott -- Saturday 09 July 2005 11:51: Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der Zwischenzeit den halben FlightGear um :-) No, I'm not going to rewrite fgfs while the others are on vacation. :-) Although these changes look extensive, they aren't really. If I hadn't committed the font file, and changed some variable names for easier editing, there wouldn't have much been left from the diffs. Just a few lines. And I'm almost done with it. (I just try to split the patches into smaller parts, so that I look busier. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth In directory baron:/tmp/cvs-serv20421 Modified Files: Makefile.am Log Message: Fix another dependency. [...] GPSsmooth_LDADD = \ ! -lsgtiming -lsgmisc -lsgdebug -lplibnet -lplibul \ $(joystick_LIBS) $(base_LIBS) -lz Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/utils/GPSsmooth Makefile.am, 1.1,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/source/utils/GPSsmooth In directory baron:/tmp/cvs-serv15890 Modified Files: Makefile.am Log Message: Attempt to add -lwinmm for windows builds (untested.) I'd like to suggest another fix, as the IRIX build lacks -lm, which is apparently needed. Cheers, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
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, 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/FDM groundcache.cxx, 1.7,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/FDM In directory baron:/tmp/cvs-serv27859/FDM Modified Files: groundcache.cxx Log Message: Mathias Fröhlich: this is basically the past patch I sent to the list and which should now really (...!?!?) fix the no ground below aircraft problem. Unfortunately the 'quick hack' was a better solution for my setup. Could you elaborate the substantial difference between the 'hack' and this patch set ? Cheerio, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/FDM groundcache.cxx, 1.7,
* Martin Spott -- Thursday 02 June 2005 13:35: Mathias Fröhlich: this is basically the past patch I sent to the list and which should now really (...!?!?) fix the no ground below aircraft problem. Unfortunately the 'quick hack' was a better solution for my setup. Could you elaborate the substantial difference between the 'hack' and this patch set ? What about elaborating first why the quick hack was a better solution for you? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
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 ? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 20:38: Martin Spott wrote: Melchior Franz wrote: Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? [...] 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. 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. :-) 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 21:02: Melchior FRANZ wrote: 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. Is this something that people should consider for any high poly structures then? For similar objects, yes. But you won't easily find something similar. The ground cache doesn't consider a big area, only about the size of the aircraft AFAIK. The Nimitz, for example, has 2071 faces (Only a bit more than twice as much as the beacon! :-) But if you fly over it, only a few hundred vertices end up in the ground cache at the same time. Because of the small size of a beacon, all the 950 went into the cache in one go. In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. I could be wrong, of course ... 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml , 1.8,
* Frederic Bouvier -- Sunday 29 May 2005 21:32: 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. I saw them when I edited it in Blender. But how is this relevant? If the FDM stuttered before, and doesn't now? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/AIModel AIAircraft.cxx,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/AIModel In directory baron:/tmp/cvs-serv670/src/AIModel Modified Files: AIAircraft.cxx Log Message: Solaris fixes ^^ + #elif defined(sun) || defined(sgi) + # include ieeefp.h ^^^ Hehe ;-) Thanks for applying these fixes ! 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/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
