Board index FlightGear Development Nasal

Spoken ATC

Nasal is the scripting language of FlightGear.

Re: Spoken ATC

Postby Hooray » Sat Jul 22, 2017 12:23 pm

Regarding the state machine logic (nested conditionals), I kinda agree with Torsten's comments on the devel list that this would be better handled in a more flexible fashion - unfortunately, SimGear's state machine framework isn't currently exposed to Nasal space at all.

However, you could look at Stuart's tutorial/checklist system to see how it is using so called SGConditions, this is a SimGear-level conditionals framework that implements support for expressing complex conditional statements on top of the property tree - in other words, this means that your code would automatically support being XML-configurable (akin to checklists and tutorials): http://wiki.flightgear.org/Conditions

For starters, I suggest to take a look at props.nas and the conditions handling APIs available there.

You may find that this looks a bit weird at first, but it would greatly help simplify your underlying Nasal code and move all of the expression logic into XML/property tree space, so that even non-coders could help grow/maintain your ATC logic.

To really understand the potential of the system, I suggest to start by looking at $FG_ROOT/Docs/README.conditions: https://sourceforge.net/p/flightgear/fg ... conditions

Next, take a look at props.nas and the code beginning at compileCondition(): http://wiki.flightgear.org/Nasal_librar ... tion.28.29

like I said, there are various examples on using this to be found in $FG_ROOT/Nasal

Speaking in general, it would be good if core developers could explore exposing SGExpressions, SGStateMachine and property rules to Nasal space, so that we can get away with using much less Nasal for these things - which would also help us make things more deterministic.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby rleibner » Sat Jul 22, 2017 4:16 pm

Hooray wrote in Sat Jul 22, 2017 12:23 pm:You may find that this looks a bit weird at first . ..

Yes, you can be sure of that! :shock:
It is very different from everything I am used to, and I still do not fully understand its potential.

But I understand that I am still new in this world and I trust in your experience, so I will focus on the study of the approach that you and Torsten suggest.

On the other hand, I understand that I should rely more on the property tree, but I still do not know which properties are plane-specific and which are general ones.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Spoken ATC

Postby Hooray » Sat Jul 22, 2017 4:33 pm

Actually, my suggestion would be to use whatever works best for you - also, I don't think Torsten actually suggested this.
In general however, there is a tendency among core developers to look at such Nasal based contributions and "dissect" them in the sense that they'd like to see them re-implemented on top of "more native" APIs/technologies, as in encouraging people to use less Nasal code, to do things in a more deterministic way.

The issue/challenge however is that while many of these systems do indeed use better/faster implementations (being written in C/C++), they are often not exposed to scripting space at all, which means that they are not accessible/available in Nasal scripts, this applies specifically to useful features such as:

  • autopilot/property rules
  • state machines
  • simgear expressions


However, looking at some of the more/most complex Nasal scripts, many of these tend to re-invent the wheel unfortunately, because sooner or later they develop a need to encode state machine-like semantics in the form of Nasal patterns - unfortunately, these don't scale at all, and they're often complicating matters for people want to see less Nasal code used.

In particular, this applies to complex Canvas-based MFDs - soooner or later, even displays like the ND end up using fairly low-level concepts like various forms of nested timers and listeners, that unfortunately add tons of Nasal callbacks to the main loop, so that this is conflicting with efforts and people wanting to see less Nasal used.

This is unnecessarily tainting Nasal's reputation however - Nasal is great for protoyping such features, but it is usually not a good idea to add too much code, or code that needs to be called very often (think at frame/fdm rate).

To be fair, this is not specific to Nasal at all - Torsten and others also raised the issue when they talked about supporting Python:

https://sourceforge.net/p/flightgear/ma ... /34793778/
Torsten Dreyer wrote:Advanced Weather
springs to my mind here. The prototyping phase has never ended up to now.
Why would you think that would change with Python?

Honestly, that Python integration is exactly the opposite way of what I
would like the fg core to develop. Instead of adding just-another-feature
we need to strip it down to getting a fast and constand fps rendering
engine. Everything else needs to run outside the main loop and has to
interact with the core by, say HLA/RTI or whatever IPC we have.


As you can see, we have a number of examples developed in Nasal that were never "ported" to native code.

