Nasal HLA standalone: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 8: Line 8:
One of the things that is most frustrating and time consuming when working with Nasal scripts is the brute force and manual nature of testing the scripts. A simple misspelling in a custom script can take 5-10, or more, minutes to fix from the point of finding it (shut down FG, change script, startup FG and get back to a point in the sim where the code will execute). Obviously Nasal is tightly coupled to FG at this point and most scripts won't run without access to the property tree. That doesn't mean that it can't be done though.
One of the things that is most frustrating and time consuming when working with Nasal scripts is the brute force and manual nature of testing the scripts. A simple misspelling in a custom script can take 5-10, or more, minutes to fix from the point of finding it (shut down FG, change script, startup FG and get back to a point in the sim where the code will execute). Obviously Nasal is tightly coupled to FG at this point and most scripts won't run without access to the property tree. That doesn't mean that it can't be done though.


This article will serve as the guinea pig for writing [[Developing with HLA]], using [[FlightGear HLA support (High Level Architecture)]].
{{cquote|Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts 
basically interact with the sim via properties (which they already do) and that any system functions they call are thread safe - not very 
hard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html|title=<nowiki>[Flightgear-devel] multi-threading / CPU usage</nowiki>|author=James Turner|date=Fri, 03 Oct 2008 06:52:12 -0700}}</ref>|James Turner}}


This article will serve as the guinea pig for writing [[Developing with HLA]], using [[FlightGear HLA support (High Level Architecture)]].


== Status 06/2013 ==
== Status 06/2013 ==
Line 55: Line 59:


Obviously, one would need to expose other FG/Nasal APIs eventually, but we should probably learn to walk before we run
Obviously, one would need to expose other FG/Nasal APIs eventually, but we should probably learn to walk before we run
{{cquote|Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts 
basically interact with the sim via properties (which they already do) and that any system functions they call are thread safe - not very 
hard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html|title=<nowiki>[Flightgear-devel] multi-threading / CPU usage</nowiki>|author=James Turner|date=Fri, 03 Oct 2008 06:52:12 -0700}}</ref>|James Turner}}


At the time of writing, The SimGear repository already contains all required HLA primitives to map the property tree and other C++ classes to HLA. For example, see:
At the time of writing, The SimGear repository already contains all required HLA primitives to map the property tree and other C++ classes to HLA. For example, see:

Navigation menu