rleibner wrote: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 <u>exclusively of SpokenATC</u>.
Now, if the weight argument here is to preserve a uniform style in the FGFS addons, I can understand it.<ref>{{cite web
Referring to your other comments, I don't think this was ever about "performance" actually - Torsten mentioned the structure of the code and how a state machine-based approach may be preferable, but personally I tend to look at this from a fgdata standpoint, i.e. XML-based config files are much more likely to be edited/maintained than Nasal code, just like Nasal code is more likely to be edited/maintained by others compared to say GLSL or C++
Thus, I really think that Thorsten's analysis is spot-on - it really is a pain/gain thing, and there is very little to be gained given the degree of work involved - however, speaking purely on technical grounds, I tend to agree with Torsten (which isn't necessarily always the case either ...) - and from a fgdata/contributor standpoint, I think that some kind of XML-based markup may help lower the barrier to entry for those wanting to get involved in helping extend/maintain the system, without necessarily being "coders".
Thus, I don't have any preference, other than what Thorsten pointed out previously when he remarked, that I was speaking about architectural issues, that are not at all specific to your addon - but depending on how you'd like to see this evolve over time, my assertion is that some kind of simple XML-based system may encourage more folks to get involved, especially if accompanied by a few short tutorials illustrating how to customize the system.
Then again, this is a purely theoretical benefit as long as this isn't the case obviously - and that, too, is a recurring theme - one of the longest standing suggestions related to the "random buildings" subsystem was to make it Nasal configurable, so that non C++ folks could get involved - and for a number of years (dating back as far as 2012), the consensus has been the following:
Subject: Random Buildings
stuart wrote:Torsten has rather hit the nail on the head:it would be somewhat far-fetched to ask Stuart to make a faster Nasal interface than the existing one just because someone might eventually work on it.
Yes, it would be possible but it probably represents 10 hours of speculative development that I don't have time for right now. Given that people don't seem to making significant use of the tools already available by modifying materials.xml (at least not in a way that is making itself as far as git), I just don't see sufficient interest. That may change once these changes are available, as it'll give people a lot more scope for creating cities.
-Stuart
These days however, things seem to have changed a little - mainly because of all the momentum created by the varous OSM2* efforts.
But keep in mind, for the better part of the last 5 years, Stuart and Thorsten were right about this - which kinda supports Thorsten's pain/gain notion in a fairly compelling way