The real dilemma however is that excellent alternatives are available in SimGear/FlightGear, but that these are not made available to fgdata developers, so that some approaches tend to use inefficient coding patterns - when it comes to Nasal/Canvas avionics, we are still seeing tons of MFDs animated through nested chains of timers and listeners that end up invoking callbacks to "animate" possibly dozens of groups/element on an individual basis, often with dozens (if not even hundreds) of context switches between Nasal and C++.

Thus, when I suggested to look at "property conditions", I was also merely suggesting a workaround - because Stuart used this successfully in his tutorial/checklists scripts (and possibly also in the joystick configuration UI).

It would obviously be much better if we had access to the SimGear APIs mentioned above - however, James once summed up the dilemma pretty nicely when he said this:

https://sourceforge.net/p/flightgear/ma ... /35627739/
James Turner wrote:I would much rather people add C++ / core features when needed, rather than doing things badly / inefficiently in Nasal. But that puts the onus on me to write the C++ code for them!
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby Thorsten » Sun Jul 23, 2017 6:43 am

The issue/challenge however is that while many of these systems do indeed use better/faster implementations (being written in C/C++), they are often not exposed to scripting space at all, which means that they are not accessible/available in Nasal scripts


There's this terrific interface called 'property tree'.

Of course it is possible to utilize the autopilot system in a Nasal script - the script can set input properties or fetch output properties.

The whole Shuttle AP is done in that way - Nasal scripts make the high-level decisionmaking, mission phase management and compute orbital targeting stuff such as engine cutoff condition, JSBSim functions take the guidance targets provided and fly the vehicle, Nasal scripts pick up outputs in the next iteration and include them into the decisionmaking.

You can equally well use property rules (including the state machine) or autopilot tags for the job.

The key is to understand what tool to use best for what.

Advanced Weather springs to my mind here. The prototyping phase has never ended up to now.


Not sure who came up with the idea, but the prototyping phase ended long ago and there were never any plans to port this to C++, it was from the beginning to now envisioned as a Nasal system (with a division of labour as for the Shuttle AP - Nasal does the high-level planning and calls C++ functions to do the actual performance-critical work).

However, looking at some of the more/most complex Nasal scripts, many of these tend to re-invent the wheel unfortunately


Given that the canvas API was specifically intended to give users standardized code to work with and given that by re-inventing the wheel and not using the standard API I could speed up my displays by a factor 3, I suspect re-inventing wheels may not unconditionally be a bad thing (TM).

If Nasal coders were generally performance aware and C++ coders were poor algorithm designers, the reputations were probably reversed. The truth is that bad code is slow, but also that beginner coders can't handle C++, which is why on average the algorithms on the C++ side are better (in addition to a native performance advantage).

If you know your problem well and know where your tools burn performance, you can write fast code. If you know one of them, you can write decent code, if you know none and are just fooling around, the end result will be slow.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Spoken ATC

Postby Hooray » Sun Jul 23, 2017 8:13 am

Thorsten wrote:There's this terrific interface called 'property tree'.

Of course it is possible to utilize the autopilot system in a Nasal script - the script can set input properties or fetch output properties.


You misunderstood, the point was that it is not possible to dynamically instantiate and reconfigure the corresponding C++ systems from Nasal space - no matter if that means state machines, expressions or property rules/autopilots - obviously, you can "use" pre-created systems, but you cannot create them on demand, and reconfigure them.

From a use-case standpoint, imagine that you are coding a Canvas MFD and that you'd like to move the update() semantics of certain elements to property rules - however, you don't know really know how many symbols/elements are displayed on the display (think AI traffic nodes) - equally, the autopilot, state machine or expressions systems cannot be dynamically instantiated to help control AI entities (think tanker.nas, fox2.nas, bombable etc).

So this is not a matter of having/using the property tree - for that to be the "solution", it would have to work akin to the Canvas system, i.e. on top of listeners to dynamically instantiate what you need, "on demand"

Honestly, even if you don't believe me, take it from the horse's mouth, and look what Torsten, James and others have previously said - if we want people to stop writing and using tons of custom Nasal code for these purposes, we also need to provide a way to dynamically set up these systems from scratch, just like Torsten suggested once:

