Re: [Flightgear-devel] Duplicate properties?
I see rho-slugsft3 in the built-in property browser (View/Properties), but rho-slugs_ft3 in the httpd property browser. I think what is happening is that the latter is correct, but the PLIB default font fails to show underscore characters. I would guess that you took the name as you saw it without the underscore, inserted it in an XML configuration file and then ran FG, which would cause your new property to be created. Then the property browser would show both of them; it knows they are different, but they display the same. We need a different (or rather a complete) font. This has been mentioned before. The PLIB guys said something like It's easy to create one. We could supply one in Flight Gear, but really someone ought to complete the one in PLIB. - Julian John Wojnaroski wrote: Odd. I'm only calling tie once, and my little fltk property browser only shows the correct value. The duplicate showed up in the pull-down menu from view properties. You might check the value of /environment/density-slugft3. It's probably better to use that one anyway as it is not FDM specific. Right, that's what I wound up doing. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Altimeter broken
I should have mentioned that the altimeter in my local source code is connected to the
reported air pressure, rather than just an artificial conversion of the FDM's known
altitude. This is what I have in steam.cxx to find the static pressure:
#ifdef FG_WEATHERCM
sgVec3 plane_pos = { cur_fdm_state-get_Latitude(),
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Altitude() * SG_FEET_TO_METER };
double static_inhg = WeatherDatabase-get(plane_pos).AirPressure *
(0.01 / INHG_TO_MB);
#else
double static_inhg =
globals-get_environment_mgr()-getEnvironment().get_pressure_inhg();
#endif
set_lowpass ( the_STATIC_inhg, static_inhg, dt );
It was working OK with WEATHER_CM, but not now with the new Environment.
FGEnvironment::get_pressure_inhg() is returning a ridiculously tiny number.
By the way, I have just stepped through this and I noticed that
FGEnvironmentMgr::getEnvironment returns a _copy_ of the environment object, which
involves setting up new interpolation tables. Wouldn't it be more appropriate to
return a reference to it?
- Julian
Julian Foad wrote:
The altimeter seems to be broken at the moment. /steam/altitude-ft shows a huge,
unchanging, random value for me, and the instrument (on more than one aircraft) just
stays at zero.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate properties?
Andy Ross wrote: Julian Foad wrote: We need a different (or rather a complete) font. This has been mentioned before. The PLIB guys said something like It's easy to create one. We could supply one in Flight Gear, but really someone ought to complete the one in PLIB. I started thinking about this sort of thing, too. Ripping* an existing truetype or postscript font into an antialiased texture is actually really easy -- render each glyph using ghostscript into a bitmap at 16x the intended resolution and downsample into a gray scale image. I've been thinking about this over the past few days as a straightforward application of the same scripting I've used for the panels. Problem is, I don't know anything about the glut font format, and a cursory look around the web didn't turn up any pointers. Does anyone know this stuff well enough to write up a quick format document? You don't need to create a GLUT font. You only need to create a *.rgb texture file with the renderd letters for PLIB. Just have a look at those that are already distributed with PLIB and the PLIB source code. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Norman and others: what code editors do ya'll recommend
I have found a nice command line AND X programming editor called WPE/XWPE (Window Programming Environment) on sunsite. It has its faults, but is quite nice overall, with build integration and editing via error message. Still looking for other programming editors (corporate or open source) that you might recommend. Only caveat is I'm looking for one that supports Macos X or X Window (or both, in a perfect world). Thank you! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: C172P Hi-Res Panel Photos
I have put some pictures up at the following address. http://64.81.150.106/planes/ I have cockpit and exterior shots of an old C182 (1957), Beechcraft Sierra and a Piper Warrior. I also have external shots of a Grumman Tiger. I will need to redo some of them as they were a bit fuzzy. I filled my memory stick up before I got to the Arrows or any of the other aircraft. I will bring my laptop next weekend so that I have a little more storage. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: Friday, June 21, 2002 5:52 PM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] ANN: C172P Hi-Res Panel Photos Ryan Larson writes: I can get hires photos of a Warrior, Archer, Arrow, Grumman Tiger, Beechcraft Sierra, C182, C172R, C172RG, Mooney 201, Saratoga II and possibly an Aztec F. I love my new flying club! Sounds good. We have an Arrow as well, but I don't think they'll let me close to it yet (ditto for the Duchess). What do we have and what do we need? Well, we have the C182 modelled already, so it would be a good start. Otherwise, it depends on what people want to model (aero-wise). Would it also be helpful to get hires photos of the outsides of planes and maybe the moving parts (gear, alerons, rudder, flaps, elevator and the prop)? Yes, I took some of those, too (all from the left side, hidden by the plane, to avoid too much embarrassment, but I still got jokes about taking 'before and after' photos before I went up). Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Buffer overflow in auto_gui.cxx
I got bitten by some static data corruption problems while working on
the panel stuff this afternoon (which I have almost working, by the
way -- expect a big code drop tomorrow morning). I tracked it down to
a buffer overflow in auto_gui.cxx. In the string formatting code for
the labels, there are some sprintf calls that look like this:
sprintf(buffer, %05.2f, value);
Where the buffer is a static variable with a length of 8. It turned
out that one of the values was a huge garbage value -- something like
1e223.
This code looked correct to me, with the field width being less than
8. But it turns out that that C standard allows for the buffer to
overflow anyway. What happens is that the exponential form of the
number can't fit for whatever reason, so the glibc sprintf tries to
print it in (gack!) decimal. You can verify this with the following
tiny program:
int main() { printf(%05.2f\n, 1.1235e223); }
...which gives the following output on my machine:
11234993833496141165207167137504629455791386815894971093998449766224059134612227306117948559764428592704563810063396445147361721349723249504875046156126872109285397930933011042616316938278030005998645453598490624.00
Needless to say, the static data area wasn't happy with 200+ bytes of
overflow. :)
In my copy, I fixed this with snprintf, but something nags at me that
this isn't portable to some platform we care about. We could mock up
a slow version that did an unchecked sprintf into some very large
buffer and copied the result out. Probably a better idea is to sanify
the input values so they can't have such unprintable values.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D Modeling Of FGFS
Hi AllI am working on the 3D Graphics Implementation of the FGFSandI have some questions. 1- What is the modeling of objects? 2- What is the Modeling of Scenery and terrain? 3- What is the Files format?In general How can you Guid me about 3D graphics implementation of FGFS.thanks alot Ali JafariDo You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup
Re: [Flightgear-devel] Buffer overflow in auto_gui.cxx
On Sun, 2002-06-23 at 21:14, Andy Ross wrote:
I got bitten by some static data corruption problems while working on
the panel stuff this afternoon (which I have almost working, by the
way -- expect a big code drop tomorrow morning). I tracked it down to
a buffer overflow in auto_gui.cxx. In the string formatting code for
the labels, there are some sprintf calls that look like this:
sprintf(buffer, %05.2f, value);
Where the buffer is a static variable with a length of 8. It turned
out that one of the values was a huge garbage value -- something like
1e223.
This code looked correct to me, with the field width being less than
8. But it turns out that that C standard allows for the buffer to
overflow anyway. What happens is that the exponential form of the
number can't fit for whatever reason, so the glibc sprintf tries to
print it in (gack!) decimal. You can verify this with the following
tiny program:
int main() { printf(%05.2f\n, 1.1235e223); }
...which gives the following output on my machine:
11234993833496141165207167137504629455791386815894971093998449766224059134612227306117948559764428592704563810063396445147361721349723249504875046156126872109285397930933011042616316938278030005998645453598490624.00
Needless to say, the static data area wasn't happy with 200+ bytes of
overflow. :)
In my copy, I fixed this with snprintf, but something nags at me that
this isn't portable to some platform we care about. We could mock up
a slow version that did an unchecked sprintf into some very large
buffer and copied the result out. Probably a better idea is to sanify
the input values so they can't have such unprintable values.
Ahh, vindication is sweet!
At any rate, MSVC is at least one that has trouble with it, we use this
in JSBSim:
#ifdef _MSC_VER
#define snprintf _snprintf
#endif
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
