[Flightgear-devel] triplicate code
Do we really need three pieces of code that try to do the
same thing?
simgear/props/props_io.cxx: static const char * getTypeName
(simgear::props::Type type)
src/Network/props.cxx: static string getValueTypeString(const
SGPropertyNode *node)
src/GUI/property_list.cxx: static string getValueTypeString( const
SGPropertyNode *node )
==
commit 92b369deb2654351ce4e385a773ccbe01113ce14
Author: John Denker j...@av8n.com
Date: Sun Feb 7 02:37:55 2010 -0700
Export the code that translates the _type_ of a property node
to a human-readable string.
diff --git a/simgear/props/props_io.cxx b/simgear/props/props_io.cxx
index 48244c7..214d73f 100644
--- a/simgear/props/props_io.cxx
+++ b/simgear/props/props_io.cxx
@@ -410,9 +410,10 @@ void readProperties (const char *buf, const int size,
#define INDENT_STEP 2
/**
- * Return the type name.
+ * Convert the _type_ of a property node
+ * to a human-readable string.
*/
-static const char *
+const char *
getTypeName (simgear::props::Type type)
{
using namespace simgear;
diff --git a/simgear/props/props_io.hxx b/simgear/props/props_io.hxx
index b619c04..22c0cfb 100644
--- a/simgear/props/props_io.hxx
+++ b/simgear/props/props_io.hxx
@@ -68,6 +68,13 @@ void writeProperties (const std::string file,
bool copyProperties (const SGPropertyNode *in, SGPropertyNode *out);
+/**
+ * Convert the _type_ of a property node
+ * to a human-readable string.
+ */
+const char *
+getTypeName (simgear::props::Type type);
+
#endif // __PROPS_IO_HXX
// end of props_io.hxx
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for generic.cxx
Mirko Stanisak wrote: Hello everybody, I'm currently working on interacting flightgear with other applications. For this I use the generic protocol via UDP like this: fgfs --generic=socket,out,10,localhost,1234,udp,exchange -- generic=socket,in,10,localhost,1235,udp,exchange where exchange.xml is my XML protocol definition. Unfortunately, the in declaration produced a never ending loop. Thus, I propose this little patch for inclusion in CVS. Thanks, I've committed a different patch that should do the same. Problem with your solution is that the ascii parser didn't retrieve all queued packaged like before. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On Saturday 06 Feb 2010, Ron Jensen wrote: [snip...] ./configure --datadir=$parent/bogus \ --with-osg=$parent/usr \ --with-simgear=$parent/usr \ --with-plib=$parent/usr \ --prefix=$parent/usr Isn't exactly a stock setup... And neither is shuffling libraries into non-standard directories. The system does not seem to be highly customised and generating a makefile that doesn't work cannot be passed off as just not working in the way expected. The issue seems to be the makefile expects to find OSG's libraries in $parent/usr/lib where they were specified to be, and he/his system placed them in a non-standard place. Look at his command line again. g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX He *told* it osg was in $parent/usr/ (and I am assuming $parent=/games/orig) and the makefile is telling g++ to look in -L/games/orig/usr/lib for libraries. But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Is it not the case that ./configure has run ok, presumably believing that it has found the libs it needs, but then generated a makefile that fails because it can't find them? That was what I thought the problem was. Using non-standard configurations is far from forbidden on linux; that's why there are options (parameters) to override normal defaults, but ./configure should be checking for consistency and failing when it finds inconsistency, not giving the appearance that all is well. LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
leee wrote: But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Is it not the case that ./configure has run ok, presumably believing that it has found the libs it needs, but then generated a makefile that fails because it can't find them? That was what I thought the problem was. Using non-standard configurations is far from forbidden on linux; that's why there are options (parameters) to override normal defaults, but ./configure should be checking for consistency and failing when it finds inconsistency, not giving the appearance that all is well. Agreed. I'll see if I can fix it somewhere this week (unless someone else beats me to it). By the way: I don't dislike the idea of switching to CMake but I have no experience in creating configuration files for it myself. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
Hi All, Wow, don't you love it when a topic generates real interest. I count over 30 posts on this so far... and I can not help but add one more ;=)) To try to directly address the problem as posted on - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit the case of a 'missing' osgFX So the question is where is osgFX installed? And this, as others have pointed out, would depend on what was fed to cmake, if OSG is compiled from source, or where the package manager put it... I suspect it is in a 'lib64' folder, either /usr/lib64 or maybe /usr/local/lib64, or /games/orig/usr/lib64 Why OSG cmake does this I have no idea. Maybe cmake thinks it is being 'smart' ;=() If it is in /games/orig/usr/lib64, and there is no /games/orig/usr/lib, or it is empty, then creating a link lib - lib64 with /games/orig/usr $ ln -s lib64 lib will get the compile/link to complete. If it is in /usr/lib64 or /usr/local/lib64, then we know there is already a /usr/lib and /usr/local/lib, so the 'link' solution can NOT be used. I guess the only solution for this would be to move everything out of the 'lib64' into lib... or indeed into somewhere like - /games/orig/usr/lib[64] And be aware, except for the /usr/lib move you will then have to add a 'fix' when ever you run 'fgfs', since now the dynamic shared runtime library loader will also not be able to find osgFX, and all the other OSG shared libraries... To run 'fgfs' you will have to do - export LD_LIBRARY_PATH=/games/orig/usr/lib64 or export LD_LIBRARY_PATH=/games/orig/usr/lib if you created the suggested 'link'. And this will also apply when you run say fgviewer, or others that depend on the OSG shared libraries, so can be a bit of a pain... Or this can be made 'permanent' by adding another say osg.conf to /etc/ld.so.conf.d since my /etc/ld.so.conf contains a line - include /etc/ld.so.conf.d/*.conf Something I think maybe cmake OSG should have done... Now whether or not this can be classified as a FG 'bug' is a mute point. As Lee and others have pointed out, I do think FG auto configuration could have a check for say osgFX, or osgDB, and politely exit with message before it is seen in the actual compile/link... I have NO problems compiling, linking, and running in my Ubuntu 64-bit, and to share how I get around all this - $someroot in my case is '/home/geoff/fg/fg7' but can be just about anything... 1. OSG - I use - cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \ -D CMAKE_C_FLAGS=-O3 \ -D CMAKE_INSTALL_PREFIX:PATH=$someroot/install/OSG281 This installs the OSG libraries in $someroot/install/OSG281/lib64 And the OSG headers are thus installed in $someroot/install/OSG281/include and say osgviewer binary in $someroot/install/OSG281/bin Then in this folder $someroot/install/OSG281 I make a link lib - lib64 2. PLIB ./configure --prefix=$someroot/install/plib \ --exec-prefix=$someroot/install/plib 3. SG ./configure --prefix=$someroot/install/simgear \ --exec-prefix=$someroot/install/simgear \ --with-osg=$someroot/install/OSG281 \ --with-plib=$someroot/install/plib \ --with-jpeg-factory \ --with-boost=$someroot/install/boost 4. FG ./configure --prefix=$someroot/install/fgfs \ --exec-prefix=$someroot/install/fgfs \ --with-osg=$someroot/install/OSG281 \ --with-simgear=$someroot/install/simgear \ --with-plib=$someroot/install/plib This is using OSG release 281, but this approach gives me the flexibility of using the later 282, of even the OSG svn trunk... likewise with various release versions, or svn, of plib... perhaps the only case for using non-standard directory installations... Of course, I have ALL this in a script - http://geoffair.net/tmp/makefg so I do NOT have to remember each time... and that script generates a run_fgfs.sh script, that does the export LD_LIBRARY_PATH thingy before running fgfs... And as you can read in that script, I have a 'switch' to install OSG in the 'standard' path, /usr/lib etc, but never got that working ;=() I will add and test a few additions to configure.ac to 'search' for the OSG libraries, like we do for most others, and present it shortly... and maybe others, like Erik says, have ideas on this... maybe it would also be possible to ferret out even a 'lib64' installation... HTH, Regards, Geoff. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
leee wrote: But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Yup, and if it doesn't find OSG libraries, then it'll be going to write approx. eight messages in sequence about OSG libraries not being found. The only point which might be debatable here is wether you'd expect 'configure' to exit ungracefully at this point for those users who don't care to understand 'configure's output. BUT those who don't are probably not the primary target group for compiling FlightGear and all it's dependencies from source. BTW, FlightGear's 'configure' behaves similarly wrt. other libraries - seems to be like being the FlightGear way of dealing with missing libraries, Martin. P.S.: The compile-time linker on Debian/Lenny/AMD64 is happily going to pick the libraries from /usr/lib64/ if you move the files there. You just have to point the runtime-linker at the directory in order to start FlightGear. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
Geoff McLane wrote: Why OSG cmake does this I have no idea. Maybe cmake thinks it is being 'smart' ;=() OSG is destined to compile and work on a lot more Unix systems than those who are supported by FlightGear (at least nowadays, we were having a few more in the past). Quite a few of these systems are following conventions about the naming of library-directories which are different from the respective habits on Linux. Thus, storing 64-bit libraries in $prefix/lib64/ (on platforms which might support different word-sizes) doesn't look that bad as being cross-platform solution, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
Wow, what a debate. This is a reply to an early post in this thread. On 2/5/10 6:21 PM, Martin Spott wrote: Jari Häkkinen wrote: Actually I think subversion support in terrasync should be removed altogether or fixed. If removed then all svn checks could be removed. Oh my, could you _please_ stop this litany ? One posting of this sort per day should really be enough, two or more are a nuisance. According to my experience you're trying to make people throw the baby out with the bath water, which is not appropriate here. Well, I am only trying to suggest improvements to the code/build environment. I think this is the first time I actually suggest a feature to be thrown out. I remember trying to convince developers to remove dependencies on PLIB parts that are implicitly stated to not being used according to the fg build instructions. I have suggested that some code should be conditionally built (i.e. by doing make check). I had a few more posts but my hope and intent is that my postings actually improves fg. Nae, sorry Martin I have something more to say about terragear and subversion. I posted my previous message with a few things in mind 1) Document for other newcomers (I been around for one year soon but still consider me a fg code beginner since I only look at the code occasionally) that there are some strange features wrt subversion and terragear. They might catch this thread through their favourite search engine. 2) I wanted to report the bug (oups there I used the nasty word) in terrasync ... it locks directories. I gave a reference to another posting where I think it was clear that the issue was not being fixed by the father of the baby. 3) Also, on my machine with subversion development libs the configuration script fails out of the box. Therefore I attached a patch for others to use or ignore. 4) I also acknowledged the fact that Geoffs was right but I wanted to highlight that the terragear flaw is still valid. Geoffs response to my posting explains why he is not experiencing the issues I see. If we were to drop every feature which _might_ occasionally have a malfunction here or there, then we would end up with having no FlightGear at all, The problem is that the terrasync issue happens almost every time I run fg but then of course terragear is started each time I run fg (even for short tests). There are many directories to sync each time terrasync stars. I don't want to drop features and I am crazy enough to run terragear with the current subversion flaw ... hoping it will be fixed some day. Am I the only one using subversion built-in terragear? Cheers, Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MP Errors
With ATC2, I keep getting a Nasal error, which results in having to restart. Nasal runtime error: nil used in numeric context at /home/flight-sim/flight-gear-9/data/Nasal/multiplayer.nas, line 285 http://code.google.com/p/flightgear-bugs/issues/detail?id=51 kind regards Pete -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Outerra
Hi, Just for those who wants to know what's going on in the flight sim world: Outerra is a new 3d-engine for seamless planet rendering. They included JSBSim, so it can be used as Flight Sim. It is still in developement, but they hope it will be used in any games and sims in near future. There is a demo planned for the next few weeks. I wonder if we can use this with FGFS as well ;-) But it seems that the new technics used shows the future of flight sims graphics and abilities Cheers HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Outerra
Heiko Schulz wrote: Hi, Just for those who wants to know what's going on in the flight sim world: Outerra is a new 3d-engine for seamless planet rendering. They included JSBSim, so it can be used as Flight Sim. It is still in developement, but they hope it will be used in any games and sims in near future. There is a demo planned for the next few weeks. I wonder if we can use this with FGFS as well ;-) But it seems that the new technics used shows the future of flight sims graphics and abilities Very impressive. I wonder how well it handles more urban environments. The screenshots of the road rendering are very nice. Jon -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Outerra
Heiko Schulz wrote: Just for those who wants to know what's going on in the flight sim world: Outerra is a new 3d-engine for seamless planet rendering. Wow, the video on the page: http://outerra.blogspot.com/ is amazing if it's real time. That's what a dense forest should look like. And that grass textures! And look at the shadow when they fly along lowly, that slightly bumpy ground surface. These are the 3 biggest things I've always been ultimately disappointed by in any flight sim. Wow! -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] property browsing
Hi -- I made multiple improvements to the http property browser. -- much easier to navigate up the tree -- clearer indication of property type -- possible to re-examine property that has just been set See http://gitorious.org/~jsd/fg/sport-model/commits/sport = Some minor mysteries I encountered while testing the property browser: *) What is the difference between /rendering and /sim/rendering? Is there any available guidance about which should be used for what? *) What is /models ? *) What is /orientation/yaw-deg ? Is it supposed to be related to heading, or to slip angle, or *) It appears VEC3D and VEC4D property types are defined, but -- they are not fully supported -- there are no examples of them in the main property tree (globals) -- there is some code in simgear/scene/material/mat.cxx and ./Effect.cxx that does a few things with them. -- There is no nasal support at all. Is that about right? Are there plans to promote these types to fully-supported status? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property browsing
yo John Denker We are working on the same goal, in identifying bugz, and other little imperfections ;-) Please join the google code bugs experiment for FG = R+D. ie a list of bugs. Its an independant tangent, like your spreadsheet, except its online and you can use it also.. http://code.google.com/p/flightgear-bugs/issues/list Hopefully, together, we'll be creating them issues, and then crossing them off soon, however superfrivilouis or indeed majour, then once their fixed, and TESTED and valid via quality control; then issue is removed. Have and industrial view against FG. I started inputing monsiour spreadsilksheet issues, I started at the top , then after a while, started from the bottom up; only to realise that bottom issues were resolved issues, so I had to delete a load of them, and that miffed me. Its therfore probably best if we can all work at the issues together, so we can figure it out, and like a pinot, sniff, then determine who has the cork and point to the right team to hopefully fix it. se lav vie, chow, bella, pedro ;-) John Denker wrote: Hi -- I made multiple improvements to the http property browser. -- much easier to navigate up the tree -- clearer indication of property type -- possible to re-examine property that has just been set See http://gitorious.org/~jsd/fg/sport-model/commits/sport = Some minor mysteries I encountered while testing the property browser: *) What is the difference between /rendering and /sim/rendering? Is there any available guidance about which should be used for what? *) What is /models ? *) What is /orientation/yaw-deg ? Is it supposed to be related to heading, or to slip angle, or *) It appears VEC3D and VEC4D property types are defined, but -- they are not fully supported -- there are no examples of them in the main property tree (globals) -- there is some code in simgear/scene/material/mat.cxx and ./Effect.cxx that does a few things with them. -- There is no nasal support at all. Is that about right? Are there plans to promote these types to fully-supported status? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Outerra
On Mon, 8 Feb 2010, James Sleeman wrote: Heiko Schulz wrote: Just for those who wants to know what's going on in the flight sim world: Outerra is a new 3d-engine for seamless planet rendering. Wow, the video on the page: http://outerra.blogspot.com/ is amazing if it's real time. That's what a dense forest should look like. And that grass textures! And look at the shadow when they fly along lowly, that slightly bumpy ground surface. That is just astonishing. These guys have done a fantastic job too. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 57 in flightgear-bugs: Font selection in ATC
Comment #2 on issue 57 by pedromorgan: Font selection in ATC http://code.google.com/p/flightgear-bugs/issues/detail?id=57 Why are there font in flightgear? cant it use local fonts ? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 58 in flightgear-bugs: New Joystick configuration: SpeedLink SL-6640 Black Widow Flight Stick
Updates: Labels: joystick Comment #2 on issue 58 by pedromorgan: New Joystick configuration: SpeedLink SL-6640 Black Widow Flight Stick http://code.google.com/p/flightgear-bugs/issues/detail?id=58 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Outerra
On Sun, 07 Feb 2010 21:52:23 +, Jon wrote in message 4b6f3617.6000...@stockill.net: Heiko Schulz wrote: Hi, Just for those who wants to know what's going on in the flight sim world: Outerra is a new 3d-engine for seamless planet rendering. They included JSBSim, so it can be used as Flight Sim. It is still in developement, but they hope it will be used in any games and sims in near future. There is a demo planned for the next few weeks. I wonder if we can use this with FGFS as well ;-) But it seems that the new technics used shows the future of flight sims graphics and abilities Very impressive. I wonder how well it handles more urban environments. The screenshots of the road rendering are very nice. ..aye, chk out his videos. ;o) Jon -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
