Re: [Flightgear-devel] Docs installation with cmake
On 29 Nov 2011, at 23:14, ThorstenB wrote: On 29.11.2011 23:59, Jon Stockill wrote: I've just noticed that the README files are being installed to /usr/doc since the switch to cmake. This should be /usr/doc/flightgear Right. Also noticed this recently. The correct location also depends on the (Linux) distribution, i.e. OpenSuSE wants /usr/share/flightgear/... Luckily CMake can automatically provide the correct location (GNUInstallDirs = DOCDIR), we just need to use that variable in our makefile. I'll have a look at this some time - unless James... Thanks Jon, a good catch. As Thorsten said, we fortunately have a helper script to deal with this, just need to use in the appropriate place. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
On Tue, Nov 29, 2011 at 10:14 PM, Arnt Karlsen wrote: On Tue, 29 Nov 2011 10:26:10 -0600, Curtis wrote in message On Tue, Nov 29, 2011 at 8:35 AM, Stuart Buchanan wrote: I came across the FS Break podcast (http://www.fsbreak.net/) just the other day, which discusses flight simulation - mainly FS-X and X-Plane. I think it would be worth arranging some interview/announcement for when the 2.6.0 release comes out. I'm happy to run this, but thought it would be worth having someone else on as well to give a different perspective. Anyone else interested? Hi Stuart, This sounds like a great idea. Please let me know what I can do to help. Curt. snipping various criticisms Denigrating people whose marketing help we would like on a public mailing list isn't exactly going to warm them to us, is it Arnt? If you don't have anything nice to say about someone, it's usually better not to say anything at all. (For any third party reading this, Arnt's comments are not usually a reflection of the general view of the FG community, as a perusal of the mailing list will quickly show) -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
Stuart Buchanan wrote: (For any third party reading this, Arnt's comments are not usually a reflection of the general view of the FG community, as a perusal of the mailing list will quickly show) +1 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
On Wed, 30 Nov 2011 09:22:45 +, Stuart wrote in message CAP3ntyt5a8XRQ3JXN-YQ0mMPGgTdmSL2PMDgiUdRk=ntcz6...@mail.gmail.com: On Tue, Nov 29, 2011 at 10:14 PM, Arnt Karlsen wrote: On Tue, 29 Nov 2011 10:26:10 -0600, Curtis wrote in message On Tue, Nov 29, 2011 at 8:35 AM, Stuart Buchanan wrote: I came across the FS Break podcast (http://www.fsbreak.net/) just the other day, which discusses flight simulation - mainly FS-X and X-Plane. I think it would be worth arranging some interview/announcement for when the 2.6.0 release comes out. I'm happy to run this, but thought it would be worth having someone else on as well to give a different perspective. Anyone else interested? Hi Stuart, This sounds like a great idea. Please let me know what I can do to help. Curt. snipping various criticisms Denigrating people whose marketing help we would like on a public mailing list isn't exactly going to warm them to us, is it Arnt? ..having spent over half an hour on his X-plane 10 First Look video, I honestly don't see why we would want to annoy people that same way, I was annoyed. Short teaser videos is the way to go, e.g. one per question, or point, or feature. If you don't have anything nice to say about someone, it's usually better not to say anything at all. ..and some times brutal truths must be told. This guy has potential, but he blows it all away with me with his overlenght and oversize nonsense. Cut the crap, get to the points, also visually. That includes the crappy oversize white banner left over half the panel and over way too much of the scenery that at least I wanted to see. ..move it out of the way, make it transplarent, put your face in it, or make it a watermark style banner. Fade it from white will also work, should also work for the crowd who likes his current style. (For any third party reading this, Arnt's comments are not usually a reflection of the general view of the FG community, as a perusal of the mailing list will quickly show) ..am I the only one who would like to see him able to put his face right next to the radio stack? Would also work with Atlas and other moving map etc window apps that we etc might wanna test. ..a valid point you could have made, is my all ideas no code contribution. Not my choice, I've been too busy fighting off Statoil.com since 2005, their straw men bought the workshop I built my thermochemical gasifier in, they don't want me nor my clients making power from crap. Zero code until I have a new place. ..another valid point is I don't waste my time watching TV, which over time makes you a stranger in your own country, TV spoon feed has a strong dumbing down influence on culture, premier case in point are the in all senses of the word, _cheap_ reality shows. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
Arnt, ...and some times brutal truths must be told. You have potential, but you blow it all away with me with his overlenght and oversize use of dots. Cut the crap, get to the points, not the dots. Gijs Stuart, Excellent idea! Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Improving random trees buildings
Hi All, Having seen some recent screenshots from X-Plane 10, I've been thinking about ways to improve our random scenery, in particular buildings. At present, we have random building scattered over the scenery, based on .ac models, plus the Urban shader. The former are limited in that performance suffers significantly as density increases, and there is little control over their placement. The Urban shader provides an good impression of a complex city-scape, but the sides of the buildings are rather gray, and the visuals suffer at low viewing angles. It also has a significant performance impact. I'm wondering whether there is any mileage in using a variant on the scheme we use for random vegetation to create a cityscape. As you may be aware, the random vetegation uses a small number of geomerties instantiated all over the terrain, and uses a vertex shader (which is much cheaper than a fragment or geometry shader) to provide height, width and texture information. Of course, there's no point at all in doing this unless it provides better performance than the urban shader. The Default materials.xml tree density is 4000m^2, or a tree per 63mx63m square (ish). The trees themselves have similar geometric complexity to a cuboid (same number of vertices), but buildings don't generally have any alpha blending requirements. So to a first level of approximation, we should be able to populate the urban area with textured cubeoids at the same density as the trees for a similar cost performance-wise. To provide more interesting buildings, I'm anticipating using a cuboid per floor, plus a modified cuboid for the roof, so probably ~ 4x the complexity of trees geometrically for a 3 storey building. Obviously there would be XML controls in materials.xml (or a linked XML file) for the length, width, number of floors, textures, and roof. At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. It may be that my system is unique in that one is cheap and the other expensive, and this is all pointless! Thanks, -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
On Wed, 30 Nov 2011 13:40:39 +0100, Gijs wrote in message dub102-w3714d4187c340d8ee4d23bd3...@phx.gbl: Arnt, ...and some times brutal truths must be told. You have potential, ..yeah, it's a BS prefix to the no-gasifier excuses I hear. get to the points, not the dots. ..my points were snipped. ;o) Stuart, Excellent idea! ..aye, the FS Break guy is _annoyingly_ close to what I'd like to see. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stuart Hi All, Having seen some recent screenshots from X-Plane 10, I've been thinking about ways to improve our random scenery, in particular buildings. At present, we have random building scattered over the scenery, based on .ac models, plus the Urban shader. The former are limited in that performance suffers significantly as density increases, and there is little control over their placement. The Urban shader provides an good impression of a complex city-scape, but the sides of the buildings are rather gray, and the visuals suffer at low viewing angles. It also has a significant performance impact. I'm wondering whether there is any mileage in using a variant on the scheme we use for random vegetation to create a cityscape. As you may be aware, the random vetegation uses a small number of geomerties instantiated all over the terrain, and uses a vertex shader (which is much cheaper than a fragment or geometry shader) to provide height, width and texture information. Of course, there's no point at all in doing this unless it provides better performance than the urban shader. The Default materials.xml tree density is 4000m^2, or a tree per 63mx63m square (ish). The trees themselves have similar geometric complexity to a cuboid (same number of vertices), but buildings don't generally have any alpha blending requirements. So to a first level of approximation, we should be able to populate the urban area with textured cubeoids at the same density as the trees for a similar cost performance-wise. To provide more interesting buildings, I'm anticipating using a cuboid per floor, plus a modified cuboid for the roof, so probably ~ 4x the complexity of trees geometrically for a 3 storey building. Obviously there would be XML controls in materials.xml (or a linked XML file) for the length, width, number of floors, textures, and roof. At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. It may be that my system is unique in that one is cheap and the other expensive, and this is all pointless! Sounds a good idea - I hate the random objects - they are always the wrong style/size and in the wrong place. Just do it - we'll make it switchable at runtime. Users can make up their own minds (or as it has been said of users: what they are pleased to call their minds). Looking forward to testing it, Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd)
Hi Thorsten, Thanks for your reply. I've decided to repeat again the full process for compiling FG under Windows. I get systematically the same error: 1Compilation en cours... 1ReaderWriterOGR.cpp 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2146: erreur de syntaxe : absence de ';' avant l'identificateur 'CPLOSGErrorHandler' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2182: 'CPL_STDCALL' : utilisation non conforme du type 'void' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(43) : error C4430: spécificateur de type manquant - int est pris en compte par défaut. Remarque : C++ ne prend pas en charge int par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(50) : warning C4508: 'CPLOSGErrorHandler' : la fonction doit retourner une valeur ; type de retour 'void' pris par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(100) : error C2664: 'CPLSetErrorHandler' : impossible de convertir le paramètre 1 de 'int (__cdecl *)(CPLErr,int,const char *)' en 'CPLErrorHandler' 1Aucune fonction ayant ce nom dans la portée ne correspond au type de la cible 1Le journal de génération a été enregistré à l'emplacement file://c:\FGDev\OpenSceneGraph-3.0.1\OpenSceneGraph\build\src\osgPlugins\ogr\osgdb_ogr.dir\Debug\BuildLog.htm 1Plugins ogr - 4 erreur(s), 1 avertissement(s Have you an idea how to solve it? Many thanks, Cheers, Fatima -Message d'origine- De : ThorstenB [mailto:bre...@gmail.com] Envoyé : mardi 29 novembre 2011 14:43 À : Iervolino Fatima Cc : FlightGear developers discussions Objet : Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd) Hi Fatima, that's not an aircraft-dependent problem - you seem to have a fundamental issue with loading the scenery itself. May well be related to the PNG lib / malformed chunk warnings in your console - this could be scenery textures which fail to load. Maybe check which PNG library you're using - and if the files in the data directory are ok. You can also try to add this to your fgfs command-line: --prop:sim/sceneryloaded-override=1 That won't fix the underlying issue, but it will tear down the splash screen immediately instead of waiting for scenery to be loaded. Looking at the scenery may help seeing what the issue is - i.e. do you get any scenery at all, are only (some) textures missing etc. cheers, Thorsten Am 29.11.2011 13:49, schrieb Iervolino Fatima: Hello Thorsten, Many thanks for your help. It's better now but the FlightGear is blocked to the step of loading scenery for all kind of aircrafts. Could you please help me? You'll find here https://docs.google.com/document/d/1Sw7OM3piEq-TUhHnIRTcKw3lpQT2QUrdApcYYPX8KdM/edit a screenshot of the program the command DOS. Cheers, Fatima -Message d'origine- De : ThorstenB [mailto:bre...@gmail.com] Envoyé : lundi 28 novembre 2011 17:26 À : FlightGear developers discussions Cc : Iervolino Fatima Objet : Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd) Am 28.11.2011 16:57, schrieb Alan Teeder: This was sent directly to me. Does anyone know what her problem is likely to be? (I, and others , have already given several answers to this question on the FG forum) After having compiling in DEBUG RELEASE mode FlightGear under Windows, I get systematically an error while I'm trying to launch fgfs under Windows command DOS. “Fatal error: Unrecognized flight model 'jsb', cannot init flight dynamics model.” Alan, please add a forum link when cross posting: http://www.flightgear.org/forums/viewtopic.php?f=35t=14371hilit=jsb With the introduction of CMake it is possible to enable/disable the different FDMs. The JSBSim and YASim are enabled by default, only the LARCSim and UIUC flight dynamics are excluded from the build by default. As Anders said on the forum, something must have gone wrong while configuring the build, so somehow the default was changed, and JSBSim support disabled and excluded from the build. Either remove CMakeCache.txt and run cmake again (so the correct defaults are taken), or run cmake -DENABLE_JSBSIM:BOOL=ON to override the current local setting. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
On 30 Nov 2011, at 11:29, Martin Spott wrote: Stuart Buchanan wrote: (For any third party reading this, Arnt's comments are not usually a reflection of the general view of the FG community, as a perusal of the mailing list will quickly show) +1 +2 Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
Another big influence is the antenna pattern of the antenna on the aircraft. Fuselage, wing and empennage are the blocking structures of course. If you want I can have a look and get you some typical data for structure blocked signal loss. A lot of aircraft have a seperate GS antenna in the cockpit because: 1. antenna cable short (NAV unit is in cockpit usually) 2. excellent view of the runway (...) Thanks for the information. Of course, this would depend on the antenna position on the fuselage. Would it be placed underneath the aircraft? Perhaps the antenna gain might be increased in some situations by the fuselage acting as a huge reflector? Since there can be many specific situations, antenna gain will be configurable on a case by case basis. I will spend more time doing research, but would definetly appreciate if you know a reliable source for this type of information online. As I said earlier, I think it could be possible to add antenna radiation patterns, at least in a simplified way. Thinking of most GA and business aviation aircraft I know the NAV antenna (VOR/LOC/GS) is always located on the vertical tail, just below the horizontal tail with a cross or t-tail and on top of the vert. tail with a low hor. tail. These are usually two antennas, one on each side of the structure. They are on the vertical tail because NAV signals are polarized horizontally and thus the antenna must be installed that way (unlike COM which is polarized vertically and you will find these antennas standing up or down.) As I mentioned before, there is sometimes a separate GS antenna in the cockpit or on the fuselage directly above it. It looks like a small V about 30cm wide. These are all passive antennas. See http://www.cobham.com/about-cobham/aerospace-and-security/about-us/antenna-systems/fullerton/products/vorlocgs.aspx for instance Gain increase by reflection on aircraft is not something I am aware of. I know that for COM 1/4 lambda antennas (or 1/4 lambda antennas in general) you need a good ground plane to get the VSWR down to an acceptable level. Regards Eric -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast
Am 30.11.11 15:56, schrieb Durk Talsma: On 30 Nov 2011, at 11:29, Martin Spott wrote: Stuart Buchanan wrote: (For any third party reading this, Arnt's comments are not usually a reflection of the general view of the FG community, as a perusal of the mailing list will quickly show) +1 +2 +(n+1) Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
Thinking of most GA and business aviation aircraft I know the NAV antenna (VOR/LOC/GS) is always located on the vertical tail, just below the horizontal tail with a cross or t-tail and on top of the vert. tail with a low hor. tail. These are usually two antennas, one on each side of the structure. They are on the vertical tail because NAV signals are polarized horizontally and thus the antenna must be installed that way (unlike COM which is polarized vertically and you will find these antennas standing up or down.) Thanks, I didn't know NAV is polarized horizontally (which makes sense given the need for an elevated pattern). I've been doing some reading about ground VOR equipment, and it seems there are 3 main types. Terminal VOR - around 50 W ERP, service radius approximately 25 miles under 12000 feet Low altitude VOR - power output unknown, range 80 miles under 18000 feet High altitude VOR - around 200 W, range 200 miles above 2 feet I got this information from the book Aviator's guide to GPS by Bill Clarke. Other sources on the internet which seem particularly reliable to me, mention a standard setting of 100-130 W with a maximum power of 200 W, which is set based on local site surveys. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd)
Am 30.11.2011 15:40, schrieb Iervolino Fatima: I get systematically the same error: 1Compilation en cours... 1ReaderWriterOGR.cpp 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2146: erreur de syntaxe : absence de ';' avant l'identificateur 'CPLOSGErrorHandler' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2182: 'CPL_STDCALL' : utilisation non conforme du type 'void' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(43) : error C4430: spécificateur de type manquant - int est pris en compte par défaut. Remarque : C++ ne prend pas en charge int par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(50) : warning C4508: 'CPLOSGErrorHandler' : la fonction doit retourner une valeur ; type de retour 'void' pris par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(100) : error C2664: 'CPLSetErrorHandler' : impossible de convertir le paramètre 1 de 'int (__cdecl *)(CPLErr,int,const char *)' en 'CPLErrorHandler' 1 Aucune fonction ayant ce nom dans la portée ne correspond au type de la cible 1Le journal de génération a été enregistré à l'emplacement file://c:\FGDev\OpenSceneGraph-3.0.1\OpenSceneGraph\build\src\osgPlugins\ogr\osgdb_ogr.dir\Debug\BuildLog.htm 1Plugins ogr - 4 erreur(s), 1 avertissement(s Have you an idea how to solve it? Many thanks, Hmm. Unfortunately I have little help here. Actually you're compiling a part of the OpenSceneGraph library there - not FlightGear itself. However, I can see that for some reason the OSG plugin ogr was never compiled on my system. Not sure what it does, but it seems we don't need this for FlightGear. Maybe this OSG plugin is broken somehow. I would probably just try to disable ogr (i.e. remove the ADD_SUBDIRECTORY(ogr) from the CMakeList.txt) and see if that works. Otherwise you may need to ask the OpenSceneGraph forum/devel-list. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd)
Am 30.11.11 21:13, schrieb ThorstenB: Am 30.11.2011 15:40, schrieb Iervolino Fatima: I get systematically the same error: 1Compilation en cours... 1ReaderWriterOGR.cpp 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2146: erreur de syntaxe : absence de ';' avant l'identificateur 'CPLOSGErrorHandler' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2182: 'CPL_STDCALL' : utilisation non conforme du type 'void' 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(43) : error C4430: spécificateur de type manquant - int est pris en compte par défaut. Remarque : C++ ne prend pas en charge int par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(50) : warning C4508: 'CPLOSGErrorHandler' : la fonction doit retourner une valeur ; type de retour 'void' pris par défaut 1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(100) : error C2664: 'CPLSetErrorHandler' : impossible de convertir le paramètre 1 de 'int (__cdecl *)(CPLErr,int,const char *)' en 'CPLErrorHandler' 1 Aucune fonction ayant ce nom dans la portée ne correspond au type de la cible 1Le journal de génération a été enregistré à l'emplacement file://c:\FGDev\OpenSceneGraph-3.0.1\OpenSceneGraph\build\src\osgPlugins\ogr\osgdb_ogr.dir\Debug\BuildLog.htm 1Plugins ogr - 4 erreur(s), 1 avertissement(s Have you an idea how to solve it? Many thanks, Hmm. Unfortunately I have little help here. Actually you're compiling a part of the OpenSceneGraph library there - not FlightGear itself. However, I can see that for some reason the OSG plugin ogr was never compiled on my system. Not sure what it does, but it seems we don't need this for FlightGear. Maybe this OSG plugin is broken somehow. I would probably just try to disable ogr (i.e. remove the ADD_SUBDIRECTORY(ogr) from the CMakeList.txt) and see if that works. Otherwise you may need to ask the OpenSceneGraph forum/devel-list. cheers, Thorsten You probably have to check gdal version and if there are none or multiple gdal libs present in your path. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
