Re: [Flightgear-devel] Aircraft with old JSBSim specs in base package
Josh Babcock wrote: Well, the B-29 doesn't really have any correct JSBSim config at all, so you might as well just ignore that entry. I don't think I will ever get the polar data for the Boeing wing, so it will probably not happen in the future either. Are you sure: http://www.ae.uiuc.edu/m-selig/ads/coord_database.html#B http://www.ae.uiuc.edu/m-selig/ads/afplots/b29root.gif http://www.ae.uiuc.edu/m-selig/ads/coord/b29root.dat http://www.ae.uiuc.edu/m-selig/ads/afplots/b29tip.gif http://www.ae.uiuc.edu/m-selig/ads/coord/b29tip.dat Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: simgear for Mac OS X Tiger
Hi Jeehyeon, I have the feeling you think I'm one of the MacOS developers, but unfortunately I'm not. You would be best off directing the question to the developers mailinglist. Erik Jeehyeon Eom wrote: Hi, first of all, I am enthusiastic fan of FlightGear, and I appreciate for your great job! I'm trying to compile FlightGear 0.9.10-pre3 on my PowerBook, but the installation of simgear fails while make with following error messages: if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/FlightGear/include -g -O2 -D_REENTRANT -MT visual_enviro.o -MD -MP -MF .deps/visual_enviro.Tpo -c -o visual_enviro.o visual_enviro.cxx; \ then mv -f .deps/visual_enviro.Tpo .deps/visual_enviro.Po; else rm -f .deps/visual_enviro.Tpo; exit 1; fi In file included from ../../simgear/scene/sky/bbcache.hxx:30, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:36: ../../simgear/screen/RenderTexture.h:343: error: 'CGLContextObj' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:344: error: 'CGLPBufferObj' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:346: error: 'CGLContextObj' is used as a type, but is not defined as a type. make[3]: *** [visual_enviro.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 I'm using Mac OS X.4.6 and Xcode 2.2.1. What am I doing wrong? What I need to do to finish building simgear and FlightGear on my machine? I'm a not so experienced programmer, or exactly, it's almost my first try to build a programm from source :-). Can you please help me? Thanks in advance Sincerely Jeehyeon -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)
Olaf Flebbe Please use the OpenAL Distribution from creative, not the cygwin one. Since it is necessary to do some changes I have a a zip for you: http://www.oflebbe.de/oflebbe/FlightGear/AL.zip For other pitfalls http://www.oflebbe.de/oflebbe/FlightGear/index.html Please either use MSVC or cygwin headers and libraries, but please do not mix them. Olaf 2006/4/2, Vivian Meazza [EMAIL PROTECTED]: Olaf Flebbe Yes there is a patch outstanding. Please go to the FlightGearLib Project in the solution explorer right click, select properties (the last entry) choose build events / pre build events. There was a typo: Please edit change the line to copy ..\..\src\Include\config.h-msvc8 ..\..\src\Include\config.h The Release Mode was correct only debug was wrong. I have no clue what went wrong with exit(). Olaf 2006/4/1, Vivian Meazza [EMAIL PROTECTED]: Olaf Flebbe Cygwin last time, so I wonder if anyone has a quick and dirty howto for compiling flightgear and its dependencies in MSVS 2005? I looked at the wiki, but I think there are some main problems that I don't really Have a look at http://www.oflebbe/oflebbe/FlightGear BTW: The patches for SimGear/FlightGear are in CVS now. Olaf Looks like good work, unfortunately FG does not compile here atm using the project files in cvs, and the above link is broken. SG seems to compile OK. The errors I'm getting are: Error 1 error PRJ0019: A tool returned an error code from Creating Config.h FlightGearLib Error 7 error C2381: 'exit' : redefinition; __declspec(noreturn) differs c:\program files\microsoft visual studio 8\vc\include\stdlib.h 406 Error 8 error C3861: 'exit': identifier not found c:\cygwin\flightgear-cvs\source\src\main\fg_os.cxx 159 OK, I've now got as far as trying to compile and link OpenAL. I get this error: Error 9 fatal error C1189: #error : Do not know sized types on this platformc:\cygwin\freealut-1.0.1\src\alutinternal.h 32 Error 10 fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory c:\cygwin\freealut-1.0.1\test_suite\.libs\lt-test_errorstuff.c 17 After untangling Cygwin stuff, and figuring out how I applied /MT, I successfully compiled and ran cvs/HEAD under MSVC8. Only took me a week :-). Unfortunately, I discovered that submodels no longer work. I downloaded Fred's binary of -0.9.10-pre3 this morning, and they no longer work there either. So far as I can see, they are still working under Cygwin as of last night. I'm doing some more investigations, can anyone else confirm this problem? Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: simgear for Mac OS X Tiger
I'm trying to compile FlightGear 0.9.10-pre3 on my PowerBook, but the installation of simgear fails while "make" with following error messages: if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/FlightGear/include -g -O2 -D_REENTRANT -MT visual_enviro.o -MD -MP -MF ".deps/visual_enviro.Tpo" -c -o visual_enviro.o visual_enviro.cxx; \ then mv -f ".deps/visual_enviro.Tpo" ".deps/visual_enviro.Po"; else rm -f ".deps/visual_enviro.Tpo"; exit 1; fi In file included from ../../simgear/scene/sky/bbcache.hxx:30, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:36: ../../simgear/screen/RenderTexture.h:343: error: 'CGLContextObj' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:344: error: 'CGLPBufferObj' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:346: error: 'CGLContextObj' is used as a type, but is not defined as a type. make[3]: *** [visual_enviro.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 I'm using Mac OS X.4.6 and Xcode 2.2.1. What am I doing wrong? What I need to do to finish building simgear and FlightGear on my machine? I'm a not so experienced programmer, or exactly, it's almost my first try to build a programm from source :-). Can you please help me? Ah, this is due to the render-texture code for OS-X code that was patched into SimGear; I had to fix an include to make it build, I'll send the (minor) patch for that to Erik once I get home; basically you need to pull in OpenGL/CGLTypes.h at the top of the file. The bigger problem is, the RenderTexture code doesn't work, and worse, is resetting the active GLContext to NULL when it fails, so I was getting errors from PLIB about no context being active during startup. I disabled the RenderTexture code in my local tree by adding an early return to the initialise() method.If you just want to fly, you can try the binary I posted yesterday, of course (works on PPC Tiger and Panther, but crashes under Rosetta)http://homepage.mac.com/zakalawe/.Public/flightgear-0.9.10-pre-osx.dmgRegards,James -- All hail the hypno-toad!
[Flightgear-devel] Proposal for 1.0
Hello, this is now going to be the third release in a row that relies on PLIB CVS, I find this is a bit unsatisfactory. On the other side people are waiting endlessly to get patches incorporated into PLIB. I herewith propose to put a copy of PLIB into the SimGear tree after the release is out, to rip those pieces off that FlightGear doesn't use (think of the audio stuff) and to maintain the rest inside Simgear. The few patches that the current PLIB CVS tree actually sees should be easily tracked and incorporated into Simgear/PLIB if required. Regard, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)
Unfortunately, I discovered that submodels no longer work. I downloaded Fred's binary of -0.9.10-pre3 this morning, and they no longer work there either. So far as I can see, they are still working under Cygwin as of last night. Do you have a test case ? What should I do to exhibit the problem ? -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: compile with MSVC 2005 (the same as msvc 8?)
* Frederic Bouvier -- Thursday 06 April 2006 12:09: Unfortunately, I discovered that submodels no longer work. Do you have a test case ? What should I do to exhibit the problem ? The most important submodels are without any doubt the bo105's Gatling style guns M134. :-] $ fgfs --aircraft=bo105 --prop:/sim/model/bo105/variant=4 ... then pull js-trigger or press b-key (red tracers) The 737 has contrails above 50,000 ft, the Spitfire group has starti[ engine smoke. Lee's aircraft usually have trajectory markers, e.g: $ fgfs --aircraft=CanberraBI8 ... outside view, Shift-k-key (red/blue T-s) m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)
Fred Unfortunately, I discovered that submodels no longer work. I downloaded Fred's binary of -0.9.10-pre3 this morning, and they no longer work there either. So far as I can see, they are still working under Cygwin as of last night. Do you have a test case ? What should I do to exhibit the problem ? -Fred And if you ensure that AI models is checked in fgrun, they work just fine. I'd forgotten that fgrun doesn't use fgfsrc. My fault, forget all the forgoing. Sorry for the brain fade Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal for 1.0
On Thu, 6 Apr 2006 09:21:33 + (UTC) Martin Spott wrote: Hello, this is now going to be the third release in a row that relies on PLIB CVS, I find this is a bit unsatisfactory. On the other side people are waiting endlessly to get patches incorporated into PLIB. I herewith propose to put a copy of PLIB into the SimGear tree after the release is out, to rip those pieces off that FlightGear doesn't use (think of the audio stuff) and to maintain the rest inside Simgear. The few patches that the current PLIB CVS tree actually sees should be easily tracked and incorporated into Simgear/PLIB if required. Wow, I've been so out of the loop up to a month and a half ago that had no idea the releases were being built on PLIB CVS. But yesterday I came across a post I made in late February asking whether Tiago Gusmão's texture compression stuff had made it into plib or not, and his replying that after over a month he was still having trouble getting folks on the plib development list to reply. How much extra work would this mean *after* putting it into SimGear? Does plib have a high patch submission rate, thus requiring that someone would have to duplicate the efforts of whoever evaluates and commits patches for plib? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature
Re: [Flightgear-devel] Proposal for 1.0
On Thursday 06 April 2006 10:21, Martin Spott wrote: this is now going to be the third release in a row that relies on PLIB CVS, I find this is a bit unsatisfactory. I've been building CVS with plib-1.8.4 (the last release) for ages with no particular problems, so I'm not sure it's true to say that we _rely_ on PLIB CVS. This is not to detract completely from your point though... On the other side people are waiting endlessly to get patches incorporated into PLIB. That seems to be true. I'm personally using Tiago's texture compression patch with 1.8.4 and it is the sort of thing that would have been applied almost immediately were it part of simgear, say. We should also bear in mind the possibility that PLIB might not be the most suitable platform for fgfs in the future and that migration to OSG would be an option. However, I'm not a coder and other than having played about with some fairly inspiring (visually) OSG applications, I have no really valid opinion on that matter; that would almost certainly be post-1.0 anyway I would imagine? Cheers, AJ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Proposal for 1.0
AJ MacLeod On Thursday 06 April 2006 10:21, Martin Spott wrote: this is now going to be the third release in a row that relies on PLIB CVS, I find this is a bit unsatisfactory. I've been building CVS with plib-1.8.4 (the last release) for ages with no particular problems, so I'm not sure it's true to say that we _rely_ on PLIB CVS. This is not to detract completely from your point though... On the other side people are waiting endlessly to get patches incorporated into PLIB. That seems to be true. I'm personally using Tiago's texture compression patch with 1.8.4 and it is the sort of thing that would have been applied almost immediately were it part of simgear, say. We should also bear in mind the possibility that PLIB might not be the most suitable platform for fgfs in the future and that migration to OSG would be an option. However, I'm not a coder and other than having played about with some fairly inspiring (visually) OSG applications, I have no really valid opinion on that matter; that would almost certainly be post-1.0 anyway I would imagine? I think that this provides a sensible migration route to OSG, if that is the way we are going, otherwise it seems a good proposal in its own right. Apart from the number of updates required (small) I can't see a downside. Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] v0.9.10 source code
As some of you have already noticed, the source/data tarballs for FlightGear-v0.9.10 are now available. Fred has already made a windows binary available, so I'm going to try to get the web site updated and push out an official announcement today. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Proposal for 1.0
* Curtis L. Olson -- Thursday 06 April 2006 15:08: Huh!?! I've been building with plib-v1.8.4 happily without any problems. Officially we depend on v1.8.4. If there's something in plib-cvs that we could benefit from, then we should encourage those guys to do another release. I would *really* like to switch to a new plib version (and make this a requirement), because ... - several pu.h widgets are depreciated, and are now in puAux, where they are actually maintained. (It's quite embarrassing if one has to submit bugfixes for obsolete widgets, when there are already newer ones.) - 1.8.4 has a few bugs that cause gui style problems (pink input field) - we have still our own version of puList, although that has now been included in puAux. (Cleanup of our code base.) - we have #ifdefs for plib 1.8.4 that shouldn't be there forever - we have at least one ugly workaround for a bug that is fixed in plib/CVS - puAux contains new widgets that we could use I don't think we gain much from forking plib. *If* we have people interested in working on plib, those can as well ask for plib write access. (The texture compression was IMHO not advertized well, so I'm not really surprised that it was ignored.) m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft downloads problem .....
syd sandy wrote: Hi all , just discovered a problem with the aircraft downloads from the website while trying to solve a problem for Steve , who downloaded my Citation Bravo and reported errors. The Bravo , and several others of mine rely on instruments in the Instrument-3d folder , but they dont appear to be included in the aircraft file. How should this be solved , keep all aircraft neccecary files in a single directory? I dont care much for that idea ...requires duplicating instruments for each aircraft folder . ... wasteful . Any suggestions ? Instruments-3d is distributed with the base package. So if people upgrade to v0.9.10 they shouldn't have a problem running the new aircraft. There are some potential syncing problems if they want to run a newer development version of the aircraft on an older release. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Proposal for 1.0
Melchior FRANZ wrote: I would *really* like to switch to a new plib version (and make this a requirement), because ... - several pu.h widgets are depreciated, and are now in puAux, where they are actually maintained. (It's quite embarrassing if one has to submit bugfixes for obsolete widgets, when there are already newer ones.) - 1.8.4 has a few bugs that cause gui style problems (pink input field) - we have still our own version of puList, although that has now been included in puAux. (Cleanup of our code base.) - we have #ifdefs for plib 1.8.4 that shouldn't be there forever - we have at least one ugly workaround for a bug that is fixed in plib/CVS - puAux contains new widgets that we could use I don't think we gain much from forking plib. *If* we have people interested in working on plib, those can as well ask for plib write access. (The texture compression was IMHO not advertized well, so I'm not really surprised that it was ignored.) In the past, when we've lobbied the plib people for a new release, they've been very forth coming. Has anyone asked them to consider rolling out a new release? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal for 1.0
Curtis L. Olson wrote: Huh!?! I've been building with plib-v1.8.4 happily without any problems. Officially we depend on v1.8.4. If there's something in plib-cvs that we could benefit from, then we should encourage those guys to do another release. Several patches and improvements went in since the last release of PLIB happened and nobody managed to convince Steve to do a new release over the last year. You probably don't notice the problems with 1.8.4 because you run Linux, people using other platforms run into difficulties with 1.8.4. On the other hand there are small but known bugs in the build system of PLIB CVS and nobody cares over months Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Proposal for 1.0
Melchior FRANZ wrote: I don't think we gain much from forking plib. *If* we have people interested in working on plib, those can as well ask for plib write access. (The texture compression was IMHO not advertized well, so I'm not really surprised that it was ignored.) Forgive me my ignorance, I have only tested the first posted version of the patch. Is compression with this patch optional? Using the patch was no problem with my ATI card (although it didn't help much), but results were just ugly after I switched to nvidia. Nine --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Proposal for 1.0
* Curtis L. Olson -- Thursday 06 April 2006 16:11: In the past, when we've lobbied the plib people for a new release, they've been very forth coming. Has anyone asked them to consider rolling out a new release? Yes, Martin has. Shortly before the 0.9.9 release, and Steve's response was very positive: Sure - seems like a good idea. But then there was some discussion about remaining things to fix in this thread, and it died out without anyone reporting success or bringing a new release up again. Currently CVS/HEAD has one GUI problem for which there's a working and approved fix. Rest is AFAIK stable and usable. (I'm almost always using fgfs with plib/HEAD.) A new release right now wouldn't be necessary, but an agreement that we rely on CVS/HEAD from a particular date (once that GUI bug is fixed), would be nice. Then we could start to get rid of the old plib stuff in fgfs and update it to the state of the art. Relying on a CVS version shouldn't be a problem for developers. And, of course, we'd need a new plib release before our next release. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Proposal for 1.0
On Thursday 06 April 2006 15:32, Stefan Seifert wrote: Forgive me my ignorance, I have only tested the first posted version of the patch. Is compression with this patch optional? Using the patch was no problem with my ATI card (although it didn't help much), but results were just ugly after I switched to nvidia. It's true that the results can be a wee bit ugly but at the same time I'm very happy to live with surfaces showing slight compression noise artefacts when it means I can use the carrier and detailed models like the Hurricane with decent fps on old hardware (64Mb MX420.) On the very same box with a nvidia 6200 card installed I don't see any noise visible at all... Cheers, AJ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Proposal for 1.0
* Stefan Seifert -- Thursday 06 April 2006 16:32: Melchior FRANZ wrote: The texture compression was IMHO not advertized well, so I'm not really surprised that it was ignored.) Forgive me my ignorance, I have only tested the first posted version of the patch. Is compression with this patch optional? No. ... that is, yes: if you apply it, you have compression. Otherwise not. ;-) Using the patch was no problem with my ATI card (although it didn't help much), but results were just ugly after I switched to nvidia. Frankly, I tried it today for the first time (nvidia). It worked very well. With it I can not only resize the window down, but up to fullscreen again. I haven't noticed any artifacts, but also no speed increase. (Do newer nvidia drivers perhaps compress automatically?) But anyway: the discussion was not about the texture compression patch, but about whether we should fork plib. One argument was the sometimes poor handling of submissions, and the compression patch is mostly mentioned first. When we see how questionable it is, this doesn't seem to be a good example. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update: Experimental lighter-than-air support for JSBSim and FlightGear
On Wed, 5 Apr 2006, Lee Elliott wrote: On Wednesday 05 April 2006 10:24, [EMAIL PROTECTED] wrote: [snip] Are there anyone else interested in lighter than air flight for FlightGear/JSBSim? Comments and suggestions are welcome! There is a balloon fdm in FlightGear but the last time I tried it I got some very strange results, and accelerations;) Well, it is a hot air balloon FDM and not a gas balloon FDM.. :) I'd _would_ like to do some Zeppelins though... Me too, but I'm not quite there yet, or, rather, I do think the basic functionallity needed is there (although crude), but I don't have the skills needed to write a working Zeppelin JSBSim specification using it yet. (My attempts tend to behave like pendulums while either floating skywards or sinking through the ground..) If someone wants to try, please do! You are absolutely right about incorporating the dynamic lift aspects of airships - it was a vital factor in their operation. Yes, and that is why I choose to work on adding the static lift capability to JSBSim instead of starting with some thing like the balloon FDM and add aerodynamics - to me the static lift seemed relatively simple to model while aerodynamics and propulsion seem (very) hard. Cheers, Anders -- - | Anders Gidenstam | | | Email: anders(at)gidenstam.org | WWW: http://www.gidenstam.org| - --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 737-300 re-entry
Howdy everyone, As far as the super 737 goes, it indeed looks like the FDM is getting bad info from FG, but I don't know details as I haven't looked into it. As I wrote to Jon, I suspect sea-level atmosphere numbers are being sent. How high can a 737-300 go? Nobody knows. Even though the airplane is certified to 37000 feet I'm sure it can go to at least 5. 72000 looks too high, so the engine config will need another column for 6 feet to further reduce thrust. We model transonic drag rise, but we don't model Mach buffet, which could also have a lift effect. Also, the lift curve is straight from Aeromatic and is too simple for accurate modelling right at the stall, and it doesn't have stall hysteresis. Some tweaks here might help. Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] air-ground.nas
The air-ground.nas system assumes that the airplane starts on the ground. I used this assumption to simplify things because air-ground.nas was my first attempt at Nasal system programming. In order to get the spoilers working right for an in-flight start you might need to disable air-ground.nas in the 737-300-set.xml file. I'll take a look at air-ground.nas and see if I can fix the limitation. BTW, as Innis covered in an earlier email, the air-ground.nas system was something I wrote to model the autospoilers and autobrakes systems. The model isn't exact, but it's pretty close. To get a more exact model I'd have to include an antiskid system, and I'd also have to do it in C++ since I'm more comfortable with that. The current 737-300 model, with air-ground.nas activated, works like this. The autospeedbrakes are disarmed, and the autobrakes switch (a 6-position rotary switch) is in the RTO position. This is the normal setup for takeoff. If you reject the takeoff above 80 knots ground speed the ground and flight spoilers all come up, and the brakes go to maximum force. Once airborne you should select an autobrake setting for landing, either OFF, 1, 2, 3 or MAX. These settings are mapped to the property /controls/gear/autobrakes with values 0, 1, 2, 3, and 4. AFAIK there is no panel switch for this yet, so you have to set this in the property browser. Prior to landing you should also set the autospeedbrakes by setting the property /controls/flight/autospeedbrakes-armed equal true. Now when you land the ground and flight spoilers will come up. Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal for 1.0
On Thursday 06 April 2006 15:07, Vivian Meazza wrote: I think that this provides a sensible migration route to OSG, if that is the way we are going, otherwise it seems a good proposal in its own right. Apart True, I have most of that parts of ssg that are required by flightgear simgear reimplemented using osg nodes below. That is not yet ready for use, but that might be a useful way to go. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: FlightGear/SimGear dsp/dsw files
Hi, I too had some delays - mainly due to house guests cutting down my computer time ;=)) Thanks for the addition of config.h-msvc8 to CVS. I wonder why it was not called either just config.h-msvc, since it WORKS with ALL version of MSVC, or at least config.h-msvc6, as it WAS called before ... but no problem ... what's in a name ;=)) And is there any need now to keep config.h-msvc6.in? Or does cygwin somehow need this? I think not ... Also noted - #define ENABLE_AUDIO_SUPPORT 1 has been added, although it had already been defined later in the file, with - #ifndef ENABLE_AUDIO_SUPPORT #define ENABLE_AUDIO_SUPPORT #endif but luckily I had put this define, within an #ifndef so no warning of a 'redefinition' ;=)) Also, since presently every usage in the source uses - #ifdef ENABLE_AUDIO_SUPPORT and NOT #if ENABLE_AUDIO_SUPPORT then the defining of it as equal to 1 does not make sense, but it is no problem either ... Further - #define ENABLE_THREADS 1 has been added, making 'threads' a DEFAULT choice. I had left this out, since it seems it should be a user OPTION, thus added only as a MSVC define, ONLY IF DESIRED BY THE USER ... but, why not? pthreads is a quick easy download, and install ;=() just one MORE thing to do ... Have now had a chance to download, and install 'Express' MSVC8 ... and have been reading all the other posts on this ... I had some initial problems because I had installed and tried earlier Beta versions, but someone in MS has written a nice (unsupported!) clean-up tools ... Still have not got the Platform SDK exactly right ... seems missing GL/glut.h, for example, but on this occasion chose to go the freeglut way ... thus was able to compile FlightGear, using the new projects/VC8 SLN/VCPROJ files, after considerable modification to suit my local environment, mainly folder/directory arrangements ... I did the whole gambit in MSVC8 - PLIB, OpenAL, pthreads, zlib-1.2.3, freeglut, SimGear/source, and FlightGear/source ... all were the latest, circa 4/5 April, CVS updates, except zlib, which comes only in tar.gz form ... ... do not know about MSVC8, since I have yet to BUY, and use this extensively ... There is almost no difference between the express and the professional version. ... For one thing, the express version has NO resource editor ... luckily FlightGear uses none, like most of the dependent projects, so this is not a particular drawback for this project, but would severely inhibit a native WIN32 build ... I wonder what else is 'broken' in the free 'express' version? ... Naturally I used the newly provided VC8/SLN|VCPROJ files, but feel you have just as many 'fix-ups' to be done in these, as with using the DSW/DSP files, and NO automated process to 'fix' them, as they inevitably become 'stale' ... This is no problem while we have an ACTIVE, AVAILABLE and WILLING group of developers using MSVC8, provided they REMEMBER each time a SG/FG Makefile.am is CHANGED, these files will have to be MANUALLY changed in CVS ... While the use of am2dsp.pl has its drawbacks as well, at least it is an 'auto' process ... I am still unsure exactly what 'errors' come from the use of DSW/DSP conversion ... I have had none ... something was said about dependencies, size and compile times ... but no real details ... just implied problems ... FUD factor 7.5? ;=)) Ok, we now have VC8 project files in SimGear and FlightGear, but there are NONE in PLIB, freeglut, pthreads ... those in zlib FAILED to work at all ... so, IMHO, it still seems the DSW/DSP set are the BEST BET for all versions of MSVC, all projects ;=)) I think am2dsp.pl, and its am2dsp.cfg files could be massaged quite a lot, and these would automatically produce a consistent, automatic, functional set of build files, FOR ALL VERSIONS OF MSVC ... given some 'agreed' folder structure ... I have done some of that massaging for myself, but my sense is that some of the MSVC developers do not LIKE this system, so have never tried to put forward the massive improvements that could be done ... Like providing configuration values that advised your exact folder structure, and producing DSW/DSP files to match ... but this also means 'distributing' the actual perl script, and the user having some perl installed to run it ... Like separating the Debug and Release more, like some of what was done recently, etc, etc, etc, ... As you are no doubt aware, MSVC7.1 will NOT accept MSVC8 files, so the most 'compatible' is to provide MSVC6 build files that CAN be used by ALL VERSIONS ... and I really dispute that this 'breaks' some sense of dependency, or significantly 'slows' the compile ... It has always been true that it seemed somewhat senseless to put all the generated object files in separate 'library' folders ... as is done by the Makefile.am system, and this significantly adds to the DSP size, just adding all these folder names ... and the 'new' VC8 files have straightened this out a little ... But even now, again I am puzzled by the
Re: [Flightgear-devel] Aircraft with old JSBSim specs in base package
I'll look into it, maybe i can make those plots for you using a vortex panel method on the profile of the airfoil. I'll keep you posted. Julien
Re: [Flightgear-devel] Re: AP messed up? agl-hold vs. terrain-follow
On Thursday 06 April 2006 10:50, Melchior FRANZ wrote: * Melchior FRANZ -- Wednesday 05 April 2006 07:51: * Lee Elliott -- Tuesday 04 April 2006 22:49: There also seem to be some quirks in the way that the A/P gui handles things - if you already have an A/P mode engaged but didn't set it via the gui it will not be shown as set in the gui and then when you close the gui that setting becomes un-set. That's already fixed in my version of the dialog. Which is now committed. I waited for cvs being tagged for release, because I wasn't sure if it would work well enough already. But it seems to work without problems, so, if a packager wants to include it despite it being in 'instable' CVS/HEAD only ... :-) I also (think I) fixed a bug in gui.nas, that sometimes prevented the autopilot menu entry from getting activated when it should. m. Fixing the behaviour is good work, now all we need from everyone else is a decision on 'agl-hold' vs. 'terrain-follow'. Either is ok to me but as I mentioned, agl-hold is quicker to type while you're testing stuff (although my fingers now 'remember' 'terrain-follow' :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Stalls
Andy Ross wrote: [redirecting to flightgear-devel] If audio is required, then this ought to be tied to turbulence also, or maybe to instantaneous acceleration changes (a delta of more than YYY m/s^2 over the last 0.XX seconds triggers the start of a whump sound). I have been thinking about the audio aspect for a while, though not in the context of stalls. I think that a broader approach of linking certain sounds such as rattles and whumps to various types of changes in acceleration and some calculated vibration property would add a lot of realism. This would buy you sound from turbulence, violent maneuvers, wheel rolling, and wind shear. Unfortunately I have not had a chance to play with the idea yet, but I do have some handwritten notes that I would be willing to share. It would be nice to have a script for all the models to use that would provide a few easy to link to properties for various mechanical sounds. Josh --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
