#77 re-thinking scripting support (consider supporting Nasal)


it might make sense to consider adding better or even full scripting support to jsbsim:There have been lots of discussions regarding this (some of which are referenced below). This could possibly even be directly based on "nasal" which is already available in simgear, and thus automatically supported by the build system and all dependencies.

The problem is not so much about people resorting to use Nasal for certain things, but rather that there is no good alternative available in jsbsim for these things, because of the way "FGScript" is implemented in jsbsim.

The jsbsim scripting capability is a huge XML based "workaround" for implementing code and logics in XML space, even David Megginson has repeatedly emphasized that code should ideally not be implemented in XML files and that data definitions should not live in code either.



  • Jon S. Berndt

    Jon S. Berndt - 2010-12-12

    If we went to anything else, we'd almost certainly go to Python.

    The JSBSim scripting capability is an event language. What XML has going for it is a schema that can support validation prior to runtime. Going against it is the fact that it is very verbose. The XML language is not really meant fo rhuman reading/editing, but for applications that will deal with the configuration files and shield the user from the XML files themselves.

    I'm not really interested in supporting another major capability, though, at this time. There are also the Python bindings that are already available for JSBSim.

    Also, I'm not sure that you really are talking about the FGScript class, which is not used at all in FlightGear. What is used in all cases are the XML-based files in which one defines GNC functions, such as waypoint calculations, etc.

  • Jon S. Berndt

    Jon S. Berndt - 2010-12-17

    There are established languages that might be far more appealing, and would provide an even broader compatibility and usefulness, such as Python. Our XML format is clunky and verbose for some applications, but there are also benefits to it, including schema validation prior to runtime. I don't see a reason to go with another language that would involve an additional dependency at this time.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks