Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Monday, October 24, 2011 16:53:23 James Turner wrote: Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one (or several) paths to search - I tested that this morning and updated the README. As you guessed, manually setting the the detection variables (SIMGEAR_VERSION_OK, etc) is a bad idea, unless you set *all* the generated variables correctly - not impossible, but a lot of work. The error you report looks like it's happening because the detection script has got confused, but I need to see the arguments / environment passed to CMake, to understand why. James Hi James, and thanks for updating the readme. I may be blind or just stupid, but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. Adding it to environment variables does not do anything, and cmake fails to find the libraries. Do you, or anybody else, know how to get KDevelop to use custom paths the way cmake does with -D CMAKE_PREFIX_PATH ? I'm using KDevelop 4.01 on Debian Squeeze. Thanks, Adrian -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 25 Oct 2011, at 09:39, Adrian Musceac wrote: Hi James, and thanks for updating the readme. I may be blind or just stupid, but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. Adding it to environment variables does not do anything, and cmake fails to find the libraries. Do you, or anybody else, know how to get KDevelop to use custom paths the way cmake does with -D CMAKE_PREFIX_PATH ? I'm using KDevelop 4.01 on Debian Squeeze. It's a cmake variable, not an environment one, so I guess all I can really say is 'set it the same way you pass any other variable to cmake in Kdevelop' - but that's not much help, I appreciate! Note from the command line, you must not include a space between the -D and the cmake variable name, i.e I need to do: cmake ../source/dir -DCMAKE_PREFIX_PATH=/path/one;/path/two (the quotes are necessary if specifying multiple paths for me, otherwise bash treats the semi-colon as a command separator - depending on how Kdevelop invokes cmake, that may or may not be necessary for you) James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fgpanel and ubuntu 11.10 build linking failed on libz, solved.
Am 24.10.2011 13:08, schrieb James Turner: [...] Also, there is something configuration dependent happening here, since other people have reported a similar issue (also with Ubuntu 11) on IRC, but I don't see the issue on my Ubuntu install. Anyone else seeing this problem (on any other distribution?) At least on Ubuntu 11.10 64bit, some libraries have been moved from /usr/lib to /usr/lib/x86_64-linux-gnu, among which are at least libz.so and libGLU.so. I also ran into linking problems with these two libs after upgrading from 11.04, but after deleting the CMake cache and re-configuring (both SimGear and FlightGear), everything went fine. Best regards, Andreas -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft split
Hi . Though it appears to have it's drawbacks , from a selfish point of view ,the split makes work here much easier. Thanks again. Just another (possibly useless) idea . What about adding a text/xml file of all available aircraft , or even an aircraft.dat file,somewhere in fgdata? I haven't thought it out too deeply , but maybe in this format : Aircraft: Citation-X Author: Syd Licence: GPL URL: git clone or download url Splash: path/url to thumbnail It would be up to the aircraft developers to fill it in and maintain it, and possibly a nice little GUI could be created to automate the viewing and downloading. Just a thought. Cheers -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On Tue, 25 Oct 2011 00:18:36 +0200 HB-GRAL flightg...@sablonier.ch wrote: Hi Core (and the rest of the entire organism of course) Why not splitting up the Aircraft folder into hangars as collection of aircrafts as plug-ins, collection of big teams or small but heavy industries ? IMHO that adds another not very logical layer of complication for little gain. There's a nice democratic aspect to every aircraft being in a single central repository, and reduced opportunities for those clique type groups that so naturally spring up and are divisive and very offputting to new contributers coming to the project. Up until now it's been very straightforward to get a new model included - if it's your own work and under a suitable licence you simply ask someone with commit rights if you know one, or offer it to the dev list and it goes in. There's no embarrasment over which hangar / group / clique to submit it to, and I think that's a very good thing. Cheers, AJ -- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Mon, 2011-10-24 at 14:53 +0100, James Turner wrote: On 24 Oct 2011, at 13:17, Geoff McLane wrote: In my case I like to be able to compile against different versions of say OSG - like - OSG301=1# stable release 3.0.1 - default OSG283=0# general release 283 - option OSG299=0# another development release OSGTRUNK=0 # option, for 'trunk' version I have yet to try the idea from Mathius, using a semi-colon set of paths, maybe replacing some or all the 'export' items, like - -D CMAKE_PREFIX_PATH=/path/to/osg;/path/to/simgear;... - this seems a good idea to try... maybe cmake will like it ;=)) Okay, *but*, for your own sanity, you need to keep the Simgear-built-against each of these separate too (anf FlightGear). By all means install each OSG somewhere special, but then you need to build FG and SG against the same version - so you may as well share a prefix for that build config (this is what Jenkins does to build trunk OSG vs stable) Put it another way - you need to reconfigure and rebuild SG FG entirely, when switching OSG version, so I don't see any problem with installing to the prefix for that OSG build too. I'd do: mkdir osg-build-301 cd osg-build-301 cmake ../path/to/osg-301-source -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 make install cd .. mkdir sg-build-with-osg-301 cd sg-build-with-osg-301 cmake ../path/to/simgear -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 make install cd .. ... and repeat once more for FlightGear Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one (or several) paths to search - I tested that this morning and updated the README. As you guessed, manually setting the the detection variables (SIMGEAR_VERSION_OK, etc) is a bad idea, unless you set *all* the generated variables correctly - not impossible, but a lot of work. The error you report looks like it's happening because the detection script has got confused, but I need to see the arguments / environment passed to CMake, to understand why. James Hi James, As always thank you for your input... Yes, I hear you, and understand to use different versions of OSG, you need to redo both SG and FG at the same time... I do all of this using my 'makefg' script, so such a feat is as easy as pie ;=)) - .../fg16$ makefg OSG301 FGCLEAN SGCLEAN .../fg16$ mv install/fgfs install/fgfs-301 .../fg16$ mv run_fgfs.sh run_fgfs_301.sh .../fg16$ edit run_fgfs_301.sh to add '-301' .../fg16$ makefg OSG283 FGCLEAN SGCLEAN .../fg16$ mv install/fgfs install/fgfs-283 .../fg16$ mv run_fgfs.sh run_fgfs_283.sh .../fg16$ edit run_fgfs_283.sh to add '-283' .../fg16$ makefg OSG299 FGCLEAN SGCLEAN ...etc...etc... Then I can run the versions via the run_fgfs-ver scripts, side-by-side if desired... real simple... no problem... And all this noise is only about getting that script exactly 'right' to now use cmake, as it did previously with automake... and I am willing to take the time ;=)) need to see the arguments / environment passed to CMake, to understand why. But in each case I have explicitly given you the exact exports and cmake commands used... What more do you need? Anyway, as mentioned, have moved onto doing the same SG/FG/TG update in my XP WIN32, since there the powerful source view debugger will allow me to trace easily into say a tile load... But have already encountered a problem or 2 which you may be able to help with... I am sure I will be able to HELP enhance and maintain the cmake files as I gain more understanding... But the problems at the moment are that it 1. can NOT compile sgsound due to NOT finding AL/al.h The GUI asks for the OPENAL_LIBRARY, which in my case is - C:\Program Files\OpenAL 1.1 SDK\libs\Win32\OpenAL32.lib But for some reason it does NOT ask for an OPENAL_INCLUDE, which of course would be - C:\Program Files\OpenAL 1.1 SDK\include Like it does for multiple OSG, and JPEG, ZLIB, etc... And that additional path needs to be added to the additional paths when building this particular library, but it does not matter if it is added to ALL builds... Of course I can manually fix this in the MSVC IDE, *OR* I could COPY AL/al.h to the '3rdparty/include' I am using, that already contains many other of the 3rd party dependents... But the 'correct' fix would be for the CMake GUI ask where to find it... How can I do this? 2. It fails on linking test_binobj, Configuration Debug, with link error LNK2005: LIBCMT.lib conflicts with LIBCMTD.lib... But this does not make sense. It is building the Debug configuration, so why has it linked also with the NON-Debug version... AH HA! There it is - cmake is linking with all the correct Debug SG libraries, like sgiod.lib, note the added 'd', but makes a MISTAKE with C:\FG\30\3rdparty\lib\zlib.lib!!!
Re: [Flightgear-devel] Enabling HLA - missing RTI.hh
On Monday, October 24, 2011 22:12:15 Martin Spott wrote: George Patterson wrote: Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am not sure if Mathias has moved the above project to another host. I'm sure Mathias will speak about the details himself, but aside from that I can confirm he's aware of the implications. In case of doubt, there's our mirror at: http://mapserver.flightgear.org/git/gitweb.pl?p=openrti Uh, you alredy mirrored this one?! Ok. I am currently thinking of what to do with the project. But in the meantime my upstream git is now at gitorious: https://gitorious.org/openrti/openrti with the git clone url: git://gitorious.org/openrti/openrti.git So berlios is already considered dead ... Mathias -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenRTI git repository
Hi, Some of you have already noticed that berlios is closing at the end of the year. So OpenRTI needs to find a new home. I have recently just changed my upstream repository to git://gitorious.org/openrti/openrti.git This is not a full replacement for the berlios site, but currently at least the location of the git repository. Still thinking about what to do with mainling lists, that were until now unused, and bug tracking and so on. If you have problems with anything there feel free to contact me. thanks Mathias -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Hello, IMHO that adds another not very logical layer of complication for little gain. There's a nice democratic aspect to every aircraft being in a single central repository, and reduced opportunities for those clique type groups that so naturally spring up and are divisive and very offputting to new contributers coming to the project. Sorry, I hate it to say, but we have that situation already. Up until now it's been very straightforward to get a new model included - if it's your own work and under a suitable licence you simply ask someone with commit rights if you know one, or offer it to the dev list and it goes in. There's no embarrasment over which hangar / group / clique to submit it to, and I think that's a very good thing. So far it is working. BUT: Those who have commit rights are already busy with their own stuff. For a new aircraft it is o.k. to ask them- but when I want to update my work? For each small update asking and stealing time of those people? But the last sentence is not true again, sorry. It should be like that, but it isn't any more. The idea of Yves aka HB-GRAL is quite nice and seems to me to reflect the actual situation. But I must admit- in the whole thing I'm quite uncertain how to proceed. I just know that the current FGData make more and more problems with its size! -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Hi, good to see some more factual discussions. Let me emphasize that anyone is welcome to add/edit concerns/questions/answers/solution to the wiki: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata Those who have commit rights are already busy with their own stuff. For a new aircraft it is o.k. to ask them- but when I want to update my work? For each small update asking and stealing time of those people? No matter what aircraft-split we end up with, aircraft authors will always be able to update their own aircraft at any time. With the current setup you can for example commit (and accept merge requests) for your EC130:https://gitorious.org/flightgear-aircraft/ec130 When you start on a new aircraft and would like to have its repository under the FlightGear Aircraft project, you do have to ask one of the people from the team: https://gitorious.org/+flightgear-aircraft You also have to contact that teammembers when you'd like to get access to an existing repo (or give someone else access to your aircraft's repo). We could implement Yves' idea (giving teams access to repos, rather than individuals) in the FlightGear aircraft project. But I don't think it is worth most of the trouble. I think it would make things even more un-clear when there are hundreds of teams... But I might be wrong of course. Cheers, Gijs -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
Hi, On Monday, October 24, 2011 10:27:11 thorsten.i.r...@jyu.fi wrote: My understanding is that * the vertex shader computes stuff for each vertex Yes. If I don't use a fragment shader (as e.g. in the 3dclouds), things like shading get a linear interpolation between vertices. You need to have both shaders if you use one of them. Just using one of which is not allowed by gl. To understand what happens I try to give a brief sketch on how this works: varying results from the vertex shader are fed into the rasterizer which takes the primitives and the varyings at the corners and generates fragments (pixels) for these geometries. The scanline algorithm is applied to the varyings which means along the edges of the primitives the varying is interpolated linearily according to its position between the vertices. Then along the scanline the varying result is taken at the two endpoints that are located on the edges the varying is again linearily interpolated for each fragment. This is still the same than it was done in the good old fixed function pipeline days. Just that you have today a variable amount of varyings with arbitrary names that are handled like the above. * the fragment shader allows me to specify a non-linear function to interpolate between vertices Hmm, I do not understand this. Understand the above and it gets clear what happens. If I have two points with distances d1 and d2, I can either compute fog1 = exp(-d1/vis) and fog2 = exp(-d2/vis) in the vertex shader. The result will then be a linear increase in fog from fog1 at d1 to fog2 at d2 - which is in general very wrong for large d1-d2 because the actual result is exponential and not linear. Or I can pass d1 and d2 to the fragment shader and compute the non-linear exponential there - which would give me the correct result, since a linear interpolation between d1 and d2 actually should be an exact result. Ok, I see: In other words you are correclty claiming that exp(x*a) != x*exp(a) which just means that the exponential is *not* a linear function. Which means you can't just pull that out of the fragment shader into the vertex stage without changing the results. :) So there should in fact not be any loss of accuracy when I move linear quantity computations to the vertex shader, this should only be true if I move non-linear quantities. Is this essentially correct? Essentially yes. Hope this helps Mathias -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Hello, there was little input on the fgdata split and few people speaking up when things were started. We do see a lot of responses now - many being in favor of the change, but also concerns about remaining issues. Indeed, setting up the new repo isn't as simple as it seemed initially, and there are issues which need to be resolved. We also need common acceptance of the new structure, tools and processes. Unfortunately, the call for split completed was communicated ahead of time - even before fgdata itself was switched. And we still do see a need for a proper testing phase before switching - including a chance for everyone to give input, raise concerns, etc. Thanks for that- it looked to me like the changes have been made to quick without seeing the consequences. Nethertheless, I'm in favor for a split. My Reasons: -Gitorious.org had problems with the size of our repo. This was one cause why Merge-requests didn't worked for a while. They fixed it, but as the number aircraft are increasing I wonder for how long. -There are countries and locations where download speed isn't really fast, but even very slow. And yes, Germany is indeed one of them -for each small update developers without commit rights it wasn't that comfortable to get them up. For those people I think it wasn't easy as well to find time to work on their own projects and review and commit new updates of aircraft. That was the reason why I set up my own repos. It was easier for to organize my work, still open and free for users even if they want to contribute, tar.gz was made automatically (no need of uploading to my Homepage), and still had the possibility to let commit it to FGdata. On the other side clone each of the 300+ aircraft isn't that comfortable as well. I would rather liked to see a FGAircraft or FGAicraftFixedWings,FGAicrafthelicopters,... Heiko -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On the other side clone each of the 300+ aircraft isn't that comfortable as well. There are various ways to tackle that problem. One could write a script to clone/pull all the aircraft with a single click, but an even nicer solution might be to use submodules, as mentioned at the wiki (sorry for promoting the wiki this often, but it really makes discussions a lot shorter/better if everyone reads the plan as written down there :P) Gijs -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft split
On 25 Oct 2011, at 14:30, syd adams wrote: I haven't thought it out too deeply , but maybe in this format : Aircraft: Citation-X Author: Syd Licence: GPL URL: git clone or download url Splash: path/url to thumbnail It would be up to the aircraft developers to fill it in and maintain it, and possibly a nice little GUI could be created to automate the viewing and downloading. Just a thought. I'm working on pretty much exactly this, only with a bit more intelligence - version numbers, mirrors, other metadata. It will happen, but there's quite a few parts to get working - including the GUIs as you mention. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terragear now sans plib
Hi there, maybe you have noticed some exceptionally high activity in recent days/weeks on the Terragear repo. Well, there is one particular reason for it: It now supports the cmake build system and, as of today, does no longer depend on plib. These changes are not yet in the master tree, but can be tested in the topics/cmake-integration branch. Please do so, if possible, so we can iron out any showstoppers. Chris -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 25 Oct 2011, at 15:20, Geoff McLane wrote: need to see the arguments / environment passed to CMake, to understand why. But in each case I have explicitly given you the exact exports and cmake commands used... What more do you need? The problem is you've confused me, with all the discussion :) So it would help, to be able to see exactly the commands, all of them, in one place - maybe upload your scripts to someplace? Then I can get an overview of what you're doing. 1. can NOT compile sgsound due to NOT finding AL/al.h Of course I can manually fix this in the MSVC IDE, *OR* I could COPY AL/al.h to the '3rdparty/include' I am using, that already contains many other of the 3rd party dependents... But the 'correct' fix would be for the CMake GUI ask where to find it... How can I do this? Seems like a bug in the FindOpenAL module (we use the standard CMake one) - might need to report it upstream. We can fork the script locally, and add support, but I wonder why other Windows users didn't report this. Maybe they all use Fred's standard dependencies package? 2. It fails on linking test_binobj, Configuration Debug, with link error LNK2005: LIBCMT.lib conflicts with LIBCMTD.lib... But this does not make sense. It is building the Debug configuration, so why has it linked also with the NON-Debug version... Why did it NOT apply that rule in this case? Is there something I can change in the CMakeLists.txt files to make this happen? The problem is library detection, not generation (so changing the postifx won't help - it only affects the libraries that are produced). Again it may be an issue with the FindZLib module on Windows - I don't run Windows so not really able to say. On Unix, CMake will use both the debug and release versions if it finds them, otherwise it will use the release (no suffix) version for everything. That's fine on Unix, but obviously not on Windows, since the runtimes clash as you described. 3. Question of library output directory But at present it is outputting the libraries to C:/FG/30/simgear/build/simgear/io/debug/sgiod.lib and C:/FG/30/simgear/build/simgear/io/release/sgio.lib Ideally I would 'like' it to output them all to C:/FG/30/3rdparty/lib/sgiod.lib and C:/FG/30/3rdparty/lib/sgio.lib That is the whole purpose of using this 'd' for the Debug, to keep the names separate... thus do NOT want them placed in .../build/projects/debug|release/lib[d] So again, do you know of a way to 'teach' cmake this little trick ;=)) Can't you just run 'make install'? The build locations are correct, if you want them to end up in their final home, you need to actually perform the install step. Assuming I understand what you're trying to achieve. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft split
Oh good. I figured someone would be way ahead of me :) Cheers On Tue, Oct 25, 2011 at 11:32 AM, James Turner zakal...@mac.com wrote: On 25 Oct 2011, at 14:30, syd adams wrote: I haven't thought it out too deeply , but maybe in this format : Aircraft: Citation-X Author: Syd Licence: GPL URL: git clone or download url Splash: path/url to thumbnail It would be up to the aircraft developers to fill it in and maintain it, and possibly a nice little GUI could be created to automate the viewing and downloading. Just a thought. I'm working on pretty much exactly this, only with a bit more intelligence - version numbers, mirrors, other metadata. It will happen, but there's quite a few parts to get working - including the GUIs as you mention. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Am 25.10.11 19:09, schrieb syd adams: I dont personally see any advantage myself, I'd have to vote no.Sorry Yves. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi Syd There is nothing to vote yes or no actually. But thanks anyway to read and give some feedback. Cheers, Yves -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
