[Flightgear-devel] osg transparency bug
7000 ft above KSFO, daytime: http://people.freebsd.org/~jylefort/fg-noon.png As you can see, the thin cloud layer does not hide the ground. However, after switching the time of day to night: http://people.freebsd.org/~jylefort/fg-night.png The airport and city lights only become visible (all of a sudden) after descending below the cloud layer. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpyXzN9hU9uu.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] On 11/22/06, Foo Bar [EMAIL PROTECTED] wrote:
On Wed, 22 Nov 2006 19:36:56 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: It seems to become common practice to include the email address in the attribution line of replies. This is a very bad habit, as the addresses end up in the mailing list archives, where harvesters happily pick them up. Spammers will be grateful. I won't. I get enough spam already! Please stop this shit. Otherwise I'll stop posting to the fgfs lists, and will only send private messages. In the sf archives the email addresses are truncated. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpaTn4fxnSZd.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Not only landing lights...
On Wed, 25 Oct 2006 09:56:24 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: * Yurik V. Nikiforoff -- Wednesday 25 October 2006 07:24: There are two problems around this issue. These two problems sound exactly like the ones that we had with another light patch a while ago. It was done the wrong way (lights not in the scenegraph) and was unfixable. According to Mathias, who knows his stuff. :-) This one: http://people.freebsd.org/~jylefort/flightgear-aircraft-lights.diff -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpl1wn5lopMy.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airport lights
On Mon, 19 Jun 2006 23:12:05 -0700
syd sandy [EMAIL PROTECTED] wrote:
I know this was discussed a while back , and if there was a solution I
think I missed it.
So I'll stick my neck out and ask
I used to get better framerates night flying, unless I enabled enhanced
lights.
Now it doesnt matter if enhanced lights are enabled or not , I get the
low framerates as soon as the airport lights come on. Ive got a 1.1 gig
AMD Athalon , with a Geforce 4 MX4000.
Average framerates are 25 - 30 , and drop to about 8 looking at KSFO at
night.
Is there a way to get the old style lighting back? Ive looked through
the code but haven't sorted that out .
I apologize if I missed the solution , if its been posted , but I'm
working on the cockpit lighting for the 777-200 , and its frustrating
enough that I give up after a while .Well , that and whatever recent
change that has caused the program to sit at Initializing subsystems
for a good 4-5 minutes.
Thanks for any help, I really think its a fantastic program , and wish I
had time to brush up on my opengl programming so I could contribute more
than just aircraft.
I give up on the sourceforge mail archive and I therefore reproduce my
mail below; you can solve your problem by applying the provided patch:
===
From: Jean-Yves Lefort [EMAIL PROTECTED]
To: flightgear-devel@lists.sourceforge.net
Reply-To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] performance and appearance issues with point sprites
Date: Sun, 5 Mar 2006 06:42:17 +0100
X-Mailer: Sylpheed running on FreeBSD
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false true2 steady thick points [1]
truefalse 11 dim and blinking pixels [2]
truetrue11 steady thin points [3]
[1] Identical to CVS 20060126.
[2] Nice for christmas, but otherwise completely broken. This is what
I get without the patch.
[3] Best attempt at looking like a real airport, I'd use this on a
more powerful system.
Enabling line-smooth removes about 7 fps from these figures.
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
[flightgear-perf.diff text/plain (1.3KB)]
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.44
diff -u -r1.44 renderer.cxx
--- src/Main/renderer.cxx 21 Feb 2006 01:19:19 - 1.44
+++ src/Main/renderer.cxx 5 Mar 2006 05:29:14 -
@@ -222,8 +222,9 @@
glFrontFace ( GL_CCW );
// Just testing ...
-if ( SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
- SGIsOpenGLExtensionSupported(GL_NV_point_sprite) )
+if ( (SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
+ SGIsOpenGLExtensionSupported(GL_NV_point_sprite))
+fgGetBool(/sim/rendering/point-sprite))
{
GLuint handle = thesky-get_sun_texture_id();
glBindTexture ( GL_TEXTURE_2D, handle ) ;
@@ -232,7 +233,8 @@
// glEnable(GL_POINT_SMOOTH);
glPointSpriteIsSupported = true;
}
-glEnable(GL_LINE_SMOOTH);
+if ( fgGetBool(/sim/rendering/line-smooth) )
+glEnable(GL_LINE_SMOOTH);
// glEnable(GL_POLYGON_SMOOTH);
glHint(GL_POLYGON_SMOOTH_HINT, GL_DONT_CARE);
glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE);
===
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
pgpuRvu4VKXw7.pgp
Description: PGP signature
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] b1900d fixes
Hi, I'm attaching two small fixes for the b1900d: - Unbreak night lighting of the GPWS buttons - Fix the author tag (spelling, and remove the line break since the property browser does not like it) PS: Syd: now the instruments lighting stays on even when I switch off the battery, both generators, the avionics switch and the engines. Is this intended? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/b1900d/b1900d-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/b1900d-set.xml,v retrieving revision 1.11 diff -u -r1.11 b1900d-set.xml --- Aircraft/b1900d/b1900d-set.xml 11 Apr 2006 21:11:12 - 1.11 +++ Aircraft/b1900d/b1900d-set.xml 13 Apr 2006 17:03:02 - @@ -19,9 +19,7 @@ descriptionBeechcraft B1900D (YASim) w 3d panel/description statusdevelopement/status - authorSyd Adams (3d model/FDM) - - Jean-Yves Lefort (MKVIII gpws) - /author + authorSyd Adams (3d model/FDM) - Jean-Yves Lefort (MK VIII EGPWS)/author flight-modelyasim/flight-model aerob1900d/aero @@ -37,7 +35,7 @@ red alias=/sim/model/b1900d/material/instruments/emission/red/ green alias=/sim/model/b1900d/material/instruments/emission/green/ blue alias=/sim/model/b1900d/material/instruments/emission/blue/ -factor alias=/sim/model/b1900d/material/instruments/factor/ +factor alias=/controls/lighting/instruments-norm/ /emission /assemblies /mk-viii pgpiRlH82EMFv.pgp Description: PGP signature
[Flightgear-devel] b1900d polish
Hi, I've removed the old GPWS objects from the b1900d model, since it now uses the MK VIII. The anim patch is attached, and the .ac file with the GPWS, GPWSon, BELOW-GS, BelowGsOn and warninglamps objects removed can be found here: http://people.freebsd.org/~jylefort/b1900d.ac.gz Syd Adams CC'ed. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/b1900d/Models/b1900d-anim.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/Models/b1900d-anim.xml,v retrieving revision 1.3 diff -u -r1.3 b1900d-anim.xml --- Aircraft/b1900d/Models/b1900d-anim.xml 4 Mar 2006 22:28:51 - 1.3 +++ Aircraft/b1900d/Models/b1900d-anim.xml 20 Mar 2006 17:10:16 - @@ -2570,47 +2570,6 @@ z-m-0.088/z-m /center /animation -!-- GPWS-- -animation - typeselect/type - object-nameBelowGsOn/object-name - condition -and -greater-than - property/instrumentation/nav[0]/gs-needle-deflection/property - value1.3/value -/greater-than -less-than - property/position/altitude-agl-ft/property - value1000.0/value -/less-than - /and - /condition -/animation - -animation - typeselect/type - object-nameGPWSon/object-name - condition -less-than - property/instrumentation/airspeed-indicator/indicated-speed-kt/property - value180.0/value -/less-than -less-than - property/position/altitude-agl-ft/property - value1000.0/value -/less-than - less-than -property/gear/gear/position-norm/property -value1/value - /less-than - equals -property/surface-positions/flap-pos-norm/property -value0.0/value - /equals -/condition -/animation - !--__ airspeed -- pgpPZXDL5bTDK.pgp Description: PGP signature
Re: [Flightgear-devel] fix mouse view regression
On Fri, 10 Mar 2006 08:14:17 +0100 Mathias Fröhlich [EMAIL PROTECTED] wrote: On Thursday 09 March 2006 21:19, Jean-Yves Lefort wrote: This change actually breaks the view mode with PU_USE_GLUT (at least for me). It was working properly before the change; now the view jumps whenever the mouse reaches a screen edge. Checked in a fix which at least fixed that form me. Please give it a try. It works, thanks. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgprveOmEOJtr.pgp Description: PGP signature
[Flightgear-devel] fix mouse view regression
input.cxx log:
revision 1.82
date: 2006-02-16 01:30:28 +; author: david; state: Exp; lines: +5 -11
The constrained property for a mouse mode now actually constrains
the mouse rather than wrapping it. Wrapping around to the other side
of the screen has very bad consequences when using the mouse for
flying or viewing -- it can result in sudden jumps in the controls or
the viewpoint when the mouse jumps to another side of the screen.
Right now, the mouse is constrained to stay between 25% and 75% of the
screen on both the X and Y axis -- whenever it hits an edge, it jumps
back to the centre of the screen again (which causes no control or
view jump).
This change actually breaks the view mode with PU_USE_GLUT (at least
for me). It was working properly before the change; now the view jumps
whenever the mouse reaches a screen edge.
If nobody has a better idea, I suggest to commit the attached patch
(it simply restores the pre-1.82 code in the PU_USE_GLUT case).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
Index: src/Input/input.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/input.cxx,v
retrieving revision 1.83
diff -u -r1.83 input.cxx
--- src/Input/input.cxx 21 Feb 2006 01:18:51 - 1.83
+++ src/Input/input.cxx 9 Mar 2006 20:16:54 -
@@ -387,6 +387,23 @@
// Constrain the mouse if requested
if (mode.constrained) {
bool need_warp = false;
+#ifdef PU_USE_GLUT
+if (x = 0) {
+ x = xsize - 2;
+ need_warp = true;
+} else if (x = (xsize-1)) {
+ x = 1;
+ need_warp = true;
+}
+
+if (y = 0) {
+ y = ysize - 2;
+ need_warp = true;
+} else if (y = (ysize-1)) {
+ y = 1;
+ need_warp = true;
+}
+#else /* PU_USE_SDL */
if (x = (xsize * .25) || x = (xsize * .75)) {
x = int(xsize * .5);
need_warp = true;
@@ -396,6 +413,7 @@
y = int(ysize * .5);
need_warp = true;
}
+#endif
if (need_warp)
fgWarpMouse(x, y);
pgpFSCS4CtggH.pgp
Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Tue, 7 Mar 2006 08:07:00 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Martin Spott -- Monday 06 March 2006 15:17: FreeBSD-5.3: Assertion failed: (status == 0), function ~SGMutex, file /opt/FlightGear/include/simgear/threads/SGThread.hxx, line 227. Abort (core dumped) OK, that's enough proof. This definitely needs to be fixed. If it can't be done cleanly before the release, then we can still comment out the destructors again for a *very* short period. This is a crude hack that mustn't prevail for years again. Less offensive (while still bad) would be to only comment out the triggering ASSERT. What about my solution? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp5PX6oHItb1.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Tue, 7 Mar 2006 09:39:31 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Jean-Yves Lefort -- Tuesday 07 March 2006 09:30: Melchior FRANZ [EMAIL PROTECTED] wrote: If it can'tbe done cleanly before the release, then we can still [...] What about my solution? Oh, true. Still an ugly workaround, but the best of all so far. It's not an ugly workaround, it's the only clean way to ensure portability. According to the test page, no standard requires the C++ stack to be unrolled after a cancellation is received. You can see that the cancellation_exception test is reported to fail on LinuxThreads, OS X, HP-UX, FreeBSD, Solaris and cygwin. BTW: what about the other thread using subsystems (voice, tilemanager)? No problems there? FGVoiceMgr would crash on destruction if you didn't leak _thread (FGVoiceThread::_mutex would then be destroyed while it is still locked by wait_for_jobs()). FGTileLoader would crash if FGGlobals::tile_mgr was destroyed. PS: Can you *please* finally stop to send a CC of everything? I mean, is it not obvious that I'm subscribed here and follow the thread? Netiquette may vary. In the other technical mailing lists I hang on, people copy eachother. I'll try to remember to make an exception for you (please do copy me, btw). -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpK6qhl0qKCd.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 08:01:54 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: In the FGMetarEnvironmentCtrl destructor, thread-cancel() causes the following thread-join() call to return without actually waiting on the thread (btw, thread-cancel() does not cause the thread to exit). It causes the thread to to be left at the next cancellation point, that would be the wait() in the SGBlockingQueue::pop. So the guarded mutex should automatically be unlocked and the thread left. That's according to the documentation and works here. My initial assumption is wrong. Here's another one: pthread_cancel() does cause the thread to exit, but the C++ destructors are not invoked. The SGGuard destructor can therefore not unlock the mutex. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpBI1B734S1V.pgp Description: PGP signature
Re: [Flightgear-devel] performance and appearance issues with point sprites
On Mon, 06 Mar 2006 09:30:08 +0100 Erik Hofman [EMAIL PROTECTED] wrote: Jean-Yves Lefort wrote: A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight: See the attached patch (I think point-sprite and line-smooth should be disabled by default). Why, because an ancient video card can't display it properly? s/ancient/low end/ If we go that way then please disable fog-nicest also because my O2 can't handle it... It might be best to be able to turn it off at the command line instead. Maybe enable line smoothing and disable point sprites. If someone starts fg for the first time and gets dim blinking pixels as lights, he might end up thinking that the software is bogus. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp3A7c6vXsvI.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 11:37:21 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Jean-Yves Lefort -- Monday 06 March 2006 11:28: pthread_cancel() does cause the thread to exit, but the C++ destructors are not invoked. The SGGuard destructor can therefore not unlock the mutex. Which destructor is not invoked (apart from the SGGuard one)? ~FGEnvironmentCtrl()? That would be very strange. Are you sure you have SimGear CVS/HEAD? No sticky tags/dates or something? Especially on simgear/structure/subsystem_mgr.cxx, where SGSubsystemGroup::Member::~Member() (line 227) didn't delete the subsystem in past version, but now does. The C++ stack of the cancelled thread is not unrolled. See http://www.slamb.org/projects/cancellation_tests/ -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpQEMCJKnPZ9.pgp Description: PGP signature
[Flightgear-devel] performance and appearance issues with point sprites
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false true2 steady thick points [1]
truefalse 11 dim and blinking pixels [2]
truetrue11 steady thin points [3]
[1] Identical to CVS 20060126.
[2] Nice for christmas, but otherwise completely broken. This is what
I get without the patch.
[3] Best attempt at looking like a real airport, I'd use this on a
more powerful system.
Enabling line-smooth removes about 7 fps from these figures.
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.44
diff -u -r1.44 renderer.cxx
--- src/Main/renderer.cxx 21 Feb 2006 01:19:19 - 1.44
+++ src/Main/renderer.cxx 5 Mar 2006 05:29:14 -
@@ -222,8 +222,9 @@
glFrontFace ( GL_CCW );
// Just testing ...
-if ( SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
- SGIsOpenGLExtensionSupported(GL_NV_point_sprite) )
+if ( (SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
+ SGIsOpenGLExtensionSupported(GL_NV_point_sprite))
+fgGetBool(/sim/rendering/point-sprite))
{
GLuint handle = thesky-get_sun_texture_id();
glBindTexture ( GL_TEXTURE_2D, handle ) ;
@@ -232,7 +233,8 @@
// glEnable(GL_POINT_SMOOTH);
glPointSpriteIsSupported = true;
}
-glEnable(GL_LINE_SMOOTH);
+if ( fgGetBool(/sim/rendering/line-smooth) )
+glEnable(GL_LINE_SMOOTH);
// glEnable(GL_POLYGON_SMOOTH);
glHint(GL_POLYGON_SMOOTH_HINT, GL_DONT_CARE);
glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE);
pgprMEdUHNju5.pgp
Description: PGP signature
[Flightgear-devel] c172p normalized control surface positions
Hi, The attached patch restores normalized control surface positions on the c172p. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/c172p/c172p.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c172p/c172p.xml,v retrieving revision 1.15 diff -u -r1.15 c172p.xml --- Aircraft/c172p/c172p.xml12 Jan 2006 15:07:14 - 1.15 +++ Aircraft/c172p/c172p.xml5 Mar 2006 21:24:06 - @@ -219,6 +219,19 @@ /range outputfcs/elevator-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Elevator Position Normalized +inputfcs/elevator-pos-deg/input +domain + min-28/min + max23/max +/domain +range +min-1/min +max1/max +/range +outputfcs/elevator-pos-norm/output +/aerosurface_scale /channel channel name=Roll summer name=Roll Trim Sum @@ -240,6 +253,19 @@ outputfcs/left-aileron-pos-rad/output /aerosurface_scale +aerosurface_scale name=Left Aileron Position Normalized +inputfcs/left-aileron-pos-deg/input +domain + min-20/min + max15/max +/domain +range +min-1/min +max1/max +/range +outputfcs/left-aileron-pos-norm/output +/aerosurface_scale + aerosurface_scale name=Right Aileron Control inputfcs/roll-trim-sum/input gain-0.01745/gain @@ -249,6 +275,19 @@ /range outputfcs/right-aileron-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Right Aileron Position Normalized +inputfcs/right-aileron-pos-deg/input +domain + min-15/min + max20/max +/domain +range +min1/min +max-1/max +/range +outputfcs/right-aileron-pos-norm/output +/aerosurface_scale /channel channel name=Yaw summer name=Yaw Trim Sum @@ -269,6 +308,19 @@ /range outputfcs/rudder-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Rudder Position Normalized +inputfcs/rudder-pos-deg/input +domain + min-16/min + max16/max +/domain +range +min-1/min +max1/max +/range +outputfcs/rudder-pos-norm/output +/aerosurface_scale /channel channel name=Flaps kinematic name=Flaps Control @@ -293,6 +345,19 @@ /traverse outputfcs/flap-pos-deg/output /kinematic + +aerosurface_scale name=Flaps Position Normalized +inputfcs/flap-pos-deg/input +domain + min0/min + max30/max +/domain +range +min0/min +max1/max +/range +outputfcs/flap-pos-norm/output +/aerosurface_scale /channel /flight_control aerodynamics pgpfpq65rIgcq.pgp Description: PGP signature
Re: [Flightgear-devel] mk-viii instrument addition to cvs
On Mon, 27 Feb 2006 17:43:55 + Justin Smithies [EMAIL PROTECTED] wrote: Hi all, I've just tested the mk-viii instrument on the 737-300 and it works great. I have the files required for addition to the FG cvs and it compiles fine. All thanks have to go to Jean-Yves Lefort for this excellent bit of coding. Email me and i'll send the files for you to test. This has to be added to the cvs as it can be used in any aircraft. You get vocal warnings for bank angles to too low / terrain warnings etc and pull up. I'll put together a doc on how to implement it into aircraft shortly. Don't bother, I'll do that after someone commits the device: http://people.freebsd.org/~jylefort/mk-viii.tgz -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp8Z33993dhO.pgp Description: PGP signature
Re: [Flightgear-devel] MK VIII EGPWS emulation
On Wed, 22 Feb 2006 22:02:47 +0100 Frederic Bouvier [EMAIL PROTECTED] wrote: Jean-Yves Lefort wrote : Hi, I have implemented a Honeywell MK VIII EGPWS emulation for FlightGear, available at http://people.freebsd.org/~jylefort/mk-viii.tgz The MK VIII is an Enhanced Ground Proximity Warning System aimed at regional turboprop and small turbofan aircrafts such as the Citation, Citation Bravo, B1900D, Beechcraft 99 and L410. Questions are welcome. PS: this is a repost of my original message dated January 31; maybe someone can tell me if this will go in or not? Thanks Did you checked with the author of the B1900D ( Syd Adams ? ) that your proposed change doesn't conflict with his current work, if any ? No. Someone will need to ask if he approves the b1900d changes. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpegbuKbTylz.pgp Description: PGP signature
Re: [Flightgear-devel] 2d panel question
On Wed, 15 Feb 2006 17:16:03 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: I have a 2d panel question. I want to make an annunciator light for a 2d panel. But, I don't want it to have any of the default panel illumination at night. I want it to be dark when the light is off, and lit when the light is on. But at night, the default panel illumination makes it difficult to see if the light is on or off. Is there a way to do accomplish this with the 2d panels? http://javky.rozhled.cz/jprojdwn.php?id=fgfsl410/l410-0.9.9-src-v4.0.tar.gz Search for JVK in src/Cockpit/panel* PS: what about merging the modifications contained in that tarball? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp6iV5H9vgJx.pgp Description: PGP signature
[Flightgear-devel] MK VIII EGPWS emulation
Hi, I have implemented a Honeywell MK VIII EGPWS emulation for FlightGear, available at http://people.freebsd.org/~jylefort/mk-viii.tgz The MK VIII is an Enhanced Ground Proximity Warning System aimed at regional turboprop and small turbofan aircrafts such as the Citation, Citation Bravo, B1900D, Beechcraft 99 and L410. Questions are welcome. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp9A2MTiElPm.pgp Description: PGP signature
[Flightgear-devel] crash in FGTower::ProcessDownwindReport()
This crash occurs quite frequently (/sim/ai-traffic/enabled=true): #0 0x080be433 in FGTower::ProcessDownwindReport (this=0x1e31a800, t=0x2153fc00) at AIPlane.hxx:80 #1 0x080beffc in FGTower::Respond (this=0x1e31a800) at tower.cxx:520 #2 0x080c2b5a in FGTower::Update (this=0x1e31a800, dt=0.083329) at tower.cxx:356 #3 0x0809e8db in FGATCMgr::update (this=0x17512000, dt=0.083329) at stl_list.h:131 #4 0x0805291e in fgMainLoop () at globals.hxx:279 #5 0x485d798f in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3 #6 0x485d80d5 in glutMainLoop () from /usr/X11R6/lib/libglut.so.3 #7 0x08054d6a in fgMainInit (argc=5, argv=0x1) at main.cxx:1007 #8 0x080511a1 in main (argc=0, argv=0x0) at bootstrap.cxx:197 I suppose that tt-planePtr is either dangling or null. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpuI4WXBGy7P.pgp Description: PGP signature
