[Flightgear-devel] Problems with FG slave...
Hi, I've a slave instance running on a separate machine. Relevant specs are: - Ubuntu Karmic - Xorg Edgers PPA (to get 3D support) - 3ghz P4 (non-HT) - 1gb RAM - ATI X300 PCIe / 128mb I basically just want a chase view window on which I can also open a couple of FG dialogue boxes. The updated Xorg and video drivers got me a 640x480 window with all rendering options presently min'ed out (as opposed to being max'ed), running at a capped 20fps. The two main problems I have are: - Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) -- this message repeats constantly on the CLI. - A very jerky display. As in, the aircraft sorta jerks backwards a little a couple of times per second when it's on the move. Sitting still and moving the control surfaces, it seems okay (although that's not much of a sample to go by...). This only happens with external views (particularly the heli and chase views - dunno about tower views). In cockpit and fly-by views, it's okay. I'm running at 30hz for both FDM and model rendering on the slave. While I'm at it, I'd also like to ask how much functionality I should be seeing across the socket/s (I also have the native-ctrls configured, although I have no clue what that's for). I generally like to spawn dark - no engines running, no power / APU, no lights, dark cockpit, etc, etc. Turning the lights on (for instance) doesn't propagate to the slave instance. Similarly, neither does setting stuff (like, say, the AP or the radios) from dialogue boxes on the slave instance. Should / can this stuff be working across both instances? Note: I posted this message to the forum several days ago. Anders suggested I set the FDM data rate to half the FPS throttle, which didn't help (but I've left those settings as they are - the slave's refresh is throttled to 20fps, and 10hz is likely all I need for the slave display I'm after). He also suggested that this may be the known update order problem, which I've asked him to explain and haven't seen a response to (I'm in AU... gotta love timezones ;-)). Another thing I've been wondering is that I compiled the suite (from CVS) on my main workstation (briefly, an e7400 @ ~3.2ghz and a PCIe nVidia 8400gs), then copied the entire tree over to the slave PC. Could this problem be, at least in part, due to building against one set of GL libraries but running on another? Cheers, Mattt. -- Cheers, Mattt. SpotSafe - WiFi Hotspot solution - http://spotsafe.net There are only 10 kinds of people. Those who understand binary, and those that don't... -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with FG slave...
On Wed, 5 May 2010, Mattt wrote: - A very jerky display. As in, the aircraft sorta jerks backwards a little a couple of times per second when it's on the move. Sitting still and moving the control surfaces, it seems okay (although that's not much of a sample to go by...). This only happens with external views (particularly the heli and chase views - dunno about tower views). In cockpit and fly-by views, it's okay. ... Note: I posted this message to the forum several days ago. Anders suggested I set the FDM data rate to half the FPS throttle, which didn't help (but I've left those settings as they are - the slave's refresh is throttled to 20fps, and 10hz is likely all I need for the slave display I'm after). He also suggested that this may be the known update order problem, which I've asked him to explain and haven't seen a response to (I'm in AU... gotta love timezones ;-)). Hi, I think this is the same problem as this recent (inconclusive) discussion: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26721.html Further, but without much actual investigations I think the jitter is an artifact of the main loop update order which has a history breaking one neat feature or another when moving subsystems around. I seem to recall that the question about the jitter in external views when using network replay has showed up several times during the last years. Looking at the log for src/Main/main.cxx, if it worked ok in 1.9.1 I'd look closer at this commit: commit ea4a3ee1df65b75169941af64f6f772737ff7ca4 Date: Mon Sep 7 07:27:38 2009 + Otherwise I suspect that this jitter problem has been present since Feb 2008 and was traded for other neat features in these commits: commit 366178f801a921e73ca991f69a61bbea7faf9d0e Date: Mon Feb 25 12:59:24 2008 + commit 0bca82cb6c1e1fc7891fa349964e58dc5b6875c7 Date: Sat Feb 23 09:45:56 2008 + commit 271487328aa78570c70bffc62620ba840c924174 Date: Tue Nov 6 21:05:38 2007 + (Commit IDs from the gitorious FG/CVS mirror) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Question about *LUT/*lut.h OSX
Hello James(?) I will call it *LUT just not to add another thread to a long long list. Took me some days to read about this problem on OSX. I apologize that I can not solve my new compiler issues with this holy-book-of-keeping-alut-thread ;-) Recent SimGear CVS change in Soundmanager push me to install a new ALUT.framework (my recent OpenAL installation with fake alut.h on OSX worked well until last monday). I tried to work with new changes but I get undefined symbols alutGetError and alutGetErrorString from SoundManager when I try to compile FG CVS (SimGear CVS compiles well also with new SoundManager). First question is probably: Can you give me some hints how I have to set correct PREFIX path with --with-openal-framework= when my new OpenAL.framework exists at /Library/Frameworks/? Thanks- Y. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] toow many bugs on flightgear sources
There is a lot of bugs in the structure of the project None of .cpp/.cxx files include all the files they needs, they includes files which includes other files that this .cpp/.cxx depends on. Then if you modify the first include and the consequence is the first include does nt include the other files needed by the .cpp/.cxx then this .cpp/.cxx doesnt compile and its become to be very expensive to detect which include is missing. In collaborative project its really a problem ! The hierarchy of directory is not good enought, The includes directives are bugged: the files includes with absolute reference path and not relative than we have to guess what include directories to set on the path search: A project doesnt have to set include path for all the subproject: you must use relative path on the source code. The interdepencies are chaotics In first attemp to compil i took 3 days to resolve dependencies. Today, after succesfully compile flightgear since a week, I have got the new jsbsim sources and tried to include it on the Flightgear: then i got a lot of dependencies errors (includes, namespace disapeared ect ...) Before to continue to develop the project, structure and hierarchies must be cleaned !! David Ingels -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
Hi David, This post will probably not be taken well by many subscribers but I understand your frustration. The build process works but to get the first clean compile is a highly non-trivial task as you noticed. Your post is not very descriptive so I can only give you general pointers. You need to build the different dependencies in proper order using the build tools provided in the different packages (cmake and autotools). You are best of installing the different modules (make install) and use the install location in subsequent build steps. Create a build script that automates the compilation of all packages, run it regularly. Usually you need to use the latest synchronized CVS versions of simgear and flightgear (assuming you are using repository version, replace with git if that is were you fetch the sources). I haven't had time to build flightgear et al. since two months back so cannot say if my set up compiles cleanly today. I expect that it needs some tweaking ... as always. Which isn't a bad thing and should be expected since using the repository stuff is to live on the edge. Cheers, Jari On 5/5/10 12:10 PM, Ingels David wrote: There is a lot of bugs in the structure of the project None of .cpp/.cxx files include all the files they needs, they includes files which includes other files that this .cpp/.cxx depends on. Then if you modify the first include and the consequence is the first include does nt include the other files needed by the .cpp/.cxx then this .cpp/.cxx doesnt compile and its become to be very expensive to detect which include is missing. In collaborative project its really a problem ! The hierarchy of directory is not good enought, The includes directives are bugged: the files includes with absolute reference path and not relative than we have to guess what include directories to set on the path search: A project doesnt have to set include path for all the subproject: you must use relative path on the source code. The interdepencies are chaotics In first attemp to compil i took 3 days to resolve dependencies. Today, after succesfully compile flightgear since a week, I have got the new jsbsim sources and tried to include it on the Flightgear: then i got a lot of dependencies errors (includes, namespace disapeared ect ...) Before to continue to develop the project, structure and hierarchies must be cleaned !! David Ingels -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about *LUT/*lut.h OSX
On 5 May 2010, at 10:41, HB-GRAL wrote: I will call it *LUT just not to add another thread to a long long list. Took me some days to read about this problem on OSX. I apologize that I can not solve my new compiler issues with this holy-book-of-keeping-alut-thread ;-) Recent SimGear CVS change in Soundmanager push me to install a new ALUT.framework (my recent OpenAL installation with fake alut.h on OSX worked well until last monday). I tried to work with new changes but I get undefined symbols alutGetError and alutGetErrorString from SoundManager when I try to compile FG CVS (SimGear CVS compiles well also with new SoundManager). First question is probably: Can you give me some hints how I have to set correct PREFIX path with --with-openal-framework= when my new OpenAL.framework exists at /Library/Frameworks/? Right, it sounds like you are pretty close. The new situation is as follows: - don't touch your standard Apple OpenAL *at all* (apart from maybe the ALCvoid - void tweak which I suspect we are stuck with) - grab ALUT.framework from here: http://files.goneabitbursar.com/fg/alut-osx-universal.zip (temporary location) - put the framework somewhere sensible, probably /Library/Frameworks is easiest - If you are using autoconf/automake, you will need to add -framework ALUT to someplace; I haven't made the autoconf changes yet since I wanted to get some feedback on the code parts of the change before we completely commit to this new approach (if you use Tat's XCode projects, you will need to adjust things too, but I assume that is obvious) This should give you a real ALUT 1.1, no problems with the Apple OpenAL, and no compile/link problems with SimGear. At least that's the hope! Let me know what you experience, because that's exactly what I want to discover in the next couple of weeks from other Mac developers. Once I'm sure it works and makes sense for people, I will make the configure changes and put my ALUT framework somewhere official (and write some Wiki documentation, I guess) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
Ingels David wrote: The interdepencies are chaotics [ ] I've tried to understand the build instructions / FAQ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
Hi David, This post will probably not be taken well by many subscribers but I understand your frustration. The build process works but to get the first clean compile is a highly non-trivial task as you noticed. Your post is not very descriptive so I can only give you general pointers. ... Cheers, Jari I'd have to agree with all this. I stopped trying to build FlightGear years ago because it is highly non-trivial. Having been involved in several large engineering and training simulations over the years, I can say that in my experience it's almost always non-trivial. :-) But, I think that if some effort was expended, that process could be improved and made simpler or more automated for FlightGear. I'd like to see the build process formalized for building under: 1) Linux 2) Cygwin 3) MSVC++ (using the latest Express compiler freely downloadable) 4) Mac There ought to be some kind of install wizard for the source code, and an interdependency checker, or similar. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
As another note, it seems that simgear and terragear from CVS have some problems -- using simgear-cs and terragear-cs from git seems to work better. Not sure what the -cs means or why we have two different repositories in the first place. Jim On 5 May 2010 06:33, Jon S. Berndt jonsber...@comcast.net wrote: Hi David, This post will probably not be taken well by many subscribers but I understand your frustration. The build process works but to get the first clean compile is a highly non-trivial task as you noticed. Your post is not very descriptive so I can only give you general pointers. ... Cheers, Jari I'd have to agree with all this. I stopped trying to build FlightGear years ago because it is highly non-trivial. Having been involved in several large engineering and training simulations over the years, I can say that in my experience it's almost always non-trivial. :-) But, I think that if some effort was expended, that process could be improved and made simpler or more automated for FlightGear. I'd like to see the build process formalized for building under: 1) Linux 2) Cygwin 3) MSVC++ (using the latest Express compiler freely downloadable) 4) Mac There ought to be some kind of install wizard for the source code, and an interdependency checker, or similar. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
On 5 May 2010, at 12:33, Jon S. Berndt wrote: I'd have to agree with all this. I stopped trying to build FlightGear years ago because it is highly non-trivial. Having been involved in several large engineering and training simulations over the years, I can say that in my experience it's almost always non-trivial. :-) But, I think that if some effort was expended, that process could be improved and made simpler or more automated for FlightGear. To be honest, I'm not sure much simplification is possible - FG *is* a large, complex piece of code, and it doesn't live inside a build ecosystem like Gnome or KDE, so if we don't want to pull every dependency into the sources, there will always be some initial steps. It's more awkward to get building than a Linux kernel, but no worse than (say) Blender or Firefox. On Linux, the steps are (from a clean Ubuntu/Fedora install) - install various -dev packages using apt-get/yum/synaptic (openAL-dev, compiler, freetype-dev, libpng-dev, boost, cmake, cvs/svn/git clients etc) - download OSG, cmake, make and make install - download PLIB tarball, configure, make and make install - download Simgear, configure,make, make install - download FlightGear, configure, make, make install (I've done this recently to validate my Hudson build system for FG) Not trivial, but not exactly the end of the world, either. The situation on Cygwin is not as good, but the same fundamentals apply - just more work has to be done to get FreeType, boost, cmake and so on into place. In each case I don't believe *any* unusual configure arguments are required, except maybe --prefix and --with-osg/--with-simgear; The autoconf script is pretty smart these days, though I wouldn't claim it's perfect :) On Mac and Visual Studio, there's certainly more messing around, but if anyone asks here they will be helped out; probably some better Wiki documentation would help. And, as always, documenting and making beautiful build systems is less fun that hacking code - and most of us *are* doing this for fun :) Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
Jim Duchek wrote: As another note, it seems that simgear and terragear from CVS have some problems -- using simgear-cs and terragear-cs from git seems to work better. Not sure what the -cs means or why we have two different repositories in the first place. -cs is the short form for Custom Scenery - see this site for a little background: http://www.custom-scenery.org/ terragear-cs is a fork of the 'traditional' TerraGear/CVS stuff after maintenance of the latter had stalled. simgear-cs is a derivate of SimGear/CVS to allow headless operation (without a $DISPLAY), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about *LUT/*lut.h OSX
James Turner schrieb: - grab ALUT.framework from here: http://files.goneabitbursar.com/fg/alut-osx-universal.zip (temporary location) I have a own freealut 1.1.0 compiled/installed for i386. Do I have to replace this one with your framework/universal? - put the framework somewhere sensible, probably /Library/Frameworks is easiest I have tried this and SimGear/SoundManager compiles without problems. Also with my own freealut/alut.h. - If you are using autoconf/automake, you will need to add -framework ALUT to someplace; I haven't made the autoconf changes yet since I wanted to get some feedback on the code parts of the change before we completely commit to this new approach (if you use Tat's XCode projects, you will need to adjust things too, but I assume that is obvious) I do not use XCode and I found the link to a new needed precompiled framework in your CVS log message by accident ;-) Now my FG CVS is broken at the moment and does not compile anymore. But I will give it another try with your hints. Thank you for your answer -Y -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about *LUT/*lut.h OSX
On 5 May 2010, at 13:36, HB-GRAL wrote: James Turner schrieb: - grab ALUT.framework from here: http://files.goneabitbursar.com/fg/alut-osx-universal.zip (temporary location) I have a own freealut 1.1.0 compiled/installed for i386. Do I have to replace this one with your framework/universal? Yes, probably - we're trying to get away from the situation where each Mac developer needs to come up with their own solution to this problem. The code in the framework I mentioned should be exactly the same code as your freealut 1.1.0, just packaged as a framework. - put the framework somewhere sensible, probably /Library/Frameworks is easiest I have tried this and SimGear/SoundManager compiles without problems. Also with my own freealut/alut.h. - If you are using autoconf/automake, you will need to add -framework ALUT to someplace; I haven't made the autoconf changes yet since I wanted to get some feedback on the code parts of the change before we completely commit to this new approach (if you use Tat's XCode projects, you will need to adjust things too, but I assume that is obvious) I do not use XCode and I found the link to a new needed precompiled framework in your CVS log message by accident ;-) Well, that's why the message is there :) Unfortunately these kind of changes are hard to make 'smooth', especially when everybody has made their own work-around for the past problems. Also part of the excitement of using CVS! Now my FG CVS is broken at the moment and does not compile anymore. But I will give it another try with your hints. Just to be clear, are the compile problems are caused by my changes, or something else? If you have an *unmodified* Simgear from latest CVS (a problem right now, since the CVS server is broken) I would expect it to compile with just some simple changes to configure.ac: add '-framework ALUT' to libs: LIBS=$LIBS -framework IOKit -framework OpenAL -framework ALUT The check below for --with-openal-framework needs to be fixed, since it should probably be renamed to --with-alut-framework, now that people can hopefully always use the official Apple OpenAL. Hope that all makes sense, let me know if you need more help. Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
Hi David, your rant could have more weight if you included some examples. Please be more specific to help us improve the current situation. -Fred - Ingels David david.ing...@laposte.net a écrit : There is a lot of bugs in the structure of the project -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] THE ADVENTURES OF OLEG - POSTER DOC (226.8 KB bytes)
For posperity Please get a copy of my Draft promotional small poster document for THE ADVENTURES OF OLEG I had to make the images small to fit it all on the page and to save on ink levels, it's something you can print out and stick on a wall for Attracting Interest BOTH FOR FLIGHTGEAR and the Movie :) http://files.ww.com/files/67504.html Michelle-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter
Thank you for the response Maik, I am sure your helicopter has flapping. Maybe not a visible flapping hinge, but some elasticity within the blades or the blade holder. The Bo105 and the Ec135 has no flapping hinge as well. I gather then, that we need to somehow measure effective values for all of the parameters that aren't obvious? How would you recommend measuring or calculating the effective flap hinge ratio? Thanks again, Thomas -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RE : toow many bugs on flightgear sources
Example taken from hasard: the file fg_props.hxx
the begining of the file is:
// fg_props.hxx - Declarations and inline methods for property handling.
// Written by David Megginson, started 2000.
//
// This file is in the Public Domain, and comes with no warranty.
#ifndef __FG_PROPS_HXX
#define __FG_PROPS_HXX 1
#include iosfwd
#include simgear/structure/subsystem_mgr.hxx
#include simgear/math/SGMath.hxx
#include Main/globals.hxx
== it didnt include the file /simgear/props.hxx which defines namespace
props and enum simgear::props:STRING
but later it uses namespace and the enum defined in it:
class FGMakeUpperCase : public SGPropertyChangeListener {
public:
void valueChanged(SGPropertyNode *node) {
if (node-getType() != simgear::props::STRING) == here
return;
char *s = const_castchar *(node-getStringValue());
for (; *s; s++)
*s = toupper(*s);
}
== if any of the 4 files included in top of source doesnt include
/simgear/props.hxx than this file doesnt compile: it s abnormal.
The
#include simgear/structure/subsystem_mgr.hxx
is absolute includes and depends on the search path added on the project
configuration
If the directory hierarchie is well defined, you can set for example a
relative path
#include ../../../../simgear/structure/subsystem_mgr.hxx
the reader of the source can find immediately where the file included is
and can read it quickly without searching.
I am not against include directory path in project configuration for
example to set up dependencys from external project
Like openscenegraph in flightgear, but, simgear is semi-external, like
jsbsim the sources are compiled in flightgear project
Than it can be considered internal and no include path have to be added
on project, or it can be considered external in the form of a simple lib
to link with and include path in the project are added.
there are other examples where the part simgear/ is missing because the
project configuration include the path:
../../../../simgear
other example : the project configuration include the paths :
../../../src
../../../src/include
= its abnormal use only one of the two solution and set #include
directive in accordance
other example:
in my first atempt to compile flightgear i have used
Openscenegraph2.9.7 because in the doc it is say that
openSceneGraph2.9.6 and above is needed
OpenSceneGraph2.9.7 doesnt link, an obscure probleme of zlib version
used in openscenegraph2.9.7. I have decided to delete 2.9.7 and using
OpenSceneGraph2.9.6
Than i can link with 2.9.6 version
There must be someone designed to decide wich version of external
software to use and responsible of the good integration and test of the
external modules.
Do not tell to use Version2.9.6 and above, tell use only version
2.9.6 flightgear validated with 2.9.6.
Okay there are tools to setup a new jsbsim in flightgear for example, i
didnt know that before my mail, but i find its not very normal to have
to using tools.
Ok, i am returning to learn how integrate the new jsbsim in FG.
Cordialy,
David Ingels
-Message d'origine-
De : Frederic Bouvier [mailto:fredfgf...@free.fr]
Envoyé : mercredi 5 mai 2010 17:34
À : FlightGear developers discussions
Objet : Re: [Flightgear-devel] toow many bugs on flightgear sources
Hi David,
your rant could have more weight if you included some examples. Please
be more specific to help us improve the current situation.
-Fred
- Ingels David david.ing...@laposte.net a écrit :
There is a lot of bugs in the structure of the project
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery - album photo
http://www.youtube.com/user/fgfred64 Videos
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RE : toow many bugs on flightgear sources
An other sample : In source JSBSim.cxx : #include JSBSim.hxx #include FDM/JSBSim/FGFDMExec.h #include FDM/JSBSim/FGJSBBase.h #include FDM/JSBSim/initialization/FGInitialCondition.h == absolutes paths, depends on projectconfiguration i have compiling problems because i have copied the new jsbsim version, without scratching the old one, in another position in directory, made another directory in project configuration and removed from compilation the old files. (than i have 2 directorys JSBSIM in my project FlightGear: the old one (configured to not compil) and the new one.) == i want to be capable to switch betwen the two versions if the file was with relativepath it wil search the correct includes and compile : #include JSBSim.hxx #include FGFDMExec.h // same directory as the source jsbsim.cxx #include FGJSBBase.h #include initialization/FGInitialCondition.h // relative to the source compiling (jsbsim.cxx) cordialy david ingels -Message d'origine- De : Frederic Bouvier [mailto:fredfgf...@free.fr] Envoyé : mercredi 5 mai 2010 17:34 À : FlightGear developers discussions Objet : Re: [Flightgear-devel] toow many bugs on flightgear sources Hi David, your rant could have more weight if you included some examples. Please be more specific to help us improve the current situation. -Fred - Ingels David david.ing...@laposte.net a écrit : There is a lot of bugs in the structure of the project -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter
Hello Thomas, Thomas Hamilton schrieb am 05.05.2010 19:57: Thank you for the response Maik, I am sure your helicopter has flapping. Maybe not a visible flapping hinge, but some elasticity within the blades or the blade holder. The Bo105 and the Ec135 has no flapping hinge as well. I gather then, that we need to somehow measure effective values for all of the parameters that aren't obvious? How would you recommend measuring or calculating the effective flap hinge ratio? For the flap hinge I would use the value which is used at the bo105. Up to now there is no example of a helicopter with a bell-hiller rotor head for flightgear. The UH1 has the bell rotor head with stabilizer bar, but as far I know the cvs version of the uh1 is broken since some days. I have no idea, if or when helijah will commit my patch. Maybe it's easier if you just provide a (maybe very simple but right size) 3d Model of your helicopter. Then I can make a FDM similar to my rc-helicopters. At the end we only need to adjust it to make it fly as your helicopter does. Thanks again, Thomas Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RE : toow many bugs on flightgear sources
Read James' post:
On Linux, the steps are (from a clean Ubuntu/Fedora install)
- install various -dev packages using apt-get/yum/synaptic
(openAL-dev, compiler, freetype-dev, libpng-dev, boost, cmake,
cvs/svn/git clients etc)
- download OSG, cmake, make and make install
- download PLIB tarball, configure, make and make install
- download Simgear, configure,make, make install
- download FlightGear, configure, make, make install
And as James points out there are more tweaking needed on macs.
The build system works, try it. simgear is built independent of
flightgear and flighgear is build with simgear installed somewhere
(normally) outside its own build directory. If you follow the path above
everything should compile.
Do not pursue your include strategy below.
OSG 2.9.7 works for me, and if I remember correctly even 2.9.8 works.
Please search the mailing list archive on building fg et al. There is a
lot of information there.
Still, we do not know what OS you are working on? But then again you
aren't really asking for help.
Jari - is it really me writing this? Is this what happens after a while
with fg? ;-)
On 5/5/10 8:18 PM, Ingels David wrote:
Example taken from hasard: the file fg_props.hxx
the begining of the file is:
// fg_props.hxx - Declarations and inline methods for property handling.
// Written by David Megginson, started 2000.
//
// This file is in the Public Domain, and comes with no warranty.
#ifndef __FG_PROPS_HXX
#define __FG_PROPS_HXX 1
#includeiosfwd
#includesimgear/structure/subsystem_mgr.hxx
#includesimgear/math/SGMath.hxx
#includeMain/globals.hxx
== it didnt include the file /simgear/props.hxx which defines namespace
props and enum simgear::props:STRING
but later it uses namespace and the enum defined in it:
class FGMakeUpperCase : public SGPropertyChangeListener {
public:
void valueChanged(SGPropertyNode *node) {
if (node-getType() != simgear::props::STRING)== here
return;
char *s = const_castchar *(node-getStringValue());
for (; *s; s++)
*s = toupper(*s);
}
== if any of the 4 files included in top of source doesnt include
/simgear/props.hxx than this file doesnt compile: it s abnormal.
The
#includesimgear/structure/subsystem_mgr.hxx
is absolute includes and depends on the search path added on the project
configuration
If the directory hierarchie is well defined, you can set for example a
relative path
#include “../../../../simgear/structure/subsystem_mgr.hxx”
the reader of the source can find immediately where the file included is
and can read it quickly without searching.
I am not against include directory path in project configuration for
example to set up dependencys from external project
Like openscenegraph in flightgear, but, simgear is semi-external, like
jsbsim the sources are compiled in flightgear project
Than it can be considered internal and no include path have to be added
on project, or it can be considered external in the form of a simple lib
to link with and include path in the project are added.
there are other examples where the part simgear/ is missing because the
project configuration include the path:
“../../../../simgear”
other example : the project configuration include the paths :
“../../../src”
“../../../src/include”
= its abnormal use only one of the two solution and set #include
directive in accordance
other example:
in my first atempt to compile flightgear i have used
Openscenegraph2.9.7 because in the doc it is say that
openSceneGraph2.9.6 and above is needed
OpenSceneGraph2.9.7 doesnt link, an obscure probleme of zlib version
used in openscenegraph2.9.7. I have decided to delete 2.9.7 and using
OpenSceneGraph2.9.6
Than i can link with 2.9.6 version
There must be someone designed to decide wich version of external
software to use and responsible of the good integration and test of the
external modules.
Do not tell to “use Version2.9.6 and above”, tell “use only version
2.9.6“ flightgear validated with 2.9.6.
Okay there are tools to setup a new jsbsim in flightgear for example, i
didnt know that before my mail, but i find its not very normal to have
to using tools.
Ok, i am returning to learn how integrate the new jsbsim in FG.
Cordialy,
David Ingels
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
