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.