Subject: 2 Questions: vacuum & electrical

Torsten wrote:I think, performance of Nasal code and XML based property rules is pretty close. The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose - as you correctly stated.

My personal guideline for using one or the other system is:
  • Computing properties from a well defined set of other properties once per frame: use a property rule.
  • If there is no other way to get it done: use Nasal.

Torsten wrote in Thu Feb 02, 2012 10:08 pm:especially if these configurations could be instantiated at run time

Great minds think alike. I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";

etc, etc.



As long as this functionality is not provided to Nasal space, James is entirely correct: it is kinda moot to encourage people to use the hard-coded/faster systems, because that puts the onus on core developers to expose/provide the corresponding alternatives.

In layman's terms, the question is not whether you can access another/better system using the property tree as the IPC mechanism, but whether you can dynamically instantiate (create) and configure/reconfigure it for an unknown number of entities that are to be controlled - which is actually in line with one of your own recent postings:

https://sourceforge.net/p/flightgear/ma ... /35927242/
Thorsten wrote:Personally I'd rather see FG re-structured to support more than one JSBSim
FDM - but I'm not expecting everyone to jump in to support this either.
Let's agree we can all have different perspectives on what FG needs
urgently next.


To sum it up, this is about getting rid of the "singleton fallacy", or getting rid of the assumption that the number of systems we need is always fixed and must be known at design time. As long as this isn't recognized and address, our fgdata/fgaddon contributors will obviously use whatever works best for them (usually/often Nasal code) and settle for less than perfect solutions due to an accessibility issue, just like you said previously.

Thus, this is not a Nasal issue as such, because it involves other C++ systems primarily - such as the FDMShell or the route manager (which also cannot be instantiated dynamically)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby Thorsten » Sun Jul 23, 2017 9:35 am

You misunderstood, the point was that it is not possible to dynamically instantiate and reconfigure the corresponding C++ systems from Nasal space


And here I was thinking your comments had anything to do with the topic of the thread (which, after all, is one system providing ATC on demand for the user).

From a use-case standpoint, imagine that you are coding a Canvas MFD and that you'd like to move the update() semantics of certain elements to property rules - however, you don't know really know how many symbols/elements are displayed on the display (think AI traffic nodes)


But I wouldn't want to do the update() semantics to property rules because it'd be a waste of perfectly good framerate - property rules run every frame, whereas position updates happen every radar sweep, so most of the time the code would burn performance doing precisely nothing.

That's what I mean by understanding the tools.

To sum it up, this is about getting rid of the "singleton fallacy"


I'm sure you see how this relates to the topic of the thread, but I really do not. Whether you can instance multiple state machines or not doesn't change Rodolfo's problem a bit.

You know, sometimes generalizing problems to n-instances just isn't necessary. Remember your suggestions to procedurally generate and instance the Shuttle keypad dialog? We only ever need one of those, and there's just three physical keypads in the cockpit - it's a problem were we clearly do not need any ability to instance an arbitrary number.

So let's not over-engineer problems - for the ATC the state machine tags can be used fine if so desired.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Spoken ATC

Postby Hooray » Sun Jul 23, 2017 10:36 am

And here I was thinking your comments had anything to do with the topic of the thread (which, after all, is one system providing ATC on demand for the user).


Thorsten, please let's not go there (again...) it really does - and I said so previously, in reference to Torsten's comments on the devel list about the way the "state machine" handling is currently implemented:


https://sourceforge.net/p/flightgear/ma ... /35912788/
Torsten wrote:Instead of having hard-coded, I'd prefer to have some kind of state-machine
to determine the state of the ATC/aircraft interaction based on a/c course
and position, comm/nav setup, environment etc. The exact spoken words
should be dedicated to a separate layer.


Subsequently, I suggested to look at SGConditions to implement this using the props.nas helpers - pointing out that the "proper" way of doing this would not be available, because the SimGear state machiner handlers (totally unrelated to the AP) are not available in scripting space. And that this would also apply to property rules/autopilots which also cannot be dynamically instantiated/reconfigured on demand, which is why SGConditions may be the best workaround for the time, posting quotes from Torsten and James to support this view.

Thorsten wrote:I'm sure you see how this relates to the topic of the thread, but I really do not. Whether you can instance multiple state machines or not doesn't change Rodolfo's problem a bit.


