[Flightgear-devel] A tiny request
Is there a way the joystick hat for looking around would work when the game is paused as well? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A tiny request
On Saturday, 6 December 2003 12:44, Matevz Jekovec wrote: Is there a way the joystick hat for looking around would work when the game is paused as well? - Matevz I second that idea. I was trying to do some screen grabs last week and it's REALLY hard to keep the aircraft at the right attitude, get the scenery in the right position and do the grab all at the same time. It's especially hard when you are flying in a mountainous area trying to do a screen grab from a chase plane view looking backwards. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A tiny request
Frederic Bouvier wrote: Paul Surgeon wrote: On Saturday, 6 December 2003 12:44, Matevz Jekovec wrote: Is there a way the joystick hat for looking around would work when the game is paused as well? - Matevz I second that idea. I was trying to do some screen grabs last week and it's REALLY hard to keep the aircraft at the right attitude, get the scenery in the right position and do the grab all at the same time. It's especially hard when you are flying in a mountainous area trying to do a screen grab from a chase plane view looking backwards. I use the mouse ( arrow cursor ) to orient the view when paused -Fred Yes, but your hands are usually on the stick and keyboard, so mouse is a bit out of the hand, don't you think? I really use mouse panning only when it's a must (like in pause mode) and I'm sure I'm not the only one. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: dot
* Jon Berndt -- Saturday 06 December 2003 03:02: ./dot: error while loading shared libraries: libpathplan.so.0: cannot open shared object file: No such file or directory Do you have this library? I have, and it was in the package that I had prepared for you. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Aw: Re: [Flightgear-devel] DC-3 3d cockpit
Yes, I am. Ilja Von: Marcio Shimoda [EMAIL PROTECTED] Hi, Ilja! Are you running on Windows? Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Hi, Andy Andy Ross [EMAIL PROTECTED] wrote: Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... I will do that. Or, if you are feeling adventurous, try my plib patch which replaces the normal calculation step with a smarter one that understands the difference between smooth and sharp edges: http://www.plausible.org/vertsplit/vertsplit2.tar.gz (Make sure you are using the CVS version of plib, dump all the files in the tarball into src/ssg, then rebuild plib and FlightGear). I´m sorry, but I´m using the precompiled FlightGear v 9.3 for Windows and I haven´t got any compiler. The two implementations share no code, so if the problem persists with the patch, the bug is almost certainly in your model file. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? Yes, I´m sure. Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A tiny request
Matevz Jekovec wrote : On Saturday, 6 December 2003 12:44, Matevz Jekovec wrote: Is there a way the joystick hat for looking around would work when the game is paused as well? ** Yes, but your hands are usually on the stick and keyboard, so mouse is a bit out of the hand, don't you think? I really use mouse panning only when it's a must (like in pause mode) and I'm sure I'm not the only one. ** I really must have misunderstood something. Your initial post was a request you are in pause mode. Response : take the mouse When not in pause mode : take the hat. -Fred PS : Bloody HTML mail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: dot
OK, Thanks to Melchior I have a working dot on sourceforge. The diagrams are bigger than I want them to be, and Doxygen doesn't seem to be shrinking them like I'd like, but the version of Doxygen on the sf.net site appears to be older. In any case, I may pass the executable on to the sf.net admin team - maybe they'll put it in /usr/bin. Thanks to all who responded. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Martin Spott writes: Curtis L. Olson [EMAIL PROTECTED] wrote: ftp.flightgear.org is still rebooting ... /dev/hdh1 (120Gb) has gone 204 days without being checked, check forced ... might be another hour or two ... :-) I usually put everything over 10 GByte on XFS per 'default' - as well as any data that has some value for me. It should take about 5 seconds to mount a 200 gig filesystem - cheching included ;-) I'm running ext3 so normally rebooting, even after a crash would not be a problem, but in this case I exceeded the last check date threshold so it ran a full fsck on me. This drive has zillions of tiny little files on it so it's a worst case scenario for fsck performance. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Video card recommendation
Paul Surgeon wrote: Can someone recommend a nVidia based card that works flawlessly with FG? I'm on a tight budget so I'm looking at the low end cards. Does FG run well on a FX 5200? Paul, I have experience with the original GF3, the GF4 MX440, the FX 5200, the FX 5600, and the FX 5600 Ultra running in either Linux or Win XP. WRT fgfs, the main difference between the FX 5200 and the FX 5600's is the 5200 doesn't support antialiasing at all reasonably. Actually, either the GF3 or the GF4 MX440 do FSAA much better. The GF3 does fgfs well up to 1600x1200 at 16 bpp, but it is iffy to get FSAA and anisotropic filtering at 24 bpp at 1600 x 1200. This card is really an ASUS V8200 Delux GF3. Since I installed the FX 5600 Ultra, I have not been using this card and would be willing to sell it (original box and documentation). Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
On Saturday, 6 December 2003 17:31, Curtis L. Olson wrote: I'm running ext3 so normally rebooting, even after a crash would not be a problem, but in this case I exceeded the last check date threshold so it ran a full fsck on me. This drive has zillions of tiny little files on it so it's a worst case scenario for fsck performance. Regards, Curt. Can't you just force a check every now and then from a cron job? Anyway it's a small problem - a few hours of down time every year won't hurt anyone. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Paul Surgeon writes: Can't you just force a check every now and then from a cron job? Anyway it's a small problem - a few hours of down time every year won't hurt anyone. You need to unmount the drive before fsck'ing it, which you can't do unless all services / processes using files on that drive have also been killed, so effectively you need to take the machine down anyway. There's probably cleverer ways to do this, but a few hours down time a year doesn't worry me too much. The machine had been up for 70 days prior to this, but I needed to reboot to patch the kernel. For what it's worth, the record uptime for this particalar server is 177 days. The uptime record for the other fgfs server is 156 days. No where close to a world record, but these uptime streaks are interrupted by the need to do various admin tasks (upgrade hardware, security patches, etc.) and *not* because the machine died or crashed. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NMEA *out* to a Garmin
Does anyone know if it's possible for a Garmin GPS to take its position information from external NMEA input, rather than just broadcasting the position as NMEA output? I wanted to experiment with using my (brand-new) Garmin 196 slaved to FlightGear, but I have not had much luck yet. This works to slave FlightGear to the GPS: --nmea=serial,in,20,/dev/ttyS0,4800 This, however, does not work to slave the GPS to FlightGear: --nmea=serial,out,4,/dev/ttyS0,4800 I selected the NMEA IN/NMEA OUT in the 196 menu. I'd be interested in hearing from anyone who has used any Garmin receiver slaved to FlightGear (rather than the other way around). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NMEA *out* to a Garmin
David Megginson writes: Does anyone know if it's possible for a Garmin GPS to take its position information from external NMEA input, rather than just broadcasting the position as NMEA output? I wanted to experiment with using my (brand-new) Garmin 196 slaved to FlightGear, but I have not had much luck yet. This works to slave FlightGear to the GPS: --nmea=serial,in,20,/dev/ttyS0,4800 This, however, does not work to slave the GPS to FlightGear: --nmea=serial,out,4,/dev/ttyS0,4800 I selected the NMEA IN/NMEA OUT in the 196 menu. I'd be interested in hearing from anyone who has used any Garmin receiver slaved to FlightGear (rather than the other way around). I was hoping to be able to do this with my etrex handheld, but I concluded it was not possible. I'm guessing that it probably won't work for you either, although if there is a menu that says NMEA *IN*, that sounds promising. Perhaps the unit needs some sort of initialization string, or something in addition to NMEA? It might be interesting to plug the output of some other Garmin gps into your 196 to see if that works. Coincidently, I talked to Garmin this week about their higher end GPS's (like the GNS 430). None of the 400-500 series GPS's can take remote faked input. However, for the same price (which is substantial), they sell flight simulator versions of all these series 400-500 units which do take input via a serial line. However, they have a different communication protocol ... not fancy, but just a bit different from NMEA style strings. The other thing I wanted to play around with is a GPS application running on a palm pilot being fed fake gps strings from FlightGear. Has anyone done anything like that? Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Command Options
John Wojnaroski writes: Has anyone been successful in running some of the dual headed video cards with FG? I've never had a chance to play with a multi-headed opengl card. However, I've always been a little dubious about what kind of results they would yield. If you want to render two different views, one on each head, then you are going to have to draw the scene twice. Because of the way plib/ssg works, you are going to have to walk the scene graph once for each view to do the different view frustum culling. Drawing two views amounts to *nearly* twice the work of drawing one view because drawing the scene is probably 90% of the total work that FlightGear is doing. If you had multiple processors, you *might* be able to improve things, but, the rendering portion is still going to bottle neck through the single video card. So, my general gut feeling is that you'll get much better results (for out-the-window scene rendering) using 2 machines rather than one machine with two heads. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Curtis L. Olson [EMAIL PROTECTED] wrote: Martin Spott writes: I usually put everything over 10 GByte on XFS per 'default' - as well as any data that has some value for me. It should take about 5 seconds to mount a 200 gig filesystem - cheching included ;-) I'm running ext3 so normally rebooting, even after a crash would not be a problem, but in this case I exceeded the last check date threshold so it ran a full fsck on me. [...] bitchy Here you realize the difference between a wannabee enterprise filesystem and an enterprise filesystem that was designed as such from the very beginning /bitchy 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
[Flightgear-devel] Re: Rsync vulnerability
Martin Spott [EMAIL PROTECTED] writes: Curtis L. Olson [EMAIL PROTECTED] wrote: I'm running ext3 so normally rebooting, even after a crash would not be a problem, but in this case I exceeded the last check date threshold so it ran a full fsck on me. [...] bitchy Here you realize the difference between a wannabee enterprise filesystem and an enterprise filesystem that was designed as such from the very beginning /bitchy levelheaded The ext3 filesystem does not require periodic checks; those that leave them choose to suffer fsck's, nothing is making them do so. You could hobble any of the enterprise filesystems you so confidently tout in exactly the same way, merely by writing a shell script that every 180 days insists on fully scanning each of your filesystems when you reboot. /levelheaded -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Martin Spott wrote: bitchy Here you realize the difference between a wannabee enterprise filesystem and an enterprise filesystem that was designed as such from the very beginning /bitchy The automatic filesystem check is an issue of filesystem policy, and says nothing about the implementation thereof. Neither, I should add, does the appelation enterprise. :) If I had to pick, I'd go for reiserfs because of the nifty tail folding. But saying that XFS is somehow more reliable than the other choices is, honestly, kinda silly. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] No right rudder?
I just got FlightGear (0.9.3) running for the first time on MacOS X, but there seems to be no right rudder control, which makes flying a challenge. The docs say right rudder is the comma key, but that isn't doing it. (I've tried with both the laptop's keyboard and an external USB keyboard.) Left rudder with the 0 key and centering with 5 both work. The documentation also says that the comma is the left brake, which seems odd if it's the right rudder. Is this a known problem with the MacOS version? Thanks for any suggestions. --Kevin -- Kevin Savetz[EMAIL PROTECTED] http://www.savetz.com Freelance computer technology journalist ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Andy Ross writes: The automatic filesystem check is an issue of filesystem policy, and says nothing about the implementation thereof. Neither, I should add, does the appelation enterprise. :) If I had to pick, I'd go for reiserfs because of the nifty tail folding. But saying that XFS is somehow more reliable than the other choices is, honestly, kinda silly. A couple years ago at a friends wedding reception I got to sit next to an sgi xfs developer. For what ever that's worth. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] NMEA *out* to a Garmin
It would be nice if Garmin would port their demo software over to linux and be able to feed it data from another app. I use the Garmin 430's all the time when flying. Most of our club aircraft have at least one if not two of them. Oh and btw, I got taxi a Cessna 414 today and a Commander 115TC, besides flying a Piper Aztec for 2 hours. It was a fun aviation day! Now all I have to do is finish my Commercial/Multiengine with Instrument checkride and I will be happy, for now at least. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Curtis L. Olson Sent: Saturday, December 06, 2003 10:22 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] NMEA *out* to a Garmin David Megginson writes: Does anyone know if it's possible for a Garmin GPS to take its position information from external NMEA input, rather than just broadcasting the position as NMEA output? I wanted to experiment with using my (brand-new) Garmin 196 slaved to FlightGear, but I have not had much luck yet. This works to slave FlightGear to the GPS: --nmea=serial,in,20,/dev/ttyS0,4800 This, however, does not work to slave the GPS to FlightGear: --nmea=serial,out,4,/dev/ttyS0,4800 I selected the NMEA IN/NMEA OUT in the 196 menu. I'd be interested in hearing from anyone who has used any Garmin receiver slaved to FlightGear (rather than the other way around). I was hoping to be able to do this with my etrex handheld, but I concluded it was not possible. I'm guessing that it probably won't work for you either, although if there is a menu that says NMEA *IN*, that sounds promising. Perhaps the unit needs some sort of initialization string, or something in addition to NMEA? It might be interesting to plug the output of some other Garmin gps into your 196 to see if that works. Coincidently, I talked to Garmin this week about their higher end GPS's (like the GNS 430). None of the 400-500 series GPS's can take remote faked input. However, for the same price (which is substantial), they sell flight simulator versions of all these series 400-500 units which do take input via a serial line. However, they have a different communication protocol ... not fancy, but just a bit different from NMEA style strings. The other thing I wanted to play around with is a GPS application running on a palm pilot being fed fake gps strings from FlightGear. Has anyone done anything like that? Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ 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] DC-3 3d cockpit
Andy Ross [EMAIL PROTECTED] said: Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... Plib snaps vertices together. Yet another why do we need this? feature that is always on by default. I think the snap value has been reduced from 1cm to 1mm in plib cvs. Also there is a fix in plib cvs that partially fixes a problem where perfectly good triangles were being found degenerate. When plib finds degenerate triangle it just puts a 1,0,0 normal on the vertices (hence the white). It is still possible for plib to detect a good triangle as degenerate. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? It isn't showing in 24bpp mode. Some aircraft do a range select on the panel object so that it doesn't show at all when in external views (e.g. c172p-3d). Maybe that is where the confusion is. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] about the teleporting bug
The addition of this code on 10/23 to fg_init.cxx is what started the problem
with the aircraft crashing on teleports:
cout fgInitPosition() endl;
double gs = fgGetDouble(/sim/presets/glideslope-deg)
* SG_DEGREES_TO_RADIANS ;
double od = fgGetDouble(/sim/presets/offset-distance);
double alt = fgGetDouble(/sim/presets/altitude-ft);
Further down in the funciton the onground flag gets set:
// determine if this should be an on-ground or in-air start
if ( fabs(gs) 0.01 || fabs(od) 0.1 || alt 0.1 ) {
fgSetBool(/sim/presets/onground, false);
} else {
fgSetBool(/sim/presets/onground, true);
}
Is this an abuse of the property system (from a design standpoint)? Somehow,
somewhere the altitude as determined by this routine (fgInitPosition) is
getting put into /sim/presets/altitude.
If you select an airport, the altitude of the starting position of that
airport gets placed into /sim/presets/altitude. Then when you teleport the
above code detects the value, and sets onground to false. This causes the
reinitialized aircraft to be dangled in the air at the altitude of the
previous airport.
Backing out this patch fixes the teleport problem.
Isn't the advantage/purpose of the property tree to offer and easy interface
through the command line, network connections, and configuration files?
(Rather than short-cutting C++ class definitions, that is.)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] about the teleporting bug
Jim Wilson writes:
The addition of this code on 10/23 to fg_init.cxx is what started the problem
with the aircraft crashing on teleports:
cout fgInitPosition() endl;
double gs = fgGetDouble(/sim/presets/glideslope-deg)
* SG_DEGREES_TO_RADIANS ;
double od = fgGetDouble(/sim/presets/offset-distance);
double alt = fgGetDouble(/sim/presets/altitude-ft);
Further down in the funciton the onground flag gets set:
// determine if this should be an on-ground or in-air start
if ( fabs(gs) 0.01 || fabs(od) 0.1 || alt 0.1 ) {
fgSetBool(/sim/presets/onground, false);
} else {
fgSetBool(/sim/presets/onground, true);
}
Is this an abuse of the property system (from a design standpoint)? Somehow,
somewhere the altitude as determined by this routine (fgInitPosition) is
getting put into /sim/presets/altitude.
The way this was intended to work is that if you want to start on the
ground, you should set the altitude to -.
I think what we probably need is a slightly smarter set position
dialog box that knows how to set up the properties for what the user
is trying to do. If you specify a new airport and there are some
random left over values from a previous postition reset, weird things
are going to happen. What we are presented with now is a really raw
dialog box that exposes all the relevant properties, but doesn't
enforce or explain the rules so the user is very likely to stumble.
I have an external gui (perl-tk) setup for another project and it is
able to do some prevalidation of input data, and then when the user
clicks ok, it sorts out how to setup the specific /sim/presets
properties. That has been working really well for me.
However, exposing the raw /sim/presets properties to the end user
leaves a lot of room for them to make mistakes.
If you select an airport, the altitude of the starting position of that
airport gets placed into /sim/presets/altitude. Then when you teleport the
above code detects the value, and sets onground to false. This causes the
reinitialized aircraft to be dangled in the air at the altitude of the
previous airport.
Backing out this patch fixes the teleport problem.
But re-introduces other problems ... :-)
Is there any way to build smarter, higher level dialogs with our
current menu system, or are we stuck just being able to manipulate the
low level properties?
Maybe what we need is several menu items such as:
start at an airport on the ground
start relative to an airport in the air
start relative to a fix in the air
Then each of these could have separate call back functions tied to the
ok which configured the /sim/presets/ tree correctly before calling
the presets-commit function.
Isn't the advantage/purpose of the property tree to offer and easy interface
through the command line, network connections, and configuration files?
(Rather than short-cutting C++ class definitions, that is.)
It's getting pretty late here, so I'm not following what you are
getting at with this last paragraph.
Regards,
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] location dialog
Is there a way to preset certain property values when opening up a dialog box? I see that we can force arbitrary property values when clicking ok, but it would be nice to force some default values when a dialog box is opened. Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] about the teleporting bug
Curtis L. Olson writes: I think what we probably need is a slightly smarter set position dialog box that knows how to set up the properties for what the user is trying to do. If you specify a new airport and there are some random left over values from a previous postition reset, weird things are going to happen. What we are presented with now is a really raw dialog box that exposes all the relevant properties, but doesn't enforce or explain the rules so the user is very likely to stumble. I took a first stab at this, however, it would be nice to have some way to have a dialog box beable to preset certain property values ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] No right rudder?
Hi Kevin Try the Enter key on the number pad. So that would be 0 left rudder 5 centre Enter right rudder Cheers Innis The Mad Aussi Kevin Savetz writes I just got FlightGear (0.9.3) running for the first time on MacOS X, but there seems to be no right rudder control, which makes flying a challenge. The docs say right rudder is the comma key, but that isn't doing it. (I've tried with both the laptop's keyboard and an external USB keyboard.) Left rudder with the 0 key and centering with 5 both work. The documentation also says that the comma is the left brake, which seems odd if it's the right rudder. Is this a known problem with the MacOS version? Thanks for any suggestions. --Kevin -- Kevin Savetz[EMAIL PROTECTED] http://www.savetz.com Freelance computer technology journalist ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Protect your inbox from harmful viruses with new ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
