There is no active endorsement/support of combat related functionality in FlightGear, and there hasn't been any, in other words it would be difficult to "take away" from anything.
Thorsten, and a few others, just stated that they're opposed to the idea.
Personally, I am not likely to use any such functionality, but I am interested in the technical side of it - Thorsten also stated several times that he would love to get involved in creating missiles, FDMs and guidance logic - with the space shuttle, he's basically doing this kind of work now, in a non-military context though.
However, the project being GPL, it would obviously be possible for people to simply take what's there and build on it, i.e. extend such features - i.e. there's nothing that we can do to prevent people from using Thorsten's (or any other GPL) work to create transcontinental missiles and use those in a military context.
That being said, FlightGear would still be a fairly poor "military" simulation even then - and having, or not having Bombable support commited also doesn't change anything for those wanting to use it.
Like I said, I am interested in the technical side of this, but unlikely to really "play" Bombable or use other combat related functionality in FlightGear.
But it is true that people like Thorsten, Torsten and others do have a point - we have seen some really unfortunate uses of FlightGear - and while I am not easily offended, I found the whole recreation of the Hiroshima bombings extremely unfortunate, untactful, immature and extremely tasteless.
We may have the debate whether FG is even suitable to recreate such events in any realistic fashion or not, but even just having end-users team up to re-create such real events where so many people died, may reflect badly upon the project and the people involved in it, i.e. it may put harm to FlightGear as a project, and us as a community - despite those shouldering it, not even remotely being involved in such activities.
I do realize that there are many young users around here, and others lacking the background/education to appreciate such subtleties, maybe that is because most of the people involved in this community have fortunately never experienced the cruelty of war - but I would really hope that those wanting to do combat simulation try to tread more carefully here.
From where I am standing, I am still not opposed to seeing such functionality, and will support efforts on technical grounds, but I find the idea of re-creating mass-bombings in FlightGear, on MP, problematic - and I think that there's a tiny group of people who literally helped put the rest to case by behaving the way they did (not at all referring contributors like flug or Bomber).
Regarding the whole "forking" debate, I guess that having "combat" support in FlightGear may be the most legitimate and most justified reason to fork FlightGear given the priorities and interests of those currently involved, so I would not be opposed to that - and it may help both parties, because a certain subset of functionality would not need to be combat specific at all.
Apart from that, Bombable in its current form wasn't intended to be committed "as is" - quoting recent PMs to Thorsten, in response to the discussion on the devel list:
Hooray wrote:Referring to the devel list comments:
I haven't talked to flug in a while, but he didn't want the package to be committed in its current form.
His long-term hope was indeed to turn it into an entirely optional package that could be easily shipped with, and maintained in, fgdata - but he realized he wasn't there yet. I think some of the reasons are listed in various README/TODO files in the zip file.
Meanwhile, the whole fgaddon/package manager thing is materializing, so that would be another viable option - and would not cause much irritation.
My personal opinion is that I would like to see it as an optional feature included probably, even if just to simplify future maintenance/development, but there's quite a bit of work that still needs to happen for that to be viable.
He literally patched up dozens of things in fgdata if I remember correctly.
The last time we talked about this, we were thinking of useful C++ changes to allow such "addons" to be used as an "overlay" on top of fgdata, without having to maintain separate files for modified aircraft, similar to xml includes etc
flug gave me commit/admin access to his bombable github repository, and his long-term vision really was for the package to be shipped as an optional feature built into fg, but he didn't push for it, fully realizing that there's still quite a bit of work ahead to make that feasible, and that there's fairly outspoken opposition from some people.
Overall, flug was hoping to restructure bombable and get smaller, more generic, parts of it committed over time - e.g. turning bombable into a Nasal submodule and identifying useful functionality that could become a standalone module, unrelated to combat.
These days, it seems that Red Leader's "scripted AI objects" module could help generalize/strip-down Bombable significantly, without being combat specific - so that is another possibility.
And I think that this would be a worthwhile goal personally.
For now, I am afraid that it may cause too much irritation - even though I am inclined to agree with Alan's comments (as you probably guessed)
Hooray wrote:@Thorsten:
Regarding Alan's comments, you are right in that Bombable does not directly help with HLA etc, but it is another use-case that may help the efforts mentioned by Alan to be implemented in a sufficiently generic fashion - i.e. Bombable does use the multiplayer feature, dual pilot, wildfire etc.
For the time being, it does not use much more than a pseudo FDM implemented in Nasal, but given Erik's recent work on "propertyObject" support, it seems increasingly likely that independent FDM instances will be supported sooner or later, so that things like AI traffic (airliners, but also Bombable "bots") may eventually make use of a real FDM, which may thus also be subject to weather phenomena like turbulence, windshear etc
Like you say, Bombable isn't doing any of this currently - but flug was hoping to support some of these things, and simply could not implement them, because of certain hard-coded restrictions.
So I agree that Bombable does not -currently- "contribute" to the areas mentioned by Alan, but it does have the potential to help influence the underlying efforts, i.e. referring to Stuart's effort to decouple the AI traffic system and use that for an updated multiplayer system.
Bombable was pioneering quite a few features in the form of workarounds that are only about to become more standardized thanks to efforts like HLA (which does not have to do much with concurrency or framerates at this point, just distributed state management).