I see that you don't understand what this is about - I suggest to read Torsten's original comment, and then see for yourself if I am hijacking this thread, or if I am really just supporting Torsten's view that the state machine handling could/should be improved on, pointing to a feasible compromise, while mentioning that we also have other subsystems that tend to get re-implemented in scripting space, because the corresponding FG/SG-level APIs are n/a in scripting space when it comes to dynamically instantiating and reconfiguring the corresponding APIs/systems.

Thus, my responses are very much on top, even though I can see that you cannot see that currently (I could tell so by your first knee-jerk response ...)

Thorsten wrote:You know, sometimes generalizing problems to n-instances just isn't necessary. Remember your suggestions to procedurally generate and instance the Shuttle keypad dialog? We only ever need one of those, and there's just three physical keypads in the cockpit - it's a problem were we clearly do not need any ability to instance an arbitrary number.


I do, and I totally understand your way of thinking, but I sugested to do so for a reason - not because I wanted to over-engineer things, but because I saw the opportunity to integrate this properly with /some/ kind of MFD framework, where you'd encode buttons/switches/knobs semantically and could procedurally create callback maps to unify the handling of both, the UI use-case, but also the MFD/in-cockpit use-case.

And the need is still there - just look at how many (few) MFDs we really have, and what you ended up doing to make that work - i.e. you will literally have to maintain separate files to keep everything in sync, whereas the procedurally created dialog (which I prototyped/posted) would be driven by code - aka "DRY principle".

I do realize that you don't agree with this, and I am not trying to convince you either (we've both been there far too many times), but I do think that you belong to the camp of people who should actually see the potential of procedurally created "data", "data structures" and resources - because you tend to make a case FOR it, whenever it comes to procedural texturing or procedurally created Canvas path elements - in fact, you once suggested to unify your shuttle drawing helpers/code to provide some kind of foundation for procedurally created avionics IIRC.

Thorsten wrote:So let's not over-engineer problems - for the ATC the state machine tags can be used fine if so desired.


Really, and here was I thinking that you were beginning to grasp the real issue: generalizing state machine handling to cater to the "n-instances" use-case, to move stuff out of Nasal space ;-)

To use an analogy: Imagine you needed to display a table in a GUI dialog - however, your data may have a varying number of rows/columns - so that you may need to create the table procedurally (think pilot list, think performance monitor etc) - or rather, imagine a plotting helper with a varying number of axes/graphs to be shown.

Regardless of the property tree and its functionality (just believe me, I am indeed a little familiar with it ...), this doesn't change the fact that a hard-coded GUI dialog will not be able to deal with these requirements - this is why legacy PUI dialogs tend to use embedded Nasal code to procedurally re-build/update the dialog tree on demand, or why some more dynamic GUI dialogs don't even have an underlying xml file, but are completely built in scripting space (think pilot list, performance monitor)

Equally, whenever we need custom GUI widgets, we cannot augment/extend or re-implement those using the PUI engine, that only works at the Canvas level.

Stuart was facing the same challenge when he implemented the tutorial/checklist features, and he ended up using SGConditions to work around these shortcomings, for a reason.


Thorsten wrote:Given that the canvas API was specifically intended to give users standardized code to work with and given that by re-inventing the wheel and not using the standard API I could speed up my displays by a factor 3, I suspect re-inventing wheels may not unconditionally be a bad thing (TM).


That's a red herring actually - I never said that anywhere, I realize what you have done, and if you are being fair, you may also remember that I posted the findings that you made explore going down that path (props.nas being the back-end for many Canvas updates); just like you once posted evidence suggesting that setprop was faster than props.nas.


The point is, Nasal/Canvas API are encapsulated - even if something proves to be too slow, there is only a single place that needs to be updated, for all "users" to benefit automatically.

Nasal/Canvas were not designed with the use-cases in mind that they're currently being used for, especially by power-contributors like those coming up with features like Advanced Weather, or the shuttle avionics - there really isn't anything optimized at all.

Anyway, as you have been saying, the main bottlenecks are property I/O, and as I stated previously - this is primarily because many things go through props.nas

