Jump to: navigation, search

Howto:Coding a simple Nasal Framework

816 bytes added, 19:57, 26 February 2016
no edit summary
== Motivation ==I wish we could share more of our development on these things. Having lots of logic for route management and performance data and autopilot stuff re-implemented in every new "realistic" plane kinda sucks. It would be nice if we could build up the built-in system that covers 90% of the cases and any specialiation can be handled by refining the built-in system. Adding a new aircraft should be throw up a couple of displays and live with the built-in default ND and MFD in the first iteration, and then progressively refine it to match the real deal.<ref> {{FGCquotecite web |1url = the | title = <nowiki>Re: FMC</nowiki> | author = <nowiki>alge</nowiki> | date = Feb 24th, 2016 | added = Feb 24th, 2016 | script_version = 0.25 }}</ref> The whole point of developing frameworks and encapsulating functionality there is to allow people to merely "request" a certain component (think ND, PFD, map, EICAS) and "configure" it as needed (think fonts, colors, symbols, events, images etc). And once you look at the integration "code" that loads a working ND, you will see that it is merely a mark-up dialect sligthly different from XML (in fact, it could be XML just as well, but it doesn't yet make sense to provide an XML dialect currently).In basic terms, you are merely telling the system that you want a certain component, and how you want it to look - and you are doing that using a "configuration file" that could just as well be in a different format (it merely happens to be using JSON/hash syntax, because that's easy to support using Nasal hashes): [[Canvas ND Framework]]|2= <ref> {{cite web
| url =
| title = <nowiki>Re: Developing a Canvas Cockpit for the CRJ700</nowiki>
| date = Jul 7th, 2015

Navigation menu