[Flightgear-devel] RFC: FAQ Additions (LONG!)
I'm trying to roll up another version of the FAQ. Here are the set of questions I intend to add. Comments, and additions, would be most welcome. Why doesn't ATC work? Because it's a non-trivial problem that nobody's got a satisfactory solution to yet. I fall through the deck of the carrier. What am I doing wrong? This is a known problem with 0.9.8 - either use CVS, or await the next stable release. When's the next release? When we have enough stable features -- and the lead developers have enough time -- that we can prepare, test and roll out a set of binaries, all of which takes time. Addendum to the warplane discussion. Some aircraft (the Spitfire, for instance) now support firing guns and dropping bombs, but the munitions don't destroy anything yet. I'm using Cygwin and OpenAL complains. You need to download a special version from (minor policy issue: shouldn't this be on the main ftp servers, given that all cygwin users effectively need the file) I'm using Mingw and all sorts of things complain. FGFS currently won't compile on mingw without some minor changes to various parts of the codebase, only some of which are documented on the wiki. (Will fix when time - gwjr) Why is the documentation so poor/out of date/non-existent? Because writing code and flying is generally more fun than writing down stuff telling other people how to do it. Documentation is an easy area to work on if you want to improve your knowledge of how the system works --- and any help would be much appreciated. Why isn't DRI enabled? Any number of reasons, including what side of bed X got out of that morning. You can send us details, and we'll try to help, but we can't work magic. Why can I fly through buildings, hangars etc? Because we only have ground intersection code, not object intersection code. If you can find a way of fixing this that doesn't hose everybody's performance --- or make flying between buildings impossible --- please do. I can't fly the helicopter! Don't even attempt to do it with auto-coordination -- that way madness lies -- instead, control the rotation manually, using the rudder keys. Do you have X aircraft? Possibly. If we do, you can download it at: www.flightgear.org/downloads/aircraft I can't fly aircraft X! Some of them are hard to fly (especially the fast, unstable fighters). Some of them are suicidal to land unless you have some experience in other aircraft (the B-52, for instance). Some, like the well-loved Cessna, are docile and forgiving, and for that reason, they get used to train pilots. Try one of them, and then move up. Why does my aircraft veer to the left during takeoff? This is due to various forces, collectively --- and incorrectly --- labelled `torque'. Some of it is due to propeller wash on the vertical tail, and other factors. The extent to which this is correctly modelled is a matter of some debate amongst those with General Aviation experience. Apply rudder during the takeoff roll to counteract this effect. Giles Robertson PS: This would be an excellent message to practice the partial-quoting skills that Melchior gets so excited about. It's far too long already (many apologies). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: gear/flaps handling (b29, hurricane, ...)
> BEFORE: > >kbd binding--\ > |> property >js binding---/ > > > NOW (and since a while for flaps and many others): > >kbd binding\ >controls.gearDown()---> property >js binding-/ If this were extended to all controls, then it could be used as an abstraction for key bindings, which would allow us to deal with the kb localisation issues that were mentioned earlier this month. It might, then, be a good idea to have a couple of planespecific() functions, that each plane could use for weird things that other plane's don't have (Spitfire starter cartridges, for instance), but keep a sane kb layout between aircraft. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Lights was: Shadows
> But I work on it and now I have runway lights, landing lights, relief > mapping , DXT compression and another cool stuff that work on fragment and > vertex program Where can one download the code? Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
> For Cygwin users, OpenAL needs to be retrieved from this site: > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz > > I placed this file in the /usr directory and untar'ed it, though some > place it in the > /usr/local/ directory tree - which might be more appropriate. Some library > and dll files > are untar'ed into your bin/ and lib/ subdirectories. > > Once the files are untar'ed, you must cd to the include/AL/ subdirectory > and modify all > the files where "_WIN32" is present (use grep) and change it to simply > "WIN32" (that is, > remove the underscore). Also, in alc.h you must change the code at top to > look like this: > > #ifdef WIN32 <<<<<<<<--- CHANGE TO THIS > #ifdef _OPENAL32LIB > #define ALCAPI __declspec(dllexport) > #else > #define ALCAPI __declspec(dllimport) > #endif > > #ifdef WIN32 <<<<<<<<--- CHANGE TO THIS > typedef struct ALCdevice_struct ALCdevice; > typedef struct ALCcontext_struct ALCcontext; > #endif > > Once these changes are made, you should be able to compile simgear. > I'm just in the middle of finally pulling an faq update together (various exams cropped up). I'll put this in. Are there any other issues people want to go in? Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 2.37
> %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;C:\;C:\WINDOWS\system32;C:\YAFRAY_DIR;C:\Python24 You should not include both %SystemRoot% and C:\WINDOWS paths. %SystemRoot% will be defined to the correct place on all NT-based systems (I don't know about 3.1/95/98/ME); however, if, for any reason your systemroot is not C:\WINDOWS (as it might be if you have 2000 and XP installed, and are booting into 2000), you could be calling up system applications for the wrong windows version (but only if they don't exist in %systemroot%). The mantra used to be that "a short path is a fast path", but I think that consideration is probably now irrelevant. My practice is to have a path that looks like this: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;%userpath%; and to define everything else in a separate variable, %userpath%. However, there's no reason to do that except for greater aesthetics. Giles Robertson <>___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problems with todays CVS
See the same thing with CVS at KSFO this morning (but thought it was a local problem). Higher logging levels produce our well-known and well-loved "no scenery below the aircraft" ground cache message. Giles Robertson > I've just updated and built todays CVS code, discovered a problem. > Starting on runway 09 at EGNM with the default cessna the sim freezes a > couple of seconds after the aircraft starts rolling. I don't think it's <>___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FGFS final link fails: _imp__pthread symbols not found
I've tried compiling fgfs from cvs on mingw again. There are various little changes which I'll roll up at some point (as in, when it's working ;). However, there's an odd problem I'm getting at final link: g++ -DPKGLIBDIR=\"/point/share/FlightGear\" -g -O2 -D_REENTRANT -L/point/lib -o fgfs.exe bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_i n/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../.. /src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../s rc/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src /FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FD M/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/l ibSPFDM.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/In put/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/li bModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src /Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScri pting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/R eplay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../ src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 -lALut -lopenal32 -lws2_32 -lwinmm -ldsound -ldxguid -lole32 Warning: .drectve `-defaultlib:uuid.lib ' unrecognized Warning: .drectve `-defaultlib:uuid.lib ' unrecognized ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb7a): In function `ZN9FGTileMgr16all_queues_emptyEv': C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:232: undefined reference to `_imp__pthread_mutex_lock' ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb9e):C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:238: undefined reference to `_imp__pthread_mutex_unlock' This continues for many screens (and for many other calls - it's not just mutex related). The error is the same whether or not I add -lpthread to the command. Investigating the pthread library, all the calls are present in the form _pthread (_pthread_mutex_lock, _pthread_mutex_unlock, _pthread_cond_destroy etc), but none with the _imp_ prefix. gcc 3.4.2 (mingw-special) with win32 thread model. Does anybody have any ideas about what is going wrong? Giles Robertson PS: Apologies for the html email. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Recalcitrant Marker Beacons
On FGFS 0.9.8a (Win32 Release), marker beacons play when sound is disabled. Can anybody see this on other platforms? Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] today's 3d clouds commit
On a mildly unrelated note, if you fly in fgfs in the Highveld using the default cloud layers, you take off almost straight into cloud. While the default cloud is great for KSFO, it breaks down for airports at higher altitudes; perhaps a cloudbase relative to starting ground altitude would be better? Giles Robertson > Oh yes. For those of you not living here, the Highveld region of South > Africa is home to the most terrifying thunderstorms on the planet. My > house was struck once while I was hastily trying to end a phone > conversation and thrown across the room. Lightning here regularly zaps > all manner of things including trees, golf greens and good-sized chunks > of concrete buildings. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 3d city
>there is afunction of importng 3d models into sceneries. is it possible to >add a full city lets say NY; modeled in 3d primatives and covered by a >textures. what type of graphics card we need? The graphics card required would need to be quite heavyweight, though lod would help a lot. The major problem is modelling the city anyway; if you are prepared to model NY accurately, then feel free - but be aware of the size of the task, and if you already have the data, tell us where it is :) Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] GLUT dependencies ?
> I was under the impression that GLUT dependencies had been removed. > It's not that I want to blame anyone, I'm just a bit surprised to > realize that there actually _are_ dependencies - like this one: Glutless builds only work on fgfs itself; the tests and paraphernalia haven't been ported. If you want to build glutless, cd src before make. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Command Window
> When I run flightgear 9.8 nothing is written to the command window. Is there > something I have to do to get this to > > happen? Try --log-level=info and see what happens. Questions like this are probably better asked on the users list (flightgear-users@flightgear.org). Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Compiling Flightgear 0.9 from CVS on Mac OS X
> g++ -g -O2 -D_REENTRANT -L/FlightGear/lib -o test-up test-up.o > -lsgmath -lsgxml -lsgmisc -lsgdebug -lsgstructure -lsgtiming > -lplibsg -lplibul -lz > ld: can't locate file for: -lsgmath > make[1]: *** [test-up] Error 1 > make: *** [all-recursive] Error 1 That's failed to find the first SimGear library. Check that you installed (make install) SimGear after you built it, and that ./configure has detected the directory where it's installed. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Camera/FOV/View Frustum question.
> world seen through extreme overzoom (i.e. you only get a tiny, itsy, > bitty bit of the outside world expanded to fill the screen.) This isn't the same problem - and won't help you - but does anyone else see visual corruption when loading up view 0 for the first time, that clears when you reset the system, but not before? I see a view where every polygon has been drawn with at least one corner at a vanishing point in the centre of the screen - I've not been able to trace the source, but the error occurs on both MingW and MSVCC binaries, and it makes me wonder what view 0 actually does? Giles Robertson (ATI 9700/Win XP) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Instrument headaches
> 1. Display total energy (using some maths I haven't figured > out yet) How precise is this energy going to be? Working out gravitational and kinetic energy is trivial; accounting for energy in the fuel not hard - but I don't think you'll be able to account for elastic energy stored in the airframe. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Speedbrakes / Spoilers
> Can't remember if the speedbrakes actually slow the aircraft on the > 737 but the animation should work when you hit Ctrl-B The animation works, but has no noticeable affect on airspeed or attitude for all airspeeds I tested. Energy analysis of a log file didn't show any more energy dumped, either. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] SimGear CVS errors
> *** 258,264
> case "${host}" in
> *-*-cygwin* | *-*-mingw32*)
> dnl CygWin under Windoze.
> !
> AC_SEARCH_LIBS(alGenBuffers, openal32)
> AC_SEARCH_LIBS(alutInit, [ openal32 ALut ] )
> LIBS="$LIBS -lwinmm -ldsound -ldxguid -lole32"
> --- 258,265
> case "${host}" in
> *-*-cygwin* | *-*-mingw32*)
> dnl CygWin under Windoze.
> ! INCLUDES="$INCLUDES -I/usr/local/include"
> ! LIBS="$LIBS -L/usr/local/lib"
> AC_SEARCH_LIBS(alGenBuffers, openal32)
> AC_SEARCH_LIBS(alutInit, [ openal32 ALut ] )
> LIBS="$LIBS -lwinmm -ldsound -ldxguid -lole32"
In case anyone's interested, I have at times had to add -lwsock32 to
LIBS to get some compiles working under mingw (with network programs).
I forget if that's currently the case for FlightGear.
Giles Robertson
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] v1.0 musings (was: Aircraft included in basepackage)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've tried introducing a few friends to Flightgear. They are mostly Windows users, technically competent but not adept, who have had experience of video games and possibly other flight simulators. I thought I'd muse a bit on the following points, because, given the user base, it might be instructive. 1) Fgrun/fgfs. For the average windows user, this is *highly* counterintuitive. In so far as Windows has an overarching user interface and tool design philosophy, it's integration. The concept of a GUI that launches the program doesn't make sense to them; they expect to be able to run flightgear, and for it to present a menu that reads something like "New flight"/"Saved Flight"/"Options"/"Exit". I'm not saying this is the way we should go, but I'd like to note that many users, when presented with the current method, get *very* confused, especially by the absence of a flight planner. Many also find restarting FlightGear in order to change aircraft counterintuitive 2) Performance If Windows users come to FlightGear from most video games, the performance they get is not what they expect. I think that when you've been using FlightGear for some time, you can become desensitised to the lower frame rates; newer users aren't expecting this, and responses I've got range from "even so, it's flyable", through "this frame rate is ", to complaints that it hurts their eyes. 3) ATC/AI This may just be my group of friends :P, but many of them find it much more fun and interesting if there are other aircraft in the world, and if they can communicate with ATC. Durk's work in this area is making this easier, but ATC itself can still feel quite primitive. Coupled with this, people expect to start on the apron if it's there, and then to taxi out to the runway of their choice. Finally, some other shorter things that people seem to want: * Ability to save flights * Explanation about p-factor and torque. Once I tell them that it's semi-realistic modelling, they are fine with it, but until then, it can be confusing * [Bug] FGFS seems to revert to KSFO if it can't find the selected runway at the selected airport. When you've expected to load EGLL, finding yourself in California is unexpected, to say the least (this seems to happen more often to fgrun users Giles Robertson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkHv7ycACgkQrI0r/XDZkDC2SgCdGDIJHZ/zNy3OOcGLl+JggqL0 QZAAmgMT/MXe4sqrz/4sbMcmpSthdzPf =CpX9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Aircraft downloads
Can we ensure that the glider model that fgfs falls back to in the absence of another 3d model makes it in? I don't relish a set of complaints about missing glider.ac. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SG0.9.8-pre1 Mingw fix
Can someone apply the following diff on simgear/sound/soundmgr_openal.cxx: 45,47d44 < #if defined(__MINGW32__) < #define isnan(x) _isnan(x) < #endif 63a61,63 > #if defined(__MINGW32__) > #define isnan(x) _isnan(x) > #endif This shifts the isnan definition after the other includes, so isnan isn't undefined, and allows SimGear to compile clean with MingW/MSYS. Many thanks, Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Tracking camera
The tower camera tracks the fdm-controlled a/c, so poking around there might help you point it at some other object; you might need to muck around with the zoom so you could always see the a/c, though, which, AFAIK, the tower view won't do. Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Aircraft directory structure
That's much neater than what I suggested. How many of these variables do we need so that the directory for the a/c does not have to be a subdirectory of $FG_ROOT? Giles Robertson -Original Message- From: Boris Koenig [mailto:[EMAIL PROTECTED] Sent: 22 November 2004 21:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aircraft directory structure Curtis L. Olson wrote: > However, as things stand right now. We have oodles of references to > stuff as "../../../Instruments/hsi.xml" etc. If we move an aircraft one > directory level deeper (or more) all those relative references break. :-( Well, this is then about relative paths, it could probably already be solved if one added support for standard paths such as $FG_ROOT. Which could mean that the path becomes: $FG_ROOT/Aircraft/Instruments/hsi.xml I think it would take 5 minutes to add support for -automatically defined- environment variables such as: - $FG_AIRCRAFT - $FG_INSTRUMENTS These could all be based on a properly set $FG_ROOT, that way one could simply refer to: "$FG_AIRCRAFTS/c172/c172-set.xml" or "$FG_INSTRUMENTS/hsi.xml" Dealing with such path specifications would mainly come down to looking for an initial '$' sign and stripping of everything behind the first slash in order to determine the real path. > I'm calling for someone to take on the task of making aircraft more > relocatable. If you are mainly thinking about the above problem and my suggestion for a solution is already sufficient, I wouldn't mind to send Erik a corresponding patch. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Aircraft directory structure
Two points: 1) Relative vs. Absolute links. Relative links makes it tricky, to say the least, to shift a/c around (though I think I have a relative --> absolute python function kicking around somewhere; it's not hard). I can recall some dislike of absolute links. In some ways, a resource-identifier system might be a good idea (and this kind of fits with the XML philosophy), along with a central table (also in XML) that looked something like this: Resource ID Filename yazzascope-3d \instruments\yazzascope-3d-set.xml 2) Organising aircraft The categories you describe aren't exclusive - without some seriously weird symlinking, an a/c can't be a member of Boeing, and of 2-engines, and of Bizjet. (And if you symlinked for this result, Windows users might have difficulties) On a slightly more theoretical note, I would have thought that these non-exclusive categories don't need to be the subject of directories. As a developer, one pokes about the \Aircraft directory a lot. As a user, one very rarely does. What the user wants is to be able to say "gimme a list of a/c that are 2-engined Boeing passenger jets", and it produces it. That could also be the subject of a table/database - and keeping all a/c immediately under \Aircraft should make addition and removal of aircraft easier (what happens in a simple untar system, for instance, if we change the classification of, say, the 737 from Boeing to 2-engined, and the user untars an update - bingo, he has two versions of the 737 --- keeping track of this over time could be difficult) It's your two cents now. Giles Robertson -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Sent: 22 November 2004 21:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aircraft directory structure Jon S Berndt wrote: > From a JSBSim FDM point of view, I've been giving this some thought > with respect to standalone JSBSim, as well. There ought to be more > flexibility in this system. We have aircraft, engines, control > systems, etc. files. Some of them we might tend to want to be > interchangeable - that is, allow use of an engine with several > aircraft. The idea is to preclude the need to have an engine defined > in each aircraft subdirectory and just have one engine "corral" (sorry > - remember, I'm from Texas ;-) However, I am beginning to warm to the > idea of having one location where an aircraft could be found, and > under that - or even inside that directory - the engine itself could > be found, as well as other required files. The engine files > specifically are small enough so they could be duplicated with hardly > a storage impact at all. > > Ideally, the "controlling program" (either the JSBSim.cpp wrapper for > standalone operation, the Flightgear FDM interface class in the case > of integrated operation, etc...) would pass along or specify the > directory to search and the aircraft file name. We really don't care > where we get the aircraft file name from - we just need the file name > (and path). Right now, I think we are trying to be too rigid in > specifying where files are to be found. I don't think we need to kill ourselves trying to be overly flexible. I think it's worth having a central repository of commonly used items (engines, instruments, etc.) An aircraft could refer to a standard item, or could refer to a specific item in it's own directory. I don't think we would need to go overboard on recursive directory searches to hunt for stuff. However, as things stand right now. We have oodles of references to stuff as "../../../Instruments/hsi.xml" etc. If we move an aircraft one directory level deeper (or more) all those relative references break. :-( I'm calling for someone to take on the task of making aircraft more relocatable. If someone wants to make a family of aircraft varients and share parts ... I think it's ok to make them all live as siblings to a single parent directory, but right now everything is hardwired so every aircraft must be a child of the Aircraft subdirectory. We can't make up organization aircraft directories (i.e. Single-Engine, WWII, Boeing, Cargo, Biz-jet, etc.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Switching from 2D panel -> 3D panel ->2Dpanel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)
I think that's a result of the standard problem that if you move the view with the mouse in 2d panel mode, you can't see the panel, and it can be very difficult to get back to the original location; resetting resets the viewpoints back to normal, and the panel reappears. Do you get any actual graphical corruption (which is what I get - all triangles seem to be drawn to infinity - everything comes from a point at the centre of the screen) Giles Robertson -Original Message- From: Boris Koenig [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 14:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Switching from 2D panel -> 3D panel ->2Dpanel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI) Giles Robertson wrote: > This is probably unrelated, but with the 0.9.6 win32 binaries, if you > start up with a large FOV (?>90), then until you reset, 3d-cockpits are > unusable. I can confirm something that seems related: if I switch from 2D panel mode to 3D panel mode and use the mouse to change the perspective, I don't seem to be able to switch back to the 2D panel mode without having to reset the current 'situation' - tried it with different panels, seems to be a common problem. Can anybody else confirm that ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
This is probably unrelated, but with the 0.9.6 win32 binaries, if you start up with a large FOV (?>90), then until you reset, 3d-cockpits are unusable. Giles Robertson -Original Message- From: Martin Spott [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 09:29 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI Melchior FRANZ wrote: > It isn't anywhere in the scenery yet -- just in cvs. You have to add > it yourself, or replace the saratoga with it. I added this in file > $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: > > OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear on Mac OS X
I've found on some pseudo-POSIX Windows systems that the build only finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be what it takes; and it may be similar on OS X. The other tactic is to specify --prefix=/fg or some other value for every compile; PLIB, SimGear, FGFS. My 2 cents. Giles Robertson -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Sent: 10 November 2004 18:59 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X Arthur Wiebe wrote: >Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB >straight from CVS 2004-11-08. > >Looking in /usr/include/plib and /usr/lib/ it looks like plib is installed. > >The only problem I now have is when trying to configure simgear from >CVS (same date) I get: > >checking plib/ul.h usability... no >checking plib/ul.h presence... yes >configure: WARNING: plib/ul.h: present but cannot be compiled >configure: WARNING: plib/ul.h: check for missing prerequisite headers? >configure: WARNING: plib/ul.h: see the Autoconf documentation >configure: WARNING: plib/ul.h: section "Present But Cannot Be Compiled" >configure: WARNING: plib/ul.h: proceeding with the preprocessor's result >configure: WARNING: plib/ul.h: in the future, the compiler will take precedence >configure: WARNING: ## -- ## >configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >configure: WARNING: ## -- ## >checking for plib/ul.h... yes >checking for plib 1.6.0 or newer... wrong version >configure: error: Install plib 1.6.0 or later first... > >That has to mean something. > >I tried changing the version in ul.h but that didn't help :). Could >you send me your compiled files (from /usr/lib/libplibXXX and >/usr/include/plib) and see if if that works? I would love to make an >installer package for Mac OS X which would install plib for other OSX >users without having to compile it. > > The details of the configure script failure can be found in the config.log file. That may shed some light on exactly what is going wrong. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Legal file references in aircraft definitions
I'm trying to write a script to determine the interdependencies of aircraft, as a start on trying to figure out a way of splitting the aircraft into different packages. I'm dealing with searching through the files in the \Aircraft\ subdir for references to other files, and while I could take each token that could be a filename and check it against the list of filenames, I'd rather only take those that are filenames, so I'm wondering how another file can legitimately be included. ATM, I've found three places: In a environment In a environment As an "include=" argument to an tag Does anybody know of any others? Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with windows FlightGear v0.9.6
Can you run fgfs with log level "debug" set, and report the results? (Advanced > Debugging in the launcher) Giles Robertson -Original Message- From: Christian Mayer [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 16:33 To: FGFS Subject: [Flightgear-devel] Problem with windows FlightGear v0.9.6 Hi, I've downloaded FGFS (fgsetup-0.9.6.exe) and installed it. When I run it, I see the splash screen and hear the peeping sound - and then the program stops with that error message: Fatal error: Failed to gen source. (received from ) Are there any hints of what I should do? Thanks, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] ATC Network Test
DevC++ has some problems; last time I tried, you couldn't build FGFS on it because of the number of files in the final link; (it can't process the command line - too long). Giles Robertson -Original Message- From: Boris Koenig [mailto:[EMAIL PROTECTED] Sent: 05 October 2004 13:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] ATC Network Test James Turner wrote: > > On 4 Oct 2004, at 19:17, John Wojnaroski wrote: > >> >> A few details... >> >> Volunteers will get a package of software that contains the TNL >> libraries and a basic set of software to connect to the ATC net as a >> controller or pilot. Package will include ALL source code and make >> files for a Linux system. Sorry, I'm just not an MS type. However, it >> will build under Cygwin. >> > > I'm happy to test, and probably even get the code building on OS-X, > since it should be very close to working already. That would be really nice, actually I offered yesterday to make it compile under Win32 - but I didn't have MSVC in mind, but rather I was thinking of using MingW32 (Dev C++) - I am not sure how many people are actually using it here, so if there's anybody here who could assist making it compile natively under MS VC it would be appreciated. John told me yesterday he would be about to downstrip the package, so all volunteers who can help make it compile on a different platform should inform him, so that the makefiles/sources can be modified accordingly. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] A voice for FG
Beware being like Sony. Invent a new protocol that is better and more efficient and flexible, and still nobody will use it, though, on the other hand, nobody uses Sony's protocols (ATRAC-3, Betamax), because they are eyeballed with patents. Giles Robertson -Original Message- From: Arnt Karlsen [mailto:[EMAIL PROTECTED] Sent: 23 September 2004 23:04 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] A voice for FG On Thu, 23 Sep 2004 21:56:50 +0200, Boris wrote in message <[EMAIL PROTECTED]>: > And there are many more hits regarding the IVAO vs. VATSIM debate. > > Personally, I consider this ridiculous: combining their efforts and > creating ONE BIG network would benefit EVERYBODY - everything would > be perfect if they could also initiate opensource development of a > COMMON protocol that is NOT specific to a particular OS or even > flight simulator ... ..what happens if _we_ define that common protocol? ;-) "FlightGear ATC Protocol"? (Or is it a SimGear job?) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Fw: Voice stuff (sans attached)
http://homepages.westminster.org.uk/giles.robertson/fgfsvoice.htm Giles Robertson -Original Message- From: Arnt Karlsen [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 18:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Fw: Voice stuff (sans attached) On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message <[EMAIL PROTECTED]>: > FYI > > if anyone wants the files (about 200k) give a holler ..yhooo! ;-) > you can run the whole mess on a single machine along with FG. The hit > to the frame rate is TBD. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
The Stetson is being spun, so there's actually a twisting effect there as well. Giles Robertson -Original Message- From: Gene Buckle [mailto:[EMAIL PROTECTED] Sent: 19 September 2004 22:42 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Problem with ballistic sub-model > > Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a > booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do > that. > I love it. You can have a special parameter for it: slim_pickens=1. :) G -- "I'm not crazy, I'm plausibly off-nominal!" Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
> ..quite right, some of this is caused by the turbulence, some of it by > the bomb release mechanism letting go of the bomb. Also, there are > those refreshingly wild stories of guys having to enter the bomb bay > to kick out bombs riding that turbulent airflow. ;-) Can we model the Dr. Strangelove effect? Giles ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal'ing ...
Another possible issue with displaying ATC messages as dialogues is that, as far as I am aware, input bindings don't change; a mouse-controlled sim must pause and the esc key brings up the exit FGFS dialogue, rather than cancelling out of the current window. For the uninitiated, this can be extremely odd; the escape key is used in an attempt to cancel the dialogue, which brings up another dialogue. Because it's a reflexive key to remove unwanted dialogues, repeat until 5 exit FlightGear dialogues have displayed; by the time you've cleared them all your plane is probably either confusing ATC or confusing Search and Rescue. Giles Robertson -Original Message- From: David Luff [mailto:[EMAIL PROTECTED] Sent: 13 September 2004 13:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal'ing ... On 9/13/04 at 10:16 AM Boris Koenig wrote: >Hi ! > >Two things: > >1) I would like to be able to display a simple text string at > runtime in the upper left corner of the screen using > Nasal (in order to display simple in-flight information). > > I could imagine that something like this already exists, i.e. > for displaying ATIS or traffic information during flight, is > there a specific node within the property tree available to > set such a "message" item dynamically so that's then displayed > automatically ? > No, the ATIS and ATC messages are displayed by FGATCDisplay, in src/ATC/ATCdisplay.[ch]xx. This is fairly cludgy code, liable to change on my whim (since currently no-one else uses it), and more importantly, only available if ATC is enabled. It is run by calling 'conventional' class functions, not by setting property tree values. > That way one could easily use Nasal to display runtime info, > one could also use such a feature to indicate things like that > the game's been paused (which is currently not being displayed) Norman did use exactly this (the atc display) to display a 'sim is paused' message once IIRC, but that got removed I think. I guess if you wanted something to get you going for now you could easily write a command binding to the ATC display and hence use it with Nasal, but I wouldn't rely on it in the long term. I was considering displaying ATC messages in pui dialogs, but am not sure if they can be kept on-top persistantly without blocking user input to the rest of FlightGear. The current code can be very hard to read depending on the colour of the background, although I suppose an arbitrary background colour could be drawn behind the text. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] next release - ac that don't work
Automatic gearboxes fail too often on the road, without much warning, for me to want one in a chopper. At least if a fixed wing engine fails you can attempt to glide. Giles Robertson -Original Message- From: Ampere K. Hardraade [mailto:[EMAIL PROTECTED] Sent: 12 September 2004 23:15 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] next release - ac that don't work Not if the helicopter uses an automatic transmission. =P Ampere On September 12, 2004 12:35 pm, Martin Spott wrote: > BTW, isn't this totally irrealistic ? I've never seen a helicopter > clutching the rotor with engines at full speed - I assume this would > break the whole transmission at once ! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear logged its first real flight!
You might like to look into screen-grabbing programs; some of them are used for circumventing DVD protection; they aren't illegal in France yet. Giles Robertson -Original Message- From: Olivier Soussiel [mailto:[EMAIL PROTECTED] Sent: 11 September 2004 15:13 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Re: FlightGear logged its first real flight! > > By the way, how did you made a movie out of Flight Gear playback? > I've not done it yet. I'll read GPS data recorded during the real flight and send them to FG. Then I will vdo tape my PC screen. Olivier ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway distance remainingsigns+placementscript "done".
I'm aware that when ballooning, it is always preferable to land in sheep, rather than cows; cows are intensely curious, and so, although when the balloon lands, they scatter, after the envelope is deflated, they will approach and start trampling on it, and licking it with sandpaper-like tongues. The sheep just stay well away. :) -Original Message- From: Arnt Karlsen [mailto:[EMAIL PROTECTED] Sent: 09 September 2004 12:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Runway distance remainingsigns+placementscript "done". On Thu, 9 Sep 2004 06:40:53 -0400, David wrote in message <[EMAIL PROTECTED]>: > One thing we could add, at least for my part of the world, are > animated groundhogs all over the airport -- also flocks of birds near > the threshold. I also heard a story recently of cows eating the > fabric covering of a tube-and-rag airplane. ...that kinda realism might haven an impact on both the 3d model and the fdm's. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway distance remaining signs +placementscript "done".
Would adding in ILS/glidescope aerials (where they exist; that's easily checkable off Robin's database) count as too much clutter? Giles Robertson -Original Message- From: Gene Buckle [mailto:[EMAIL PROTECTED] Sent: 08 September 2004 22:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Runway distance remaining signs +placementscript "done". > life, we should aim to include them in FlightGear. First, however, we > need to start toning things down a bit. > > I take it this means no FOD sweeping gnomes? Drat. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] A method for getting funds...
Nothing stops you selling the items under a second, more restrictive license, and charging for it. Except that only an idiot would buy it; but they might not think to look for the model in FlightGear (so they'd just be misinformed, not an idiot). I think, though that that's sailing too close to the wind of dishonesty; although we wouldn't lie, we would be selectively truthful about what we were selling. My own take on funding for FlightGear is that funding FGFS itself may be difficult, but we might well be able to get corporate funding for developing SimGear as a simulation kernel. Flight Simulators don't appeal to a huge sector of the market; but an architecture on which you can build any simulation you want sounds much more attractive and useful. The likely return on a wider project could be much greater than that simply on a flight simulator. Giles Robertson -Original Message- From: Erik Hofman [mailto:[EMAIL PROTECTED] Sent: Wed 11/08/2004 10:23 To: FlightGear developers discussions Cc: Subject: Re: [Flightgear-devel] A method for getting funds... Ampere K. Hardraade wrote: > Ever thought of selling art works that are used in FlightGear at very low > price? > > http://www.turbosquid.com/ I don't think that would work because we have to make absolutely sure that the sold items are used in GPL'ed work only. Most buyers will assume they own the item and start using it in every way they can think of. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d <>___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] lwsock32
This should have a mind-blowingly easy solution, but I can't find it anywhere. With most programs that use plib's netsocket.cxx, under MingW, the wsock32 library has to be included, or you get undefined errors. How do I include it at configure (or even make) time? I've tried all sorts of mucking around with LDFLAGS (LDFLAGS="$LDFLAGS -lwsock32" etc), but to no avail. The only workaround I have at present is manually editing makefile.in in every directory where the problem occurs, which isn't exactly elegant. (I think this is a problem with PLIB, not FlightGear, but I need to work out how to patch it before submitting a patch) Giles Robertson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: default weather
I've never heard of Lee's problems, but I think it's a good idea to keep the high-level clouds because they prove that we can do them, and they make the sky look vaguely realistic (how often do you get clear skies in San Fransisco? Simply off the geography, I'd guess not too frequently, but I've never been within 5000 miles, so I don't know) Giles Robertson -Original Message- From: Lee Elliott [mailto:[EMAIL PROTECTED] Sent: 15 June 2004 20:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] RFD: default weather On Tuesday 15 June 2004 19:55, Curtis L. Olson wrote: > We currently have the ability to sync with real METAR weather reports as > we fly. > > I would like to propose that we set the default weather to zero winds, > zero turbulence, and maybe (?) zero clouds. > > Those that want interesting weather by default can use the METAR > fetching feature, and those that are trying out FG for the first time > will have fewer surprises. What do you think? > > Curt. I mentioned once that I was seeing some strange jumps in the wind and visibility when I take off (from near 0ft alt airfields) and not using METAR weather - I wonder if some of the problems that some newbies experience might also be due to this. For example, sometimes I'm getting 6kt winds at ground level, when they should be 3kt and then quite often they're up to 30kt by the time I'm up to around 800ft agl. It doesn't seem to happen consistently but I'd guess it occurs about 50% of the time. Re-applying the weather settings via the gui will eventually sort it out but frequently, after re-applying the settings by clicking the 'Apply' button, and then clicking 'OK', the weather reverts back to the incorrect settings. Sometime clicking the 'Apply' button has no immediate effect and I have to click it many times before a change occurs and even then, it's not always to the correct settings. Just to confirm, I've been checking the settings in /environment via the property browser and I can see there that the settings are incorrect. If this were to occur to a newbie I can easily imagine them having trouble keeping the C-172 level as they transition from 6kt winds in one direction to 30kt winds from a different direction, and when it does occur the transition is pretty sharp. Apart from some modifications to the visibility ranges I'm using the current default weather settings. I haven't tried zeroing all the settings yet, to see what effect that would have. Re the clouds, I think it would be a good idea to keep the high-level cirrus - that's unlikely to cause any problems with a first time user and does break up the sky a bit. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: FlightGear runs cleanly on AMD64 in 64bitmode
How long does FG take to compile with that spec? Giles Robertson [EMAIL PROTECTED] -Original Message- From: Alex Perry [mailto:[EMAIL PROTECTED] Sent: 13 June 2004 21:29 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: FlightGear runs cleanly on AMD64 in 64bitmode > > Alex Perry wrote: > > > The framerate was just over 1fps, but that's because the laptop has > > > the ATI 9600 chipset so I have to choose between the unaccelerated > > > open source driver or the 32-bit only accelerated closed source >From Arnt Karlsen <[EMAIL PROTECTED]>: > ..which laptop and which X? e-Machines M6805 The next up model in the series is the M6807 with a better optical drive. They now have a M6809 which has a 3200+ processor instead of a 3000+. Xfree86 version 4.3.0.1 on both the 32-bit and the 64-bit chroots. > How does 32- and 64-bit glxgears compare, > native screen (no resizing), 32-bit ATI driver, kernelmod, userspace: 1833 fps 32-bit ATI driver, no krnmod, userspace: 93 fps 32-bit ATI driver with 64-bit userspace: 96 fps 64-bit Open Source driver and userspace: 720 fps > full screen and "same as FG"? 32-bit ATI driver, kernelmod, userspace: 174 fps 32-bit ATI driver, no krnmod, userspace: 8.0 fps 32-bit ATI driver with 64-bit userspace: 8.5 fps 64-bit Open Source driver and userspace: 148 fps > > > driver from ATI. I used the accelerated driver, running in a chroot > > > on a biarch kernel, but ATI's kernel module doesn't compile for > > > 64-bit so I couldn't use it. > ..does ATI know? I put a note on their support site requesting a 64 bit clean "fglrx". The numbers above show why the lack of that kernel module matters. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Scenery - a few notes
I get much the same messages, except I think I'm running the new scenery - I don't recall a tower or windsock at KHAF before. Weirdly, I get these messages whatever aircraft I seem to use. I'd normally expect it to only give the stabiliser not found error on particular models, but it seems to be inherent. I haven't checked on every a/c, though. (compiled in Msys/Mingw on a PIII with WinXP and Intel 830m graphics card) Giles Robertson [EMAIL PROTECTED] -Original Message- From: Jacek [mailto:[EMAIL PROTECTED] Sent: 08 June 2004 22:18 To: FlightGear developers discussions Subject: [Flightgear-devel] New Scenery - a few notes Hi, I've got by cvs fg data today. My fg compiled from cvs a few days ago doesn't see the new scenery. So I've just done a new compilation from cvs. At first it gave: bash-2.05b$ fgfs Initializing OpenAL sound manager WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgSGIHeader::: Failed to open '/usr/share/FlightGear/Aircraft/MD11/Models/cockpit/GS.RGB' for reading. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgSGIHeader::: Failed to open '/usr/share/FlightGear/Aircraft/MD11/Models/cockpit/PANELBG.RGB' for reading. WARNING: ssgLoad3ds: Texture coords missing. Object Stabilizer01 not found Object Stabilizer03 not found Failed to find KSQL in basic.dat.gz Failed to find KSQL in basic.dat.gz I renamed GS.RGB -> gs.rgb and PANELBG.RGB -> panelbg.rgb. It helped but I still can see now: WARNING: ssgLoad3ds: Texture coords missing. Object Stabilizer01 not found Object Stabilizer03 not found Failed to find KSQL in basic.dat.gz As usually Impressed by Your work, Jacek. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] keyboard mapping
> I see it a real pilot has to let go of something to twiddle a dial
anyway, > we shouldn't complain if we have to as well.
A real pilot can keep one hand on the yoke and twiddle a dial with
another. He or she may also have a copilot. I use mouse control as I'm
without a joystick, and having either to pause the sim to drop the gear,
or to lose control at end of final, doesn't sound like a recipe for
happy landings. Not that my landings are happy anyway ;)
Giles Robertson
[EMAIL PROTECTED]
-Original Message-
From: Josh Babcock [mailto:[EMAIL PROTECTED]
Sent: 27 May 2004 21:21
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] keyboard mapping
Lee Elliott wrote:
> On Thursday 27 May 2004 20:18, Andy Ross wrote:
>
>>Josh Babcock wrote:
>>
>>>So maybe airplanes shouldn't be in the interface business. Maybe we
>>>should spend our energy agreeing on property conventions and Nasal
>>>scripts.
>>
>>Even better would be to take a big audit of all the existing bindings
>>and re-assign them from scratch. We've accumulated all sorts of
>>inconsistencies and usability glitches over the years. Here's one
>>
>>right here:
>>
>>>aTailhook down
>>>ATailhook up
>>>LToggle slats
>>
>>IMHO, we want to adhere to *either* the traditional toggle convention
>>*or* the no-shift-means-down/shift-means-up idea. Using a combination
>>in the default mappings is confusing. Likewise, we have other
>>bindings (magnetos, flaps) that use yet another convention ("key
>>pair") to indicate increase/decrease.
>>
>>I'm sure this will generate a good viscious flame war, but IMHO it
>>ought to be done sooner rather than later. We're starting to attract
>>real newbies, and they are already having a hard time with our default
>>interface.
>>
>>And while we're at it, we need to do the same thing for the joystick
>>bindings. I bought a new stick recently to replace my X45 (a Logitech
>>Extreme Digital 3D) and discovered that our default bindings for it
>>are absolutely nothing like the ones for the X45. It does "snap view"
>>with the hat instead of panning, for instance.
>>
>>
>>>Lastly, while we're at it, get rid of any key bindings define in the
>>>code and put the mappings in keyboard.xml.
>>
>>This is done already. There are no more hard-coded key bindings in
>>the C++ code. Outside of bindings done for aircraft, everything is
>>in keyboard.xml.
>>
>>Andy
>
>
> I hope there's no flame war over this - it's too important.
>
> Part of the problem with coming up with a good keyboard mapping scheme
is that
> a comprehensive survey of the requirements needs to be done before
anything
> can be planned e.g. are slats simply toggleable (erk!) or do they need
to be
> stepped up/down? (I guess this particular example could be
accommodated via
> Nasal, as used for the flap indents - I've already done this for the
B-52F,
> which only has two flap positions, so essentially they're being
toggled)
>
> Perhaps a wiki could help to gather the information, then many people
could
> enter the requirements they know about and it would avoid having to
make a
> single person responsible for finding everything out and possibly
missing
> something, which would lead to a flawed solution.
>
> Then there could also be an issue with some keyboard combinations
being
> difficult to use when the context is taken into consideration, i.e. is
having
> to use Shift/Control combos to control things a good idea at critical
points
> in the flight, such as take-offs and landings?
>
> LeeE
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
Well, I'm glad to see other people take this seriously. I consider what
I
suggested a sort of half-measure holding action. I didn't really think
that
there was enough desire out there to really look at the problem.
I actually think that it goes a little deeper than the configuration
too. One
of the basic problems is that these actions don't even mean the same
thing in
every aircraft. In the B-29 for example, flaps and gear are controlled
by an
instantaneous switch that you have to hold down throughout the transit,
with no
detents. I really haven't been able to come up with a way to deal with
that. I
think that one of the (many) things we should look at is whether it's
smart for
the input layer to be directly modifiying properties. Maybe it's smarter
for the
ke
RE: [Flightgear-devel] keyboard mapping
For those of us who use the mouse to control the aircraft, using a mouse to lean isn't the best system. (though I admit, I do already pause the simulation to change views, though more often I just zoom out to a wider angle. Giles Robertson [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Josh Babcock [mailto:[EMAIL PROTECTED] Sent: 27 May 2004 19:46 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] keyboard mapping Lee Elliott wrote: > On Thursday 27 May 2004 09:07, Erik Hofman wrote: > >>Giles Robertson wrote: >> >>>The other advantage of defining specific function is consistency across >>>aircraft models. As as user, I'd want to know that a certain key drops >>>the arrestor hook, and that that same key drops the hook in all aircraft >>>that have one. If we just make aircraft modellers use a certain set of >>>keys, inconsistencies should spring up. >> >>So far every designer seems to have accepted the same keyboard bindings >>across different aircraft. Please take a look at >>FlightGear/data/Docs/keyboard/map.pdf >> >>Erik > > > Heh! - I wasn't aware of that doc. The '[' & ']' flap keys on the AN-225 & > B-52F should operate the the flaps as normal. I re-assigned them for the > Comper-Swift because it doesn't have flaps and the only way you can see > forward is by leaning out. > > I've been using the 'd' & 'f' keys for slats as there didn't seem to be a > standard assignment for them and the keys didn't seem to be already assigned, > but I'm not fussed as to which keys are used for the slats. > > LeeE > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > I would actually like to see some standard method for leaning the viewpoint built into FG. Lots of taildraggers could benefit from this. I guess I should write a Nasal script and give it some key bindings, like maybe the numpad with some modifier. I'm not sure if that is possible though. Maybe another mouse mode, or some modifier in the view mode? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] keyboard mapping
The other advantage of defining specific function is consistency across aircraft models. As as user, I'd want to know that a certain key drops the arrestor hook, and that that same key drops the hook in all aircraft that have one. If we just make aircraft modellers use a certain set of keys, inconsistencies should spring up. Giles Robertson [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Innis Cunningham [mailto:[EMAIL PROTECTED] Sent: 27 May 2004 02:38 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] keyboard mapping Hi Josh Josh Babcock writes > >I think that there is already stuff out there that does not conform to >this, but if enough people here agree, I would be happy to chase down all >those potential conflicts and mitigate them. I think that would be a good idea there seems to be enough room on the keyboard to keep every one happy. Then the modelers would know what keys they could use without running the risk of screwing up other parts of the keyboard. > >Josh Cheers Innis _ Play Origin SMS footy trivia to win $5k. Go to http://mobilecentral.ninemsn.com.au/mcheadtohead/home.aspx ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Georegistered imagery
Terraserver.homeadvisor.msn.com has aerial photographs of the US and Alaska down to 1m resolution (though most of it is 10yrs old, for obvious reasons). Most of the US and Alaska, at least. No, we can't get photo-scenery for Groom Lake. They get the photographs from USGS, but I can't find out if it's possible to just grab the lot. I take it that it isn't, though they also seem to have colour-infrared photographs available. I'm not sure how much a non-US national can help if anybody wants the data. Giles Robertson [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Jon Stockill [mailto:[EMAIL PROTECTED] Sent: 25 May 2004 15:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Georegistered imagery Corrubia, Stacie K wrote: > Is it possible to bring in either raw or TIFF imagery to the flight > gear environment? The imagery has been georegistered and is part of a > set of stereo pair images used to create 3-D models and DEMs. Can > the imagery data (as well as 3-models and high resolution DEMs (3 > meter DEMs) be overlaid on an existing lower resolution dataset > already in the environment? Now I've stopped drooling and repeatedly saying "3 meters!" I'll reply :-) All the flightgear scenery is preprocessed using the tools available at www.terragear.org. If you're wanting to create high resolution scenery then this is where you'll need to start. There's a tutorial here: http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html That will cover the basics. The code for the positioning of photographic images is very under-developed, and not really in a usable state yet. It can be made to work reasonably effectively but imposes a very high load on the graphics subsystem as flightgear does not yet support texture paging. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear compile error
Changing the order has fixed the problem now. Thanks very much.
Incidentally, does anyone know why the clouds_3d module compiles so
dirtily? Make will just about get through it, screaming every bit of the
way, but make install commits suicide before the end, bailing out in a
veritable swimming pool of syntax errors. That being said, FGFS then
builds fine, so it isn't a problem anybody should worry about (much).
I can give people the compile logs if they want them, but I won't impose
their lurid turgidity on anybody.
Giles Robertson
[EMAIL PROTECTED]
-Original Message-
From: Vivian Meazza [mailto:[EMAIL PROTECTED]
Sent: 21 May 2004 20:33
To: 'FlightGear developers discussions'
Subject: RE: [Flightgear-devel] SimGear compile error
Frederic Bouvier
>
>
> Try moving the following code :
>
> #if defined(__MINGW32__)
> #define isnan(x) _isnan(x)
> #endif
>
> **after**
>
> #include "cloud.hxx"
>
> -Fred
>
>
> - Original Message -
> From: "Giles Robertson"
>
>
> Unfortunately not:
> Making all in clouds3d
> cloud.cxx:31:1: warning: "isnan" redefined
> In file included from cloud.cxx:22:
> c:/files/mingwin/mingw/include/math.h:324:1: warning: this is
> the location of the previous definition
> cloud.cxx: In member function `bool
> SGCloudLayer::reposition(float*, float*,
>double, double, double, double)':
> cloud.cxx:712: `isnan' undeclared (first use this function)
> cloud.cxx:712: (Each undeclared identifier is reported only
> once for each
>function it appears in.)
> make[5]: *** [cloud.o] Error 1
> make[4]: *** [all-recursive] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
>
> I deleted my local copy and grabbed it fresh off CVS because
> of a conflict.
>
> What I can't follow is why it first complains that isnan has
> been redefined, and then complains that isnan is now undefined.
>
> It then compiles clean when you muck around with clouds.cxx
> like this (lies 30-33)
>
> #if defined(__MINGW32__)
> inline int (isnan)(double r) { return isnan(r); }
> #endif
>
> Diff:
> 31c
> inline int (isnan)(double r) { return isnan(r); }
>
> Still don't understand what the problem is, though.
>
>
> Giles Robertson
> [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Frederic Bouvier [mailto:[EMAIL PROTECTED]
> Sent: 21 May 2004 16:14
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] SimGear compile error
>
> Giles Robertson wrote:
>
> > This was sorted out by uncommenting lines 28&29 of cloud.cxx:
> >
> > // #if defined (__APPLE__)
> > // // any C++ header file undefines isinf and isnan
> > // // so this should be included before
> > inline int (isinf)(double r) { return isinf(r); } //See below
> > inline int (isnan)(double r) { return isnan(r); } //HACK to
> make MingW
> > MsyS build work. Find better solution ASAP. May well break other
> > systems.
> > // #endif
> >
> > (I added the end of line comments)
> > SimGear now compiles, but this is hardly a good solution.
> Does anybody
> > know what's going on here? Why is isnan() being undefined?
> >
> > I have a feeling this may have come up before, but I can't
> find it in
> > the archives, or remember the solution.
>
It's well broken when trying to compile under Cygwin. Too many error to
even
start to list in clouds.cxx, I think, but by no means certain could be
in
clouds_3d.
Any suggestions?
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear compile error
Unfortunately not:
Making all in clouds3d
cloud.cxx:31:1: warning: "isnan" redefined
In file included from cloud.cxx:22:
c:/files/mingwin/mingw/include/math.h:324:1: warning: this is the
location of the previous definition
cloud.cxx: In member function `bool SGCloudLayer::reposition(float*,
float*,
double, double, double, double)':
cloud.cxx:712: `isnan' undeclared (first use this function)
cloud.cxx:712: (Each undeclared identifier is reported only once for
each
function it appears in.)
make[5]: *** [cloud.o] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
I deleted my local copy and grabbed it fresh off CVS because of a
conflict.
What I can't follow is why it first complains that isnan has been
redefined, and then complains that isnan is now undefined.
It then compiles clean when you muck around with clouds.cxx like this
(lies 30-33)
#if defined(__MINGW32__)
inline int (isnan)(double r) { return isnan(r); }
#endif
Diff:
31c
inline int (isnan)(double r) { return isnan(r); }
Still don't understand what the problem is, though.
Giles Robertson
[EMAIL PROTECTED]
-Original Message-
From: Frederic Bouvier [mailto:[EMAIL PROTECTED]
Sent: 21 May 2004 16:14
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] SimGear compile error
Giles Robertson wrote:
> This was sorted out by uncommenting lines 28&29 of cloud.cxx:
>
> // #if defined (__APPLE__)
> // // any C++ header file undefines isinf and isnan
> // // so this should be included before
> inline int (isinf)(double r) { return isinf(r); } //See below
> inline int (isnan)(double r) { return isnan(r); } //HACK to make MingW
> MsyS build work. Find better solution ASAP. May well break other
> systems.
> // #endif
>
> (I added the end of line comments)
> SimGear now compiles, but this is hardly a good solution. Does anybody
> know what's going on here? Why is isnan() being undefined?
>
> I have a feeling this may have come up before, but I can't find it in
> the archives, or remember the solution.
Should be fixed now.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New contributor questions: taxiwayandairport stuff; 3D building/landmark model stuff.
> (e.g. put in a separate file, or given a separate > identifier than "T" so that it's excluded from export filters if > necessary, can be acted on to produce curved taxiway lines, etc.) I think that that could become quite important. I have a great fear that if we ever get round to automatic handling of curved taxiways, and to automatic production of the right textures at taxiway intersection etc, then we don't want to find our taxiway data full of small little metre-long taxiways that gunges the whole place up. I'm very worried by taking the data denoting 'real' taxiways, and adding in lots of small ones. Especially for the AI side of things - a network with masses of small little nodes is going to be very nice, except exceedingly large, and, topologically, irrelevant (except for physical movement of aircraft models). Giles Robertson [EMAIL PROTECTED] > I'm not entirely sure where the acceptable number of segments / amount > of detail trade-off will end up. Jon Stockill has done some very > detailed UK military layouts with hundreds of segments to show all the > dispersal areas, but I don't think he's submitted them yet. So far the > airports I have done haven't had more than about 100 segments, less than > some of the default ones. I deliberately avoided KSQL after seeing the > massive extra aprons on the aerial photos! Hopefully what is acceptable > to Robin in terms of number of segments vs. detail vs. accuracy will > become more clear after I get some X-Plane export filters in and users > start submitting in a format he can accept. Well, for the purposes of getting more stuff in the default area into CVS, and with the possibility that "aesthetic" taxiways might be handled differently (e.g. put in a separate file, or given a separate identifier than "T" so that it's excluded from export filters if necessary, can be acted on to produce curved taxiway lines, etc.), maybe it makes the most sense for me to just forego rounding interesections right now, and instead just get the taxiways and aprons put in place for places I work on? I can always go back and add the curvature (since playing with KSQL, I know I can do it OK), and by that point maybe we'll have settled on how to treat the additional stuff? Of course, I have no idea how to handle KPAO in either case -- its main feature is a large circular apron for a parking area, with a circular taxiway running its circumference. >> Perhaps a better way of handling curved intersection corners would >> be to generate for each intersection a set of four boolean flags >> indicating whether or not that corner should be rounded, and let >> TerraGear round the corners when it puts the taxiways into the scenery? >> But I bet that requires hard work on their part, so maybe not such a >> good idea. > > > It's a good idea, but as you say requires a lot coding in TerraGear as > well. Better handling of taxiway/taxiway and taxiway/runway > intersections is something that's been mulling in the back of my mind > for ages, but realistically I haven't got a chance of finding time to > work on it in the foreseeable future. I understand. At this point, I think the biggest reason I wish I could code (well, in something other than FORTRAN or the bash shell) is because it's gotta be a bit annoying to people in a project for other people (like me) to come in with ideas for *them* to implement. "Wouldn't X be cool? Why don't you go do X?" [ Two quotes from you ] >>>>> There's lots of room for improvement to the airport modelling. I >>>>> guess >>>>> that ultimately artistic orientated folk will start doing custom >>>>> scenery >>>>> for certain areas, rather than relying on the automated processing >>>>> of >>>>> compiled data as we do at the moment. [ snip ] > I hope > that eventually people will start making detailled representations of > their local areas available, in a similar manner to MSFS scenery > designers. Part of MSFS' success at having so many people developing aircraft liveries and a huge quantity of landmarks, accurate airport structures, traffic patterns and gate usage, etc., (seen e.g. in all the stuff on http://www.avsim.com/ and http://www.flightsims.com/ ) is doubtless based on the number of people running it. But I also wonder if another reason is that it's fairly well facilitated. The infrastructure is there, and it's straightforward to use it. My understanding (but I'm not sure; haven't run any MS software since the 80s) is that the software one uses for creating and adding such stuff comes with MSFS, and that the procedure for how to create
[Flightgear-devel] SimGear compile error
>From compiling SimGear (this is only the last part of the clouds-3d
mess):
SkyRenderableInstanceCloud.hpp:230: warning: argument to `int' from
`float'
In file included from SkyRenderableInstance.hpp:27,
from SkySceneManager.hpp:38,
from SkySceneManager.cpp:29:
mat33.hpp:60: warning: friend declaration `Vec3 operator*(const
Vec3&, const Mat33&)' declares a non-template function
mat33.hpp:60: warning: (if this is not what you intended, make sure the
function template has already been declared and add <> after the
function
name here) -Wno-non-template-friend disables this warning
mat33.hpp:64: warning: friend declaration `Mat33 operator*(Type,
const
Mat44&)' declares a non-template function
In file included from SkySceneManager.hpp:41,
from SkySceneManager.cpp:29:
SkyRenderableInstanceCloud.hpp: In member function `int
SkyRenderableInstanceCloud::_GetRequiredLogResolution(float, float,
float)':
SkyRenderableInstanceCloud.hpp:230: warning: initialization to `int'
from `
float'
SkyRenderableInstanceCloud.hpp:230: warning: argument to `int' from
`float'
cloud.cxx: In member function `bool SGCloudLayer::reposition(float*,
float*,
double, double, double, double)':
cloud.cxx:705: `isnan' undeclared (first use this function)
cloud.cxx:705: (Each undeclared identifier is reported only once for
each
function it appears in.)
make[5]: *** [cloud.o] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
This was sorted out by uncommenting lines 28&29 of cloud.cxx:
// #if defined (__APPLE__)
// // any C++ header file undefines isinf and isnan
// // so this should be included before
inline int (isinf)(double r) { return isinf(r); } //See below
inline int (isnan)(double r) { return isnan(r); } //HACK to make MingW
MsyS build work. Find better solution ASAP. May well break other
systems.
// #endif
(I added the end of line comments)
SimGear now compiles, but this is hardly a good solution. Does anybody
know what's going on here? Why is isnan() being undefined?
I have a feeling this may have come up before, but I can't find it in
the archives, or remember the solution.
Giles Robertson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] wing icing
Add to that a set of ground conditions: Ice on ground, wet ground, etc. Giles Robertson -Original Message- From: David Megginson [mailto:[EMAIL PROTECTED] Sent: 18 May 2004 18:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] wing icing Curtis L. Olson wrote: > What other potential hazards did you have in mind? Structural damage, fire, obstructed visibility (say, ice on the windshielf) and depressurization spring immediately to mind. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MingW, GUI, and build errors
Just got an error on the following compile: This is an automated build using the MSYS command line environment and GCC 3.3.3 of FlightGear and SimGear This compile was started by user: giles.robertson on 05/12/04-20:14:57-UTC And simgear compiled fine (with the usual heap of errors in clouds3d - I've never got that file to compile cleanly, or the feature to work) Flightgear went through with the usual set of errors, but hiccupped here: Making all in GUI trackball.c:18: warning: ignoring #pragma warning AirportList.cxx: In constructor `AirportList::AirportList(int, int, int, int)': AirportList.cxx:22: warning: embedded `\0' in format In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, from layout-props.cxx:1: C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or directory In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, from layout-props.cxx:1: C:/msys/1.0/fg/include/plib/puGLUT.h: In function `int puGetWindowGLUT()': C:/msys/1.0/fg/include/plib/puGLUT.h:42: `glutGetWindow' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:42: (Each undeclared identifier is reported only once for each function it appears in.) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puSetWindowGLUT(int)': C:/msys/1.0/fg/include/plib/puGLUT.h:47: `glutSetWindow' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puGetWindowSizeGLUT(int*, int*)': C:/msys/1.0/fg/include/plib/puGLUT.h:52: `GLUT_WINDOW_WIDTH' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:52: `glutGet' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:53: `GLUT_WINDOW_HEIGHT' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puSetWindowSizeGLUT(int, int)': C:/msys/1.0/fg/include/plib/puGLUT.h:58: `glutReshapeWindow' undeclared (first use this function) make[1]: *** [layout-props.o] Error 1 make: *** [all-recursive] Error 1 It's just occurred to me that a probable reason for this error may be that we now need PLIB cvs to build FGFS cvs (I'm still using 1.8.1), and I'll deal with it once I've reinstalled windows, but I thought you lot might like to know, especially as, should that be the case, this is the first time since 0.9.4 we have moved from being dependent on Plib 0.8.x :) Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] A/C turns without power
Lee - There's no way that the screenshots on your site look like my standard FG scenery - I've never seen proper joins of taxiways to runways etc. How did you take them? Giles Robertson > -Original Message- > From: Lee Elliott [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 18:38 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] A/C turns without power > > On Wednesday 12 May 2004 14:16, David Culp wrote: > > > > While playing around tonight I > > > > noticed that the models on the > > > > groung with no engines running > > > > will turn in a circle left or right depending > > > > on which way the rudder/steering is pointing. > > > > if the steering is straight ahead(rudder centered) > > > > then the A/C does not turn. > > > > > > Which FDM(s)? > > > > I see it happening in JSBSim, with engines running or not. Could be due > to > > the jitter, or residual "u-fps", which never gets to zero (fluctuates > > around 0.002 to 0.007). The new ground reactions system might fix that. > > > > As for Yasim, I tried the A-10, but it either sits on its tail, or > bounces > > continualy on its gear. Maybe I have an old config. > > > > > > Dave > > Re the A-10 problem: is this with the cvs version? > > There's an updated package available at > > http://www.overthetop.freeserve.co.uk/FlightGearAC.html > > It's still not textured properly atm - just converted to .ac format and > coloured, but as it's been re-named it'll co-exist with the version > currently > in cvs. This version should sit on it's u/c ok, even with no fuel in it;) > > LeeE > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MD-11 Good News
How often do people need to specify the state of gear etc globally? I can't, offhand, think of a point at which you want all the aircraft in the world how drop the gear. Considering this, is the typo easy enough to make that we ought to change the behaviour? - or is this mucking up the established system too much? Or perhaps, /property/value should reference to the aircraft currently under user control, which would extend compatibility if we ever implement a 'switch which aircraft you are flying in mid-air' feature. Giles Robertson > -Original Message- > From: Andy Ross [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 14:21 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] MD-11 Good News > > Mathias Fröhlich wrote: > > May be this 'do not use a leading slach' should also show up in that > > model animation HOWTO? > > Or even generate a runtime warning during parsing. This is a really > easy typo to make. > > Andy > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Why ZERO
Because 0 is used in computing, if not aeronautics. (Small explanation for the non-technical: Originally, for complex and obscure technical reasons, array elements were numbered (indexed) starting at 0. This is still the case for c & c++ and most other languages. There is no real reason for doing so at present that I've ever found, apart from tradition. That said, some of the fastest binary tree implementations take advantage of this, but with the processing power we play with these days it can't be really relevant) Giles Robertson > -Original Message- > From: Innis Cunningham [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 13:30 > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Why ZERO > > Hi Guys > I am just wondering is there a > very good reason that we use > zero to number things in FG.Engines > tanks and the like.Because in the real > world of aviation nothing is numbered > zero as far as I know. > Why does it matter you may ask. > Well it seems a bit strange that a four > engined aircraft has engines numbered 0-3 > and a three engined aircraft has engines > numbered 0-2 and so on. > As FG grows and more systems are added > it would seem to me that the confusion > could multiply. > Is there a good reason that we do this > and how hard would it be to change. > I guess this applies to the FDM's to. > > Cheers > Innis > > _ > Personalise your phone with chart ringtones and polyphonics. Go to > http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Concorde model
Thanks for telling me about a possible duplication of effort. I think Concorde has to be done in JSBsim - I can't honestly see the YASIM solver being able to cope with 6 elevons (and the quite complicated relationship between input and output on them, especially as this should strictly be related to speed - on the real Concorde, outboard elevon deflection decreases as speed increases in order to keep the thing flyable and the airframe temperatures OK), the nose, and no horizontal tail, but if anyone thinks different, please say. Does JSBsim handle lift generated by a vortex or a delta wing at low speeds - and does it handle the ground effect of deflected air? Giles Robertson > -Original Message- > From: Jim Wilson [mailto:[EMAIL PROTECTED] > Sent: 11 May 2004 12:04 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Concorde model > > Giles Robertson said: > > > Someone said a small time ago that there was a GPL 3d model for Concorde > > available. I'm trying to knock together an FDM in JSBsim - where would I > > find the model? > > > > Giles Robertson > > > > This is gziped 781k. It might be a little slow as I'm in the middle of a > pretty good size download. It is only going to be available temporarily. > > http://www.spiderbark.com/fgfs/concorde.ac.gz > > BTW there is also a non-posting fgfs mailing list recipient working on a > jsbsim FDM for the concorde. Perhaps if he spots this request he'll get > in > touch with you directly about sharing ideas and work. > > Best, > > Jim > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Concorde model
Someone said a small time ago that there was a GPL 3d model for Concorde available. I'm trying to knock together an FDM in JSBsim - where would I find the model? Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] laptops
By contrast, my experience with Acer laptops has not been good, but that may not be Acer's fault, due to various complicated support arrangements. The build quality on mine wasn't designed for it being humped around and used for at least 8hrs a day, though, which mine is. Benchmarks I've seen of Dothan don't seem to suggest that it's worth the higher price tag, especially considering, although the operating power is lower, the standby power is higher, so battery life remains much the same. Giles Robertson > -Original Message- > From: Christian Mayer [mailto:[EMAIL PROTECTED] > Sent: 10 May 2004 22:07 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [OT] laptops > > Jim Wilson schrieb: > > > I've been asked to recommend a laptop with long battery life for use on > long > > trans continental airline flights. The user is word > processing/spreadsheet > > oriented. > > Get an Centrino based laptop. > > Windows is fully supported and Linux is getting there (the WLAN driver > is in a useable beta stage) > > The brand (Acer, Dell, IBM, ...) doesn't really matter. Every major > player has high quality / high price modells as well as those with a > smaller price tag (and a not so good quality...) > > CU, > Christian > > PS: I'm writing this on an Acer Travelmate 800 series laptop - which I'd > buy again. It's high quality with a very reasonable price tag. And > performance (even with FlightGear) is great > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] laptops
Practically all laptops allow you to buy another battery, so even though you have to power down the laptop to switch, you don't do too badly. With that, I can last the 5:30hr journey by train from London to Edinburgh. (Word processing only. If you want to run FGFS, or compile it, then you are looking at *much* shorter timescales). Spreadsheet could be more intensive depending on application. Giles Robertson. > -Original Message- > From: Curtis L. Olson [mailto:[EMAIL PROTECTED] > Sent: 10 May 2004 21:03 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [OT] laptops > > Jim Wilson wrote: > > >I've been asked to recommend a laptop with long battery life for use on > long > >trans continental airline flights. The user is word > processing/spreadsheet > >oriented. > > > >This isn't my cup of tea, as I'm more of a book reader in flight (who > doesn't > >like carrying crap--even 6 lb computers--around airports). I am aware of > the > >technical issues and websites with specs online. Just hoping for some > first > >person accounts of actual performance. > > > > > > Some laptops I've seen (Dell) allow you to substitute an extra battery > pack instead of the cd rom drive giving you 2x the normal battery > life. That makes a big difference in how long your laptop is useful > ... I've also seen people buy extra batteries and charge them up in > advance ... more weight to carry but a reasonable option. > > Curt. > > -- > Curtis Olsonhttp://www.flightgear.org/~curt > HumanFIRST Program http://www.humanfirst.umn.edu/ > FlightGear Project http://www.flightgear.org > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenGL/DirectX wrapper
The other problem is that it doesn't work. I got a friend with a trident card sans GL drivers to download and install FGFS. It didn't work, but unfortunately I didn't have the time before he deleted it to check what call wasn't in the library. It didn't work with other GL games either (Vietnam, Quake III engine) Giles Robertson > -Original Message- > From: Arnt Karlsen [mailto:[EMAIL PROTECTED] > Sent: 06 May 2004 19:54 > To: FlightGear developers discussions > Cc: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] OpenGL/DirectX wrapper > > On Thu, 06 May 2004 14:57:57 +0200, Erik wrote in message > <[EMAIL PROTECTED]>: > > > > Hi, > > > > I found a wrapper that lets OpenGL programs use the DirectX API > > without any change. It's using Mesa (it's even included in Mesa 3.1 > > and later) and hence is Freeware: > > > > http://www.altsoftware.com/products/opengl-directx.html > > > > It might be a good idea to put a link on the FlightGear page. > > ..I can only see legal problems, Microsoft "I.P." etc litigation, > I mean, they _can_ pull another SCOeme on us, say for > "threatening their flight sim biz" or "for infringing on their API", > just check http://groklaw.net/ . > > .._everything_ else can be fixed. And, their stereoscopic 3d > and graphics kits looks cool. ;-) > > -- > ..med vennlig hilsen = with Kind Regards from Arnt... ;-) > ...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. > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenGL/DirectX wrapper
Just because cards have OpenGL drivers doesn't mean that they have *good* OpenGL drivers, and several laptop cards (Trident etc), don't. Not but what, interpreting to an API wouldn't be too great either. Giles Robertson > -Original Message- > From: Erik Hofman [mailto:[EMAIL PROTECTED] > Sent: 06 May 2004 13:42 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] OpenGL/DirectX wrapper > > Curtis L. Olson wrote: > > Erik Hofman wrote: > > > >> I found a wrapper that lets OpenGL programs use the DirectX API > >> without any change. It's using Mesa (it's even included in Mesa 3.1 > >> and later) and hence is Freeware: > >> > >> http://www.altsoftware.com/products/opengl-directx.html > >> > >> It might be a good idea to put a link on the FlightGear page. > > > > Are there modern cards with enough power to run FlightGear that don't > > have OpenGL drivers for them? > > I wouldn't know. I'm using IRIX and Linux. > Matrox cards maybe? > > Erik > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] how to determine when flightgear hasfullyinitialized
Then just add this:
fgsetbool("sim/initialised",true);
at line 1436 of main.cxx so the function reads like this:
if ( idle_state == 1000 ) {
// We've finished all our initialization steps, from now on we
// run the main loop.
fgsetbool("sim/initialised",true);
fgRegisterIdleHandler(fgMainLoop);
} else {
if ( fgGetBool("/sim/startup/splash-screen") ) {
fgSplashUpdate(0.0, 1.0);
}
}
I suppose I ought to have done a diff on this, but it seems so trivial.
Giles Robertson
> -Original Message-
> From: Erik Hofman
[mailto:[EMAIL PROTECTED]
> Sent: 05 May 2004 08:05
> To: FlightGear developers
discussions
> Subject: Re: [Flightgear-devel] how
to determine when flightgear
> hasfullyinitialized
>
> Seamus Thomas Carroll wrote:
> > Hi,
> >
> > Is there a simple way to test in the code to see if
flightgear has
> > initialized such as a boolean?
>
>
> Not that I know of, but it would be nice to have one.
> That would allow the sound (for example) to be quiet until the
startup
> is completed.
>
> Erik
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] how to determine when flightgear hasfullyinitialized
From main.cxx:
if ( idle_state == 1000 ) {
// We've finished all our
initialization steps, from now on we
// run the main loop.
fgRegisterIdleHandler(fgMainLoop);
idle_state appears to be declared globally, so you should be able to
test straight for that:
bool checkinit()
{
if (idle_state == 1000)
{return true;}
else
{return false;}
}
Though it would make a lot more sense to add a value to the property
tree in the code snippet above so that you could use fgGetBool() on it.
Giles Robertson
> -Original Message-
> From: Seamus Thomas Carroll
[mailto:[EMAIL PROTECTED]
> Sent: 05 May 2004 06:15
> To: [EMAIL PROTECTED]
> Subject: [Flightgear-devel] how to
determine when flightgear
> hasfullyinitialized
>
> Hi,
>
> Is there a simple way to test in the code to see if flightgear has
> initialized such as a boolean?
>
> Seamus
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear news letter
How about: "On a wing and a prayer" (or are we all too atheist? - I am, and don't care, but some might) Giles Robertson > -Original Message- > From: John Check [mailto:[EMAIL PROTECTED] > Sent: 03 May 2004 20:57 > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] FlightGear news letter > > On Monday 03 May 2004 02:52 am, Durk Talsma wrote: > > On Sunday 02 May 2004 17:20, Jonathan Richards wrote: > > > Firstly, a title. Jon's newsletter is called 'Back of the Envelope', > > > which I think is particularly clever - JSBSim is anything but a > > > back-of-the-envelope calculation, and there are echoes of flight > > > envelope, too. > > > > The first thing I could think of was something like "Open Wings", but > right > > now, Lynyrd Skynyrd's song "Freebird" keeps spinning through my head. > Since > > I just read that multiple entries are allowed, I'd like to enter > both. :-) > > > > That would give the impression of crashiness. > > > > Secondly, we're missing suggestions for content. Suggest away, but > what > > > I'd really like is for you to suggest and volunteer to write, as well. > > > > A few ideas, aside from an introductory article, as was mentioned by > > somebody else, what about a history of the project, a background stody > on > > the development of on of flightgear's subsystems, some in depth coverage > of > > some of the academic uses of FlightGear, conference of expo proceedings? > > > > Cheers, > > Durk > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FGFS and MSYS
My apologies to those who couldn't read the original message. To clarify what happened at this end: My mail service is run off a MS Exchange server. I'm not the admin (read: yes, I hate it too. Don't complain to me about it). When I'm onsite I use Outlook, which interfaces fine, and appears to be able to send most messages without killing people's clients or rendering stuff unreadable. When I'm offsite, I have to use the MS exchange webmail system. This does some very, very weird things, and the problems with it I won't go into, but it does mangle things and send them in unicode, and won't let me send non-html email (or so I think - if this comes out as plain text, please tell me). On a rather different note: I'd be perfectly happy to set up a nightly MS build (using msys/mingw), if people think that there is demand for it, and that it would be useful. Is this a sensible thing to do? Giles Robertson -Original Message- From: Andy Ross [mailto:[EMAIL PROTECTED] Sent: Sun 02/05/2004 21:34 To: FlightGear developers discussions Cc: Subject: Re: [Flightgear-devel] FGFS and MSYS Martin Spott wrote: > mail2news, inn, tin ;-)) > Aside from that, I find it very unfamiliar to post _any_ sort of > human-_un_readable messages to a mailing list. Isn't it ? It was a perfectly readable text document, it was just flagged with an encoding of UTF-8, which while more general than necessary (the actual document was 100% ASCII) isn't technically incorrect. This is no more incorrect or unreadable than sending the identical document with a Latin-1 encoding, which presumably you would have been able to read fine. My Mozilla displayed it inline as part of the message. Honestly, you need to get a more recent mail client. Text encoding limitations are ancient history; the whole world is moving to unicode. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel <>___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGFS and MSYS
I've compiled FGFS under MSYS, and have written instructions on how to do it. It seems that there's a problem with the pthread.h library - you have to comment out line 167, because no config.h file exists in the folder where you install it. You also have to rename Andy's Pthread.dll binary to PthreadGC.dll, because that's what the mingw build expects. Otherwise it compiles and runs fairly painlessly. Giles Robertson (Apologies for HTML email but the webmail system won't allow anything else) Compiling FlightGear under the MSYS command line environment. Giles Robertson, 2004 Written 1/05/2004 This file is in the public domain. Acknowledgments: Andy Ross, who a) built the binary libraries needed by hand and b) wrote up how to compile using mingw32 on Cygwin/Linux, both of which were essential when writing this. Comments/suggestions/flames to [EMAIL PROTECTED] or to the flightgear-devel list This gives instructions on how to build FlightGear under the MSYS environment. This was written for compiling a CVS checkout at 01/05/2004. I assume you have a fairly minimal knowledge of standard unix commands. You also need a working CVS client at present. 1) Download MingW from www.mingw.org. (Downloads page, look for MingW-x.x.x.exe among the plethora of packages) 2) Install it. I installed it to C:\mingw, but one could conceivably install it anywhere. It isn't material. 3) Download MSYS from www.mingw.org (Downloads page again, this time look for MSYS-x.x.x.exe) 4) Install that. After it has installed, it will ask to do a post install process. Let it. It will ask you for where you installed MingW. Give it the path you installed in step 2) 5) Download and install the Creative OpenAL SDK (follow link from www.openal.org) 6) Create a folder to put your fgfs sources in. I used C:\fg (under msys, this is /c/fg ) 7) Download Plib 1.8.3 (though anything later than 1.7.0 should work) from www.plib.org [NOTE: If FG 0.9.5 is out, you can skip the next two steps and grab the files straight from www.flightgear.org] [CVS instructions are available at www.flightgear.org] 8) Checkout SimGear from cvs.simgear.org:/var/cvs/SimGear-0.3 9) Checkout FlightGear from cvs.flightgear.org:/var/cvs/FlightGear-0.9 10) Run msys. Type mkdir /fg CD to the directory you have your source files in (that you made in step 6) If you followed step 6: cd /c/fg 11) Install Andy's binary libraries. Download http://plausible.org/andy/fgfs-mingw-libs.tar.gz to C:\fg Type (in MSYS) cd /fg tar xvzf /c/fg/fgfs-mingw-libs.tar.gz tar xvf openal.tar tar xvf pthread.tar tar xvf sdl.tar tar xvf zlib.tar Rename /fg/bin/pthread.dll to pthreadGC.dll [NOTE: You may have to find pthread.h (in /fg/include) and comment out line 167, if you get a build error when building SimGear] 12) Build and Install plib Type cd /c/fg tar xvzf plib-1.8.3.tar.gz cd plib-1.8.3.tar.gz ./configure --prefix=/fg make make install 13) Build and Install SimGear [If you grabbed a tarball off the website, untar it before proceeding] cd /c/fg cd simgear ./autogen.sh ./configure --prefix=/fg make make install 13) Build and Install FlightGear [If you grabbed a tarball off the website, untar it before proceeding (and substitute source for your fg src directory] [At present, we only make the /src directory as the others don't work automatically] cd /c/fg cd source ./autogen.sh ./configure --prefix=/fg --enable-sdl cd src make make install 14) Strip the binaries cd /fg/bin strip *.exe 15) Install the base package (from CVS or the website) and tell FlightGear where it is. 16) Fly. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
> "Giles Robertson" wrote: > > That would argue for a variable for each viewpoint changing the > > directionality of the sound (i.e the size of the magnitude of difference > > between the speakers). > > No - at least not as long as I don't misunderstand your point ;-) I'll give an example. In a fictional world, you are facing north, and can't turn, or anything. On your left, you have a one sound (A), and on the right, another (B). Should there be no reflection at all (and diffraction round to your ear will be minimal), you will get nearly all A sound through the left ear, and all B sound through the right ear. Now imagine that you are sitting in a (vastly simplified) cockpit. Because it distributes sound, you can't hear where either A or B are coming from. So we have at least two scenarios - one where all sounds are *only* heard from where they originate, and one where there's no directional sound (sounds are heard equally for all places). Obviously, this is in fact a sliding scale from one to the other. And in some scenarios (tower view) we are pretty close to one end of the scale, and in others (cockpit) we are pretty close to the other end. So we put in a parameter that affects how directional the sound is, with different values for different viewpoints (tower, chase, cockpit). What I don't know is how to implement this, because I've never used OpenAL. Giles Robertson > -Original Message- > From: Martin Spott [mailto:[EMAIL PROTECTED] > Sent: 29 April 2004 18:49 > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Positional sounds > > > >From an engineers point of view (I _am_ an engineer but not a software > architect, so peopülemight disagree) it would be sufficient to give > each source of noise a 3D location and bind the listeners ears directly > to the viewpoint and -direction. The rest would be pretty simple > calculöaions of angle and distance, > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
That would argue for a variable for each viewpoint changing the directionality of the sound (i.e the size of the magnitude of difference between the speakers). Howe easy would this be to implement? Giles > -Original Message- > From: David Megginson [mailto:[EMAIL PROTECTED] > Sent: 29 April 2004 15:34 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Positional sounds > > Jim Wilson wrote: > > > Lower frequencies especially would be hard to detect direction anyway > even > > without the hard surfaces. This reminds me of the engine out protocol > on > > light twins, which seems to assume that you won't hear which engine is > silent. > > That's an excellent point -- there are several procedures for identifying > which engine is out, and none of them has to do with directional sound. > Essentially, the engine noise is transmitted through the entire airframe, > and you're doing the equivalent of sitting inside a loudspeaker. > > I think that the directional sound will be very interesting for external > views, and might also be useful for near midair collisions, but in general, > I don't think it's much use inside the cockpit. > > > All the best, > > > David > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
AFAIK that isn't possible because the "earpoint" would change whether you were looking at the ground in front or the air 10 miles away. What shouldn't be hard is to take an audio feed from a different location from the viewpoint, but not much might happen if the audio hasn't been initialised because you aren't there yet ... Giles > -Original Message- > From: Jonathan Richards [mailto:[EMAIL PROTECTED] > Sent: 29 April 2004 08:44 > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Positional sounds > > On Thursday 29 Apr 2004 6:40 am, Martin Spott wrote: > > I _strongly_ support Arnt's idea of 3D coordinates for the sound/noise > > sources. To complete the picture I'd suggest binding the listener's ear > > positions to the view direction (implemented somewhere in the viewer > > mechanics in order to make it work in _every_ view that might be > > invented in the future). In the long run people will want to hear the > > left engine of a C310 from the _front_ when they turn the cockpit view > > to the left, they will want to have a realistic noise location on a > > walkaround or any other view that moves relative to the aircraft. > > > > You could also add noise to any stationary object on the ground - not > > that I'd want to make FlightGear as noisy as the real world > > Seconded - this is very important for first-person games [0], but it would > be > good to have, for instance surround wind noise, engine noise from the > engine > directions and ATIS speaking from the speakers. Oh, hold on. In a real > plane, I've got headphones, haven't I... Their purpose is to deaden > ambient > noise, and remove stereo cues from sound communications! > > > Since the field-of-view control gives me a virtual telescope, can we have > field-of listen zooming, to simulate directional parabolic ears? > > > Regards > Jonathan > > [0] By which I mean, it has been done already for a number of OpenAL > applications. > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Because of the FG/OpenAL/Cygwin problem, I'm trying to get FG to compile using Msys and mingw. (This doesn't hold out a huge amount of hope, as msys is a cygwin fork, but, we might get somewhere). Does anybody have any instructions on this? (I don't want to sink large amounts of time if somebody's already done it) Giles Robertson > -Original Message- > From: D Luff [mailto:[EMAIL PROTECTED] > Sent: 27 April 2004 12:47 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] OpenAL > > On 27 Apr 2004 at 7:23, Jon Berndt wrote: > > > > Jon, > > > > > > I have *no* idea if it actually produces any sound as > > > I don't have a sound board on my development system > > > but > > > > > > after getting the OPENAL CVS files > > > > > > cvs > > > -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository > login > > > (use password "guest") > > > cvs > > > -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository > > > co openal > > > > > > then > > > % cd $OPENAL > > > % cd linux > > > % ./autogen.sh > > > > I got this after running autogen.sh: > > > > configure.in:147: warning: AC_TRY_RUN called without default to allow > cross > > compiling > > configure.in:147: warning: AC_TRY_RUN called without default to allow > cross > > compiling > > configure.in:256: warning: AC_TRY_RUN called without default to allow > cross > > compiling > > > > ... and then make totally cratered. > > > > I also got that output from autogen.sh, also on Linux - it appears to be > harmless. Make > went fine on Cygwin. No audio output from the test programs on Cygwin > though :-( > Haven't managed to get FlightGear to link to it on Cygwin yet either. As > you say, > googling OpenAL and Cygwin appears to find sweet FA. > > Cheers - Dave > > This message has been scanned but we cannot guarantee that it and any > attachments are free from viruses or other damaging content: you are > advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building FlightGear / getting some errors
Ah. Thanks. I'll try that. I was hoping to try and get along with something slightly less stodgy than Cygwin, though. I was also hoping to use MSYS so that I didn't need to use Cygwin or a windows IDE to produce the makefile. I've always thought that Cygwin was a little heavy for something that should be quite simple :) Giles > -Original Message- > From: Norman Vine [mailto:[EMAIL PROTECTED] > Sent: 19 April 2004 21:28 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] Building FlightGear / getting some errors > > Andy Ross writes: > > > > Giles Robertson wrote: > > > Not that I've noticed. It would be useful for mingw32. I've tried > > > building on that, and it compiles fine, but the linker fails because > > > the input is too long ;). > > > > The linker fails with long file lists? That sounds odd -- > > The Windows cmd shell has a command line length limitation > that I get around by using MingW from a Cygwin bash shell. > > Compiling from a bash shell under MSYS might work too > I don't really know as I haven't used it > > Note when using bash under Cygwin you need to substitute > the Cygwin 'make' for the MingW 'make' and you will need to > configure using the appropriate --prefix argument for your system > > Perhaps the easiest way around this is to use the standard way > of overcoming the Windows command line length limitation by > redirecting the link command line to a file and then massaging that > so as to have the final linking arguments to gcc be read from that file > > I believe that this could be done using the --dry-run flag for make > but I have nevered tried this as I use a Cygwin shell as outlined above > > HTH > > Norman > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building FlightGear / getting some errors
Yes, it fails with exit "Error: The input line is too long". I was going to look into this a bit more but the real world is calling quite loudly at the moment. Is there anybody who has successfully built fgfs under mingw32? And does anybody know what I need to do to cull the UIUC and LARCsim files from the codebase in order to reduce the input length? Giles Robertson PS: I can't really give you much hard data until sometime later this week, unfortunately. > -Original Message- > From: Andy Ross [mailto:[EMAIL PROTECTED] > Sent: 19 April 2004 21:07 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Building FlightGear / getting some errors > > Giles Robertson wrote: > > Not that I've noticed. It would be useful for mingw32. I've tried > > building on that, and it compiles fine, but the linker fails because > > the input is too long ;). > > The linker fails with long file lists? That sounds odd -- this is the > same linker used in Linux, and it's always been quite robust in my > experience. Are you sure you aren't simply running out of memory or > swap? The final fgfs link is definitely memory-intensive. > > Andy > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building FlightGear / getting some errors
> 2) For an FDM developer, how can some of the FDMs be left out of the build > if a developer is only concentrating on development of one FDM? Is this > easily possible? Not that I've noticed. It would be useful for mingw32. I've tried building on that, and it compiles fine, but the linker fails because the input is too long ;). I've also tried cutting out file-expensive FDMs (read: UIUC & LARCsim), but that doesn't do the rest of the compile any good. I'll have another look into it when I've passed my current work crisis (huge). Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Trademark violations could be a problem
Let's check the patent filing dates etc. Could just be that we have prior art. Can anybody get a date that nasal was originally committed? Giles Robertson > -Original Message- > From: Lee Elliott [mailto:[EMAIL PROTECTED] > Sent: 26 March 2004 02:20 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Trademark violations could be a problem > > I was just reading about how M$ has recently started patenting lots more > of > their stuff than they used to - link: > > http://www.theregister.co.uk/content/4/36520.html > > and came across the following: > > 'The 139 patents assigned to the company by the USPTO already in 2004 > includes, "Systems, methods and data structures for encompassing scripts > written in one or more scripting languages in a single file using XML"' > > This sounds a lot like how some of us have used Nasal in the aircraft '- > set' > files. > > I hope it's nothing to worry about. > > LeeE > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: base package aircraft and aliases
Does anybody have a problem with a --fdm switch, defaulting to whatever's available if that aircraft isn't modelled with the fdm. That's the obvious extension of having a --2d and --3d switch. Giles -Original Message- From: Jon Berndt [mailto:[EMAIL PROTECTED] Sent: 17 March 2004 13:18 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] RFD: base package aircraft and aliases > I completly agree with that, please keep the aliases > and remove extenion names like jsbsim, 2d/3d etc. in the > --show-aircraft list. How will the situation be handled where several FDMs model the same aircraft - that day is coming if it is not here already. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Metakit?
This assertion also appears in the compile instructions. Giles Robertson -Original Message- From: Richard Bytheway [mailto:[EMAIL PROTECTED] Sent: 27 February 2004 14:02 To: FlightGear developers discussions (E-mail) Subject: [Flightgear-devel] Metakit? I noticed on the web site (http://www.flightgear.org/cvs/anoncvs.html) the assertion that Metakit is required: Metakit. A suitable version of MetaKit is included in the SimGear/src-libs/ subdirectory. If your distribution doesn't provide a Metakit (and Metakit-devel) package, you will have to build and install it before you can compile SimGear. I thought we had exorcised Metakit? Richard Bytheway ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