If/when props.nas gets re-implemented in C++ space,, and if we begin to encode update semantics directly, we can do away with much less Nasal code running, doing much less property I/O (smarter I/O), while making it much faster in the process - as in have our cake and eat it.

All this may seem hugely offtopic to you, but it's rather on-topic actually, and it's a long-standing problem and pattern, too - just look at our tendendy to discourage people from implementing control algorithms (or other complex systems) in scripting space, or the tendency among core developers to encourage contributors to port Nasal systems to favor the use of property rules (or other native code) - just look at the wingflex module, and the discussion that took place on the devel list.

This makes none of your points invalid, but you are also not exactly the average contributor around here - and most people are unlikely to be aware of the intricacies involved here, so that they may be in for a huge surprise when/if some of their contributions make it to the devel list - because there, it's really been one consistent opinion that is being made: move away from huge/complex systems implemented in scripting space, and favor the use of native APIs whenever possible - just like Torsten, James and Mathias have been saying for years meanwhile.

Given the state of affairs when it comes to Nasal's lack of access to the corresponding FG/SG APIs and subsystems, changing spoken ATC to use SGConditions is the easiest way to have our cake and eat it, unless someone shows up who is willing to expose the corresponding FG/SG APIs to Nasal space.

Please don't get me wrong, I fully realize what you were trying to do here, and why you were doing that - and I do sincerely appreciate having a balanced discussion, as in not seeing topics hijacked - but this is not one of those cases, it also isn't one of those cases where you cannot see the big picture because you're lacking the corresponding background - as a matter of fact, you are actually familiar with the benefits of supporting "n-instances" and the advantages of procedurally creating/updating "n-instances" of a resource/data structure or system.

So, sorry - if this topic has become too technical meanwhile, it is in fact because we disagreed on what this is all about - which really wasn't necessary, had you looked up Torsten's original comments regarding state machine handling, you would have noticed that my comments were spot-on.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby Thorsten » Sun Jul 23, 2017 10:48 am

Sorry, I don't think you're helping the OP here at all.

It's one of these instances where we can all agree what'd be ideal, and then we wait for HLA &Co. to appear.

Or we can realize that we're dealing with a completely performance un-critical system, do the non-ideal thing and re-invent a couple of wheels, give someone a few Nasal pointers and have it ready for the next release.

I see that you don't understand what this is about


I understood the OP is trying to code an ATC interaction and not improving the FG general architecture. But maybe I got that wrong.

because you tend to make a case FOR it, whenever it comes to procedural texturing or procedurally created Canvas path elements


You can call me a pragmatist. I'm for things based on a pain/gain ratio given the manpower and constraints we have, not based on any coding dogma of what /should/ be ideal.

I much prefer a working ugly AW over a theoretically ideal HLA effort.

The point is, Nasal/Canvas API are encapsulated - even if something proves to be too slow, there is only a single place that needs to be updated, for all "users" to benefit automatically.


Nope, because what's faster for one particular use case isn't necessarily faster for a different use case. It's again down to knowing your problem and selecting the suitable tool - but it's a fallacy to believe there is one ideal tool for everything.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Spoken ATC

Postby Hooray » Sun Jul 23, 2017 10:52 am

Never mind, I am beginning to see how much less time consuming it would be to actually talk to people in person, make a phone call or even conduct google hangouts....

And by the way: have a nice weekend :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby Torsten » Sun Jul 23, 2017 6:58 pm

...or meet in person at FSWeekend :-)

back on topic: the new addon "API" lets you add a config.xml to override the settings in defaults.xml.
That easily allows to
  • Override key bindings (as in the spoken atc addon)
  • Add or override autopilots and property rules
  • And of course introduce XML-statemachines
Unless your really want to add/change/remove those at runtime, this should cater for most use cases.
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Spoken ATC

Postby Hooray » Sun Jul 23, 2017 7:13 pm

like you originally said once, the real problem arises when the number, or nature, of required instances is dynamic, i.e. not known to be fixed beforehand.

Anyway, one of the more common use-cases will involve adding custom entries to the menubar, and loading custom XML dialogs.
Ideally, those would be integrated with the localization infrastructure that is currently being revamped.

