Template:CppBind Ideas: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Candidates: http://forum.flightgear.org/viewtopic.php?f=4&t=25157&p=262400#p262400)
m (Switch to the {{forum url}} template for all forum links.)
(5 intermediate revisions by 2 users not shown)
Line 14: Line 14:
== Done ==
== Done ==
* SGPath {{Done}} (by TheTom)
* SGPath {{Done}} (by TheTom)
* SGCondition {{Done}} (by TheTom) [https://gitorious.org/fg/flightgear/commit/1b55ab5f4032c6f3f1a4d07c0b9babd3744f1c37]
* SGCondition {{Done}} (by TheTom) {{flightgear source|commit=1b55ab5f4032c6f3f1a4d07c0b9babd3744f1c37|view=commit}}


== Work in Progress ==
== Work in Progress ==
* SGPropertyChangeListener {{Pending}} (suggested by Zakalawe & TheTom) [http://forum.flightgear.org/viewtopic.php?f=71&t=24649&p=225062#p225044]
* SGPropertyChangeListener {{Pending}} (suggested by Zakalawe & TheTom) {{forum link|p=225044}}
{{FGCquote
{{FGCquote
   |This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
   |This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
Line 28: Line 28:


== Autopilot/Property Rules ==
== Autopilot/Property Rules ==
{{Note|This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain [[How the Nasal GC works|Nasal GC issues]], so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [http://forum.flightgear.org/viewtopic.php?f{{=}}71&t{{=}}23807] and [[User:TheTom#Simulation_.2F_systems|TheTom's system-modeling plans]].}}
{{See also|FGTraffic#Scripting}}
{{Note|This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain [[How the Nasal GC works|Nasal GC issues]], so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS {{forum link|t=23807}} and [[User:TheTom#Simulation_.2F_systems|TheTom's system-modeling plans]].}}


{{FGCquote|1= Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.|2= {{cite web  | url    = http://forum.flightgear.org/viewtopic.php?p=254557#p254557 | title  = <nowiki>Re: Route manager leg modes</nowiki>  | author = <nowiki>Alant</nowiki>  | date  = Aug 19th, 2015  }}}}
{{FGCquote
|1= 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.
|2= {{cite web
  | url    = {{forum url|p=268723}}
  | title  = <nowiki>Re: Military simulation (from Su-15 Screenshots)</nowiki>
  | author = <nowiki>curt</nowiki>
  | date  = Dec 16th, 2015
  | added  = Dec 16th, 2015
  | script_version = 0.23
  }}
}}
 
{{FGCquote|1= Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.|2= {{cite web  | url    = {{forum url|p=254557}} | title  = <nowiki>Re: Route manager leg modes</nowiki>  | author = <nowiki>Alant</nowiki>  | date  = Aug 19th, 2015  }}}}


{{FGCquote
{{FGCquote
Line 79: Line 93:
{{FGCquote
{{FGCquote
   | it should basically resemble the C++ 3D animation system and be invisible (enough) that it could easily be replaced with more C++ should we need more performance (or just 'cause). Exposing SGExpression to Nasal would be helpful soon but not necessary yet.
   | it should basically resemble the C++ 3D animation system and be invisible (enough) that it could easily be replaced with more C++ should we need more performance (or just 'cause). Exposing SGExpression to Nasal would be helpful soon but not necessary yet.
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216731#p216731
   |{{cite web |url={{forum url|p=216731}}
     |title=<nowiki> animations</nowiki>
     |title=<nowiki> animations</nowiki>
     |author=<nowiki>Philosopher</nowiki>
     |author=<nowiki>Philosopher</nowiki>
Line 88: Line 102:
{{FGCquote
{{FGCquote
   |Given that a very simple animation system would mainly need to deal with "events/triggers"  (i.e. timers &amp; listeners) and "actions", we might even be able to reuse some of galvedro's sophisticated failure management modules, because those already deal with both concepts via the property tree (sent a heads-up to him for some feedback).
   |Given that a very simple animation system would mainly need to deal with "events/triggers"  (i.e. timers &amp; listeners) and "actions", we might even be able to reuse some of galvedro's sophisticated failure management modules, because those already deal with both concepts via the property tree (sent a heads-up to him for some feedback).
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216744#p216744
   |{{cite web |url={{forum url|p=216744}}
     |title=<nowiki>Re: </nowiki>
     |title=<nowiki>Re: </nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 110: Line 124:
{{FGCquote
{{FGCquote
   |I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.  
   |I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.  
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=149376#p149376
   |{{cite web |url={{forum url|p=149376}}
     |title=<nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
     |title=<nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
     |author=<nowiki>Torsten</nowiki>
     |author=<nowiki>Torsten</nowiki>
Line 121: Line 135:


An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.  
An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.  
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193357#p193357
   |{{cite web |url={{forum url|p=193357}}
     |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
     |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
     |author=<nowiki>galvedro</nowiki>
     |author=<nowiki>galvedro</nowiki>
Line 130: Line 144:
{{FGCquote
{{FGCquote
   |Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38170.html just to prevent scripters from implementing APs in Nasal (due to garbage collection issues)] - so that should be a no-brainer actually, and such work should be appreciated
   |Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38170.html just to prevent scripters from implementing APs in Nasal (due to garbage collection issues)] - so that should be a no-brainer actually, and such work should be appreciated
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193359#p193359
   |{{cite web |url={{forum url|p=193359}}
     |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
     |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 141: Line 155:
There's also a very powerful route manager.
There's also a very powerful route manager.
Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space.
Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space.
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=146787#p146787
   |{{cite web |url={{forum url|p=146787}}
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 151: Line 165:
{{FGCquote
{{FGCquote
   |Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM  functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
   |Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM  functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=146562&sid=abcb74fa1c205a226f167a9c0de2c19c#p146562
   |{{cite web |url={{forum url|p=146562}}
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 159: Line 173:


{{FGCquote
{{FGCquote
   |The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually: [http://flightgear.org/forums/viewtopic.php?f{{=}}23&amp;t{{=}}12849&amp;p{{=}}134970&amp;#p134970 http://flightgear.org/forums/viewtopic. ... 0&amp;#p134970]
   |The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually: {{forum link|p=134970}}
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=146787#p146787
   |{{cite web |url={{forum url|p=146787}}
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 170: Line 184:
{{FGCquote
{{FGCquote
   |At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
   |At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=153269#p153269
   |{{cite web |url={{forum url|p=153269}}
     |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
     |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 179: Line 193:
{{FGCquote
{{FGCquote
   |You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: [[An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic]]
   |You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: [[An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic]]
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=153269#p153269
   |{{cite web |url={{forum url|p=153269}}
     |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
     |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 191: Line 205:
Thus, the problem lies in the integration part and not the lack of computing power: AI traffic is already the component that accounts for many reported performance bottlenecks and unfortunately the "solution" has often be to disable AI traffic or at least reduce traffic complexity. <br/>
Thus, the problem lies in the integration part and not the lack of computing power: AI traffic is already the component that accounts for many reported performance bottlenecks and unfortunately the "solution" has often be to disable AI traffic or at least reduce traffic complexity. <br/>
Before these issues are resolved, we are unlikely to see real FDMs being supported to simulate AI traffic, even though that would simplify many things in one go (e.g. any aircraft could be used as an AI aircraft and so AI aircraft could also benefit from other systems such as the autopilot or route manager).
Before these issues are resolved, we are unlikely to see real FDMs being supported to simulate AI traffic, even though that would simplify many things in one go (e.g. any aircraft could be used as an AI aircraft and so AI aircraft could also benefit from other systems such as the autopilot or route manager).
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=66441#p66441
   |{{cite web |url={{forum url|p=66441}}
     |title=<nowiki>Re: "Sophisticated AI aircraft" ... ?</nowiki>
     |title=<nowiki>Re: "Sophisticated AI aircraft" ... ?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 200: Line 214:
{{FGCquote
{{FGCquote
   |you would need to hack the autopilot code so that autopilot configurations can be loaded and created '''dynamically'''. At the moment, the autopilot code makes the fixed assumption that there's only a single "main aircraft", so it doesn't know about more than one aircraft.
   |you would need to hack the autopilot code so that autopilot configurations can be loaded and created '''dynamically'''. At the moment, the autopilot code makes the fixed assumption that there's only a single "main aircraft", so it doesn't know about more than one aircraft.
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=146787#p146787
   |{{cite web |url={{forum url|p=146787}}
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 209: Line 223:
{{FGCquote
{{FGCquote
   | if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
   | if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=146787#p146787
   |{{cite web |url={{forum url|p=146787}}
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |title=<nowiki>Re: Multiple intelligent flyers</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
Line 216: Line 230:
}}
}}


== props.nas ==
{{FGCquote|1= ne thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialiation) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode("/my/config/root", 1); var x = cfg.getDoubleValue("x"); var do_it = cfg.getBoolValue("do_it"); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method).|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/30723401/  | title  = <nowiki>Re: [Flightgear-devel] Nasal props API relative path support</nowiki>  | author = <nowiki>Thomas Geymayer</nowiki>  | date  = Apr 14th, 2013  }}}}
== Candidates ==
== Candidates ==
* environmental sounds [http://forum.flightgear.org/viewtopic.php?f=4&t=25157&p=262400#p262400]
* environmental sounds {{forum link|p=262400}}
* [http://api-docs.freeflightsim.org/simgear/classsimgear_1_1PropertyBasedElement.html simgear::PropertyBasedElement] ([[Canvas_Development#The_Future_of_Canvas_in_FlightGear|background/motivation]])
* [http://api-docs.freeflightsim.org/simgear/classsimgear_1_1PropertyBasedElement.html simgear::PropertyBasedElement] ([[Canvas_Development#The_Future_of_Canvas_in_FlightGear|background/motivation]])
* for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://support.hyperic.com/display/SIGAR/Home SIGAR] (Windows, MacOS & BSD/Unix) {{Not done}}
* for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://support.hyperic.com/display/SIGAR/Home SIGAR] (Windows, MacOS & BSD/Unix) {{Not done}}
* Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? [http://wiki.flightgear.org/List_of_Nasal_extension_functions#Positioned_Object_Queries][http://forum.flightgear.org/viewtopic.php?f=75&t=23041]
* Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? [http://wiki.flightgear.org/List_of_Nasal_extension_functions#Positioned_Object_Queries] {{forum link|t=23041}}
* FGProtocol, to implement I/O protocols via Nasal (and help solve {{issue|396}} and support AJAX, REST, JSON or WebSockets) {{Progressbar|30}} [http://forum.flightgear.org/viewtopic.php?f=30&t=21346&p=194458&hilit=fginterface#p194456] [http://forum.flightgear.org/viewtopic.php?f=18&t=21561&p=196141#p196141] [http://forum.flightgear.org/viewtopic.php?f=18&t=22630&p=205664#p205430] (stubs available at [https://gitorious.org/fg/hoorays-flightgear/commits/topics/cppbind-fgprotocol])
* FGProtocol, to implement I/O protocols via Nasal (and help solve {{issue|396}} and support AJAX, REST, JSON or WebSockets) {{Progressbar|30}} {{forum link|p=194456|hilit=fginterface}} {{forum link|p=196141}} {{forum link|p=205430}} (stubs available at {{gitorious source|proj=fg|repo=hoorays-flightgear|branch=topics/cppbind-fgprotocol|view=shortlog}}).
* the loglist/SG_LOG() logging buffer machinery [http://forum.flightgear.org/viewtopic.php?f=30&t=24876][http://forum.flightgear.org/viewtopic.php?f=17&t=21480&p=195517#p195517]
* the loglist/SG_LOG() logging buffer machinery {{forum link|t=24876}} {{forum link|p=195517}}
* expose [https://gitorious.org/fg/flightgear/source/b80b010ef146b3d5914ea8e608eeb53aef28798e:src/Sound/VoiceSynthesizer.cxx#L51 VoiceSynthesizer]/FLITE TTS[https://gitorious.org/fg/flightgear/commit/b80b010ef146b3d5914ea8e608eeb53aef28798e] to Nasal to get rid of ATC chatter [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/F10078E6-0D1B-458E-9DAB-2E54D877EA6E%40mac.com/#msg32314788] {{Not done}}  
* expose {{flightgear source|commit=b80b010ef146b3d5914ea8e608eeb53aef28798e|path=src/Sound/VoiceSynthesizer.cxx|line=51|text=VoiceSynthesizer}}/FLITE TTS[{{flightgear source|commit=b80b010ef146b3d5914ea8e608eeb53aef28798e|view=commit|full=1}}] to Nasal to get rid of ATC chatter [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/F10078E6-0D1B-458E-9DAB-2E54D877EA6E%40mac.com/#msg32314788] {{Not done}}  
* the SGSubsystem interface to register scripted SGSubsystems
* the SGSubsystem interface to register scripted SGSubsystems
* flight path history [http://forum.flightgear.org/viewtopic.php?f=71&t=21139&p=196295#p196295] {{Done}} (by TheTom)
* flight path history {{forum link|p=196295}} {{Done}} (by TheTom)
* the flight recorder system (replay buffers) {{Not done}}
* the flight recorder system (replay buffers) {{Not done}}
* [[State machines]] e.g. to help clean up the ND code [https://gitorious.org/fg/fgdata/commit/f8c56dcc52ffd3d6dfca1d39dc4a72b6b3478368]
* [[State machines]] e.g. to help clean up the ND code [{{gitorious source|proj=fg|repo=fgdata|commit=f8c56dcc52ffd3d6dfca1d39dc4a72b6b3478368|view=commit|full=1}}]
* exposing the sound manager, so that scripts can directly play audio files [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18550.html]
* exposing the sound manager, so that scripts can directly play audio files [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18550.html]
* exposing the random buildings system [http://forum.flightgear.org/viewtopic.php?f=30&t=24966][http://forum.flightgear.org/viewtopic.php?f=5&t=21131&p=192489&hilit=cppbind#p192489] {{Pending}} [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/11741AA1-DC4C-4F27-BF8C-6F8629F6CAB0%40web.de/#msg32326144] [http://sourceforge.net/p/flightgear/mailman/message/33054935/]
* exposing the random buildings system {{forum link|t=24966}} {{forum link|p=192489|hilit=cppbind}} {{Pending}} [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/11741AA1-DC4C-4F27-BF8C-6F8629F6CAB0%40web.de/#msg32326144] [http://sourceforge.net/p/flightgear/mailman/message/33054935/]
* There's also a pending feature request ({{Issue|619}}) to implement USB-HID support [http://forum.flightgear.org/viewtopic.php?f=24&t=20159&p=185021&hilit=cppbind#p185021].  
* There's also a pending feature request ({{Issue|619}}) to implement USB-HID support {{forum link|p=185021|hilit=cppbind}}.
* ESRI shapelib? [http://forum.flightgear.org/viewtopic.php?f=19&p=209432#p209432]
* ESRI shapelib? {{forum link|p=209432}}
{{FGCquote
{{FGCquote
   |When we have vector road data at runtime, we can do the following:
   |When we have vector road data at runtime, we can do the following:
Line 253: Line 269:
[[Canvas_GUI#PUI_Widgets]]<br/>
[[Canvas_GUI#PUI_Widgets]]<br/>
<ul>
<ul>
<li> [http://gitorious.org/fg/flightgear/commit/6bf47cd248ed388e6a4dd3ffa2d00977b00b62fb POI support]</li>
<li> {{flightgear source|commit=6bf47cd248ed388e6a4dd3ffa2d00977b00b62fb|view=commit|text=POI support}}</li>
<li> [http://gitorious.org/fg/flightgear/commit/658bda6e40da65c317fd387ed1a2fcf628e7ed1b countries &amp; towns]</li>
<li> {{flightgear source|commit=658bda6e40da65c317fd387ed1a2fcf628e7ed1b|view=commit|text=countries &amp; towns}}</li>
<li> [http://gitorious.org/fg/flightgear/commit/38a373ba845d2bbea920cbcff90be5dc33040fe5 AI traffic routing/flight plans]</li>
<li> {{flightgear source|commit=38a373ba845d2bbea920cbcff90be5dc33040fe5|view=commit|text=AI traffic routing/flight plans}}</li>
</ul>
</ul>


   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213293#p213293
   |{{cite web |url={{forum url|p=213293}}
     |title=<nowiki>Phasing out MapWidget post 3.2</nowiki>
     |title=<nowiki>Phasing out MapWidget post 3.2</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>

Revision as of 10:53, 8 June 2019

FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to development on Tom's Canvas system, there's now a new bindings framework to be found in $SG_SRC/simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features by operating through classes and methods with full STL support, abstracting most common operations away.


After working through the Nasal/CppBind article, some of the more useful things to play with in the beginning, would be exposing additional SG/FG classes to Nasal space, such as for example:

Done

Work in Progress

  • SGPropertyChangeListener Pending Pending (suggested by Zakalawe & TheTom) [1] This is a link to the FlightGear forum.
Cquote1.png This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
— Thomas Geymayer (2014-11-22). [Flightgear-devel] RFC: Nasal ghosts and garbage collection.
(powered by Instant-Cquotes)
Cquote2.png

Autopilot/Property Rules

Note  This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain Nasal GC issues, so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [2] This is a link to the FlightGear forum. and TheTom's system-modeling plans.
Cquote1.png 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)
Cquote2.png
Cquote1.png Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.
— Alant (Aug 19th, 2015). Re: Route manager leg modes.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I would prefer to do this in an XML filter in the generic autopilot helpers - definitely not in Nasal. It can be done in C++ if strictly required but then we need way to disable it for people who want different filtering.
— James Turner (2015-04-03). Re: [Flightgear-devel] Route manager: waypoint smoothing.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I vote for #3: avoid *any* Nasal in the fast simulation [FDM] loop. Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want.
Cquote2.png
Cquote1.png Concerning your original issue on implementing an autopilot: a much better way to do it is to avoid Nasal for the actual autopilot controller elements (numeric computation). Instead, use XML "autopilot" rules for the filter, gain, damper, integrator elements: http://wiki.flightgear.org/Autopilot_Configuration_Reference

You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS).


Cquote2.png
Cquote1.png This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward.
Cquote2.png
Cquote1.png I agree with your main point that xml-configured hard-coded filters are the right way to implement and autopilot, and I also agree that in general low-level multi-purpose workhorse code should be C++ whereas Nasal is more suitable for the numerically cheap high-level specific functions.
— Renk Thorsten (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png it should basically resemble the C++ 3D animation system and be invisible (enough) that it could easily be replaced with more C++ should we need more performance (or just 'cause). Exposing SGExpression to Nasal would be helpful soon but not necessary yet.
— Philosopher (Sat Aug 16).  animations.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Given that a very simple animation system would mainly need to deal with "events/triggers" (i.e. timers & listeners) and "actions", we might even be able to reuse some of galvedro's sophisticated failure management modules, because those already deal with both concepts via the property tree (sent a heads-up to him for some feedback).
— Hooray (Sat Aug 16). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I'd strongly agree with Thorsten here. It's nothing against Nasal from me - I've not even used it - but creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry as Thorsten mentions as exemplified by Mathwork's $imulink product.

Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again, is the way that JSBSim has approached the solution. Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one materialize. The downside is that XML can be verbose, but it's a price I've come to accept.


— Jon S. Berndt (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
— Torsten (Thu Feb 02). Re: 2 Questions: vacuum & electrical.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D

An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.


— galvedro (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated
Cquote2.png
Cquote1.png there's an extremely powerful and flexible autopilot system in FG that is entirely XML configurable: Autopilot

There's also a very powerful route manager. Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space.


— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
— Hooray (Tue Jan 03). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually: [3] This is a link to the FlightGear forum.
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic
— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png When you then take into account that you will probably not need to run the AI traffic FDM at a rate of 120 hz (the FlightGear default), but much more likely at 1-5 hz (at most), you should be able to multiplex at least 20-30 different aircraft onto one dedicated FDM thread (or process).


Thus, the problem lies in the integration part and not the lack of computing power: AI traffic is already the component that accounts for many reported performance bottlenecks and unfortunately the "solution" has often be to disable AI traffic or at least reduce traffic complexity.
Before these issues are resolved, we are unlikely to see real FDMs being supported to simulate AI traffic, even though that would simplify many things in one go (e.g. any aircraft could be used as an AI aircraft and so AI aircraft could also benefit from other systems such as the autopilot or route manager).


— Hooray (Wed Feb 24). Re: "Sophisticated AI aircraft" ... ?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png you would need to hack the autopilot code so that autopilot configurations can be loaded and created dynamically. At the moment, the autopilot code makes the fixed assumption that there's only a single "main aircraft", so it doesn't know about more than one aircraft.
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png

props.nas

Cquote1.png ne thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialiation) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode("/my/config/root", 1); var x = cfg.getDoubleValue("x"); var do_it = cfg.getBoolValue("do_it"); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method).
— Thomas Geymayer (Apr 14th, 2013). Re: [Flightgear-devel] Nasal props API relative path support.
(powered by Instant-Cquotes)
Cquote2.png

Candidates

Cquote1.png When we have vector road data at runtime, we can do the following:
  • render it in moving-map displays - either real ones (Garmin G1000 / G430) or the map dialog
  • use it to drive building outline creation as Thomas was suggesting
  • animate traffic on the roads, as point lights at night or even meshes in daytime
    (the important one...)
  • generate tile overlay textures dynamically (and based on view distance) to show the roads on the terrain surface. (And the detail of this texture can include road markings / borders based on distance from the viewer / view angle / etc)

— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND

Canvas_GUI#PUI_Widgets


— Hooray (Tue Jun 24). Phasing out MapWidget post 3.2.
(powered by Instant-Cquotes)
Cquote2.png
Note  Before working on anything related, please do get in touch with other contributors to ensure that this list is still up-to-date.

For more technical Nasal questions (C API, internals etc), you'll probably want to refer to Philosopher, TheTom, Zakalawe or Hooray on the forum - TheTom and Zakalawe can also provide help on using cppbind, having both used it extensively during the last months.