Board index FlightGear The FlightGear project

Military simulation (from Su-15 Screenshots)

Questions about the FlightGear organisation, website, wiki etc.

Re: Military simulation (from Su-15 Screenshots)

Postby Warty » Wed Dec 16, 2015 12:52 am

Just when I thought I was starting to understand things, I now fear I have lost the plot :oops: Isn't this thread about the problems/difficulties/whatever of doing "combat" stuff in FG because of the the lack of C++ support for it ?? Am I now to understand that the airliner side of FG is also limited by current C++ functionality?? i.e.: the military side of FG is not being picked on particularly.

I don't have any major problem with this: FG works fine for my purposes. But if the civil/airliner/peaceful side of FG are also struggling then there's no point making much of an issue over this. Just let the guys who are working on this (voluntarily) get on with things, maybe.
User avatar
Warty
 
Posts: 378
Joined: Sun Mar 29, 2015 7:53 pm
Location: Spain
Callsign: Warty
Version: 2020.4.0
OS: Mac OS 13

Re: Military simulation (from Su-15 Screenshots)

Postby curt » Wed Dec 16, 2015 2:09 am

The quantity of details and system modeling that goes in to covering all the aircraft of the world is impossibly complex. The idea is to put as much support for common/shared systems in C++ as we can and then make it possible to stitch these systems and details together and configure them with xml in a wide variety of ways to create aircraft. But we can never anticipate every system in use, and we can't anticipate the level of detail or feature set that every aircraft developer might want to implement or experiment with, and even if we could there would be no way to model everything in the world in a single application. Nasal gives a lot of flexibility to cover those unanticipated gaps and it allows aircraft developers to push in new areas ahead of the C++ coverage.

Now in many cases, aircraft developers were happy with the nasal implementation and called it good enough. Many aircraft developers have become proficient and comfortable in nasal and prefer doing their work there.

Hooray makes some points about performance limitations of any scripted languages, and some of the specific limitations of the nasal garbage collector and how it affects FlightGear.

But please, don't make this another us vs. them crazy debate. Just be educated and pick the best tool for the job. If nasal enables something that isn't otherwise possible or easy to do, just use it carefully and be aware of the performance implications as the nasal code complexity and size increases.

I implemented a full autonomous landing system for the F-14 onto a moving carrier with any wind and hit the touch down spot every time ... I did that with a combination of nasal and autopilot configuration tweaks. It was an interesting experiment and I learned a lot, but the code was ugly. Some of those concepts eventual found their way in the real world uav autopilot system I help develop, but that is all C/C++ running on embedded linux.

Here's a video the system in action doing a 100% autonomous autolanding ... (some of the S-turning is due to the specific aircraft being kind of a wanderer that doesn't respond precisely to inputs ... i.e. I can put it in a bank, but it doesn't always turn proportionally to the bank ... and there is about a 6-7 kt cross wind that is also affecting the landing.)

https://www.youtube.com/watch?v=6m9-wJ2haEU

Compare to the original simulator/nasal implementation (especially the 3rd and 4th approaches in the movie with turbulence and cross wind) :-) And of course the capt. would point the boat into the wind in real life, but I wanted the system to be able to handle all possible conditions.

https://www.youtube.com/watch?v=FWghkjE8HMY

This real world system runs the flightgear property system, the xml loader, xml-configurable autopilot PID system from FlightGear, includes much of the low level FlightGear wgs84 math routines, the route manager was originally inspired by the flightgear route manager, and I'm sure if I took a browse through the code I'd be reminded of many other systems and pieces that are taken straight from FlightGear or inspired by FlightGear.

Code for anyone interested: https://github.com/AuraUAS, currently running on a beaglebone with a custom designed cape and using a $30 ardupilot mega for all the sensor data. The result is a very inexpensive autopilot that has very high function and capability.

Regards,

Curt.
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: Military simulation (from Su-15 Screenshots)

Postby Thorsten » Wed Dec 16, 2015 9:54 am

Isn't this thread about the problems/difficulties/whatever of doing "combat" stuff in FG because of the the lack of C++ support for it ??


I don't know what it is about.

There's a difference with what you can do with FG and what gets committed to the repository in the first place.

There's no technical reason why you shouldn't make hundreds of liveries of Nazi Germany airplanes - FG as a platform allows you this. You probably will find they won't get committed to the repository though.