I realize that bugman already mentioned the bombable addon, and not wanting to open yet another can of worms - but even if nobody around here is interested in doing the corresponding work, there is quite a bit to be learnt from looking at some of our more established "addons", to determine how the addon.nas file/framework may evolve over time.

Like you, and Thorsten, said on the devel list, there is a very real chance that addons may impact the way FlightGear fgdata development happens in the future - I think you used the word "mess" to express some of your concerns - to avoid that, it would really make sense that we look at potential candidates to be turned into addons and identify overlapping requirements and functionality - pretty much along the lines of ThorstenB's original Nasal submodules work.

Speaking in general, it may be worthwhile to consider adding $FG_HOME/Addons as a user-specific location for addons, and supporting $FG_ROOT/Addons for addons that can be shipped by default with each new release - that would at least help address some of the concerns expressed on the devel list, i.e. about features not making it back into the project.

My personal view is that such addons should be required to be GPL and that for any of them to be committed, they should be compatible with other committed addons, to ensure that we don't end up introducing tons of mutually-exclusive addons with nice features.

There are some comparatively simple Nasal files that are currently loaded unconditionally - turning stuff like glide_slope_tunnel.nas into an actual addon would also help unclutter the Nasal namespace for people wanting a "lean" environment, without unnecessary Nasal stuff running.

We could also change addon.nas to honor an addon-specific userarchive attribute to easily allow addons to be loaded/unloaded (disabled) automatically, making the setting persistent.

Anyway, regardless of how this will evolve, the one thing that is really needed is adding support for querying /sim/version to determine if the addon is compatible with the flightgear version, as well as having an addon.nas specific version number, to communicate the version of the addon API.

Everything else can be added at a later time, i.e. evolve organically - but versioning is a key requirement to make sure that people don't literally yell at us once we do improve the addon framework.

Funniliy enough, this is overlapping with Richard's recent posting, who summed up things pretty nicely: https://sourceforge.net/p/flightgear/ma ... /35960289/
And we actually do have working Nasal/Canvas code to implement this kind of functionality: http://wiki.flightgear.org/FlightGear_Version_Check

Image

In other words, getting back on topic regarding SGCondition/props.nas, that may be the easiest thing to use to support versioning queries.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby rleibner » Mon Jul 24, 2017 4:29 pm

Hi guys,
I read with interest the arguments of both sides. I will not comment on the background point, I'm not qualified for it.
But let me state some facts about this specific addon
  1. Since there are not listeners involved, it doesn't burn performance except when the user calls the speak() function.
  2. All the process takes typically 2 or 3 msec (benched in my PC).

Alternatives are either to keep the nested if/elsif scheme (cumbersome yes but quite readable) or to move all logic to conditions into the properties tree and use a statemachine approach.
Doing the latter, what can we expect?
    Less number of lines and more elegance in the code (although less readable).
    And saving ... what? 1 or 1.5 msec?
I wonder if it's worth it. I repeat, I'm speaking exclusively of SpokenATC.
Now, if the weight argument here is to preserve a uniform style in the FGFS addons, I can understand it.

(At this point, is this forum the best place to discuss this or do we move to the fg-devel list?)

Regards
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Spoken ATC

Postby Hooray » Mon Jul 24, 2017 4:34 pm

Thorsten is right, it's a pain/gain thing - and Torsten is right about the structure of the code.
What is generally considered "best practice" will mainly depend on whether you keep this discussion on the forum or if you move it to the devel list :D
Speaking in general, it's become an optional add-on, so it really is your decision - compared to core/fgdata additions, there should not be much of a rigorous review process involved when it comes to such addons.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Spoken ATC

Postby rleibner » Mon Jul 24, 2017 6:09 pm

Well ... :roll:
For now I will continue to improve the script as it is, according to the bug reports I receive.
In the meantime, I'll work on a state machine model. Once I have it, we will compare advantages/disadvantages and take a final decision on the devel list.
Solomonic :lol:
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Spoken ATC

Postby Hooray » Mon Jul 24, 2017 6:35 pm

For your info, there should be an existing Nasal-based state machine model developed by galvedro, you may want to run a forum/wiki search - I think he developed this once as part of the failure management framework:

http://wiki.flightgear.org/Failure_Manager
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Nasal

Who is online

Users browsing this forum: No registered users and 0 guests