Re: [Flightgear-devel] RFC: Toward a new policy for AIAircaft commits
On Wednesday 27 December 2006 10:29, Durk Talsma wrote: Once I have the few remaining rough edged of the new traffic scan patch ironed out, my plan would be to begin by adding the AI 737 to the base package, along with a few liveries for which I have traffic available (United, Malev, and Lufhansa). Because adding AI aircraft to the base package would mean adding quite a bit of binary texture files, I'd like keep the number of revisions for these files down to a minimum, so my proposal is to commit only those textures that are reasonably finished. I'd be interested to hear other people's thoughts and opinions before proceeding. Just to follow up on my own post: The traffic scan patch is now committed to CVS HEAD. I also committed a small sample of AI aircraft, namely the Boeing 737 with traffic for Malev, Lufthansa, and United Airlines. You can perhaps find the most interesting traffic demo at Budapest (LFBP) airport. Enjoy! Cheers, Durk - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Toward a new policy for AIAircaft commits
On Thursday 28 December 2006 10:02, Durk Talsma wrote: You can perhaps find the most interesting traffic demo at Budapest (LFBP) airport. Whoops, typo: Should be LHBP. D. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Spitfire/Seafire mag compass doesn't work in CVS - fixed
Hi all, Latest CVS osg I found the magnetic compass isn't working in the Spitfire/Seafire. After a lot of faffing about (using the Hurricane compass as reference, as that worked), I found the issue... or rather diff did. --- Spitfire/Models/compass.xml 2006-12-28 14:07:08.0 + +++ Hurricane/Models/compass.xml2006-12-28 14:06:24.0 + @@ -4,7 +4,7 @@ animation typerotate/type object-nameCompass/object-name - propertyinstrumentation/magentic-compass/indicated-heading-deg/property +propertyinstrumentation/magnetic-compass/indicated-heading-deg/property center x-m-0.02725/x-m y-m0/y-m Can you see it? In Spitfire/Models/compass.xml the the property tag, 'magnetic' is spelt wrong. I must have looked at that line a thousand times, and even looking at the diff output it is hard to see. :-D Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] setlistener oddity
* Josh Babcock -- 12/24/2006 2:48 AM: I have a setlistener that is behaving oddly. There are four basically identical ones, only difference being that the one listening to /instrumentation/marker-beacon/middle does not trigger. I assume that this marker beacon property value isn't written to via SGPropertyNode methods (setDoubleValue() etc.) but *directly*. This can be done via tie/untie, which is quicker but doesn't trigger listeners. You can check that in the property browser. If you Ctrl-click on a . entry, then the property browser shows the property's properties. A 'T' means that the property is tied. You have to use old-school polling on such directly changed tied properties, or trick one of the core developers into abandoning the tying for it. ;-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Issues
* JOSHUA WILSON -- 12/26/2006 1:17 AM: I have installed the binary, and it revealed another problem with my model. [...] This will be more difficult because I no longer have access to the Browse Internal Properties feature. As has been said already, CVS/data is not meant to work with the last released fgfs binary, but only with the development version, which will become the next release. This is also the reason for the non-working property browser: you mixed binary and data from differing versions (cvs or release). I'm actually surprised that you didn't have more problems. ;-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Alternatives to Terragear pipeline for building FGFS tiles?
Hi, I am digging into terrain tiles creation in order to get a few airports layout more close to reality. I wonder if there's an alternative or if there's even space to experiment new ways in getting a highly customized geometry (especially for airport terrain meshes). I am not very satisfied about the TaxiDraw/Terragear pipeline because of its limitations in the mesh creation technique. Using TaxiDraw rectangle blocks is not flexible enough to get proper custom geometry. I understand TerraGear is aimed at building airports layout from a specific data format and does not accept other kind of geometries for taxiway/runways/aprons. Since terrain meshes are based on triangles, I see full flexibility in that (more than what's used today). I guess rectangle blocks (I refer to taxiway/runway/aprons) were choosen in order to get airport layouts quick and easy (automatic texture mapping and lighting positioning from standard source data) but are not mandatory. I would not be surprised if someone tells me I could model my own airport mesh using any kind of geometry, texture it with custom image files, position lights (border, middle, PAPI etc...), windsocks and so on. All without being stuck to TaxiDraw/TerraGear limitations. Maybe TerraGear would be used anyway when compiling the custom mesh to a suitable .btg file, even if it does not come from a .dat TaxiDraw output? Well, what should I investigate for? I guess a good knowledge of the .btg file format would be a good first step, but ... here I get puzzled. I did find very few details on that. BTG stands for Binary TerraGear, right? Nothing more to know? Should I really read Terragear source code to get it clear? Should I search into Simgear docs? I'd really appreciate if someone could share some thoughts about this topic with me. I'd like to try and get a high quality airport layout and I'm open to not very standard approaches if needed. Curtis, I understand you are very busy with a lot of stuff, do you have any hints for me anyway? thanks, Roberto - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline for building FGFS tiles?
On Thursday 28 December 2006 13:17, Roberto Inzerillo wrote: Hi, I am digging into terrain tiles creation in order to get a few airports layout more close to reality. I wonder if there's an alternative or if there's even space to experiment new ways in getting a highly customized geometry (especially for airport terrain meshes). I am not very satisfied about the TaxiDraw/Terragear pipeline because of its limitations in the mesh creation technique. snip thanks, Roberto Last year, a few others and I did experiment with converting FAA airport diagrams (vector PDF) into 3D models then importing them into FlightGear... if that's what you are looking for. Ampere - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline for building FGFS tiles?
On 12/28/06, Ampere K. Hardraade wrote: On Thursday 28 December 2006 13:17, Roberto Inzerillo wrote: Hi, I am digging into terrain tiles creation in order to get a few airports layout more close to reality. I wonder if there's an alternative or if there's even space to experiment new ways in getting a highly customized geometry (especially for airport terrain meshes). I am not very satisfied about the TaxiDraw/Terragear pipeline because of its limitations in the mesh creation technique. snip thanks, Roberto Last year, a few others and I did experiment with converting FAA airport diagrams (vector PDF) into 3D models then importing them into FlightGear... if that's what you are looking for. Ampere I've done some very limited and reasonably successful experiments with recreating an area in Multigen Creator (I'm not claiming any particular 3d modeling skills here, I'm horrible at it) and then just placing the model in the FlightGear world a meter or two above the original surface. In my case we created a simple grid and laid google earth imagery on top of it ... it was an internal not-redistributable effort, although we did get explicite permission from google to post/publish screen shots. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Linking problems on Visual C++ 2005 Express Edition
Hi Guys, I've somehow managed to break my VC8 build of FG. I followed the instructions linked from the wiki using the 3rdparty-2006-11-25.zip and osg_ot_md.zip. This was working nicely a couple of weeks ago, so I _think_ my build system is OK. SimGear compiles quite happily, however building the FlightGear solution produces the error below. -- Build started: Project: FlightGear, Configuration: Release Win32 -- Linking... LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification Simgear.lib(animation.obj) : error LNK2019: unresolved external symbol public: __thiscall SGMaterialAnimation::SGMaterialAnimation(class SGPropertyNode const *,class SGPropertyNode *) (??0SGMaterialAnimation@@[EMAIL PROTECTED]@@PAV1@@Z) referenced in function public: static bool __cdecl SGAnimation::animate(class osg::Node *,class SGPropertyNode const *,class SGPropertyNode *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@PBVSGPropertyNode@@PAV4@@Z) Release\FlightGear.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at file://c:\Games\FlightGearOSG\FlightGear\projects\VC8\Release\BuildLog.htm FlightGear - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 3 up-to-date, 0 skipped == A couple of questions: - Is it still the case that the patched OSG that Mathias' produced around 11 November is still usable, or do I have to go to OSG CVS head ? - Am I just being thick and failing to put my SimGear libraries in the correct place after building them ? - Has anyone else seen a similar error ? Thanks -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking problems on Visual C++ 2005 Express Edition
Hi Stuart, add simgear\scene\model\SGMaterialAnimation.cxx to your simgear project file. If you get an error message like your reported one, search for a *.c?? file with the required function and add it to the project file. Or: if you update via cvs look for new *.c?? files and add them. Hint: (probably you don't know this): you can add simgear, flightgear, flightgear-lib all together into one project-folder (don't know the english MS-name for this, in german it is Projektmappe), tell mscv the dependencies of these projects and build all the projects by one click. Maik Stuart Buchanan schrieb am 28.12.2006 20:56: Hi Guys, I've somehow managed to break my VC8 build of FG. I followed the instructions linked from the wiki using the 3rdparty-2006-11-25.zip and osg_ot_md.zip. This was working nicely a couple of weeks ago, so I _think_ my build system is OK. SimGear compiles quite happily, however building the FlightGear solution produces the error below. -- Build started: Project: FlightGear, Configuration: Release Win32 -- Linking... LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification Simgear.lib(animation.obj) : error LNK2019: unresolved external symbol public: __thiscall SGMaterialAnimation::SGMaterialAnimation(class SGPropertyNode const *,class SGPropertyNode *) (??0SGMaterialAnimation@@[EMAIL PROTECTED]@@PAV1@@Z) referenced in function public: static bool __cdecl SGAnimation::animate(class osg::Node *,class SGPropertyNode const *,class SGPropertyNode *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@PBVSGPropertyNode@@PAV4@@Z) Release\FlightGear.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at file://c:\Games\FlightGearOSG\FlightGear\projects\VC8\Release\BuildLog.htm FlightGear - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 3 up-to-date, 0 skipped == A couple of questions: - Is it still the case that the patched OSG that Mathias' produced around 11 November is still usable, or do I have to go to OSG CVS head ? - Am I just being thick and failing to put my SimGear libraries in the correct place after building them ? - Has anyone else seen a similar error ? Thanks -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline for building FGFS tiles?
Last year, a few others and I did experiment with converting FAA airport diagrams (vector PDF) into 3D models then importing them into FlightGear... if that's what you are looking for. Ampere No, that's not the idea. I know about that experiment, I followed the thread and looked at the results. Impressive and mostly usefull when you have high detailed PDF diagrams. But out of my scope. I'm trying to fine model the mesh without using other sources. I'd like to have much more control on the geometry, without the limits imposed by predefined primitives (like TaxiDraw rectangles and lighting schemes). What I need is more freedom when modifying geometry, full controll on mesh vertices movement and alignment; the same goes for textures and lighting positioning. E.g. I like the basic runway texture scheme used in FlightGear, but taxiway/apron textures is way too uncontrollable and rigid when trying to create high quality layouts. What I need is more freedom in creating/modifying geometry. That's the point. That's at least the first step in every possible working pipeline I could imagine. Roberto - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire/Seafire mag compass doesn't work in CVS- fixed
Nick Warne wrote Hi all, Latest CVS osg I found the magnetic compass isn't working in the Spitfire/Seafire. After a lot of faffing about (using the Hurricane compass as reference, as that worked), I found the issue... or rather diff did. --- Spitfire/Models/compass.xml 2006-12-28 14:07:08.0 + +++ Hurricane/Models/compass.xml2006-12-28 14:06:24.0 + @@ -4,7 +4,7 @@ animation typerotate/type object-nameCompass/object-name - propertyinstrumentation/magentic-compass/indicated-heading- deg/property +propertyinstrumentation/magnetic-compass/indicated-heading- deg/property center x-m-0.02725/x-m y-m0/y-m Can you see it? In Spitfire/Models/compass.xml the the property tag, 'magnetic' is spelt wrong. I must have looked at that line a thousand times, and even looking at the diff output it is hard to see. Well, it certainly is an error, but not in cvs head cvs-plib perhaps? There was another bug to do with electrical outputs which I have corrected. Vivian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire/Seafire mag compass doesn't work in CVS- fixed
On Thursday 28 December 2006 21:01, Vivian Meazza wrote: object-nameCompass/object-name - propertyinstrumentation/magentic-compass/indicated-heading- deg/property +propertyinstrumentation/magnetic-compass/indicated-heading- deg/property center x-m-0.02725/x-m y-m0/y-m Can you see it? In Spitfire/Models/compass.xml the the property tag, 'magnetic' is spelt wrong. I must have looked at that line a thousand times, and even looking at the diff output it is hard to see. Well, it certainly is an error, but not in cvs head cvs-plib perhaps? There was another bug to do with electrical outputs which I have corrected. Vivian Yes, as explained (and sorted) in IRC, it looks like I got messed up and used my plib data source rather than the data source for osg build. All works good now (apart from rear castor, but that is another issue). Thanks, Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking problems on Visual C++ 2005 Express Edition
--- Maik Justus wrote: Hi Stuart, add simgear\scene\model\SGMaterialAnimation.cxx to your simgear project file. If you get an error message like your reported one, search for a *.c?? file with the required function and add it to the project file. Or: if you update via cvs look for new *.c?? files and add them. That did the trick. Thanks -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline for building FGFS tiles?
Hi Roberto! Roberto Inzerillo wrote: What I need is more freedom in creating/modifying geometry. That's the point. That's at least the first step in every possible working pipeline I could imagine. Maybe you are aware that there is a new version of the apt.dat file format upcoming that should provide you with exactly this: more freedom. It shall allow the definition of taxiways and aprons using polygons including - IIRC - rounded edges as well as the exact definition of the locations of markings and lighting. I had started a reorganisation of the TaxiDraw code structure some time ago (might be around 1 year) to support exactly this type of change. Unfortunately, I'm not done yet with the restructuring (essentially, the whole UI codebase is rewritten from scratch) and we'd still need somebody to write an appropriate generator to convert the new apt.dat files into btg-files. I'm currently using my holidays to get as much done as possible on the TaxiDraw reorganisation side. You can follow this by watching the NEW_GUI_CODE branch in the TaxiDraw CVS. We will get that new freedom, but it may still take a bit of time. Cheers, Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] error: 'osg' has not been declared
When I compile cvs version of flightgear in a gentoo and gcc-4.1 I get the following errors: if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT groundnetwork.o -MD -MP -MF .deps/groundnetwork.Tpo -c -o groundnetwork.o groundnetwork.cxx; \ then mv -f .deps/groundnetwork.Tpo .deps/groundnetwork.Po; else rm -f .deps/groundnetwork.Tpo; exit 1; fi ../../src/AIModel/AIBase.hxx:122: error: 'osg' has not been declared ../../src/AIModel/AIBase.hxx:122: error: expected ';' before '' token ../../src/AIModel/AIBase.hxx:177: error: 'osg' has not been declared ../../src/AIModel/AIBase.hxx:177: error: expected ';' before '*' token make[2]: *** [groundnetwork.o] Error 1 make[2]: Leaving directory `/home/edi/games/simuladores/fgfs/cvs/osgflightgear/tmp/src/Airports' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/edi/games/simuladores/fgfs/cvs/osgflightgear/tmp/src' make: *** [all-recursive] Error 1 I have fixed the compilation with this patch that includes osg headers into src/AIModel/AIBase.hxx: diff -urN source/src/AIModel/AIBase.hxx tmp/src/AIModel/AIBase.hxx --- source/src/AIModel/AIBase.hxx 2006-11-26 13:02:06.0 +0100 +++ tmp/src/AIModel/AIBase.hxx 2006-12-28 23:11:36.0 +0100 @@ -33,6 +33,11 @@ #include Main/fg_props.hxx +// By Edi: Include osg layer here +#include osg/ref_ptr +#include osg/Node +// End osg layer + SG_USING_STD(string); SG_USING_STD(list); There may be another cleaner way of fixing it. If it is an error please, fix it in cvs. If not I would be interested in knowing my mistake or the circunstances that produces this error in my system. Thanks in advance. -- Woodyst. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim gear patch (make use of ground properties (friction, bumpiness, solid/fluid))
Hi, here is a new version of the YASim-gear patch. It should work with plib and osg. But osg sometimes reports the sea to be solid, which sometimes lead to a airplane-crash. I hope this can be fixed soon. But on solid ground it should work similar to plib (as on sea osg sometimes do not report the ground properties correctly, therefore a default value is used (I have choosen solid and 20% bumpiness) which lead to some bumps on the runways... I hope this can be fixed soon). Since my last version some tags have been changed (now it should be clearer, if a gear is defined to work on water or on solid ground or on both). The inverse-speed-spring-is-doubled has been replaced by another mechanism which should give more realistic behavior (thanks to Detlef Faber for pointing this out). It still is in the code, but probably it will be deleted until cvs. The on grass braking problems of some warbirds pointed out by Detlef should be reduced by a lower frequency bump-function I am using now. If the problem still exists: I think it should be possible to fix this with the gear parameters. Up to now the surface in flightgear was 100% bumpless and all gears are optimized for this. If it is not possible to fix this with the gear parameters: I have add two ugly parameters to fake this, but I prefer to delete them until cvs. For demonstrating fluids I have added a diff for the dhc2F. Don't forget to retract the gear before landing on water! The jitter on solid surfaces is unchanged to the cvs version. To fix this, one need to specify smaller spring-values and longer extend values, but the animation fails then. For this I can add an initial load to the yasim-gear. @andy: how do you think about this? Before this can be commited to cvs, I would like to have some feedback (it will affect all yasim aircrafts). And I need to remove some debugging stuff and want to remove the mentioned tags. And, of course, we need the agreement of Andy. Maik Maik Justus schrieb am 21.12.2006 02:14: Hi here is a patch that YASim gears make use of the ground properties (friction, bumpiness, etc). It enhances the gears, that you can define different gears for on water and for not on water. And you can define inverse-speed-spring-is-doubled, with this the gear extends with increasing speed which can be used for lifting the airplane out of the water with increasing speed. The friction at this speed is reduced by reduce-friction-by-speed to simulate (fake?) the reduced drag. This patch is tested only a very bit on default scenery with only one aircraft. It is probably not ready for cvs. (all enhancements for water aircrafts are fully untested...) I hope I find the time to test the beaver in the next days. Maik Maik Justus schrieb am 20.12.2006 01:19: Hi Melchior, thanks for the info. I will try to make use of this with the yasim gears. Maik Melchior FRANZ schrieb am 20.12.2006 00:56: * Maik Justus -- Wednesday 20 December 2006 00:47: does anyone know, how to access the ground properties by the FDM? Looks like the groundcache provides this: bool FGGroundCache::get_agl(double t, const SGVec3d dpt, double max_altoff, SGVec3d contact, SGVec3d normal, SGVec3d vel, int *type, const SGMaterial** material, double *agl) The ground cache is already used by JSBSim and YASim for gear contact. See simgear/scene/material/mat.hxx for SGMaterial. It has methods to read friction/bumpiness/... m. Index: YASim/Airplane.cpp === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Airplane.cpp,v retrieving revision 1.20.2.2 diff -u -p -r1.20.2.2 Airplane.cpp --- YASim/Airplane.cpp 22 Dec 2006 18:02:29 - 1.20.2.2 +++ YASim/Airplane.cpp 28 Dec 2006 22:30:32 - @@ -602,6 +602,7 @@ void Airplane::compileContactPoints() // I made these up g-setStaticFriction(0.6f); g-setDynamicFriction(0.5f); +g-setContactPoint(1); _model.addGear(g); } @@ -706,7 +707,8 @@ void Airplane::solveGear() g-getPosition(pos); Math::sub3(cg, pos, pos); gr-wgt = 1.0f/(0.5f+Math::sqrt(pos[0]*pos[0] + pos[1]*pos[1])); -total += gr-wgt; +if (!g-getIgnoreWhileSolving()) +total += gr-wgt; } // Renormalize so they sum to 1 Index: YASim/FGFDM.cpp === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/FGFDM.cpp,v retrieving revision 1.44.2.1 diff -u -p -r1.44.2.1 FGFDM.cpp --- YASim/FGFDM.cpp 18 Dec 2006 21:32:56 - 1.44.2.1 +++ YASim/FGFDM.cpp 28 Dec 2006 22:30:34 - @@ -273,6 +273,15 @@ void FGFDM::startElement(const char* nam g-setDynamicFriction(attrf(a, dfric, 0.7)); g-setSpring(attrf(a, spring, 1)); g-setDamping(attrf(a, damp, 1)); +