Same with what bombable provides - FG as a platform allows you to do AI adversaries for dogfights, hit determination,... JSBSim as a platform allows you damage simulation to systems and aerodynamics. The effect or the particle systems allow you to create explosion visuals of all kinds of weapons. There just won't be a ready-made folder with explosion visuals on the repository, there won't be a ready-made damage simulation (well, I suspect it'd not be viable to create an aircraft-independent one in any case).

No one really made them as an addon either, so they're just not there.

I frankly don't know of any specific air-combat related features which could not be implemented using the available toolkit of JSBSim tags, property rules and Nasal. Even for spaceflight (something FG was never really designed to do) the toolkit is enough to get good results.

Given that I have never seen any combat-related C++ patches being submitted and rejected, I suspect it's just a lot easier to ask for a feature on the C++ side because then it's someone else's job to implement it rather than do it yourself in JSBSim/ property rules.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Military simulation (from Su-15 Screenshots)

Postby Hooray » Wed Dec 16, 2015 10:45 am

Thorsten wrote in Wed Dec 16, 2015 9:54 am:I suspect it's just a lot easier to ask for a feature on the C++ side because then it's someone else's job to implement it rather than do it yourself in JSBSim/ property rules.


I think that's a pretty accurate assessment of what's usually happening whenever FlightGear itself must be treated like a platform that comes with certain subsystems and "frameworks" to accomplish something that nobody else has done yet - no matter if that means "spaceflight" or "combat" functionality.

There's a strong tendency among people (usually end-users) to suggest that something about FlightGear would need to be changed to be viable for their particular use-case - but in actuality, there are really only very few hard-coded restrictions in most cases - and people would normally be unlikely to encounter those, i.e. they would be much more likely to hit the ceiling of their own capabilities/expertise and other resources long before FlightGear related limitations would show up.

I think that the Bombable addon is a fairly compelling example of what can be done by a single dedicated individual, without any support from core developers at all - equally, the local/advanced weather systems demonstrate that people can build up enough momentum to convince core developers to respond to certain enhancements sooner or later.

As far as I can tell, there are only very few limits when it comes to supporting combat functionality in FlightGear, and most people would not even be aware of those after having worked with FlightGear for a couple of years, i.e. in the form of coding/scripting addons ("mods").

In fact, flug would probably be in an excellent position to judge if/what and how things need to be changed, so that certain scripted functionality can be put into the core (e.g. using property rules instead of Nasal).

But otherwise, there should be hardly any need for dedicated combat related subsystems, as long as the underlying building blocks are sufficiently generic in nature, people would also be unlikely to offend people like Torsten who are strongly against any combat specific elements in FlightGear.

Admittedly, there are a handful of implicit design assumptions (like those mentioned earlier), but Bombable does demonstrate that people can accomplish a ton of things without those having to be the bottleneck.

In a perfect world, anybody interested in "combat" support in FlightGear would get up to scratch with Bombable and team up with flug to determine what else may need changes on the C++ side to make such modifications easier - without any focus on "combat" functionality itself.

The advanced weather system started out as a scripted "addon" - these days, its main "workhorses" are living in C++ space, and are not necessarily specific to weather scripting, but can be used elsewhere (think terrain presampler).
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: Military simulation (from Su-15 Screenshots)

Postby MIG29pilot » Thu Dec 17, 2015 2:29 pm

If someone created an accurate, doable, reasonable combat/damage simulation package in simgear, would it get committed? I think that was what this thread started by asking.
User avatar
MIG29pilot
 
Posts: 1465
Joined: Tue May 19, 2015 5:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 2020.1.3
OS: Windows 10

Re: Military simulation (from Su-15 Screenshots)

Postby Hooray » Thu Dec 17, 2015 3:08 pm

MIG29pilot wrote in Thu Dec 17, 2015 2:29 pm:If someone created an accurate, doable, reasonable combat/damage simulation package in simgear, would it get committed? I think that was what this thread started by asking.


No, like Curt explained previously, FlightGear (and even more so, SimGear) are intended to provide building blocks in the form of customizable components that can be "stitched" together - there's nothing specific to "airliners" when it comes to FDM like yasim/jsbsim, which also applies to the property tree, xml, nasal, effects/shaders etc

So please stop thinking in terms of "combat functionality" - and just focus on what you need, so that the building blocks required for this can be determined - like Thorsten said, they are likely to be there alredy (think property rules, jsbsim systems, nasal etc).

In /some/ cases (e.g. the Canvas examples I mentioned), FlightGear would indeed benefit from certain C++ enhancements - but otherwise, most existing subsystems don't care about your use-case at all

EDIT: For the record, for a number of years, the standpoint related to "combat support" communicated on the devel list, but also in the official manual - was much more positive than it may appear to some people around here, no matter if that means people interested in combat capabilities or senior contributors who have meanwhile become key contributors and who are very much against this - in fact, here's what the manual originally read:

http://sourceforge.net/p/flightgear/get ... e2db90dd8f
in 2006, the manual wrote:To the disappointment of some users, it is currently not a combat simulator; however, these features are not explicitly excluded. We just have not had a developer that was seriously interested in systems necessary for combat simulation.


http://wiki.flightgear.org/Combat_Support_in_FlightGear

Personally, I am not very interested in combat functionality, but I consider the use-case itself just as valid as "spaceflight" or anything else that is related to flight simulation.
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: Military simulation (from Su-15 Screenshots)

Postby Foxtrot15 » Thu Dec 31, 2015 2:44 am

I'll just add my two cents here:

I totally understand that military aviation is not the original focus of FlightGear. For people who want to fly military jets authentically, they can go fly in Arma or DCS.

On the official FlightGear website, it is stated that
The idea for Flight Gear was born out of a dissatisfaction with current commercial PC flight simulators. A big problem with these simulators is their proprietariness and lack of extensibility. There are so many people across the world with great ideas for enhancing the currently available simulators who have the ability to write code, and who have a desire to learn and contribute. Many people involved in education and research could use a spiffy flight simulator frame work on which to build their own projects; however, commercial simulators do not lend themselves to modification and enhancement. The Flight Gear project is striving to fill these gaps.
The last sentence is key: FlightGear was intended to fill the gaps in commercial PC flight simulators.

So far, this has been done wonderfully. We have access to over 400 aircraft and counting, scenery and weather that is improving daily, and all the while keeping it light on the computer compared to other commercial flight simulators. It is actually a known fact that FSX crashes a lot. It's also free, allowing aspiring aviators facing budget constraints to fulfil their dreams, such as me.

However, taking away military aviation from a side focus of FlightGear's development would create two problems. Firstly, a gap would be caused in FlightGear, as FSX and X-plane both support military aviation. Secondly, aviation would not have reached today's standards without military aviation. Radar, jet engines and the helicopter are some examples of what military aviation made possible.

I do have to admit that the current stage of FlightGear's military side is quite admirable, and definitely comparable to other paid flight simulators. Of course, military aviation does have the dark side of death. However, what happens in FlightGear is more of a competition than cold-blooded murder. Having flown with the KSUU crew, I must say that we don't laugh at each other's fails and deaths. Instead, we help each other out, giving tips to how to avoid missiles and manoeuvre. When we are ready, we test each other's understanding of flight at its very basics, a competition of knowledge and skills. And when its over, we comment on what we each did right and wrong.

In conclusion, I feel that military aviation should remain as an option in FlightGear, perhaps something like an addon. There is no need to develop to the point of walking pilots and ejection sequences or the ability to kill the pilot. Just keep it purely to machine.

Cheers!
Foxtrot15
 
Posts: 378
Joined: Thu Aug 27, 2015 6:01 am
Location: Singapore
Callsign: Ice-99
Version: 2016.1.0
OS: OS X

Re: Military simulation (from Su-15 Screenshots)

Postby Thorsten » Thu Dec 31, 2015 8:20 am

As said a few times in this thread, there are neither technical nor moral objections against having an air combat package available as an addon - as for instance bombable currently provides :-)

