Bomber wrote in Fri Sep 15, 2017 1:02 pm:There's simply no point in Hooray holding out any olive branch or saying that people ought to be working on building blocks of code rather that focusing on combat functionality if as we know there's NO chance of combat being a part of flightgear... Combat is ALWAYS going to be on the periphery, so asking someone to create building blocks of code that works for civil as well as combat is rather pointless if at the end of the day the combat functionality that has NO chance of being included has to always interact with this new building block from the periphery using an addon mod.
[...]
Then maybe we'd see people more interested in creating these building blocks that Hooray talks about as opposed to thinking that "well if anything I do that has the whiff of combat about it can never be implemented, what's the point"
Just to be clear, I am neither in a position to hold out an "olive branch", nor was I trying to do so. Rather, the point was that "modding" the sim is in fact very well possible and also very feasible, the Bombable addon is a rather compelling example - as is the spaceshuttle/spaceflight effort (as a matter of fact, there is much better combat support in FG than there is support for spaceflight in terms of core level "building blocks").
Speaking in general, there is APIs like the property tree, XML, fgcommands, bindings, the XML configurable GUI, property rules, Nasal and Canvas - none of which are specific to any particular use-case. Which is to say that there is no way to prevent people from using these features for arbitrary purposes, including those that many of us may disagree with - thus, it is is technically the right approach to learn the corresponding lesson and continue to provide generic building blocks, and instead of adding controversial stuff like "CombatScript" or "CombatCanvas" or "FighterFDM", we can provide generic building blocks - pretty much the same building blocks will indeed be required for continuing with the development of the spaceshuttle/spaceflight projects.
As a matter of fact, I have suggested on various ocassions to read up on the history of "combat" and "dogfighting" discussions in the devel list/forum archives - and in particular, I suggest to read up on the whole "FGScript" debate. People doing so will realize just how much of an impact these discussions had on Nasal and its way it is integrated. Sure, it never became known as "FGScript" or "CombatScript" - but it's really accomplished pretty much
everything that people originally suggested, with much less of an impact in terms of controversial debates.
Nasal scripting in conjunction with a strong IPC mechanism (e.g. Emesary) and some way to run stuff asynchronously could provide a good foundation for implementing all sorts of neat side-kicks that none of the key core folks have to agree with necessarily.
Even if you totally dislike Nasal, look at the history of the Canvas system and how it came to be - and keep in mind that it's not specific to a single aircraft, type of aircraft or use-case, it's as generic as things can get (heck, you can even create UIs or HUDs procedurally).
Thus, this is the right approach to have your cake and eat it, no matter what your cake is - to see that this is indeed the case, look at what the spaceshuttle folks have created over te course of the last 18 months despite years of debates deep in the archives stating that this would not be possible, and that dedicated spaceflight tools would be needed.
Likewise, you could look at other "sidekicks" like Advanced Weather and/or ALS that have become key-features despite being largely implemented in a fashion that many core developers seem to disagree with (think having a scripted weather system)
I once had the same discussion with flug, suggesting that his work be reviewed to extract generic building blocks that are not specifici to the dogfighting use-case, to help make the Bombable addon smaller and more modular, and provide dediated APIs. Thanks to Torsten's recent addon work that should be increasingly possible now, and the addon framework would greatly benefit from being augmented to support "power" addons like the Bombable addon.
Personally, I would love seeing the Bombable refactored accorddingly, so that generic building blocks can be extracted and moved to the FlightGear fgdata repository, which Bombable would simply use, so that over time Bombable would indeed become an addon that can be easily installed, updated/managed and removed using the built-in package manager. FlightGear as a project could greatly benefit from doing so, and particularly Torsten's addon framework could literally thrive by being augmented to support such addons (totally unrelated to their nature).
PS: I don't think the turrent thing would be difficult to implement or get committed, we've had this discussion before - it's very much overlapping with certain non-combat use-cases, e.g. 6DOF cams mounted to a news/SAR helicopter. And I guess that's how I'd approach the whole thing: identify overlapping use-cases and implement the whole thing as a building block, so that it can be used by aircraft developers accordingly.