Re: [Flightgear-devel] splash screen
On Sun, 16 Jan 2005 20:27:10 - Jim Wilson wrote: The problem is we're doing way to much before even getting that far. It looks like 90% of the delay is loading the Airport database. The problem is that loading the airport database take *much* (10 times) longer on Windows than Linux. That means that a lot of the core developers don't really notice this as much. We should be able to just load the configuration and parameters and do the rest of the work that's being done in fgInitMain after we get the loop going. Everytime I look at this init code I've got to relearn how it works. It is still a mess. Agreed. I had a look at some of it recently with a view to automatically starting on the into the wind runway with real-weather. At the moment it can't be done, since real-weather is dependent on position, and I'm trying to introduce the counter-dependency as well. What I think needs to happen is to init approx location first, then init the environment, then init exact location. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen
On Sun, 16 Jan 2005 22:20:07 +0100 Durk Talsma wrote: On Sunday 16 January 2005 21:54, D Luff wrote: On Sun, 16 Jan 2005 20:27:10 - Agreed. I had a look at some of it recently with a view to automatically starting on the into the wind runway with real-weather. At the moment it can't be done, since real-weather is dependent on position, and I'm trying to introduce the counter-dependency as well. What I think needs to happen is to init approx location first, then init the environment, then init exact location. David, as I mailed to you off-list (but probably not yet to FlightGear-devel), I'm working on extending the airport code. Part of the new code is going to be a function that returns the active runway for a specific airport. So, I guess, initialization could be something like (in pseudo code): 1) get airport 2) airport-get weather 3) airport/weather-getActiveRunway 4) user-init at active runway Hi Durk, Yes, if you're trying to more intelligently choose the active runway, then you're probably wanting both aircraft type and weather set before your runway choosing function gets called. Add stage 1a - get aircraft type (heavy, light etc). At the moment though, you'll be able to set the runway for all the AI traffic very nicely, but at startup you'll still have missing information at the time of setting it for the user, just as the current code does. Your mail is stuck in proprietry format on a box I can't boot at the moment BTW :-( As soon as it's resusitated (reinstall OS) I'll take a look at it. If it's still in your outbox, perhaps you could hit the send button again... 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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] applications for FGFS
On 26 Mar 2004 at 16:52, Erik Hofman wrote: Oliver C. wrote: And Taxidraw, another usefull tool for Flightgear Development. http://www.mail-archive.com/[EMAIL PROTECTED]/msg19682.html Yes, but there's no official URL... Ah, yes, I've got a half-written homepage knocking about - I'll try and tidy it up and put it up! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: RFD: base package aircraft and aliases
On 17 Mar 2004 at 13:00, Melchior FRANZ wrote: * David Luff -- Wednesday 17 March 2004 12:22: On an (almost) totally unrelated note, I think it would be a good idea to test unknown options against aircraft names, so that, for instance, bin/fgfs --T38 would work to bring up the T38. Would patches to add this be accepted? Urks. That would totally break Unix semantics. Options are options. Make that $ fgfs T38 I've always thought that it would be nice if fgfs would accept one optional argument that would start it in a situation. For example, one could make a file ~/.fgfs/situation/rescue that contains definitions to start with a bo105 (parked on a hospital helipad; doors open; engines off) or ~/.fgfs/situation/carrier etc. This would then be started as $ fgfs carrier. OTOH, one could easily do this with a wrapper ... OK, I convinced myself and I'll implement this in my fgfs starter script *now* ... :-) Maybe unix semantics are totally broken ;-) OK, I see your point. Please disregard the original brain-dump. I stand by my assertion that it's preferable for the short-form aircraft name to be the user-visible one when possible though. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: base package aircraft and aliases
On 17 Mar 2004 at 7:17, Jon Berndt wrote: 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. Use the short form name for the accepted 'best' aircraft (currently jsbsim for the c172, yasim for the 747 if an alpha jsbsim 747 were to show up) and add an extension for the other. Given that Curt is for trimming the size of the official release, there shouldn't be too many duplicates showing up (although I think having one plane such as the c172 with all fdms represented is good for comparision). See my suggested C172 example: c172c172p (jsbsim) c172-610x c172p with a full-screen, hi-res panel (jsbsim) c172-ifrc172p in IFR configuration (jsbsim) c172-yasim c172r (yasim) c172-larcsimc172 (larcsim) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tile queue
On 15 Mar 2004 at 7:14, David Culp wrote: I'm getting alot of this: Alert: catching up on tile delete queue on the console, in quiet mode, while flying the T-38. There doesn't seem to be any effect on the sim, though. Is there a way to make this go away? see http://baron.flightgear.org/pipermail/flightgear-devel/2004-February/025791.html You can make it go away by moving the tile manager initialisation in fg_init.cxx from before the view initialisation to after it. As far as I can see from a fair bit of testing this has no adverse affect on the fdm or viewer init, but I haven't checked through the fdm init code enough to actively push for this change yet. I have sometimes seen a slight pause on a Cygwin box when this happens, it's definitely something that should be sorted at some point. The pollution of the tile cache by the AI code mentioned in the thread above should now be fixed in CVS - AI traffic now only determines ground elev when in visual range, which by definition means with an already loaded tile. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Low poly model LOD request
I'm currently using the pa28-161 and the c172-dpm models for the AI traffic, both of which I believe are David M's models. These are great models, but there can be quite a few flying around in the field of view within a few miles, and this can have quite an impact on frame rates. And that's without even thinking about statics! Couple of requests - could the pa28 instruments get a range lod in the same manner as the c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
On 15 Mar 2004 at 9:41, David Megginson wrote: D Luff wrote: Couple of requests - could the pa28 instruments get a range lod in the same manner as the c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. It's not a hard task. Blender has a face-reduction function built in that does a wonderful job simplifying models -- the only problem is that you lose the UV mappings, so you have to spend an hour or so remapping textures. I will happily make the source for any of my Blender models (pa28, c172p, j3cub, dc3) available to anyone who wants to play with them; as a matter of fact, we should probably set up a permanent home for this stuff (*not* in the base package, though). Could you mail me the pa28 and c172dpm (the yellowish one) source please, and I'll have a play at some point. The low poly versions can loose their textures anyway - over half a mile away it shouldn't matter. A separate CVS repository of base file sources would be an excellent idea - there's other stuff besides models such as the docs that could benefit. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
On 15 Mar 2004 at 15:11, Erik Hofman wrote: D Luff wrote: c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. Maybe you could quit rapidly go to a model consisting of three double-sided, textured quads that are perpendicular to each other (X,Y,Z)? The trouble is that it's possible to zoom in quite a lot whilst flying to see what the AI traffic are up to, but due to the nature of the zoom (fov reduction) I suspect that the LOD of the model won't change, so it would be best if it looked at least something like what it's meant to! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] KSFO Terminal ???
On 6 Jun 2003 at 9:00, Norman Vine wrote: Innis Cunningham writes: So any windows people managed to fix this. Does it mean also if the file can be textured it will show?. I would love to add some buildings but untill we get this little problem sorted it will be a bit hard to see what I have built LOL. I haven't updated my files since just before the FGFS - SimGear reorganization but the SFO terminal shows just fine with my executable so if the terminal is not showing this is recently introduced problem. I've never seen the terminal on my Cygwin built exe, I've always seen it (since it's introduction) on my Linux built exe. Perhaps this is purely a Cygwin problem since yourself (MingW ?) and Fred B (MSVC) don't seem to have it. Is there anyone on the list who has seen the terminal on a non-MingW Cygwin build? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Segmentation fault in FGTower
On 11 Mar 2003 at 20:17, Martin Spott wrote: My UUCP connection is broken this afternoon, so I can't directly reply to dave's mail. Nevertheless I tried his patch - yet without success: Hmm, I'll have a think. If there's no resolution soon or if others start getting bitten by this I'll back this stuff out. This fault also as a nice side - I'm getting forced to learn about using CVS to update my local tree to a repository's former state ;-) You should presumably be able to just revert the ATC sub-directory to a few days ago. Since nothing in the main part of Flightgear depends on the ATC you'll still get the progress in the rest of FG without suffering this bug. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Re: Slow framerate near Burbank (real)
On 22 Apr 2002, at 13:16, Curtis L. Olson wrote: Who was it that said they might have put a bunch of C172 models on top of each other at the end of a runway at KEMT (El Monte, CA)? This is what is killing performance out of Burbank for Melchior. It is also (I believe) what is triggering the DList messages out of plib. Guilty as charged - that was me. It was experimental and meant to be removed before the release, but 0.7.10 came out before I even noticed! Since I haven't got time to finish that bit of code (make it fly circuits) at the moment it might as well be ripped out - I'll send a patch. Hopefully I should eventually be able to rewrite it using David M's 3D model interface without the problems it has now. Cheers (and sorry!) - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Re: Slow framerate near Burbank (real)
On 22 Apr 2002, at 13:11, Robert A. Knop Jr. wrote: Who was it that said they might have put a bunch of C172 models on top of each other at the end of a runway at KEMT (El Monte, CA)? This is what is killing performance out of Burbank for Melchior. It is also (I believe) what is triggering the DList messages out of plib. Aha-- that would make sense, if there's a whole lot of extra models. I'll go to that airport tonight and see if those puppies are all there. Why are they there? Can we get rid of them? Are there other airports with similar traps? No, other than too much texture usage for some older cards (KFSO hammers one of the machines at work). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] fuel measure
David Megginson wrote: Curtis L. Olson writes: What units are we measuring fuel quantity in these days? If not gallons, can someone give me a rough conversion from what we are using to gallons (ignoring issues such as temperature ...) The property system currently publishes the value using US gallons, but think that almost everyone agrees that using a volume measurement is wrong, since volume is relative to temperature and air pressure. For the big iron, yes, but for small piston planes I personally think volume is fine - after all, the panel guages are instrumented in volume, the pilots think in volume (AFAIK), and a float type fuel guage sender measures volume. BTW, clicking reply is defaulting to the poster rather than the list, is this something wrong on my end or have the list settings changed? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
Jonathan Polley wrote:
Doing some more investigation, I found that there is a runways.cxx in both
FlightGear/src/ATC and FlightGear/src/Airports. Are they the same?
OK, sorry for breaking things...
runways.cxx shouldn't be in ATC - get rid of it. It was in there
because I wasn't sure about the change to it and I thought Curt
should look at it before overwriting the proper one.
ground.[ch]xx is not meant to be compiling yet - remove it from
makefile.am - its in there purely so others working on the ATC can
see where its at.
In ATC.cxx change:
int FGATC::RemovePlane() {
}
to
int FGATC::RemovePlane() {
return 0;
}
to fix your compiler error.
The problem in approach.cxx is the good old (for int i= ...
business. Alexander - MSVC6 can't scope variable declarations
within a for loop declaration properly so you need to do
int i;
for(i= ... {
}
for(i= ... {
}
instead of
for(int i= ... {
}
for(int i= ... {
}
which works on conforming compilers.
Cheers - Dave
Thanks,
Jonathan Polley
On Wednesday, April 3, 2002, at 07:30 PM, Jonathan Polley wrote:
I just updated to the latest CVS and tried to build.
ATCmgr.cxx
c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715:
'FGATCMgr::GetATCPointer' : not all control paths return a value
JSBSim.cxx
c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' :
must return a value
Linux complains as well, but generates a WARNING for the second problem
instead of an error.
I then fix the error, updated to Erik's version of uiuc_menu.cpp, rebuild,
and I then get:
approach.cxx
c:\flightgear\src\atc\approach.cxx(360) : error C2374: 'i' : redefinition;
multiple initialization
c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
c:\flightgear\src\atc\approach.cxx(366) : error C2374: 'i' : redefinition;
multiple initialization
c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
ground.cxx
c:\flightgear\src\atc\ground.hxx(28) : error C2065: 'vector' : undeclared
identifier
c:\flightgear\src\atc\ground.hxx(28) : error C2501: 'SG_USING_STD' :
missing storage-class or type specifiers
c:\flightgear\src\atc\ground.hxx(29) : error C2065: 'list' : undeclared
identifier
c:\flightgear\src\atc\ground.hxx(29) : error C2501: 'SG_USING_STD' :
missing storage-class or type specifiers
c:\flightgear\src\atc\ground.hxx(29) : error C2086: 'SG_USING_STD' :
redefinition
c:\flightgear\src\atc\ground.hxx(49) : warning C4091: 'typedef ' :
ignored on left of 'struct arc' when no variable is declared
c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
missing ';' before ''
c:\flightgear\src\atc\ground.hxx(51) : error C2378: 'list' : redefinition;
symbol cannot be overloaded with a typedef
c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
missing ';' before ''
c:\flightgear\src\atc\ground.hxx(52) : error C2653: 'arc_list_type' : is
not a class or namespace name
c:\flightgear\src\atc\ground.hxx(52) : error C2146: syntax error :
missing ';' before identifier 'arc_list_itr'
c:\flightgear\src\atc\ground.hxx(52) : fatal error C1004: unexpected end
of file found
runways.cxx
c:\flightgear\src\atc\runways.cxx(40) : fatal error C1083: Cannot open
include file: 'runways.hxx': No such file or directory
I can fix the problem in approach.cxx, but the ones in ground.cxx I
cannot (I love the STL problems). Also, I have no idea where runways.hxx
went.
Thanks,
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Error running flightgear
Latest CVS simgear/flightgear/base compiles OK but crashes when running: Initializing FGLocalWeatherDatabase - Initialising spherical interpolator. [100%] Finished initialising spherical interpolator. out of memory The computer has plenty (512M) physical memory. Any ideas? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error running flightgear
Christian Mayer wrote: I doubt that it's caused in the WeatherCM code. Hi Christian, I don't think its in the WeatherCM either. On my development copy which worked until I did a cvs update only in the ATC directory I'm getting to: Initializing FGLocalWeatherDatabase - Initialising spherical interpolator. [100%] Finished initialising spherical interpolator. Registering event: weather update Loading Navaids VOR/NDB ILS and Marker Beacons Fixes ATIS out of memory This has Melchior's bug fixes applied only to atislist.cxx but *not* navlist.cxx, wheras in my 'clean' version on which I ran cvs update on the whole tree navlist.cxx also has his patches and probably dies there before the last bit of console output gets flushed. Does anyone know how I can revert to a previous version or date of specific files using CVS in order to test this? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error running flightgear
D Luff wrote: dies there before the last bit of console output gets flushed. Does anyone know how I can revert to a previous version or date of specific files using CVS in order to test this? OK, I can now confirm that the latest 'bug fixes' to ilslist, fixlist, navlist and atislist.cxx are crashing Flightgear on Windows. Can I request that the changes get rolled back out of the official CVS until this is resolved please, especially since they fix only valgrind/compiler warnings rather than user-visible bugs. Melchior, don't take this the wrong way, I appreciate what you're doing, but in this case somewhere along the line something is going pear- shaped. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error running flightgear
D Luff wrote: I've now found that its definately only atislist.cxx that is crashing, not navlist, ilslist or fixlist.cxx. Its quite possible that something that Melchior has done has uncovered a latent bug that previously wasn't triggered. I'll have a look, albeit with couts rather than gdb. OK, here's the problem. Melchior's patches are fine - leave them in. In my default.atis I have a comment line at the start - this started with // but looking at simgear/misc/stream.hxx I see it needs to start with # This fixes it. However, default.nav and default.ils both start their comments with // (where I copied it from !) so I don't know how they get away with it and default.atis doesn't. Cheers (and apologies Melchior) - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Minor nits
It seems to be minor nit time, so here goes: The tiled panel has lines between the sections - is anyone else seeing this or is it a Windows only problem. As someone else has pointed out, resizing the screen can cause the panel to obscure the runway. In general the panel could be made slightly less tall IMHO - the registration mark takes up otherwise unused vertical space and the instruments could be squeezed a fraction closer together vertically. Thats probably a matter of taste though. It would be much better to start up with the brake on (IMHO. The vibration (JSBSim) with the brake on at standstill occurs whether the engine is on or off. And a long standing one that I've never heard anyone else mention - I get other colours and textures bleeding through at the runway touchdown zones and numbers, when viewed at certain shallow angles. This happens on several varieties and combinations of Windows, processor and graphics card. I've not seen it on any of the screenshots that John and Curt have put up - am I the only one seeing this? And now NaN (Not-a-Nit) :-) the new engine starting sounds are excellent. Great stuff whoever came up with those. (Erik?) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Julian Foad wrote: Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. With Norman's main, maximising the window and then returning it to 800x600 leaves the external view of the plane (and probably the scenery but its hard to tell) all scrunched up. I suspect this is probably what you're looking for... Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Why doesn't this code work?
OK, I'm going to be a wimp and ask the list why this code doesn't
work. Basically I'm interested in the logic of making an AI plane fly
a pattern without hitting others, not in implementing its rendering,
and needing to render it is stopping me - I just can't get my head
round this view stuff and hoped I'd never have to!
The attached code is mostly copied from the DCS stuff in main and
is meant to produce a Cessna at KEMT. It doesn't. If anyone has
any idea why it doesn't I'd be most gratefull, since this is really
driving me nuts!! According to the console output ssgLoad loads
the Cessna model sucessfully, and the Transform() function is
called each timestep. Unfortunately all the matrix stuff might as
well be black magic to me, so there could be glaring errors in how
I've used it and I'll never find them. If it turns out to be a silly
mistake non-matrix/view/something-I-don't-understand-related then
I'll happily serve my penance by documenting something ;-)
Thanks - Dave
--
[EMAIL PROTECTED]
// FGAILocalTraffic - AIEntity derived class with enough logic to
// fly and interact with the traffic pattern.
//
// Written by David Luff, started March 2002.
//
// Copyright (C) 2002 David C. Luff - [EMAIL PROTECTED]
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
/*
*
* WARNING - Curt has some ideas about AI traffic so anything in here
* may get rewritten or scrapped. Contact Curt [EMAIL PROTECTED]
* before spending any time or effort on this code!!!
*
**/
#include main/globals.hxx
#include scenery/scenery.hxx
//#include simgear/constants.h
#include simgear/math/point3d.hxx
#include simgear/math/sg_geodesy.hxx
#include simgear/misc/sg_path.hxx
#include string
SG_USING_STD(string);
#include AILocalTraffic.hxx
extern ssgRoot* scene; // The global Flightgear scene graph
FGAILocalTraffic::FGAILocalTraffic() {
}
FGAILocalTraffic::~FGAILocalTraffic() {
}
// In AILocalTraffic.hxx we have:
// ssgEntity* model;
// ssgTransform* position;
void FGAILocalTraffic::Init() {
// Hack alert - Hardwired path!!
string planepath = Aircraft/c172/Models/c172-dpm.ac;
SGPath path = globals-get_fg_root();
path.append(planepath);
ssgTexturePath((char*)path.dir().c_str());
model = ssgLoad((char*)planepath.c_str());
if (model == 0) {
model = ssgLoad((char*)Models/Geometry/glider.ac);
if (model == 0)
cout Failed to load an aircraft model in AILocalTraffic\n;
} else {
cout AILocal Traffic Model loaded successfully\n;
}
position = new ssgTransform;
position-addKid(model);
// Hardwire to KEMT
lat = 34.086659;
lon = -118.031982;
elev = 296.0 + 10.0; // Ground is 296 so this should be above it
heading = 90.0;
pitch = 0.0;
roll = 0.0;
Transform();
}
// Run the internal calculations
void FGAILocalTraffic::Update() {
// No logic to move the plane yet since we can't even render it :-(
Transform();
}
void FGAILocalTraffic::Transform() {
// Most of this is copied straight from the ADA DCS stuff
double bz[3];
double sl_radius;
double latgc;
//Geodetic to Geocentric angles for rotation
sgGeodToGeoc(lat,elev,sl_radius,latgc);
//moving object gbs-posn in cartesian coords
Point3D obj_posn = Point3D(lon, lat, elev);
Point3D obj_pos = sgGeodToCart( obj_posn );
// Translate moving object w.r.t eye
Point3D Objtrans = obj_pos - scenery.get_center();
bz[0] = Objtrans.x();
bz[1] = Objtrans.y();
bz[2] = Objtrans.z();
// rotate dynamic objects for lat,lon alt and other motion about its axes
sgMat4 sgTRANS;
sgMakeTransMat4( sgTRANS, bz[0],bz[1],bz[2]);
sgVec3 fwd, rt, up;
sgSetVec3( fwd, 1.0, 0.0, 0.0);//east,roll
sgSetVec3( rt, 0.0, 1.0, 0.0);//up,pitch
sgSetVec3( up, 0.0, 0.0, 1.0); //north,yaw
sgMat4 sgROT_lon, sgROT_lat, sgROT_hdg, sgROT_pitch, sgROT_roll;
sgMakeRotMat4( sgROT_lon, lon * SGD_RADIANS_TO_DEGREES, up );
sgMakeRotMat4( sgROT_lat, 90-latgc*SGD_RADIANS_TO_DEGREES, rt );
sgMakeRotMat4( sgROT_hdg, 180.0, up );
sgMakeRotMat4( sgROT_pitch, pitch, rt );
sgMakeRotMat4( sgROT_roll, roll, fwd );
Re: [Flightgear-devel] Why doesn't this code work?
D Luff wrote: OK, I'm going to be a wimp and ask the list why this code doesn't work. OK, I've got it sorted now (well at least I sort of understand roughly where I'm meant to be going). You can all ignore the last desperate post - it was sent in a moment of temporary insanity! Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Adding arbitrary 3D model to scene
Is there currently anywhere in the code where I can say: Here's a ssgEntity already loaded. Here's its position, heading, roll and pitch this frame, draw as appropriate (ie work out the appropriate transform in relation to the viewer for me). Allow the position, heading roll and pitch to be updated whenever necessary. Repeat until I decide it's gone out of view and cancel it. ? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem loading aircrafts
Marcio Shimoda writes: Hi! I'm having problems to load aircrafts... The command line flightgear --aircraft=c172 results in WARNING: ssgLoad: Failed to open '/flightgear//flightgear/Aircraft/c172/Models/c172-dpm.ac' for reading Why??? It looks like its looking at the wrong path, judging by the double forward slash in it. Are you on Windows? I'm seeing the same thing if I startup with a separate base directory and explicitly set the FG_ROOT, eg set FG_ROOT=f:\unix\cvs_base\fgfsbase gives: Failed to open f:/unix/cvs_base/fgfsbase/f:/unix/cvs_base/fgfsbase/Aircraft etc and if I set FG_ROOT=f:\unix\cvs_base\fgfsbase\ I get a double forward slash in there as you do. but if I put the base in the same root as the bin and set FG_ROOT=. (the default) then it works OK. It seems that an explicit FG_ROOT gets set twice, and I would hazard a guess that this only affects Windows machines. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Comms
A few quick questions to the pilots about comm radios - do you hear transmissions from both comm1 and comm2 if appropriately tuned in without having to expicitly switch between them. If so, do simultaneous transmissions get overlaid and garbled or does it just play the strongest one. And can I assume that two comm radios is the most anyone will ever have or do some planes have 3, 4, more? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comms
Alex Perry writes: Each radio operates independently and will receive whatever is onchannel. However, usually the radios (and other things that make noises) are wired through the so-called audio panel that decides which combination of sounds is sent to the speaker and/or the headset and/or any other place that sound can be heard. So supposing a pilot is communicating with approach on comm1, but has comm2 monitoring the tower, what happens if a stronger tower transmission is received at the same time as an approach transmission? Will the audio panel loose it, or play them in sequence? And would a pilot actually set his radios up like that, or simply have the tower frequency in comm1 standby ready to switch over? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Mike Marhoefer
On 4 Mar 2002, at 15:54, Curtis L. Olson wrote: Can anyone confirm or deny this? My virus checker (F-Secure) say's its clear, and the md5 sum is the same as the one in the original tar.gz file that I downloaded from Cygwin. I would be extremely surprised if it really is infected. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
On 5 Mar 2002, at 8:40, Curtis L. Olson wrote: David, This is going to mess up rendering of distant mountains for people with voodoo cards (i.e. 16 bit buffers). And not just 16 bit cards - I get flashing polygons in the sky with two different 32 bit cards at 0.5, progressively cured by pushing out to 1.2ish, although no-one else seems to be afflicted by this. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Alex Perry writes: and for the latter you're in ground haze in any case. You Californians speak for yourselves! :-) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Strangeness
Paul Deppe writes:
Gents,
With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the
textures in mountainous areas seem to walk across the ground and appear
and disappear in a very strange manner. I am wondering if anyone else sees
this problem.
You're almost certainly seeing some of the effects of bringing the
near clip plane right in, which occured in today's CVS. Try backing
out the change below and see if that helps. It will probably get
changed back (or to something else) at some point anyway.
Cheers - Dave
Index: main.cxx
=
==
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/main.cxx,v
retrieving revision 1.245
retrieving revision 1.246
diff -C2 -r1.245 -r1.246
*** main.cxx3 Mar 2002 22:20:55 - 1.245
--- main.cxx5 Mar 2002 12:35:48 - 1.246
***
*** 662,673
globals-get_current_view()-get_v_fov() );
! double agl = current_aircraft.fdm_state-get_Altitude() *
SG_FEET_TO_METER
! - scenery.get_cur_elev();
!
! if ( agl 10.0 ) {
! ssgSetNearFar( 10.0f, 12.0f );
! } else {
! ssgSetNearFar( 0.5f, 12.0f );
! }
current_model.update(0); // FIXME: use real delta time
--- 662,666
globals-get_current_view()-get_v_fov() );
! ssgSetNearFar( 0.1f, 12.0f );
current_model.update(0); // FIXME: use real delta time
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re [Flightgear-devel] Taxiway signage and default.apt file
Curt Olson writes: D Luff writes: Yes, that's basically what I'm planning to do. I keep forgetting you're a driving sim guy and probably have some very relevant expertise here. What co-ordinate systems are you using? That's not a trivial question to answer, why don't I say we are using the MN state plane coordinate system which maps into X, Y, Z with Z being up, X being in the longitude direction, and Y being in the latitude direction. I'm rapidly coming to the conclusion that nothing about coordinate systems is ever trivial :-) At airport level lat/lon spherical co-ordinates are really overkill for whats basically a planar problem. I was considering assuming that for a limited area (a few miles each way) one could assume that lines of lat and lon were straight and parallel, and possibly map the lat/lon to x/y depending on latitude to get the x and y axis subdivisions equal. This would be a lot cheaper that doing proper spherical - planar projection. The logical network would be defined in terms of these x,y and the airplanes lat/lon quickly and cheaply converted. Comments? For doing 2d positions near the airport that might be ok, but when you calculate which heading you want to travel to go from point A to point B, you might be a fair bit off if you don't use spherical or wgs-84 coordinates. This could result in the autonomous airport traffic taxing off the edge of a long taxiway, or getting pushed off the edge of a long runway, or doing other odd stuff. I think that should be OK, since the end points of all the long runs will be defined in the logical network in x,y, and they will have been converted in the same manner as the plane is, so it should hit them spot on. I'm just a touch worried that it will appear to describe an arc down the runway though as it gets converted to WGS84 in my simple scheme for rendering. Still, if it doesn't work I can always use a full conversion to WGS84 for both the network and planes. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re [Flightgear-devel] Taxiway signage and default.apt file
Curt Olson writes: Well as you get towards the poles the distortions increase if you are using a lon/lat = x/y projection. The flaw in your logic is if you map lon/lat directly to x/y headings in this coordinate system will be significantly different from headings in the real world (or the wgs-84 approximation to the real world.) Since flightgear uses a wgs-84 world, the heading you have to follow in flightgear to get to some lat/lon will be significantly different than what you are calculating. If FlightGear used the same projection then you'd be ok, but the headings in the two projection become significantly different as you move away from the equator. There are plenty of hacks you could use to make things work, but be careful because usually these hacks will come back to bite you later. :-) Hack!%? I'm sure the phrase you were looking for was 'design time optimisation' :-) Still, I take your point. I'll probably stick to using Flightgears existing coord systems. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: DC-3 model now animated
Alex Perry writes: What about cowl flaps? All of my experience is with jets, what exactly are cowl flaps? For aircooled engines, the flaps either constrain the airflow into the engine compartment, or constraint it coming out of the compartment. The C172RG has them underneath behind the gear. Flaps are open at slow speed and high power settings (eg climb) and are closed at high speed and low power (eg cruise). Hmm, I suppose I really ought to take some consideration of this into the CHT model. Are these a manually operated thing? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken Code
David Megginson writes: There are two important C++ APIs you have to learn for properties -- I added extensive documentation comments to both so that contributors won't have to guess how to use them. The low-level implementation is declared in simgear/misc/props.hxx, and Curt has autogenerated HTML documentation here: http://www.simgear.org/doxygen/props_8hxx.html Most of the time, though, you can get away with using the higher-level functions declared in src/Main/fg_props.hxx. Curt hasn't generated HTML documentation from this yet, but if you look at the file, you'll see about a 1:1 documentation:code ratio, and the comments are fairly easy to read. You can look at many parts of FlightGear to see how properties are being used in actual code. src/Main/fgfs.hxx is also a good spot to read the comments. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATC
Now that 0.7.9 is released I've got round to looking at the subject of ATC again. This is probably going to be a long post so make sure you've all had your coffee :-) I basically hacked the ATIS support into Flightgear, on the grounds that is was the simplest possible part of ATC to implement, and could be done by that kind of thuggery. As the ATC gets extended though this approach won't be good enough, so after some thought I've come up with a proposed ATC architecture within Flightgear. I'm not an experienced programmer as far as architecture goes though (this is the only large scale C++ code that I contribute to) so I'd like to throw it out to the rest of you for consideration. At the moment I've modelled the comm/ATIS interaction on how the nav/VOR adf/ADF works in FGRadioStack. The FGRadioStack::Search() function searches for valid stations and flags hits. The FGRadioStack::Update() function processes the results of valid hits, updating the vor/adf/ils needles, and managing and updating the atis transmission. This works fine for vor/nav/adf etc since the pilot is only concerned with his/her own instruments, and it is a fairly well bounded problem. It's going to fall down with ATC since potentially the system must display messages from/to other aircraft, and the problem is much larger in scope and will thoroughly mess up radiostack.cxx. Hence I propose that all FGRadioStack does is to either just supply the selected comm frequencies to an ATC manager, or possibly do the station lookup in the Search() function and then flags hits to relevant stations to the ATC manager. The latter has the advantage that any work done by the navaid people to better model the limits of reception may be used by the comm stuff. The former has the advantage that the ATC manager will probably have to have the capability to do station/frequency lookups anyway for the AI traffic. For the ATC itself, I propose that the overall ATC is handled by one global FGATCMgr. This will accept input from several sources; the radiostack of the current aircraft (as discussed above), the position of the current aircraft, the AI traffic module, and an input module to parse input from the user of the current airplane. It will output to one global FGATCDisplay module (as the hack does at the moment) for rendering of the ATC output, either to screen or voice or both, and also directly to the AI traffic module. It will maintain instances of FGATIS, FGTower, FGEnRoute, FGGround etc as needed, possibly more than one instance of each if required. These sub-modules will do the actual work of generating the transmission contents. Its possible that it might be necessary to write an FGFlightPlan module as well - can someone tell me whether real life ATC actually knows whats in a flightplan after its been filed or is it simply a case of the pilot just requests what's on his/her flightplan? ATC potentially requires large amounts of data - airways, sid/stars, frequencies for all the types of ATC, etc etc. For now I will carry on with the STL map approach that the airport data and atis uses, but try to compartmentalise the reading of the data such that it will be easy to just change the data access functions if we want to move to a database or whatever in the future. None of this is going to appear very quickly (unless someone else is already working on it or planning to!) since I am very time pressed, but I will start implementing this, so get comments on the architecture in now if you think I'm going wrong please. If anyone else is working on aspects of ATC/AI traffic modelling please give me a shout since I've no desire to duplicate work. I'm sure someone mentioned on this list once that they were working on canned voice ATC, or was I imagining it? Due to the natural physical splitting of ATC into ground/tower/approach/departure etc in real life its also a prime candidate for a collaborative approach if anyone who wants to contribute to Flightgear but doesn't know where to get started fancies pitching in... Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: David Megginson writes: What you need to do is isolate the tile manager completely, so that it has (almost) no dependencies on the rest of the program, except for one structure for data exchange. I don't think the solution can be that trivially simple. The render thread has opengl/scene graph dependencies. The tile pager has opengl/scene graph dependencies. That in itself forces you to do a *lot* of horsing around. For instance, you can't directly call a plib model loader in the tile paging thread because that could involve creating textures (which would involve opengl calls) and you'd open yourself up for strange crashes and wierd visual anomalies. Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC
On 25 Feb 2002, at 11:00, D Luff wrote: thoroughly mess up radiostack.cxx. Hence I propose that all FGRadioStack does is to either just supply the selected comm frequencies to an ATC manager, or possibly do the station lookup in the Search() function and then flags hits to relevant stations to the ATC manager. The latter has the advantage that any work done by the navaid people to better model the limits of reception may be used by the comm stuff. The former has the advantage that the ATC manager will probably have to have the capability to do station/frequency lookups anyway for the AI traffic. In fact, after looking at it, I think I'll just get the comm frequencies directly into the ATC manager with the bind method and rip all of the comm stuff out of radiostack. Any objections? Also, am I right in thinking that the global ATC manager and ATC display manager should both be derived from FGSubsystem and declared in FGGlobals in order to fit in properly with the future direction of FlightGear? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: D Luff writes: Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Surely it is possible, but if your goal is to push all time consuming portions of the tile paging process out into a separate thread to avoid rendering pauses, then this doesn't buy you as much as you might hope. Fair enough. I was under the impression that it was the disk access taking the time. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Orphaned code
Since someone has mentioned cleaning up unused code, the old Phil Schubert engine models aren't used. The files are 10520d.cxx 10520d.hxx ps-10520c.cxx and 10520c.hxx in the fdm directory, also pstest.exe which is built from the latter. Phil is still credited in the IO360.cxx file which grew out of these models initially so we wouldn't be removing him totally :-) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Crossing runways
Some time ago I recall a dicussion on the correct way to handle the markings when runways crossed, which I don't recall ever being definitively decided. The images at: http://www.spaceimaging.com/gallery/ioweek/archive/iow093001/iow 093001.htm clearly show that our present way of simply overlaying one runway with another seems to be correct, at least in the US. All we are lacking is some logic as to the order of importance of the runways. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
Curtis L. Olson wrote: As people build executables for these platforms it would be great to be able to point to them. Dave, were you going to do the windows binaries like you did for the pre releases? I can do. I assumed Norman would provide a MingW compiled one, but he doesn't seem to be around at the moment. I've put a Cygwin compiled one up at http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9.zip You can download it from there and put it on the main FlightGear server. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
David Megginson writes:
No, that's not right after all. Following a message from Jon Berndt,
I took a peek at the property browser, and the wind-{north|east}-fps
is the to- direction, not the from- direction. JSBSim was using the
from- direction already, while the other FDM's were usign the to-
direction. In any case, the command-line option now works properly,
and all the FDMs behave the same way; it's just that the properties
need to be interpreted differently.
So, what do we do?
Meteo convention is from - hence the command line should use
that.
All fdm writers can use whatever vector convention they wish
internally as long as they document it.
Since the wind-{north|east}-fps property may be accessed by any
fdm it should follow a clearly documented convention - I would
suggest the meteo convention.
Each fdm can then process the property however it likes when
converting into a vector.
For clarity, how about we rename the property from wind-
{north|east}-fps to wind-from-{north|east}-fps or wind-to{north|east}-
fps, depending on which is chosen.
How's that for a solution?
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release windows binary
Alex Perry writes: Alex Perry writes: * On a G400 card with lots of memory, I'm getting 4fps out-the-box. This is down from the high 20s previous versions. It improves to 14fps if I get rid of the Textures.high directory temporarily. Thus, the decision making for texture sizing could be better. Is this built --with-logging or --without-logging? Dunno. It was the pre2 prebuilt binary from the Nottingham server ... It was built without logging: CFLAGS=-Wall -O2 CXXFLAGS=-Wall -O2 ./configure --without- logging The JSBSim logging is still output but most of that is not output during actual flight. I get fine framerates with it - they seem to be fill-rate limited at 37fps at 1152x864 on an Athlon 1.2 with Oxygen VX1. On a P350 with a 32MB ATI card (one of the Rage Chipsets - no TL) I get high 30's (probably fillrate limited) most of the time in the UK, dropping into the teens around high polygon areas such as KSFO. I have noticed that some cards get hit very hard at the larger airports (ie KSFO), dropping to low single figures when looking at the airport, but they are generally 8MB cards. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
Curtis L. Olson writes: I'd prefer the scrolling text to be off be default. Again for the sake of realism, you don't have scrolling text across your windshield in a real plane. I know this is a compromise because we are in a simulated environment, and it's a nice feature, but I think I would prefer to have it off by default. I'd agree with that as well. Logically, the pilot should be tuned to tower when on the runway, having listened to the ATIS transmission prior to startup. Leaving it as the standby frequency means that people can find it very easily if they wish. May I also suggest that we change the primary nav frequency, since it is tuned to a VOR that is just out of range, and hence flicks back and forward. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
Jim Wilson writes: It's mine...started with a photo: http://www.aircraftdealer.com/hdmandassociates/list_1/images/panel-1.jpg But as you can see there isn't much resemblence to the photo other than general shape of the corner. It was the wrong perspective etc, etc. I've put a photo of a C310 panel that I took about 15 years ago up at: http://www.nottingham.ac.uk/~eazdluf/C310Panel.jpg in case its of any use to any of the artists. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations on latest cvs flightgear
David Megginson writes: Andy Ross writes: The startup stuff, though, should be really simple. What do I do, check the cranking flag and add some delay before it turns over? It would be better to have a cutoff RPM where the engine stops running. As long as the cranking flag is set, keep incrementing RPM slightly; once RPM hits the minimum cutoff, the engine can cough to life and run on its own (assuming available fuel, etc.). That doesn't really mimic what happens though. The torque curve of the starter motor means that the engine should spin up to its cranking speed very quickly. I'd go with the first scheme - just adding a bit of delay before it will fire when cranking. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Two more stray couts
In atis.cxx, line 163: cout cloudbase = cloudbase endl; This one can be commented out. And in runways.cxx, lines 84 and 124: cout index = index endl; should be either commented out or turned into an SG_LOG Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Second pre-release Windows binary
I've put up a Cygwin compiled binary of the second 0.7.9 pre- release candidate up at: http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9pre2.zip in case anyone with windows but without a compiler wants to test it. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
Curtis L. Olson writes: David Megginson writes: I am convinced that we're best off starting with the engines idling rather than off, since our default start is always on a runway (even if you specify a different airport). No C++ code changes are necessary, other than a small bug-fix to JSBSim.cxx; I've just changed some properties in the default settings for the c172, c182, and c310 so that they now all start at an idle (you'll note that the C-310's idle is too high, but we'll have to fix that after 0.7.9). If Curt and the rest of you hate this change, I'm happy to roll it back out, but I've been hearing some very strong arguments against putting 0.7.9 out with engines off by default and no arguments in favour. Since this is a config-file change rather than a change to the code base proper, I hope no one minds slipping it in. I'm not entirely sure I like it, but I acknowledge that starting on the runway with engines off is not very realistic. I think its probably for the best, certainly for 0.7.9, if only because the obvious way to work the magnetos - left mouse clicking round and then holding down for the starter - doesn't work yet, and the full set of items to check isn't done yet anyway, such as master power and fuel selector switches. We will undoubtably get a lot of how? posts from users if we leave the engines unstarted, especially as we don't currently have a checklist that can be brought up from the menu. Of purely historical interest, ProPilot99 started on the runway with engines off. I hated it at first, since I was used to MSFS and had to actually read something to get in the air! However, once I got used to the sequence and managed to remember it I liked the fact that it had forced me to learn it. We do need to make sure that proper engine start modeling doesn't get lost because no one is testing it anymore ... I'll still be testing it :-) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
Curtis L. Olson writes: Here's my list of things that have been changed, fixed, or added for 0.7.9. It's rather long, but if anyone sees any major ommissions or errors in this list, please let me know. Thanks. * Fixed a bug preventing the LaRCsim engine from starting. This fixes a bug that was introduced since 0.7.8 so perhaps shouldn't be in the list? * EGT doesn't show 'running' values while cranking. should be 'LaRCsim EGT doesn't show...' etc. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Time offset still not working as before
With an update of simgear/flightgear/base from cvs a few minutes age, time offset still appears to be broken, although it appears to be behaving slightly differently. (Broken from initialisation, instead of from the first lighting update). I believe that starting mid-morning from my local airport with --time- offset=-8.00.00 should put me back in the night? This is what used to happen. At the moment the lighting is still day time. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaid bug?
John Check writes: On Monday 11 February 2002 11:58 am, you wrote: The frequency on nav1 appears to influence the to/from flag on both vor1 and vor2. I assume that this is a bug? Cheers - Dave What plane, what panel? TTYL J Default C172 but I see you've fixed it now :-) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] warning: suggest parentheses around assignment used as truth value
In net_send.cxx, in NetworkOLK, we have the following at line 262:
if (host_info = gethostbyname( src_host)) {
at line 270:
if (host_info = gethostbyname( fgd_host)) {
and at line 298:
if (host_info = gethostbyname( fgd_host_check)) {
Surely these are mistakes?
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] warning: suggest parentheses around assignment used as truth value
Curtis L. Olson writes:
gethostbyname() returns NULL if an error occured.
Expressions such as (a = b + c) evaluate to whatever value is assigned
to a so we can do things like
if ( a = b + c ) {
// a != 0
} else {
// a == 0
}
This is a little tricky, so if gethostbyname() fails, host_info will
be assigned a value of NULL and the whole entire expression then
evaluates to NULL so this should work (at least on systems that define
NULL to be 0x00.)
Thanks, I see whats going on now. I don't particularly like it
though!
a = b + c;
if(a) {
...
} else {
...
}
seems like a much better construct to me - trading a touch of
consiseness (is that a word?) for complete clarity as to the authors
intent.
That said, the entire NetworkOLK module is only half implimented, and
not really useful at this point. We really need someone to come along
and finish it, or perhaps reimpliment this functionality from scratch
using the plib networking libs.
I must confess I wasn't looking at doing anything with NetworkOLK,
simply compiling with -Wall.
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Control inputs still initialised strangely
Curtis L. Olson writes: Is there anything strange in your .fgfsrc or system.fgfsrc files? I don't have a .fgfsrc or a system.fgfsrc file anywhere on my computer. Should I? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time offset still not working as before
Curtis L. Olson writes: The time parser is expecting something like -8:00:00 (note : not .) My fault - I'm not keeping up!! It seems to work OK with the correctly formated parameter. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Control inputs still initialised strangely
Melchior FRANZ writes: What about fgfs --trace-write=/controls/aileron? (Watch for TRACE: ... lines, or filter through '21|grep TRACE'.) Does the aileron already start with wrong values from the very beginning? OK, during initialisation, the following is output: FGJSBSim::set_Velocities_Local_Airmass: 0, 0, 0 TRACE: Write node /controls[0]/aileron[0], value0.00 Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Adding condition to binding Panel visible = 1 TRACE: Write node /controls[0]/aileron[0], value-1.00 Finally initializing fdm So it seems to me that it is initially set correctly, but then for some reason it is overwitten. Any ideas? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Control inputs still initialised strangely
OK, this is now fixed. It was because NT had a joystick driver installed, but no joystick connected. Removing the joystick driver results in the controls starting centered again. My apologies for bugging you all with this! Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations on latest cvs flightgear
Curtis L. Olson writes: I'm not seeing this at all on my end. The controls all start out centered for me. Are you running with keyboard input, or joystick for the yoke? This is with keyboard. You are the only one who I've heard report such a thing. OK, I'll assume some local mods or inconsistancies have slipped into my supposedly clean tree or base. I'll check the 0.7.9 pre- release candidates for this completely separately from any possible corruption! Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Small bug report
Melchior FRANZ writes: looks quite polished, BTW, IMHO better than the current font. Of course, the radio displays don't look good with a proportional font. But I guess that plib can handle more than one font at the same time. :-) The radio displays could really do with a red LED font at some point. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Observations on latest cvs flightgear
Here's my observations from testing the latest cvs
flightgear/simgear/base:
The fixed turn co-ordinater in JSBSim is great, unfortunately it
doesn't work (freezes) after a reset. Its quite literally 'fixed' then ;-)
The output from SG_INFO to the console (Event states, mouse in
view/pointer mode, lighting updates and tile updates) can cause
nasty pauses on Windows 98 even with the console window
minimised, far worse than on NT on the same hardware. May I
suggest that we turn off all the console output during flight by
default and let users turn it on if they wish.
I get flashing polygons in the sky when on or near the ground.
Pushing the near clip plane out a touch fixes this. In main.cxx at
line 679 changing:
if ( agl 10.0 ) {
ssgSetNearFar( 10.0f, 12.0f );
} else {
ssgSetNearFar( 0.5f, 12.0f );
}
to
if ( agl 10.0 ) {
ssgSetNearFar( 10.0f, 12.0f );
} else {
ssgSetNearFar( 1.3f, 12.0f );
}
seems to do the trick, and viewing straight down still doesn't clip
the runway. Any objections to putting this in?
JSBSim seems over sensitive to rudder during the takeoff run,
making it *very* hard to maintain direction during takeoff. It seems
very keen to get into the air at the moment as well. IANAP though
so maybe I've just been softened up by too many over-easy
simulator models over the years.
The aileron starts up at full left deflection on all flight models.
Whilst this might be how real ones are left, and whilst we all ought
to preflight, a lot of people are going to wonder why the plane
suddenly goes all over the place on the runway.
YASim initialised at about 40 knots charging down the runway,
with the engines running and the magnetos off. Due to the
aformentioned full left aileron I didn't get very far.
The JSBSim engine starts before the cranking sound starts playing.
The LaRCsim engine cranks and cranks and cranks and ... oh
dear, seems to need an overhaul, it won't start.
LaRCsim reports running values of EGT whilst cranking and not
starting.
I guess I'd better look at the above 3 points!!
Overall, though, its looking great, and obviously reflects a lot of
hard work that a lot of people have put in. Its really come on a hell
of a lot since 0.58, which was the first version I ever ran. Highlights
for me are the fantastic wet compass, which behaves in turns
exactly as described in a flight training book I had out of the library,
the fantastic artificial horizon, which is beautifully fluid in turns, and
the jointing cracks down the centerline of the concrete runways.
The whole thing is really looking good though :-)
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS
Christian Mayer wrote: It'd also be great if someone can tell me how to use ATIS myself so that I can try it as well... Look up the atis frequency of your local airport (Googling with ATIS and the relevent airport ICAO code seems to get the frequency in the first 5 hits every time). Tune into it with the comm radio. You should then see the atis display, *if* the airport is in the atis database. The atis database (default.atis) is built from the DAFIF data and there is a chance of finding an airport in default.apt that was not in the DAFIF, but most European and US airports with ATIS should be in. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
Jon Berndt writes: No. That was going to be my next guess. Thanks, I'll try that! Mark I've got a perl script (and I believe Norman also has a script) that automates that whole process for me, in the corret order, with dependencies. If you do a checkout of flightgear, you should also do a checkout of Simgear and plib. FGFS depends on SimGear which depends on plib. The latest stable Plib (1.4.2 I believe) should also work (It does for me). It shouldn't be necessary to keep checking out CVS Plib. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim and MSVC
Curtis L. Olson writes: Christian Mayer writes: PS: So there's just the #include zlib.h issue left to be fully MSVC friendly... Typically in the unix world, you would install packages like zlib into a place where the compiler expects to see them, or some other place and inform the compiler where to look. In the linux world, the packaged version of zlib would typically install the library in /usr/lib/libzlib.a and the header in /usr/include/zlib.h If you were compiling and building the package from source yourself, the convention is 'usually' that you put it in /usr/local, so /usr/local/lib/libzlib.a and /usr/local/include/zlib.h The configure script automatically tells the make system to tell the command line compiler to look in /usr/local/ for includes and libs: -I/usr/local/include and -L/usr/local/lib I would think that in MSVC you should be able to do something analogous. Either install the libs and headers someplace where the MSVC compiler expects to find these things, or install them someplace else and tell the compiler where to find them. Surely you can just put libzlib.a in vc\lib and zlib.h in vc\include? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear problem + Misc other stuff
David Findlay wrote: Would it be possible to create a FlightGear Scenery Design mailling list? The Terragear mailing list would seem an appropriate place for now, especially as a lot of scenery design is likely to need modification of the tools. FWIW, I'm currently working on adding the ability to add files containing hand-crafted vector elevation data to the raster data during construction, in order to allow dem-30 based hilly areas to be manually improved. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Manifold pressure
Frederic Bouvier writes: I am wondering why the manifold pressure indicator of the c172 panel is changing while moving the throttle knob and the engine is **off** ( 0 RPM ). When I do my checklist in my plane, engine off, I verify that this pressure is the same as QFE, and during flying, the value is decreasing, not increasing. Erm, that would be a bug. I'll look into it. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Manifold pressure
Jon Berndt writes: It shouldn't be too hard to make MP dependent on throttle position AND whether it is operating or not - plus with some small lag in there. Would that be better than what is there, now? Thats what should be in there now, and is in LaRCsim (well - without the lag anyway). I've obviously thought it went into JSBSim but never actually put it in there. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem in FGPiston
Frederic Bouvier writes: There is an invalid float operation in FGPiston when the engine is off : in void FGPiston::doAirFlow(void) ... double swept_volume = (displacement_SI * (RPM/60)) / 2; double v_dot_air = swept_volume * volumetric_efficiency; m_dot_air = v_dot_air * rho_air_manifold; ... RPM is zero so m_dot_air is zero, and in void FGPiston::doEGT(void) ... double heat_capacity_exhaust = (Cp_air * m_dot_air) + (Cp_fuel * m_dot_fuel); double delta_T_exhaust = enthalpy_exhaust / heat_capacity_exhaust; ... heat_capacity_exhaust that depends on m_dot_air is zero so we should have a div by zero error but enthalpy_exhaust is also zero I think we need a special case for engine off here. Good catch. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re manifold pressure
Jon Bernt writes:
I added this in last night to JSBSim. Don't know if it's correct or
not, it
just felt right. Do you have something already in LaRCSim that
we might
steal? Or is what I put in OK:
void FGPiston::doManifoldPressure(void)
{
if (Running ) {
ManifoldPressure_inHg = MinManifoldPressure_inHg +
(Throttle * (MaxManifoldPressure_inHg -
MinManifoldPressure_inHg));
} else if (Cranking) {
ManifoldPressure_inHg += dt*(ManifoldPressure_inHg -
MinManifoldPressure_inHg / 6.0)/2.0;
} else {
ManifoldPressure_inHg = 0.0;
}
}
It was a quick and dirty fix. Comments?
Jon,
If its not running or cranking, manifold pressure = ambient (~29.92
in HG), NOT zero. (see LaRCsim)
If its running or cranking leave it as it is.
There should be a better handling of the manifold pressure at
different rpms (pressure drop across the throttle is mostly a
function of throttle position, but partly a function of the flow rate
past the throttle) - this is on my todo list.
Right now I'm wobbly after the Christmas Do so this is my last
comment on this for a while.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What data is currently used for UK scenery?
David Megginson writes: Landuse in Curt's official scenery is USGS 30-arcsecond. For my personal scenery, I'm using VMap0, just to get shaped areas (even though the resolution isn't as good). Thanks David. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What data is currently used for UK scenery?
Could someone please tell me exactly which data sources are used for the currently available scenery build, specifically in the UK? Thanks - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compass problem?
Martin Olveyra writes:
I dont know if it is a realistic effect, but, since some cvs versions ago,
the compass is stalled most of the time, so it is impossible to know the
real magnetic heading.
This is because of the skid-slip indicator problem with JSBSim. Some
code in stream.cxx locks the compass during severe slip/skids.
JSBSim seems to output much larger acceleration vectors in the Y
direction than the other fdms, and thus the skid/slip ball doesn't
work properly. Hence the mag compass also doesn't work properly!!
As a temporary hack to get the compass working, change the following
conditional in steam.cxx to if(0)
if ( fabs(the_TC_rad) 0.2 )
{ /* Massive sideslip jams it; it stops turning */
the_MH_degps = 0.0;
the_MH_err = fgGetDouble(/orientation/heading-deg) -
the_MH_deg;
} else
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
John Wojnaroski writes: Some want to work spins, prop contact points, etc. But a LOT of accidents occur because the PIC failed to do a proper weight and balance, overloaded the A/C, and/or exceeded the CG limits. Something to consider - how about a weight and balance sheet to fill out before one can start engines ( it could be a file ), but no tickee no engine start. Surely it would be more realistic if the engines would happily start without filling out the weight and balance, but a random and possibly dangerous CG would be assigned... Cheers - Dave-- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim
Richard Kis writes: I really didn't find a manual how to start C172 machine. Its magnetos won't work... You need a middle mouse button to turn the starter on :-( The attached keyboard.xml uses the 's' key to turn the starter (after using the left mouse button to move the magnetos to both), at the expense of being able to toggle to the minimal panel. Cheers - Dave -- [EMAIL PROTECTED] ?xml version=1.0? !-- Key binding definitions. This file is included by preferences.xml, and uses the context of its inclusion point; that means that you need to prepend /input/keyboard to all property names. The list here is not yet comprehensive: many of the bindings are still handled in the C++ code. Regular keycodes go up to 255; special keys start at 256, and can be calculated by adding 256 to the GLUT key value in glut.h. -- PropertyList key n=1 nameCtrl-A/name descToggle autopilot altitude lock./desc binding commandproperty-toggle/command property/autopilot/locks/altitude/property /binding /key key n=7 nameCtrl-G/name descToggle autopilot glide slope lock./desc binding commandproperty-toggle/command property/autopilot/locks/glide-slope/property /binding /key key n=8 nameCtrl-H/name descToggle autopilot heading lock./desc binding commandproperty-toggle/command property/autopilot/locks/heading/property /binding /key key n=18 nameCtrl-R/name desc(Temporary) Toggle winding-ccw/desc binding commandproperty-toggle/command property/sim/temp/winding-ccw/property /binding /key key n=20 nameCtrl-T/name descToggle autopilot terrain lock./desc binding commandproperty-toggle/command property/autopilot/locks/terrain/property /binding /key key n=13 nameEnter/name descMove rudder right or increase autopilot heading./desc binding commandproperty-adjust/command property/autopilot/control-overrides/rudder/property step type=double0.05/step /binding /key key n=14 nameCtrl-N/name descToggle autopilot nav1 lock./desc binding commandproperty-toggle/command property/autopilot/locks/nav[0]/property /binding /key key n=19 nameCtrl-S/name descToggle auto-throttle lock./desc binding commandproperty-toggle/command property/autopilot/locks/auto-throttle/property /binding /key key n=21 nameCtrl-U/name desc[Cheat] Add 1000ft of emergency altitude./desc binding commandproperty-adjust/command property/position/altitude-ft/property step type=double1000.0/step /binding /key key n=27 nameESC/name descPrompt and quit FlightGear./desc binding commandexit/command /binding /key key n=44 name,/name descLeft brake/desc binding commandproperty-assign/command property/controls/brakes[0]/property value type=double1.0/value /binding mod-up binding commandproperty-assign/command property/controls/brakes[0]/property value type=double0.0/value /binding /mod-up /key key n=46 name./name descRight brake/desc binding commandproperty-assign/command property/controls/brakes[1]/property value type=double1.0/value /binding mod-up binding commandproperty-assign/command property/controls/brakes[1]/property value type=double0.0/value /binding /mod-up /key key n=48 name0/name descMove rudder left or increase autopilot heading./desc binding commandproperty-adjust/command property/autopilot/control-overrides/rudder/property step type=double-0.05/step /binding /key key n=49 name1/name descDecrease elevator trim./desc binding commandproperty-adjust/command property/controls/elevator-trim/property step type=double-0.001/step /binding mod-shift descLook back left/desc binding commandproperty-assign/command property/sim/view/goal-offset-deg/property value type=double135/value /binding /mod-shift /key key n=50 name2/name descIncrease elevator or autopilot altitude./desc binding commandproperty-adjust/command property/autopilot/control-overrides/elevator/property step type=double-0.01/step /binding mod-shift descLook back./desc binding commandproperty-assign/command property/sim/view/goal-offset-deg/property value type=double180/value /binding /mod-shift /key key n=51 name3/name descDecrease throttle or autopilot autothrottle./desc binding commandproperty-adjust/command property/autopilot/control-overrides/throttle/property step type=double-0.01/step /binding mod-shift descLook back right./desc binding commandproperty-assign/command property/sim/view/goal-offset-deg/property value type=double225/value /binding /mod-shift /key key n=52 name4/name descMove aileron left./desc binding commandproperty-adjust/command property/controls/aileron/property step type=double-0.05/step /binding mod-shift descLook left./desc binding
Re: [Flightgear-devel] ATIS frequency selection problem
Alex Perry writes: Some units report all three digits, but designers usually want to save panel space and omit the unnecessary digit. Thus, for example, the ground control frequency for KMYF is 118.225 MHz but the radio actually displays 118.22 (a notam recently changed it from 121.9). The radio in 91R, the only one I've needed to use 25kHz spacing on, consistently rounds down, so that another frequency might be 119.77. I'm afraid I'm a touch confused here. How do you actually select the 25kHz spacing if it is not displayed? Is there a different mode of radio operation that you can get into where adjustment is in 25kHz spacing and so the last digit can be inferred, and if so how is this physically done? Additionally, some UK NDBs have the need for an additional digit on the ADF display, eg 353.5 at East Midlands. How does this work out in terms of tuning and displaying the frequency? Cheers - Dave -- David Luff Engines Research Group University of Nottingham 0115-9513814 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS frequency selection problem
Alex Perry writes: When you turn the big knob, the whole MHz number changes in steps of one. When you turn the little knob, the fractional MHz number changes, with the display sequence 00 02 05 07 10 12 15 17 20 ... corresponding to the freqs 000 025 050 075 100 125 150 175 200 kHz Thanks for the explanation. Its all clear now. I take it we should change the panel from 0.5 MHz on the MMB and 0.05 Mhz on the LMB to 1 MHz on the MMB and 0.025 on the LMB - would anyone disagree with this? Cheers - Dave -- David Luff Engines Research Group University of Nottingham 0115-9513814 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Location of SimGear
John Check writes: Is there an option to init running? /engines/engine[0]/running=true I think This dosn't work anymore at the moment. The FGEngine constructor in JSBSim contains running = false. Cheers - Dave -- David Luff Engines Research Group University of Nottingham 0115-9513814 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Location of SimGear
David Megginson writes: How about 0, 1, 2, and 3 for the magneto positions? Well it would leave m/M for mixture if required. Cheers - Dave -- David Luff Engines Research Group University of Nottingham 0115-9513814 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS Support
David Megginson writes: I'm not doing this yet -- I expect a 10-line Perl script will do the job. I shall have a go then... Cheers - Dave -- David Luff Engines Research Group University of Nottingham 0115-9513814 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
