Re: [Flightgear-devel] Small Scheme library
On Wed, 2002-07-03 at 05:04, David Megginson wrote: This claims a 64K object size in Linux: http://tinyscheme.sourceforge.net/home.html Please, don't. Incorporating this will, I think, almost instantly turn off new developers (and at least one current one). It's not possible to pick a language that will make everyone happy, but we should at least pick one that doesn't present the syntactic hurdles that the likes of Lisp and Scheme do. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ 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
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ [EMAIL PROTECTED] said: Now with a different 'approach'. Starting on ground ... $ fgfs --lon=-122.4998 --lat=37.5845 --heading=275 ... and very slowly taxiing over the border. Right when I pass over I get thrown on my back. Ouch ... :-| That did it. There is definately something at this location, on my display driven by V3-3000 I see a white line (right side of picture): http://www.spiderbark.com/fgfs/SanAndreas.png The AGL glitch you see basically means that there's a hole down there that goes to nowhere, an actual gap between tiles. AGL is determined by intersecting scenery tiles under the aircraft and measuring the distance from the aircraft position. If you cross a gap in the scenery then you'll get those kinds of numbers. On my system the c310 will ride over it (like thumping over a pothole) and the c172 will just drop in there and act crashed. Probably if I hit it at the right angle or speed the c310 would do the same. With a narrow fissure like this (I think) it's possible for the AGL to be momentarily screwed up, the aircraft then drops and a wing tip or nose contact with tile on either side of the gap triggers crash detection. I'm not familiar with the scenery generation, so I can't tell you why the gap is here. When I was working on getting the agl calculation functioning with all the viewer changes, I toyed with the idea doing something that ignored sudden (and/or unreasonable) variations to AGL, at least for a few frames. It was mostly in response to what happens when a very fast aircraft outruns the tile loading, which I decided wasn't a big enough problem to warrant tracking AGL variations. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] transponder
Curtis L. Olson [EMAIL PROTECTED] said: From my reading of the manual, the transponder FL display is always locked to 29.92 and thus could be significantly different from true altitude as you point out in your previous msg. It'd have to be that way to be useful for ATC. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] transponder
(f) Place the transponder data, if any and according to mode selected, on the property system and ideally expose it in the multiplayer stuff. That will subsequently make it easy to integrate a D-BRITE simulation. H. SquawkBox Pro Controller. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FDR playback broken?
Hi, has anyone recently used the FDR? I've just recorded a couple of flights with the a4-yasim, and whenever I try to play back the recording, fgfs dies with a segfault. The commands used were the ones from README.IO, and I've used them once a while ago with the c172. Maybe it's a yasim issue? If you need more specific info, tell me how to obtain it, and I'll run a test. Anyway, can anybody reproduce this? Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Jim Wilson -- Wednesday 03 July 2002 15:22: That did it. There is definately something at this location, on my display driven by V3-3000 I see a white line (right side of picture): http://www.spiderbark.com/fgfs/SanAndreas.png Yes. These small artifacts were always there. But they have become =much= better now -- almost invisible. Yet, once in a while there are still a few white dots. (Otherwise I wouldn't even have been able to tell, that it's a tile border problem. ;-) The AGL glitch you see basically means that there's a hole down there that goes to nowhere, an actual gap between tiles. Yes, but what strikes me is, that they are almost invisible, yet produce a series of wrong AGL values. I would have expected only one wrong value, if at all. And then, AGL in the gap should be very huge (infinity or earth radius :-), but why zero? No wonder that the fdm's don't like that. A huge value would probably only make the AGL radar flash a wrong value, but it wouldn't have further, malign effects. ... but I'm not familiar with the scenery, either. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
When I was working on getting the agl calculation functioning with all the viewer changes, I toyed with the idea doing something that ignored sudden (and/or unreasonable) variations to AGL, at least for a few frames. It was mostly in response to what happens when a very fast aircraft outruns the tile loading, which I decided wasn't a big enough problem to warrant tracking AGL variations. Perhaps that explains the problem I've been seeing. When performing autoland approaches in the 747 (approach speeds around 137-150KIAS) the aircraft would suddenly level off at decision height ( 200 ft) and then dive for the runway as it tried to reacquired the glideslope. At first, I thought it might be a problem in the FMC or some logic error that I created to initiate a TO/GA. Looked and looked and could find nothing, so I dropped it for the moment to work on other things Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
John Wojnaroski [EMAIL PROTECTED] said: Perhaps that explains the problem I've been seeing. When performing autoland approaches in the 747 (approach speeds around 137-150KIAS) the aircraft would suddenly level off at decision height ( 200 ft) and then dive for the runway as it tried to reacquired the glideslope. At first, I thought it might be a problem in the FMC or some logic error that I created to initiate a TO/GA. Looked and looked and could find nothing, so I dropped it for the moment to work on other things That's probably an issue with the autopilot and the 747. It's been difficult finding control factors that work for all the different speeds, compounded by the giant mass of the 747. At those lower speeds the effectiveness of the elevator can change dramatically with relatively small changes in speed. In any case the AGL doesn't affect the autopilot in its normal modes. If you were hearing tire screech at 200ft or it behaved differently depending on the airport, that would be a different story. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] transponder
Alex Perry writes: (c) Remember that it reports pressure altitude and not any other altitude. Is this true? I thought it was slaved to the altimeter. If so, please scratch the last part of my previous posting. No. Your mode C hardware shares the static port with the altimeter, but uses independent pressure sensing components. Thus, if you have a static failure in flight, you must immediately notify ATC and disable mode C. On the other hand, if your altimeter mechanically fails, you can continue with mode C and periodically ask ATC what altitude they see you being at. One benefit of having the transponder on pressure alt, with the ATC computer applying the kollsman correction for non flight levels, is that the radar display now provides correct relative altitudes of the aircraft even when a pilot has the wrong altimeter setting (eg after a cross country flight). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jim Wilson wrote: When I get some time I'll run further tests and maybe come up with a patch to avoid this sort of glitch. It would be helpful if someone happened to know why this gap happens in the scenery data sometimes. I'm sure Curt can talk in more detail, but my guess is that this is going to be very hard to avoid* in the general case. Maybe the best way to do this is to apply some meta-intelligence about the structure of the data. Rather than finding a purely geometic intersection with any polygons that may (or may not!) be there, test each tile individually (with a little guard band around the edge to prevent misses) and select exactly one intersection. [* It's really the same issue as the jitter -- at the scales covered by the terrain tiles, the floats in the vertex coordinates are only accurate to within a few millimeters. Even perfect math will result in cracks. The only way to avoid is would be to find all the duplicated vertices accross tile boundaries and force them to be precicely equal at load-time, which sounds like a pain to me. You can't force them to be precicely equal at generation time because each tile has its own coordinate origin and the equality test needs to happen after they're placed into the same coordinates.] Right now I'm in the middle of moving my own stuff to a new machine with a newer distro, so be a little patient please :-) Heh, join the club; I just bought a new machine too. BTW Anyone have any RH 7.2 suggestions (other than formatting and installing debian)? Any hope for the 2.96 compiler? OT so respond off list. I've been building with the default compiler on 7.2 and 7.3 with no difficulties at all. I think the 2.96 issues were all hammered out during patches to the 7.0 distribution. 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
Re: [Flightgear-devel] FDR playback broken?
Major A wrote: has anyone recently used the FDR? I've just recorded a couple of flights with the a4-yasim, and whenever I try to play back the recording, fgfs dies with a segfault. dumb-question We have a FDR feature with playback??? /dumb-question 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
Re: [Flightgear-devel] Small Scheme library
Tony Peden writes: This claims a 64K object size in Linux: http://tinyscheme.sourceforge.net/home.html In fact, it turns out to be 64K stripped *executable* size for the standalone interpreter; the object/library is even smaller. Please, don't. I hear your pain. Incorporating this will, I think, almost instantly turn off new developers (and at least one current one). It's not possible to pick a language that will make everyone happy, but we should at least pick one that doesn't present the syntactic hurdles that the likes of Lisp and Scheme do. I agree that Scheme will turn a lot of people off, but I'm annoyed that we cannot find a core ECMAScript implementation the same size (even then, the core source code for this is over 200K). There are *lots* of scheme implementations: http://dmoz.org/Computers/Programming/Languages/Lisp/Scheme/Implementations/ There are very few ECMAScript/JavaScript implementations, and at least two of those require a Java Runtime Environment: http://dmoz.org/Computers/Programming/Languages/JavaScript/Runtime_Environments/ If someone can supply a core ECMAScript implementation that is small and easy to embed, then we should jump on it; otherwise, the evil of holding back FlightGear development indefinitely might outweigh even the evil of using Scheme. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FDR playback broken?
On Wed, 2002-07-03 at 09:47, Andy Ross wrote: Major A wrote: has anyone recently used the FDR? I've just recorded a couple of flights with the a4-yasim, and whenever I try to play back the recording, fgfs dies with a segfault. dumb-question We have a FDR feature with playback??? /dumb-question I believe David added a data logging feature a while back. We really shouldn't call it a FDR, we make it too easy for that. The real thing is a PITA to extract and analyze data from. 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
Re: [Flightgear-devel] Small Scheme library
If someone can supply a core ECMAScript implementation that is small and easy to embed, then we should jump on it; otherwise, the evil of holding back FlightGear development indefinitely might outweigh even the evil of using Scheme. One of the nice things about LISP (and I assume Scheme) is that it is easy to use as an interpreter for the runtimes of other languages. Therefore, the obvious question is ... is there an ECMAscript runtime for Scheme ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
David Megginson wrote: I agree that Scheme will turn a lot of people off, but I'm annoyed that we cannot find a core ECMAScript implementation the same size (even then, the core source code for this is over 200K). A quick google showed: http://ixlib.sourceforge.net/ All of it is ~ 360 kb. If you look at it's features we might be able to strip it down significantly. CU, Christian --- 1. What is ixlib? --- ixlib is a small c++ tools library based upon the standard template library. It provides * a javascript interpreter (subset of ECMAscript 4, strict mode) [ixlib_javascript.hh] * an exception handling framework [ixlib_exbase.hh] * garbage collection [ixlib_garbage.hh] * automatic array management [ixlib_array.hh] * planar geometry (rectangles, regions) [ixlib_geometry.hh] polygons (rasterization, convex hull, smoothing, removal of crossings) [ixlib_polygon.hh] * rasterization [ixlib_drawing_functions.hh] * matrices (including linear system solver, Cholesky and LU decomposition, determinants, inversion, Gauss and Gauss-Jordan elimination) [ixlib_matrix.hh] * command line parsing [ixlib_cmdline.hh] * versatile int - string conversions [ixlib_numconv.hh] * regular expressions [ixlib_re.hh] * XML parsing (non-DTD) [ixlib_xml.hh] Some of the guidelines I tried to follow are: * use a separate namespace ixion * try to be STL-look-alike * no unnecessary dependencies: you pay only for those parts that you use (pay means: use disk space, take execution time) * no unnecessary dependencies 2: The library doesn't do any i/o by itself, except if given a stream to explicitly do so. Besides flex and the STL, there are no other dependencies. * do not use abbreviations * conform to standards (XML, ECMAscript) * do not duplicate or mimic STL functionality (e.g. no separate string class), that is be strictly an STL-add-on * provide a complete internationalization framework for localized texts and error messages Furthermore, every component of ixlib has been thoroughly tested and is considered production-quality code. -- 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] Re: crashes at tile borders revisited
* Jim Wilson -- Wednesday 03 July 2002 18:26: Melchior FRANZ [EMAIL PROTECTED] said: A huge value would probably only make the AGL radar flash a wrong value but it wouldn't have further, malign effects. Crash detection is triggered in some cases which will basically shutdown fdm. Any other malign effects? Random plane crashes without obvious reason are certainly not acceptable for a flight simulator. Even more so, if the reason is gaps in the scenery that shouldn't be there in the first place. The gaps aren't really severe and certainly hard to avoid, but I don't see why they should make the plane crash. What would you call malign? If it made your monitor explode? Killed your cat? m. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross writes: Jim Wilson wrote: When I get some time I'll run further tests and maybe come up with a patch to avoid this sort of glitch. It would be helpful if someone happened to know why this gap happens in the scenery data sometimes. I'm sure Curt can talk in more detail, but my guess is that this is going to be very hard to avoid* in the general case. Maybe the best way to do this is to apply some meta-intelligence about the structure of the data. Rather than finding a purely geometic intersection with any polygons that may (or may not!) be there, test each tile individually (with a little guard band around the edge to prevent misses) and select exactly one intersection. [* It's really the same issue as the jitter -- at the scales covered by the terrain tiles, the floats in the vertex coordinates are only accurate to within a few millimeters. Even perfect math will result in cracks. The only way to avoid is would be to find all the duplicated vertices accross tile boundaries and force them to be precicely equal at load-time, which sounds like a pain to me. You can't force them to be precicely equal at generation time because each tile has its own coordinate origin and the equality test needs to happen after they're placed into the same coordinates.] Exactly ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
On Wed, 2002-07-03 at 10:09, Christian Mayer wrote: David Megginson wrote: I agree that Scheme will turn a lot of people off, but I'm annoyed that we cannot find a core ECMAScript implementation the same size (even then, the core source code for this is over 200K). A quick google showed: http://ixlib.sourceforge.net/ All of it is ~ 360 kb. If you look at it's features we might be able to strip it down significantly. I don't know how many interdependencies there are, but the js related source and headers total 142k. CU, Christian --- 1. What is ixlib? --- ixlib is a small c++ tools library based upon the standard template library. It provides * a javascript interpreter (subset of ECMAscript 4, strict mode) [ixlib_javascript.hh] * an exception handling framework [ixlib_exbase.hh] * garbage collection [ixlib_garbage.hh] * automatic array management [ixlib_array.hh] * planar geometry (rectangles, regions) [ixlib_geometry.hh] polygons (rasterization, convex hull, smoothing, removal of crossings) [ixlib_polygon.hh] * rasterization [ixlib_drawing_functions.hh] * matrices (including linear system solver, Cholesky and LU decomposition, determinants, inversion, Gauss and Gauss-Jordan elimination) [ixlib_matrix.hh] * command line parsing [ixlib_cmdline.hh] * versatile int - string conversions [ixlib_numconv.hh] * regular expressions [ixlib_re.hh] * XML parsing (non-DTD) [ixlib_xml.hh] Some of the guidelines I tried to follow are: * use a separate namespace ixion * try to be STL-look-alike * no unnecessary dependencies: you pay only for those parts that you use (pay means: use disk space, take execution time) * no unnecessary dependencies 2: The library doesn't do any i/o by itself, except if given a stream to explicitly do so. Besides flex and the STL, there are no other dependencies. * do not use abbreviations * conform to standards (XML, ECMAscript) * do not duplicate or mimic STL functionality (e.g. no separate string class), that is be strictly an STL-add-on * provide a complete internationalization framework for localized texts and error messages Furthermore, every component of ixlib has been thoroughly tested and is considered production-quality code. -- 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 -- 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
Re: [Flightgear-devel] Small Scheme library
On Wed, 2002-07-03 at 10:23, Tony Peden wrote: On Wed, 2002-07-03 at 10:09, Christian Mayer wrote: David Megginson wrote: I agree that Scheme will turn a lot of people off, but I'm annoyed that we cannot find a core ECMAScript implementation the same size (even then, the core source code for this is over 200K). A quick google showed: http://ixlib.sourceforge.net/ All of it is ~ 360 kb. If you look at it's features we might be able to strip it down significantly. I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. CU, Christian --- 1. What is ixlib? --- ixlib is a small c++ tools library based upon the standard template library. It provides * a javascript interpreter (subset of ECMAscript 4, strict mode) [ixlib_javascript.hh] * an exception handling framework [ixlib_exbase.hh] * garbage collection [ixlib_garbage.hh] * automatic array management [ixlib_array.hh] * planar geometry (rectangles, regions) [ixlib_geometry.hh] polygons (rasterization, convex hull, smoothing, removal of crossings) [ixlib_polygon.hh] * rasterization [ixlib_drawing_functions.hh] * matrices (including linear system solver, Cholesky and LU decomposition, determinants, inversion, Gauss and Gauss-Jordan elimination) [ixlib_matrix.hh] * command line parsing [ixlib_cmdline.hh] * versatile int - string conversions [ixlib_numconv.hh] * regular expressions [ixlib_re.hh] * XML parsing (non-DTD) [ixlib_xml.hh] Some of the guidelines I tried to follow are: * use a separate namespace ixion * try to be STL-look-alike * no unnecessary dependencies: you pay only for those parts that you use (pay means: use disk space, take execution time) * no unnecessary dependencies 2: The library doesn't do any i/o by itself, except if given a stream to explicitly do so. Besides flex and the STL, there are no other dependencies. * do not use abbreviations * conform to standards (XML, ECMAscript) * do not duplicate or mimic STL functionality (e.g. no separate string class), that is be strictly an STL-add-on * provide a complete internationalization framework for localized texts and error messages Furthermore, every component of ixlib has been thoroughly tested and is considered production-quality code. -- 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 -- 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 -- 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
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Jim Wilson -- Wednesday 03 July 2002 18:26: Melchior FRANZ [EMAIL PROTECTED] said: A huge value would probably only make the AGL radar flash a wrong value but it wouldn't have further, malign effects. Crash detection is triggered in some cases which will basically shutdown fdm. Any other malign effects? Random plane crashes without obvious reason are certainly not acceptable for a flight simulator. Even more so, if the reason is gaps in the scenery that shouldn't be there in the first place. The gaps aren't really severe and certainly hard to avoid, but I don't see why they should make the plane crash. What would you call malign? If it made your monitor explode? Killed your cat? I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I can't see anything obvious in your system setup that would explain what is happening and why your experience is different from others. When I've been the only one to see weird problems it has often helped to do a complete make clean; make; make install of all the components (plib, simgear, flightgear) with the emphasis on the make clean part first. Sometimes the incremental builds can get slightly hosed for some reason ... you get an executable that links and runs, but does weird things. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Curtis L. Olson -- Wednesday 03 July 2002 19:32: When I've been the only one to see weird problems it has often helped to do a complete make clean; make; make install Hmmm ... but I interpreted Jim's That did it. There is definately something at this location... that I'm not the only one. It's nevertheless mysterious that other people don't see the problem. The question is, which AGL height other people get reported above the few gaps that we still have. Reporting anything less than the plane's CG height is in any case a bug. It potentially causes a crash where it shouldn't. But I will now eradicate all my object files and make everything clean. I'll be back ... m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
Tony Peden writes: I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. That's pretty close. I wonder how bad the dependencies are. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
David Megginson wrote: Tony Peden writes: I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. That's pretty close. I wonder how bad the dependencies are. They said: only STL and Flex But as we'd budle it (I hope so) we could run it through Flex beforehand, as -apart from Linux systems- hardly any system comes with it preinstalled. CU, Christan -- 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
Re: [Flightgear-devel] Splash screens
On Wednesday 03 July 2002 1:59 pm, Cameron Moore wrote: * [EMAIL PROTECTED] (John Check) [2002.07.03 00:32]: On Wednesday 03 July 2002 1:19 am, Cameron Moore wrote: I decided to make a couple splash screens out of some nice screenshots, and I'm curious how they look on other systems -- mainly if they are too dark. They are straight out of FG -- no tampering except for the text, of course. If you want to test them, you can get them from here: http://unbeatenpath.net/software/fgfs/Splash/ One is of the A-4 during an initial climb with runway lights in the background. The other is an overhead shot of the c172 at dusk. If you try these out, let me know what you think. Thanks I really really like the A4 one, but it's too dark IMO. This is what I expected, but wanted to share them before I get bored and go back to jacking with valgrind. I'll try to get a little more sunlight next time and see how that goes. Thanks, everyone What might work nicely is pause the sim, save the flight then play with the time. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
That's probably an issue with the autopilot and the 747. It's been difficult finding control factors that work for all the different speeds, compounded by the giant mass of the 747. At those lower speeds the effectiveness of the elevator can change dramatically with relatively small changes in speed. Errr, I don't think so. Not using the FG autopilot, and I see nothing in my FMC that would send a control command for up elevator. In fact, the FMC continues to issue a reference vertical velocity speed between 720 and 760 fpm descent which is what it was calculating at glideslope capture at the outer marker and during the approach. There is nothing in the way of a control command input, the approach is rock solid both in glideslope and localizer tracking all the down. Plus there's no reason for the aircraft to suddenly pitch up when neither the state or control surface deflections change. In any case the AGL doesn't affect the autopilot in its normal modes. If you were hearing tire screech at 200ft or it behaved differently depending on the airport, that would be a different story. When I have a moment I'll try a few approaches at other airports. Don't have sound enabled. And taker a closer look at a plot of FMC output and control surface movements. I've put this one on the back burner for the moment. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Melchior FRANZ -- Wednesday 03 July 2002 19:41: But I will now eradicate all my object files and make everything clean. Done. Same problem. Unfortunately, I'm neither familiar with the scenery handling, nor with the vector stuff. But I'll try to find out more ... :-/ m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Melchior FRANZ -- Wednesday 03 July 2002 19:41: But I will now eradicate all my object files and make everything clean. Done. Same problem. Unfortunately, I'm neither familiar with the scenery handling, nor with the vector stuff. But I'll try to find out more ... :-/ Can you dump out the ground elevation every frame and see what that does as you fly over a seam and hit the invisible wall? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] relative gear/flap sound volume
Does anyone have any objections to lowering the relative volume of the gear and flaps in the default cessna 172? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Curtis L. Olson -- Wednesday 03 July 2002 21:30: Can you dump out the ground elevation every frame and see what that does as you fly over a seam and hit the invisible wall? I did this already and posted the results in this thread. Do you want to see more? A longer period? It would be interesting to also see the actual ground elevation along with the other numbers you posted. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Curtis L. Olson -- Wednesday 03 July 2002 21:35: It would be interesting to also see the actual ground elevation along with the other numbers you posted. Ahh, sorry. I mixed up altitude with ground elevation. May take a while, I'm not sure if the jsbsim log outputs that. Give me some minutes. You could also insert a cout/printf in the main loop ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jim Wilson writes: Did you try rolling out from the position that Melchior included in this mornings message (the one with the agl data)? I couldn't replicate before but I can by rolling on the ground (a couple feet) from that position. Just curious to know if you do. I thought Melchior was having problems while in flight? Could you send me a pointer to his message? I must have missed it. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ [EMAIL PROTECTED] said: * Jim Wilson -- Wednesday 03 July 2002 18:26: Melchior FRANZ [EMAIL PROTECTED] said: A huge value would probably only make the AGL radar flash a wrong value but it wouldn't have further, malign effects. Crash detection is triggered in some cases which will basically shutdown fdm. Any other malign effects? Random plane crashes without obvious reason are certainly not acceptable for a flight simulator. Even more so, if the reason is gaps in the scenery that shouldn't be there in the first place. The gaps aren't really severe and certainly hard to avoid, but I don't see why they should make the plane crash. What would you call malign? If it made your monitor explode? Killed your cat? I'm sorry, must have misunderstood your message. I was only describing the effect from a programmer's perspective, not stating that it was acceptible. My question was just to discover if you noticed anything else, like your monitor exploding, cat getting killed, and so on. ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: Did you try rolling out from the position that Melchior included in this mornings message (the one with the agl data)? I couldn't replicate before but I can by rolling on the ground (a couple feet) from that position. Just curious to know if you do. I thought Melchior was having problems while in flight? Could you send me a pointer to his message? I must have missed it. I just forwarded it to your mailbox. It was recieved here at about 8am EST Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Curtis L. Olson -- Wednesday 03 July 2002 21:39: You could also insert a cout/printf in the main loop ... Plan B was to use the built-in logger. But apart from the table head I don't get any information. Now up to cout then ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Jim Wilson -- Wednesday 03 July 2002 21:55: I'm sorry, must have misunderstood your message. I was only describing the effect from a programmer's perspective, not stating that it was acceptible. My question was just to discover if you noticed anything else, like your monitor exploding, cat getting killed, and so on. ;-) Never mind. I just try to be a serious pilot, and dying in a plane crash is pretty dramatic. And, as a non-Micros~1 user, random crashes are generally undesirable for me. :-] m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: Never mind. I just try to be a serious pilot, and dying in a plane crash is pretty dramatic. And, as a non-Micros~1 user, random crashes are generally undesirable for me. :-] Ignoring my own previous statement about avoiding politics -- I've seen a lot of varient spellings of microsoft and windows. Acknowledging that these are offensive to some, I usually try to avoid using them, but I hadn't seen MICROS~1 yet ... got a chuckle out of it. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. I tried this with a few aircraft, and they all seem to see the same bump. Sticking a printf in YASim's update method (or actually uncommenting one that someone else added, heh) I see the terrain elevation leap by about 2 meters as you cross the tile boundary. Now, 2m doesn't sound like a lot to worry about, but clearly the terrain rendering isn't showing anything near a 2 meter difference, so the problem isn't with the scenery data itself. If there's a bug in the collision detection, it's possible that it has higher magnitudes elsewhere. I have to go back to work now, but maybe this will help someone else track down the issue. 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] Re: crashes at tile borders revisited
* Andy Ross -- Wednesday 03 July 2002 22:30: Now, 2m doesn't sound like a lot to worry about [...] Well, I wouldn't like to drive my car in a 2m high wall. That must be quite unpleasant even at lower speeds. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Curtis L. Olson -- Wednesday 03 July 2002 22:29: [...] but I hadn't seen MICROS~1 yet ... got a chuckle out of it. :-) Hey, that's how they are spelling their name themselves, even on NT-boxes. I didn't know whether I should be amused or shocked when I saw it first. :- m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson [EMAIL PROTECTED] said: Melchior FRANZ writes: Never mind. I just try to be a serious pilot, and dying in a plane crash is pretty dramatic. And, as a non-Micros~1 user, random crashes are generally undesirable for me. :-] Ignoring my own previous statement about avoiding politics -- I've seen a lot of varient spellings of microsoft and windows. Acknowledging that these are offensive to some, I usually try to avoid using them, but I hadn't seen MICROS~1 yet ... got a chuckle out of it. :-) Hehe... And a quick search on google reveals: http://www.tuxedo.org/~esr/jargon/html/entry/micros1.html http://support.microsoft.com/default.aspx?scid=kb;EN-US;q143395 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
It was a particularly nasty trick on a 172M, which uses an up/down toggle switch rather than a slider for flaps, but I caught on when the plane wouldn't climb at 70kt with full power. humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
Gene Buckle writes: humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
Gene Buckle writes: humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Ye gods. That's why you pre-flight _after_ you've fueled up. Gas it, park it and then check it _all_. I'm amazed you made it back. It doesn't take long to suck those wing tanks dry. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crashes at tile borders revisited
* Jim Wilson -- Wednesday 03 July 2002 22:45: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q143395 OK, we want to avoid politics ... but when Windows 98 was released, Apple had an advertisement campain which basically consisted of the string C:\CONGRTLS.W98 m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
Gene Buckle writes: It was a particularly nasty trick on a 172M, which uses an up/down toggle switch rather than a slider for flaps, but I caught on when the plane wouldn't climb at 70kt with full power. humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor lack-of-humour In the 172M, the rocker switch doesn't tell you anything (and the position indicator beside it was, of course, U/S). In the end, I did look out the window, which was a non-trivial bit of contortion with an instrument-training hood on. /lack-of-humour All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
Curtis L. Olson writes: The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Remember to jump up off the floor just before the plane hits the ground, and you'll be fine. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] relative gear/flap sound volume
On Wed, 2002-07-03 at 14:04, Gene Buckle wrote: Gene Buckle writes: humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Ye gods. That's why you pre-flight _after_ you've fueled up. Gas it, park it and then check it _all_. I'm amazed you made it back. It doesn't take long to suck those wing tanks dry. Could have been plenty in the center tank ... I would think fuel spraying somewhere near the nacelles or exhaust plume would be a bigger worry. g. ___ 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
re: [Flightgear-devel] relative gear/flap sound volume
Gene Buckle writes: Gene Buckle writes: humor Next time, look to your left and a little bit up and to the rear. If there's a big honkin' chunk of metal blocking your view, check the flap switch. *huge grin* /humor The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Ye gods. That's why you pre-flight _after_ you've fueled up. Gas it, park it and then check it _all_. I'm amazed you made it back. It doesn't take long to suck those wing tanks dry. That was when I was young and stupid. The pilot fueled back up, screwed on the fuel caps, and off we went again. I should have used that opportunity to exit the plane, but was too excited about the rare chance to go flying ... it was a wild ride though ... we flew up to northern AZ and were buzzing some poor rancher's cattle, or would that be some rancher's poor cattle. Anyway we were occasionally pretty close to 90 degree bank about 50' above the ground. In retrospect, yes, lucky to have made it back from both flights that day. That was the last time I went flying with that particular pilot. These days I give all my potential pilots a check ride in flightgear first before I'll go flying with them. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] relative gear/flap sound volume
On Wed, 2002-07-03 at 14:04, Gene Buckle wrote: The other one I've learned from real experience (as a passenger). If while you are looking a little up and to the rear to check flap status, if you also notice a big plume of something that looks a lot like smoke coming off one or both wings, land and check your fuel tank covers. (And extinguish your cigarettes.) :-) Ye gods. That's why you pre-flight _after_ you've fueled up. Gas it, park it and then check it _all_. I'm amazed you made it back. It doesn't take long to suck those wing tanks dry. Could have been plenty in the center tank ... I would think fuel spraying somewhere near the nacelles or exhaust plume would be a bigger worry. I think they're talking prop light aircraft. It is especially severe with high wing aircraft, since you cannot simply look at the fuel filler ports and trivially inspect them. Fuel island staff often don't know how to put the caps on right, and pilots often leave them off to dip the tanks and get distracted, so forget and take off without replacing caps. The fuel starts to siphon off as soon as the wing generates lift, which is creating a low pressure above the wing surface, and I'm told you have about five minutes before that tank is completely emptied out. The fuel doesn't siphon out before the lift is generated, so there is often no indication on the ground (during runup) of a problem. Given that this corresponds to 7 miles at normal flight speeds and a normal empty traffic pattern can be as big as four miles around, it is imperative to declare an emergency immediately and get any other traffic out of the way. You cannot afford any delay at that point. Another fun trick is to leave off the oil cap. As you're rolling down the runway and advance the throttle to full power, about five seconds later you lose all forward visibility as the engine oil gets delivered all over the windshield (at 30 mph ground speed). No, I haven't done either of these. It's amazing what you learn when working as a safety counselor (grin). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. It was actually for the release of Windows 95 and it translates to Congradulations Windows 95 g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jon S Berndt writes: On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. In unix this would probably translate to something like cw98 (to save typing.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nav and Guidance Made Easy(?)
I was always unsure about the basics of navigation and guidance until I listened to this .wav file, then everything made sense! I'm sure some of you nav people have heard it before, but it is funny. It is suppose to be from an official US Air Force training file, but it sounds as if the voice-over people were feeling a bit bored. Be warned that when I played this for someone at work, they had to sit down for a bit. http://homepage.mac.com/eq_fidget/guidedmissle.wav ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
On Wed, 2002-07-03 at 11:40, David Megginson wrote: Tony Peden writes: I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. That's pretty close. I wonder how bad the dependencies are. OK, I've gotten the compressed and uncompressed numbers confused. The two numbers I quoted above are uncompressed. The original 360k posted was for the whole library and was compressed. I've isolated all the headers and source required to get the js interpreter to compile and link. The resulting executable works, but all it does is instantiate the interpreter then delete it. At any rate, I ended up with 388k of uncompressed source. This compresses to 56k with tar and gzip. Note that du gives 17M for the FG source tree and 4.9M for the Simgear source tree after running 'make distclean' on both. Both numbers are, obviously, uncompressed. If anyone is interested, I can send you a tarball with the sources and Makefile. One more thing I should point out, the author's caveat list: quote url= http://ixlib.sourceforge.net/doc/namespaceixion_1_1javascript.html#a19 This is the list of its shortcomings: * exceptions * namespaces,packages * constness * Number/String constructor and class methods * real regexp's * the methods listed in FIXME's (js_library.cc js_value.cc) * cannot cross-assign predefined methods [won't be] * Grammatical semicolon insertion [won't be] * type declaration [won't be] Be advised that a javascript value that is passed to you through the interpreter, e.g. as a call parameter, may not be of the type that you expect. For example, in var x = 4; f(x);, what comes in as the parameter x into f is a wrapper value that adds assign()ability to a value that is wrapped inside. The advised solution to get the object that you expect is to call eliminateWrappers() on the potentially wrapped value. /quote I haven't any idea how much of a loss these represent. I will say, however, that the author seems to *really* like namespaces... All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ 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
Re: [Flightgear-devel] Nav and Guidance Made Easy(?)
On Wed, 2002-07-03 at 14:50, Jonathan Polley wrote: I was always unsure about the basics of navigation and guidance until I listened to this .wav file, then everything made sense! I'm sure some of you nav people have heard it before, but it is funny. It is suppose to be from an official US Air Force training file, but it sounds as if the voice-over people were feeling a bit bored. Be warned that when I played this for someone at work, they had to sit down for a bit. http://homepage.mac.com/eq_fidget/guidedmissle.wav So that's how they do it! ___ 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
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross wrote: Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. Yup, I see just the same as you. On crossing the dotty white crack, my little plane topples over on its back like a beetle waving its legs in the air. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 effectiveness=nnn for both hstab andvstab
This is great stuff; apologies for forgetting to respond yesterday. :) Dave Perry wrote: I was able to get good control (vtab effectiveness) and early tail up (htab effectiveness) with both values at 2.25. It was easier with both values at 2.5. I then shot a number of touch-n-goes using wheel landings. It still seems that it is very easy to over control in pitch while trying to stay on the mains. One effect that you may be missing is prop wash effects. During the takeoff roll in the real aircraft, the tail surfaces will be much more effective due to back blast from the propellers. YASim doesn't model this, so in order to get good controllability during takeoff you are probably having to increase the effectiveness more than is strictly correct. This makes the whole tail surface, including elevator and rudder authority, more effective and you get the pitch sensitivity that you mention. You could try to treat this by tuning down the flap effectiveness of the elevator (or increasing that of the rudder and turning down the overall effectiveness). Inter-surface wash effects are on a list of stuff that would be cool to implement (they get you asymmetric stall effects too, which would be nice to have modeled). I've been spending most of my time recently with the jet models, which don't really need them. Taildraggers do, though, so maybe I should give it some thought. For normal full stop landings, it is best to lock the tail wheel and do a full stall landing, brake, get rid of the flaps, and then unlock the tailwheel to turn off the active. I've found that to be true with the YASim model as well, although some articles at douglas-dc3.com indicate that normal practice was to never do a three point landing and instead plant the mains as early as possible. As you mention, the YASim model makes that difficult. If you get the model to a place where you're happy with it, would you be willing to post it so we can try it out and get it into the archive? I'm no expert on tail draggers, so I haven't done as much testing on this model as it needs. David is the only one who has spent significant time with it, I think. 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
Re: [Flightgear-devel] Nav and Guidance Made Easy(?)
Jonathan Polley wrote: I was always unsure about the basics of navigation and guidance until I listened to this .wav file, then everything made sense! I'm sure some of you nav people have heard it before, but it is funny. It is suppose to be from an official US Air Force training file, but it sounds as if the voice-over people were feeling a bit bored. Be warned that when I played this for someone at work, they had to sit down for a bit. http://homepage.mac.com/eq_fidget/guidedmissle.wav Well, that's basic set theory. Every maths student has to do it at the beginning of university, so why should a missle be more complicated? 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
Re: [Flightgear-devel] Small Scheme library
Tony Peden wrote: On Wed, 2002-07-03 at 11:40, David Megginson wrote: Tony Peden writes: I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. That's pretty close. I wonder how bad the dependencies are. OK, I've gotten the compressed and uncompressed numbers confused. The two numbers I quoted above are uncompressed. The original 360k posted was for the whole library and was compressed. I've isolated all the headers and source required to get the js interpreter to compile and link. The resulting executable works, but all it does is instantiate the interpreter then delete it. At any rate, I ended up with 388k of uncompressed source. This compresses to 56k with tar and gzip. That sounds OK for inclusion for me. Note that du gives 17M for the FG source tree and 4.9M for the Simgear source tree after running 'make distclean' on both. Both numbers are, obviously, uncompressed. Compared to what size w/o JavaScript? One more thing I should point out, the author's caveat list: I haven't any idea how much of a loss these represent. I will say, however, that the author seems to *really* like namespaces... I dunno how much we have to / want to integrate the JS into FGFS. If it's sort of independat, just with the additional functions to use the property tree we don't need to care too much about its problems (whichever it has, apart from bugs/core dumps/...) Oh, and the namespaces don't hurt us... ;) What I don't know is how portable it is. I.e. on which compilers it does compile and work. (I have no reason to be suspicious, but it's a question that has to be asked) 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
Re: [Flightgear-devel] Small Scheme library
On Wed, 2002-07-03 at 15:50, Christian Mayer wrote: Tony Peden wrote: On Wed, 2002-07-03 at 11:40, David Megginson wrote: Tony Peden writes: I don't know how many interdependencies there are, but the js related source and headers total 142k. Check that, 212k. That's pretty close. I wonder how bad the dependencies are. OK, I've gotten the compressed and uncompressed numbers confused. The two numbers I quoted above are uncompressed. The original 360k posted was for the whole library and was compressed. I've isolated all the headers and source required to get the js interpreter to compile and link. The resulting executable works, but all it does is instantiate the interpreter then delete it. At any rate, I ended up with 388k of uncompressed source. This compresses to 56k with tar and gzip. That sounds OK for inclusion for me. Note that du gives 17M for the FG source tree and 4.9M for the Simgear source tree after running 'make distclean' on both. Both numbers are, obviously, uncompressed. Compared to what size w/o JavaScript? Those numbers are as FG stands today, w/o js. One more thing I should point out, the author's caveat list: I haven't any idea how much of a loss these represent. I will say, however, that the author seems to *really* like namespaces... I dunno how much we have to / want to integrate the JS into FGFS. If it's sort of independat, just with the additional functions to use the property tree we don't need to care too much about its problems (whichever it has, apart from bugs/core dumps/...) Oh, and the namespaces don't hurt us... ;) Didn't mean to imply otherwise. However, they can, just like anything else, be abused. I'm not so sure this guy hasn't crossed that line. What I don't know is how portable it is. I.e. on which compilers it does compile and work. (I have no reason to be suspicious, but it's a question that has to be asked) Agreed. 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 -- 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
[Flightgear-devel] Competition for FGFS at LinuxWorld ?
by Rick Lehrbaum -- Executive Editor, LinuxDevices.com GUESS WHO'S COMING TO LINUXWORLD? As if to fulfill Malcolm Dean's prophecy (preceding story), word spread around Linux and Open Source oriented websites like wildfire this week that Microsoft Corp. will be an exhibitor at the LinuxWorld Conference Expo in San Francisco next month. In response to an inquiry from LinuxDevices.com, a Microsoft spokesperson provided an explanation -- and it involves 'embedded' technologies. http://www.linuxdevices.com/news/NS8261038489.html ... I wonder whether they will be demonstrating MSFS ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
