6,566
edits
Howto:Coding a simple Nasal Framework: Difference between revisions
Jump to navigation
Jump to search
Howto:Coding a simple Nasal Framework (view source)
Revision as of 09:12, 8 March 2016
, 8 March 2016Switch from {{git link}} to {{fgaddon source}} to provide a functional link to the correct infrastructure.
(Switch from {{git link}} to {{fgaddon source}} to provide a functional link to the correct infrastructure.) |
|||
| (5 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
<!-- | |||
{{WIP}} | {{WIP}} | ||
--> | |||
{{DeQuote}} | |||
== 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> {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=277481#p277481 | |||
| 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]]<ref> {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=250211#p250211 | |||
| title = <nowiki>Re: Developing a Canvas Cockpit for the CRJ700</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 7th, 2015 | |||
}} | |||
</ref> | |||
It would be helpful if someone would bootstrap such a framework. Having something there may create enough intertia to have people join the effort, otherwise there's simply no such project and I suppose some aircraft developers would rather do something of their own, at their own pace instead of waiting for such framework to maybe materialise one of these days. | |||
<ref>{{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=277524#p277524 | |||
| title = <nowiki>Re: FMC</nowiki> | |||
| author = <nowiki>CaptB</nowiki> | |||
| date = Feb 25th, 2016 | |||
| added = Feb 25th, 2016 | |||
| script_version = 0.25 | |||
}} | |||
</ref> | |||
{{FGCquote | |||
|1= Equally, even creating/adding new features to the ND code is fairly accessible these days, and people don't need to be proficient coders or even understand how Nasal/Canvas work behind the scenes - for this to work, there are tons of assumptions made on what people want to do, but that is generally a safe thing to do in a use-case specific framework (think for creating PFDs, NDs, HUDs or other MFDs). | |||
Under the hood, all that is needed is a simple animation framework to show/hide, update and animate SVG symbols using Nasal timers and listeners. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=250211#p250211 | |||
| title = <nowiki>Re: Developing a Canvas Cockpit for the CRJ700</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 7th, 2015 | |||
}} | |||
}} | |||
What would make sense is to assist the people who come second or third and want to re-use an existing framework where possible in implementing and re-factoring. Or people who just want to work on the framework and don't have a particular use case in mind. Because then you can make it work with a well-defined set of requirements in mind, rather than trying to guess what the requirements are ahead of time.<ref>{{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=277685#p277685 | |||
| title = <nowiki>Re: FMC</nowiki> | |||
| author = <nowiki>Thorsten</nowiki> | |||
| date = Feb 26th, 2016 | |||
| added = Feb 26th, 2016 | |||
| script_version = 0.25 | |||
}} | |||
</ref> | |||
{{FGCquote | {{FGCquote | ||
| Line 13: | Line 68: | ||
}} | }} | ||
}} | }} | ||
== Objective == | == Objective == | ||
Illustrate the basic thought process required to come up with Nasal/Canvas code that is sufficiently generic to meet the following requirements | Illustrate the basic thought process required to come up with Nasal/Canvas code that is sufficiently generic to meet the following requirements | ||
| Line 210: | Line 266: | ||
== Moving huge conditionals into hash functions == | == Moving huge conditionals into hash functions == | ||
The next problem we want to tackle is getting rid of huge conditional blocks inside the '''update()''' method: {{ | The next problem we want to tackle is getting rid of huge conditional blocks inside the '''update()''' method: {{fgaddon source|path=Aircraft/747-400/Models/Cockpit/Instruments/PFD/PFD.nas}} | ||
<syntaxhighlight lang="nasal" line="GESHI_FANCY_LINE_NUMBERS" start="258"> | <syntaxhighlight lang="nasal" line="GESHI_FANCY_LINE_NUMBERS" start="258"> | ||