Also, my personal impression is that all required functionality on the core side is there.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Military simulation (from Su-15 Screenshots)

Postby Thorsten » Fri Jan 01, 2016 8:39 am

As I've written earlier, I have not been adverse to the idea of simulating combat in FG and I have a history with Falcon 3 and 4 back when they came out. I have over the years looked some into how realistic damage and failure modeling could be made (and ended up implementing some of that from the Shuttle). Long time forum users might also remember me dabbling some with impact explosion visuals (I'll save you the trouble and dig up the old shot myself - to my surprise it's actually still there):

Image

I have however also come to recognize that there is a thing called a slippery slope and that adding one feature can lead to the next and the next and have the whole thing end up in a direction I no longer want. I've finally also come to recognize that there are people who would like to keep FG completely civil, that there are users and contributors who have lost friends or family members through bombs falling from the sky and that these experiences and positions also deserve respect.

I had, after the latest exchanges on the mailing list and here, the impression that keeping FG as such free of direct weapons effect simulation, but providing the hooks and experience to things like realistic damage modeling, radar target acquisition or even guidance from the FG core package to be utilized by an addon (because they're dual use technologies) is a viable compromise which works for everyone.

Recent postings on the mailing list have unfortunately proven me wrong:

https://sourceforge.net/p/flightgear/ma ... /34730659/

https://sourceforge.net/p/flightgear/ma ... /34730991/

I think it's pretty clear coming from the discussions we had here and reading about 'integrating combat support with FG' next that there are people who would exploit any slippery slope to full measure, and personally I realize that once on the slope, I'll find it harder to to stop the train on a position I still find comfortable. So, with a good measure of regret, I've come to the conclusion that I have no choice but to try my best to stop the train before it ever reaches the slope.

Thus, please count me now into the camp of people opposed to the idea of air combat in FG - I'll make sure the subsystems I maintain will not receive any such support.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Military simulation (from Su-15 Screenshots)

Postby Foxtrot15 » Fri Jan 01, 2016 9:43 am

Understood.

Just to clarify, will users have ultimately no option of air combat in FG or will it be maintained as an addon that only determined people can utilise?
Foxtrot15
 
Posts: 378
Joined: Thu Aug 27, 2015 6:01 am
Location: Singapore
Callsign: Ice-99
Version: 2016.1.0
OS: OS X

Re: Military simulation (from Su-15 Screenshots)

Postby Thorsten » Fri Jan 01, 2016 9:46 am

I don't speak for the whole community of developers so I don't know what will ultimately happen. Also, whatever is distributed outside of the official infrastructure is the business of the people distributing it, so I think the answer depends partially on what the people who opt to develop such functionality do.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Military simulation (from Su-15 Screenshots)

Postby Bomber » Fri Jan 01, 2016 1:10 pm

I oppose you Thorsten... you activily prevent the growth of flightgear in any direction other that the one you want... and to my mind your attitiude will eventually create a fork in the development.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: Military simulation (from Su-15 Screenshots)

Postby Foxtrot15 » Fri Jan 01, 2016 1:32 pm

Just for the sake of FGPromo, will current air combat be taken away (such as missile capabilities in the Mirage) or will they remain and eventually lose support?

This is because I have a few scenes showing air combat but if they are to be taken away then the promo is not accurate.
Foxtrot15
 
Posts: 378
Joined: Thu Aug 27, 2015 6:01 am
Location: Singapore
Callsign: Ice-99
Version: 2016.1.0
OS: OS X

Re: Military simulation (from Su-15 Screenshots)

Postby Hooray » Fri Jan 01, 2016 3:18 pm

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).
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: Military simulation (from Su-15 Screenshots)

