Re: [Flightgear-devel] A-4C attitude indicator
> > A number of Bf-109 pilots would have the slats bolted into the > > retracted position to keep a asymetrical slat deployment from > > ruining a gun attack. > > ..this was a "designed in feature", Luftwaffe rationale was > "help the pilot spray his fire". As survivors built aiming > skills, they developed a dislike for the "newbie feature", > and hacked their plane. ;-) > Hehhe. Neat. Thanks for the info. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
Andy Ross <[EMAIL PROTECTED]> said: > Of course, a real pilot would be able to physically move his head by a > few inches. Yes and actually they can move their head left a right a bit to see better too. I'm not opposed to fudging things a bit to allow for the limitations of flying on a PC. For example, if real dimmensions were used on the intrument layout it'd be really tough to fly (you'd have to constantly be moving the mouse around to change the view offset). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
Jim Wilson wrote: > Andy Ross wrote: > > But I also goofed and checked in some of my private changes. The > > eyepoint is slightly higher, allowing the pilot to look straight > > down the nose as I believe is true for the real aircraft (it > > radically improves visibility at high AoA's). > > You probably haven't noticed but I've been inching it up just for that > reason :-) However, studying quite a few photos, it's amazing that > pilots can see anything other than straight ahead through that target > window, even at low AoAs. I keep thinking there has to be an error > there...but the photos all show the pilot's helmut is at about the > right height and the panel in about the right place. Been using the > helmut as a guid for placing the eye. Maybe we're interpreting the photos differently? From the ones I've seen, the location of the pilots eye traces a straight line over the panel cover and straight down the nose at about 16° or so. The top of the oval windscreen is almost directly in front of the eyepoint. This allows for an approach at 13.5° AoA with some room to spare looking over the nose. I'm pretty sure that's about right. It certainly "feels" correct. Of course, a real pilot would be able to physically move his head by a few inches. If he sits with his helmet against the rest, he will obviously have less visibility. I'm assuming his neck is in "approach configuration", tilted slightly forward for best over-the-nose viewing. 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] Re: 3d Panel problem
Andy Ross <[EMAIL PROTECTED]> said: > Also, by way of the A-4 cockpit: I checked in an AoA indexer "mini > panel" last night that sits up by the windscreen edge as an example of > having more than one 3D panel. There's not geometry to go with it > yet, just a texture floating in the air. Cool! I'll check it out. > But I also goofed and checked in some of my private changes. The > eyepoint is slightly higher, allowing the pilot to look straight down > the nose as I believe is true for the real aircraft (it radically > improves visibility at high AoA's). You probably haven't noticed but I've been inching it up just for that reason :-) However, studying quite a few photos, it's amazing that pilots can see anything other than straight ahead through that target window, even at low AoAs. I keep thinking there has to be an error there...but the photos all show the pilot's helmut is at about the right height and the panel in about the right place. Been using the helmut as a guid for placing the eye. > Also, I deleted the mag compass, > as the real aircraft must have one, but not in that location. Actually in the few fuzzy photos of it, I've seen the compass about there and sometimes a little to the right. I think it gets moved around quite a bit so, not sure where it was in the a-4f or the blue angel. In any case its gotta be somewhere in that area as there really is no other place for it in that tiny cockpit. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
On Thu, 27 Jun 2002 06:58:07 -0700 (PDT), Gene Buckle <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > A number of Bf-109 pilots would have the slats bolted into the > retracted position to keep a asymetrical slat deployment from > ruining a gun attack. ..this was a "designed in feature", Luftwaffe rationale was "help the pilot spray his fire". As survivors built aiming skills, they developed a dislike for the "newbie feature", and hacked their plane. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] The "string" class fights back (was: Property browser bugs)
David Megginson writes: > >That's what I had thought as well, but it turned out not to be the >case. The string constructor is expensive, and we ended up using lots >(and lots and lots of them), running, as we were, 30-100 iterations >per second through hundreds of properties. Switching from string to >char * gave a noticable framerate improvement -- even Norm was happy. < nitpick > happier is a better word choice < /nitpick > as far as I am concerned creating an ASCII property path is a waste of time and should not be used anywhere inside the 'main loop'. It does have it's place during initialization and when processing User Interaction that is not 'normally' done every frame IMHO this is analagous to using 'text' vs 'binary' files each has it's place and there is a very clear winner if there are 'performance' issues to consider Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
Jim Wilson wrote: > We could probably have a bool property for that. I tried disabling it > in the code and found that it didn't fix the problem I'm seeing with > the AI globe. > > http://www.spiderbark.com/fgfs/a43d-panel.png > > Note that one of the polys for the AI backplate has picked up a > texture from one of the instruments (upper right of AI). That's very odd, and I don't see it. You could try crawling through the .ac file and making sure that the weird texture isn't referenced by a stray polygon, but off hand I'd say this is a driver bug. Also, by way of the A-4 cockpit: I checked in an AoA indexer "mini panel" last night that sits up by the windscreen edge as an example of having more than one 3D panel. There's not geometry to go with it yet, just a texture floating in the air. But I also goofed and checked in some of my private changes. The eyepoint is slightly higher, allowing the pilot to look straight down the nose as I believe is true for the real aircraft (it radically improves visibility at high AoA's). Also, I deleted the mag compass, as the real aircraft must have one, but not in that location. Apologies if this gets in the way of something you're doing; feel free to back it out. 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] JavaScript!
David Megginson wrote: > So, Andy, here's your challenge -- you wrote YASim to prove how small > and simple an FDM could be; how about showing us how small and simple > a JavaScript implementation can be? I'm sure FlightGear isn't the > only project that would benefit. Yikes, don't tempt me. You heard Curt -- I'd get it written, it would be small and tight and everyone would love it, and then I'd spend the next 10 years turning it into the huge monster that every other scripting language becomes. In place of the Dark Lord, you would set up a King; beautiful and terrible. All would love it and despair. Or something, anyway. I pass the test. :) Or not -- I'll admit that I've thought about writing a scripting language in the past. But it's not a simple project. Or rather, it can be a simple project if you're willing to do Scheme. If you want to do a parser for a nicer syntax and have built-in support for concepts like modules and OOP, it takes more work. 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] The "string" class fights back (was: Propertybrowser bugs)
Julian Foad wrote: > THE "STRING" CLASS IS VERY EFFICIENT! This is only sort of true. The string class is as efficient a general-purpose, arbitrary-length, arbitrary-lifespan data handler library as you can find. :) The problem is that such a beast is just going to be slow, period. Returning a string from a function requires that it be allocated in the heap, used, and then thrown back into the heap immediately. That's a round trip through the memory allocator for every such function call, which is going to be much, much slower than returning a static pointer. This is not surprising, because it's also much more robust than returning a static pointer. I'm not sure that there's a good answer here. We could consider "interning" constant strings like property paths into constant references that don't need allocation. But stuff like getStringValue() is always going to have to allocate a new string if we want to do this robustly. 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] Re: 3d Panel problem
Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > One thing I'm wondering is if we can do away with the background > > texture in the 3-D panel. Do we need it or can the "backplane" always > > be part of the model? Not sure if this would fix the problem with the > > 3-D model/instrument or not. > > There's no real need for the "panel" to have a background in a 3D > environment. It makes more sense, IMHO, for the background texture to > be part of the model geometry. I think that right now the background > (multi-)texture is required, but that'll be easy to fix. > We could probably have a bool property for that. I tried disabling it in the code and found that it didn't fix the problem I'm seeing with the AI globe. http://www.spiderbark.com/fgfs/a43d-panel.png Note that one of the polys for the AI backplate has picked up a texture from one of the instruments (upper right of AI). And the face of the backplate is otherwise transparent.Also the various indicator arrows are all but invisible. There is a line evident under the AI and above to the left (these are from the side of the instruments mounting backplate. It doesn't appear to be a depth precision issue. Moving the panel out so it is hovering over the runway doesn't change a thing on the AI instrument. Moving the AI instrument has no effect either. And removing some of the 3-D AI's layers doesn't help. But, if I remove the panel entirely from the model config the 3-D AI instrument renders normally again: http://www.spiderbark.com/fgfs/a43d-nopanel.png Any idea what we're looking at? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] New font / updated patch
On Fri, 28 Jun 2002, [EMAIL PROTECTED] (Andy Ross) wrote: > Date: Fri, 28 Jun 2002 23:15:31 -0700 > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Andy Ross) > Subject: [Plib-devel] New font / updated patch [...] > Plib folks: this patch supersedes the one I sent yesterday. My first > one missed a spot. The calculation of string width needs to use the > new width metrics too, otherwise the strings themselves will print > acceptably, but be laid out with too much space. James and I were talking about that issue yesterday. It is good to know that you fixed it, since you saved us some work this way :). Now with that problem being erased, I think there is nothing that prevents us from checking your patch into CVS. - Sebastian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: > Andy Ross writes: > > > But the language itself is pretty mild. It's a lot like perl and > > python -- hashes and vectors are the core data structures, with syntax > > support for common idioms like regular expressions and function > > calling. Object naming is represented explicitly as a hash lookup, > > etc... > > That's my thinking as well. Personally, I'd be just as happy with > Perl or even Python, but there are probably many more people out there > who know JavaScript syntax. Once we remove all the browser-specific > stuff, as you say, it should be nice and compact. So now I can safely conclude that JavaScript is the direction to go? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's Changes
Curtis L. Olson wrote: >>>really lousy from altitude ... it has horrible repeating artifacts. >>>Would anyone want to try to come up with a better rocky/desert land >>>cover texture. >> >>I might try, but won't make any promises ... > > > Actually, many of the ground cover textures could stand some rework. > Some of the grass land is pretty poor in comparison to the new crop > textures, the glacier texture could be better, etc. Hmpf, you give them one finger ... :-P Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
> > > > (I'd love a programming environment on my Palm V, for example) > > Hmm.. I sense a potential Python convert lurking in these words :-) > > http://pippy.sf.net > > Enjoy > > Norman bah... http://smallbasic.sf.net mmm.. smells like GW-BASIC... ;) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: C172P Hi-Res Panel Photos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Jun 2002 14:27, Ryan Larson wrote: > Descriptive pics are up, also added an Archer. Will add a Bonanza > tomorrow.. and possibly a couple of Saratogas.. Don't forget there's also lots on airliners.net as well as some other cool sites. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9HaXgZOfFgbBAbXARAjqmAJ9QJ8chJjBZ3+Hx9VDd2gRIkgZ9YgCgjQKf MKqIijF7pAseKVu7RLIbKVU= =fLVi -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewangle input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can the viewing angle now be set via the network interface? Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9HaF9ZOfFgbBAbXARAmWTAJ9XDsp69ns9H9t9+od14oJMi3bHjwCgoXUJ BAF+83knkuM5caaRZAXkDgw= =kU7D -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Jun 2002 05:53, Curtis L. Olson wrote: > I was just looking at the external view of the blue angels a4 ... > If someone wanted to really waste some time it might be kind of neat > to animate the helmet based on the direction of the internal view ... > > That and we should probably make the pilot be able to salute. While we're on the subject of dumb suggestions, I'd like to see multitexturing on the taxiways and runways, so up close you see all the grains, at a distance you don't. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9HZzOZOfFgbBAbXARAnDYAKCOEzGzcltNyBGsIZJBK8RMlJ59oACdFdKT ytT7DkB5hl6DUI2ooLler30= =hI1Z -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Jun 2002 15:54, Andy Ross wrote: > Jim Wilson wrote: > > One thing I'm wondering is if we can do away with the background > > texture in the 3-D panel. Do we need it or can the "backplane" always > > be part of the model? Not sure if this would fix the problem with the > > 3-D model/instrument or not. > > There's no real need for the "panel" to have a background in a 3D > environment. It makes more sense, IMHO, for the background texture to > be part of the model geometry. I think that right now the background > (multi-)texture is required, but that'll be easy to fix. That will definately require LOD then, because if it's used for panel background it would have to be detailed, but you won't want all that detail outside the aircraft. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9HZjiZOfFgbBAbXARAtNPAKCbF4d46zABJDt5wgRFax91AArroACfaNcY EZgQpfEmZD247SXFqMP8UJI= =Dfd8 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
David Megginson writes: > >Cameron Moore writes: > > > Here's another dumb suggestion: It would be pretty cool is someone > > would turn off the sun at night. This is a known issue[1], >but it's a > > pretty glaring (no pun intended) bug. > >Yes, I've had this discussion as well. The sun should stop being a >light source once it's, say, 15-30 deg below the horizon. Otherwise, >it lights up the bottoms of objects at night. I think all that is needed is to change to 'ambient' lighting only after the sun goes 'below' a certain point. didn't-we-fixe-this-once-before'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] The "string" class fights back (was: Property browser bugs)
Julian Foad writes: > These sorts of difficulties with (char *) strings, especially not > being able to pass them by value in any simple way, are the reasons > why the "string" class has come to exist. THE "STRING" CLASS IS VERY > EFFICIENT! (I'm speaking to everyone; I'm sure David already knows > this.) That's what I had thought as well, but it turned out not to be the case. The string constructor is expensive, and we ended up using lots (and lots and lots of them), running, as we were, 30-100 iterations per second through hundreds of properties. Switching from string to char * gave a noticable framerate improvement -- even Norm was happy. > So, I beg for the getPath() member to return a "string" object. > This requires one simple patch to one existing caller (which needs to > have a temporary variable added to hold the result); the other callers > want a "string" anyway and so will be more than happy to receive one. This isn't a bad idea, since getPath isn't used heavily in the loop. I'll have to think about it a little more. > I would also argue for using the "string" class in make_string() > and other appropriate places. This will remove the need for the > one-kilobyte temporary buffer that is presently included in EVERY > property node. No, that's where the problem was. There are ways that we can make this more efficient, probably -- we could make the buffer lazy, for example, or make it smaller. 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] dumb suggestion
David Megginson writes: > -- plib has a new (mostly undocumented) >particle system designed for just that sort of thing. Have you seen http://toobular.sf.net Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
Cameron Moore writes: > Here's another dumb suggestion: It would be pretty cool is someone > would turn off the sun at night. This is a known issue[1], but it's a > pretty glaring (no pun intended) bug. Yes, I've had this discussion as well. The sun should stop being a light source once it's, say, 15-30 deg below the horizon. Otherwise, it lights up the bottoms of objects at night. 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] dumb suggestion
Curtis L. Olson writes: > Aside from locating 8 suitable machines/monitors, the big issue is > that paying the union fees for moving this stuff 20 feet across the > loading doc would be extremely prohibitive. :-( You need 8 notebooks with big LCD panels and GeForce cards, together with small speakers. You could smuggle each one in a backpack. 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] JavaScript!
Cameron Moore writes: > I think it's safe to say that there are two contenders at this point: > Scheme and Lua. I'd never heard of Lua until this thread, but I've seen > Scheme. I would expect that we would use Guile for a Scheme > interpreter. How big is Guile? Has anyone ever used Lua? Run away screaming. There are several (many?) small, tight Scheme interpreters available, but Guile isn't in the list -- by now, it probably makes Python and Perl look compact. 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] JavaScript!
David Megginson writes: > > (I'd love a programming environment on my Palm V, for example) Hmm.. I sense a potential Python convert lurking in these words :-) http://pippy.sf.net Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
Jim Wilson writes: > > That and we should probably make the pilot be able to salute. > Now that would be easy, but he needs an arm first! Thumbs up first, please. > Might be fun to do an eject too :-) He'll need his own FDM, then. 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] dumb suggestion
Gene Buckle writes: > Along this vein, how about a wingtip smoke system? Red and blue smoke > would look VERY cool. Funny you should mention that -- plib has a new (mostly undocumented) particle system designed for just that sort of thing. I'm not getting through to SourceForge right now, so I cannot give you a URL from the plib-devel archives, but look for a recent message from Steve Baker describing how the code works. This is something we could look into for smoke, contrails, and even clouds, though I imagine it would get very expensive quickly unless we use big, coarse particles. 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] Re: 3d Panel problem
Jim Wilson writes: > This is in the c172: http://www.spiderbark.com/fgfs/c1723d-panel-1.png > Looks like the 3D panel is raised up off the panel's "plane" a bit (you can > see the yoke sort of in the middle of the RPM guage in this shot). Yes, that's my fault. I raised it a bit so that the mag compass face would show up. The right solution will be to make the mag compass its own panel with a different x offset, or (even better) a 3D object. Feel free to play around. 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] JavaScript!
Andy Ross writes: > But the language itself is pretty mild. It's a lot like perl and > python -- hashes and vectors are the core data structures, with syntax > support for common idioms like regular expressions and function > calling. Object naming is represented explicitly as a hash lookup, > etc... That's my thinking as well. Personally, I'd be just as happy with Perl or even Python, but there are probably many more people out there who know JavaScript syntax. Once we remove all the browser-specific stuff, as you say, it should be nice and compact. So, Andy, here's your challenge -- you wrote YASim to prove how small and simple an FDM could be; how about showing us how small and simple a JavaScript implementation can be? I'm sure FlightGear isn't the only project that would benefit. If it's small enough, it might even be useful for handhelds and the embedded market (I'd love a programming environment on my Palm V, for example) 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
[Flightgear-devel] Another JavaScript implementation
Hi, I found anouther Freeware JavaScript implementation which looks smaller than the one provided bij Mozilla and supports ECMA Script level 3. It isn't much smaller, but at least it is completely LGPL. http://www.bbassett.net/njs/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
