Nasal success stories

Probably the biggest barrier for most people is going to be getting their development system setup properly so they can compile their new code additions or changes. — Curtis Olson (Oct 24th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes. (powered by Instant-Cquotes)

its not that easy to get your changes into the system. I am not complaining about this and I acknowledge that changing the internal program is a thing that has to be carefully reviewed. Writing some Nasal code usually does not affect the whole system and can be maintained for a single aircraft. — Torsten Dreyer (Oct 25th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes. (powered by Instant-Cquotes)

The relevant question is whether any of this creates a bottleneck somewhere. And if not, if you have performance to spare (which you clearly have till you're down to 60 fps) then maintainability, ease of access and inability to segfault make Nasal a very good tool. — Thorsten (Nov 24th, 2015). Re: the real cost of the Nasal Garbage Collector. (powered by Instant-Cquotes)

The quantity of details and system modeling that goes in to covering all the aircraft of the world is impossibly complex. The idea is to put as much support for common/shared systems in C++ as we can and then make it possible to stitch these systems and details together and configure them with xml in a wide variety of ways to create aircraft. But we can never anticipate every system in use, and we can't anticipate the level of detail or feature set that every aircraft developer might want to implement or experiment with, and even if we could there would be no way to model everything in the world in a single application. Nasal gives a lot of flexibility to cover those unanticipated gaps and it allows aircraft developers to push in new areas ahead of the C++ coverage. Now in many cases, aircraft developers were happy with the nasal implementation and called it good enough. Many aircraft developers have become proficient and comfortable in nasal and prefer doing their work there. — curt (Dec 16th, 2015). Re: Military simulation (from Su-15 Screenshots). (powered by Instant-Cquotes)

Perl, Python, Lua, Ruby

FlightGear needed a built-in scripting language, and it has one. A compact, clean, elegant and fast one. In total there are at the moment more than 170.000 lines of Nasal in *.nas files and a few thousands embedded in joystick drivers, dialog description files, model animation files, keyboard.xml, mice.xml and several other files. Extension functions interface perfectly to the property tree, the event manager, the built-in XML parser etc. Nasal is very tightly integrated in fgfs and used all over the place. — Melchior FRANZ (Mar 8th, 2009). Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?. (powered by Instant-Cquotes)

When Nasal was first imagined, perl was still a pretty big deal and python was still more of the new-comer trying to break onto the scene... at the time it seemed like just another scripting language ... and slightly weird because of it's rigid white space usage. Lua was/is also a viable option. — curt (Dec 28th, 2015). Re: FGPython an propose for Python as an nasal alternative. (powered by Instant-Cquotes)

Nasal coming to FG was an enabler - suddenly all sorts of scripting was possible for people. Another scripting language - even if it is genuinely better - is just being the BlueRay to the DVD - more of the same essential experience, but adding confusion. — Thorsten (Dec 29th, 2015). Re: FGPython an propose for Python as an nasal alternative. (powered by Instant-Cquotes)

Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat ("re-invention of the wheel" is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable. — Melchior FRANZ (Mar 8th, 2009). Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?. (powered by Instant-Cquotes)

Some success stories

These were taken from the developers mailing list:

• "Nasal is *very* well designed, compact, and efficient. It is used heavily throughout many areas of FlightGear."
• "It's interesting though how much nasal you can actually get away with using without making a blip on frame rates. Nasal is *very* efficient and powerful for being an interpreted script language."
• "FlightGear needed a built-in scripting language, and it has one. A compact, clean, elegant and fast one, Nasal extension functions interface perfectly to the property tree, the event manager, the built-in XML parser etc. Nasal is very tightly integrated in fgfs and used all over the place."
• "There's no question that scripting languages are good; fgfs has a lot of Nasal code now. In my profiling I have never seen the nasal interpreter as a hot spot"
• "I'm a simple content contributor with very little background in programming. When I made my first Aircraft (the bf109) I was confronted with the need to deploy slats automatically at a given speed. I din't want to embed C++ code or had such a complex script that the error messages in FG wouldn't help me and I previously only used a bit of python. I looked at some Nasal scripts and within a few hours it worked. I was impressed how easy it is to write even complex Nasal scripts. Later I started developing the walker feature that made it possible to walk around in the scenery, all with nasal. Stuart kindly enhanced the walker and added an animation system to it (see bluebird), again with nasal. Others have made Flight computers with it (see V-22 and Su-37). Nasal is a worthy tool"
• "I used Nasal to build several rather complex systems, like Fuel System, Stab Augmentation System, Autopilot Logic, Terrain Avoidance Radar, Radar Warning Receiver and much more, and yes, I love Nasal too. Learning Nasal use was easy and fun and I din't found any limitation yet."
• There are many vital parts of FlightGear currently coded in nasal. There are also random bits of nasal code scattered around in joystick configurations, instrument and aircraft models, scenery models... everywhere.
• "We have an entire directory full of Nasal 'function' libraries now, and I'm quite happy using them instead of rolling my own duplicate functionality."
• Nearly every sophisticated Aircraft uses some kind of Nasal, be it Effects like tyre smoke or important functionalities like Engine and electric management, The Bluebird FDM is completely written in Nasal, vital parts of the V-22 Osprey rely on it, Flyby and Model View wouldn't work anymore, no more interactive objects in the scenery, lots of the MP System would be gone, ... Nasal is THE tool which makes FG development fun and adds nearly unlimited possibilities. If you need an example, look at the Bluebird animated walker, all done in Nasal."
• "there are good reasons to use Nasal - first of all the user base which regularly compiles their own code is small, whereas people do install addon packages - so I get a lot more feedback and test results. Second that one usually can't really crash the whole system from Nasal. Third, it's very easy to quickly try something and very maintenance-friendly. Fourth, you can actually start developing something without knowing how the core code ties together - which I suppose takes a lot of time to learn. And so on."
• "Hard-coding every instrument in C++ instead of nasal means only developers following/building the latest cvs head code get to use whatever until the next release cycle."
• "Hard coding every instrument/flight control in C++ means my WW-II storch (et.al.) is stuck with an autobrake functionality it doesn't have nor need."
• "I think it boils down to the fact that we have two approaches that can accomplish the same thing. The C/C++ approach offers high performance but there is a dependence on when the C/C++ code was added to FlightGear. The Nasal approach offers fast prototyping, flexibility, and more (but not complete) independence from the C/C++ code."
• "A basic problem with C++ functions is it is hard/impossible to override them for a special purpose. Writing in pure nasal allows function name hijacking and other tricks that can't be used on C++ code."
• "Given the fact that FG is platform independent, I don't know if the embedded C++ is doing the same on Windows, Linux, PPC and intel Macs. Apart from the fact that if I was able to code c++ I would embed it to FG rather than in an Aircraft specific script"
• "If we ported Nasal code over to C++ we'd lose the ability to change small things "on the fly" without compiling over and over again. We'd also lose good programmers, who prefer scripting over C++. Aircraft creation would not be customizable etc etc."
• "The argument against Nasal is essentially that C++ is faster than Nasal - which, everything else being equal, is certainly correct. But highly specialized Nasal code written for a particular problem outperforms general purpose C++ code - I've given several examples in the past. If someone were e.g. to add movement to Nasal spawned models by adding a velocity property, I'm not sure it would outperform my Nasal quadtree-sorted adaptive range code which priorizes movement for things actually inside the field of view. Of course, if you'd hard-code that specialized algorithm, it would be faster than the Nasal version - but then you couldn't apply it to other problems any more."
• "How many airplane developer will you loose if you remove the Nasal engine from FGFS because they can write Nasal code but not C++ code?"
• "The algorithm being equal, I don't think there's a question that C++ is faster (I doubt the factor 10 though - that seems to be an extreme case). Everything else being equal, I also don't think there's a question that Nasal code is more accessible. And I would base any decision what to hard-code and what not on that balance."
• "Nasal is just much better suited for FlightGear than many alternatives because of it's size, processing speed and because a number of FlightGear core developers have a good idea what's going on."
• "In theory we could even use VBScript but Nasal has proven to be valuable for almost 10 years, so no reason to change or add another scripting language. Besides, if you know JavaScript then learning Nasal would take little effort."
• "The pool of people with commit rights to the core C++ code is very, very small."

Nasal really is an excellent choice for prototyping and implementing new features and even completely new systems in FlightGear.

For example, the bombable script implements "dog fighting" support on top of FlightGear, without ANY changes to the C++ side of the code, just by using some fairly advanced scripted code (implemented in the built-in Nasal programming language). You can basically imagine it like a "MOD" of FlightGear. In other words, the bombable script creates a completely new "mode" in FlightGear.

No matter if it's scenery, aircraft, AI scenarios or whatever: many things that were originally never planned to be supported by FlightGear core developers, are now implicitly supported because of the loose coupling between highly configurable and flexible systems, such as the property tree and the Nasal scripting language.

So we are really standing on the shoulders of giants here, because we are now -after 10+ years- in the position to create significant new features (and even completely new systems in FlightGear) within the constraints of the FlightGear base package, without even touching the C++ source code at all - simply because FlightGear has become so flexible and extensible.

All of this became possible by some important architectural decisions, such as for example the use of XML and plain text files for pretty much all configuration files in FlightGear (and thus open file formats in general), a publicly accessible tree of state variables that can be easily inspected and modified at runtime (the property tree). Similarly, the decision to embed a scripting language that can be used for scripting the entire simulator was another important decision.

In FlightGear, Nasal is the most accessible method of customizing the whole simulator to a very high degree. Nasal code can be easily edited using a conventional text editor, there are no special tools required: Nasal source code is interpreted, compiled to bytecode and run by the Nasal "virtual machine" using FlightGear itself.

The emerging Local weather system was entirely prototyped in Nasal space, and is now being increasingly augmented by moving performance-critical functions to C++ space instead.

Using Nasal, it is even possible to create entirely scripted flights and smart "AI bots":

I have something here that I think is kind of fun. I've been fiddling with this off and on since last fall and decided it was time to clean it up a bit and quit hording all the fun for myself. Basically I have taken the F-14b and created a high performance Navy "drone" out of it. It can auto-launch from a carrier, auto fly a route (if you've input one) and can do circle holds (compensating for wind.) I've added a simulated gyro stabilized camera that will point at anything you click on and then hold that view steady no matter what the airplane does (similar to what real uav's can do.) Finally, you can command it to return home and it will find the carrier, setup a reasonable approach and nail the landing perfectly every time (factoring in wind, carrier speed, etc.) — Curt Olson

As of 03/2009, there were approximately 170,000 lines of reported Nasal source code in the FlightGear base package , compared to 2006 this is almost a rate of growth of 600% within 3 years . This illustrates the sheer adoption rate Nasal is experiencing in FlightGear.

(As of 10/2011, the FlightGear base package contained 326.000 lines of Nasal source code in *.nas files)

Note that this page is mostly about FlightGear-specific APIs/extension functions and usage patterns. Thus, you may also want to have a look here:

• core language/library documentation
• annotated source code examples
• Nasal design document
• a helpful tutorial about using Nasal in FlightGear.

In addition, the Nasal directory in the FlightGear base package contains a wealth of tested, proven and usually well-commented source code that you may want to check out for additional examples of using the Nasal scripting language in FlightGear.

If you have any Nasal specific questions, you will want to check out the Nasal FAQ, feel free to ask new questions or help answer or refine existing ones. If you would like to learn more about existing Nasal modules in FlightGear, you may want to check out Nasal Modules.

If you are a developer and interested in extending Nasal, you may want to check out Howto:Extending Nasal.

Many short "howto"-style tutorials on Nasal programming can be found in the Nasal category.