Postby Foxtrot15 » Fri Jan 01, 2016 4:10 pm

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.


Wow, I did not know of that until now. I now see the point: there are immature users who misuse FlightGear's combat capabilities in ways that are not appreciated or acceptable to others. What they did, I feel is not combat simulation. Combat is supposed to be a competition between two parties to reveal the victor. What they did was War Simulation, where the deaths of innocents are simulated and made fun of. If this is what the combat simulations is used for, I'd very much oppose it.

However, it has to be noted that they are a minority. I'm sure that the KSUU Crew has been noticed, and definitely raised some eyebrows. Despite being biased, I can say that we don't like shooting each other down that much, not to even talk of bombing. In fact, majority of our time is spent on formation flying and refuelling training. We do occasionally dogfight, but we do it duel style: both sides agreeing to the rules and keeping our weapons when the other side calls a time-out. Being one of the larger military groups, I can say that the probability of war simulation is rather low now.

Looking at the road ahead, if FlightGear gets developed into a combat simulator capable platform, it is very probable that the younger generations may use the combat functions in a very inappropriate way.

Hence, I totally understand the developer's points and will not whine if combat simulations get taken out of development. However as Hooray pointed out, nothing is stopping determined coders from building up FlightGear's combat capabilities. Sorry to say this, but Thorsten, Torsten, others and me do not live forever. Eventually, a new generation will take over the development of FlightGear. We may be able to stop the development of combat capabilities this semicentennial, but what's to stop the next generation?

Also, so what if there is no military simulation. People can still crash into others, or worse, into buildings. Twin buildings if you know what I mean. Should we stop development of urban scenery too?

What I propose is we lay down a set of principles, boundaries you may say. Let all users and FG developers vote on it and we let this be a guiding principle for FlightGear's development. For example, we do not simulate human beings at all for combat scenarios (e.g. no mission: Bomb random bad guy travelling across desert and we see the corpse after it is on fire) or we do not provide development for historical combat scenarios. We do not have to make it binding, just as a guide for future developers on what we should not touch.

It's kinda like the "do not touch" sign on store goods. It's not that you would die if you touch the goods, just that you might break it and in the end lose part of your paycheck. Same thing, we do not have to force the future developers on what they should or should not do, but we let them know that there should be a limit, and within that limit, nobody gets hurt, everybody benefits.

Last point, humans have a tendency to crave what we should not get. Telling a child not to eat the cookie invariably causes to cookie to be eaten. Taking away combat simulations, invariable causes more people to want to develop it and use it.
Foxtrot15
 
Posts: 378
Joined: Thu Aug 27, 2015 6:01 am
Location: Singapore
Callsign: Ice-99
Version: 2016.1.0
OS: OS X

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 5 guests