RichardH

Firstly the guiding principle of the GPL is that you, as a creator, can choose to licence your creation so that everyone can have the freedom to use it, to redistribute it, but also to distribute improvements. Any distributed improvements must have the source so that the original freedom is maintained. You get to choose if you want to licence under GPL - if you don't like it then don't use it. I really don't want to get into a licencing debate - basically the GPL means you have to distribute the source to any improvements that you distribute (regardless of whether you sell it or not).

I imagine it's a case of importing the 3d model into 3ds and exporting an LOD. Usually FlightGear models tend to be built from lots of individual models that are pulled together in the xml file - however I've got a tool that merges these into a single file (and uses a texture atlas); I've run this on the AR-234. The resulting model is entirely suitable for import into 3ds Max (the archive contains AC3D FBX and Blender formats) https://www.dropbox.com/s/0v7mh220igkfu4n/AR-234-full-model.7z?dl=1 The XML file also contains all of the animations which might be useful as a guide; and remember that this model licenced under the GPL v2.

Just to be clear nobody is promoting or encouraging any sort of distribution that isn't permitted by the existing licences. Normally in the FlightGear world we respect the creator's wishes - so if someone doesn't want something used we generally won't use it (even if an existing licence would permit this). It's a case of doing the right thing. All of FlightGear's assets are freely available and you can redistribute under the GPL https://scenery.flightgear.org/ - currently 7498 models - e.g. military objects https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=6 532 FlightGear aircraft can be found here https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ The rest of our assets are in here; https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ - e.g. low poly aircraft models https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/AI/Aircraft/ The benefit to this community is open up the development and to hopefully build something that will grow with the modding community - without negatively impacting it. Remember that ThirdWire are commercial, and in fact I just had a brief look and found these statements here https://fundrazr.com/31YZNe?ref=ab_53zatDj9Npr53zatDj9Npr - whereas any opensource game can keep going all the time that the community wishes to support it. These are the benefits for me and one of the reasons that I chose FlightGear over X-Plane, FSX, P3D - but I'm not here to try too hard to change anyone's mind. Hopefully this will be resolved by having a complete SF2 loader that will allow the entire model to be loaded and flown without any need for modders to do this. Because FlightGear is so open we don't really want to publish something that could be used to cause grief / interfere with civilian flight operations - i.e. the normal multiplayer. It would be bad for OPRF if someone put up a set of AI fighters that decided to intercept and shoot down (or just annoy) civilian traffic.

In my opinion the OSG file loader should be OpenSource; OpenSource is really the only way to guarantee the future availability of the plugin and therefore anything that depends on it. This is particularly important for community projects as it protects everyone's investment from becoming obsolete. FlightGear is multi platform (Windows, OSX, Linux) and this becomes hard when working with binary distributions. The rest of FlightGear is, and always has been OpenSource. This is tens of thousands of hours of effort - so it is only fair to keep with this philosophy. The copy protection offered by having a file format that can be reverse engineered isn't worth that much and in any case cannot protect against the use of a DirectX ripper to grab the geometry. I can understand the argument that it provides (limited) copy protection for the artwork and assets - but realistically most of us give our work away for no charge so the main use is to stop evil people from making money off our hard work; and realistically proper licencing is the best approach to this (e.g. CC NC). The OPRF current version only transmits release / hit / miss notifications - however I have a nearly finished WIP that will transmit in flight position messages for missiles and shells (subject to bandwidth limitations) Damage is calculated by the recipient based on the distance with a sprinkling of randomness. The python code isn't generally available (due to the risk of griefing)

To answer this first I need to break down the aircraft development tasks 1. Create 3d model in the right format (.ac) This can take anything from a few seconds to many hours depending on the original format, the conversion tools and the modelling package being used. Generally Blender -> AC3d works best, 3ds max often needs to go through another format (e.g. DAE, .OBJ) 2. Create animation XMLs Initially this is going to take a while; however once familiar with FlightGear's property tree it is a lot easier. Also we have the ability to use 3d objects (two-vertex lines) as animation axis which removes the need for coordinate entry; complex cockpits take longer 3. Create Flight Model Using Aeromatic++ it is possible to get a flying model in a matter of a few minutes. A complex aero model using real data (wind tunnel, flight) or CFD data (OpenVSP, OpenFoam) can take months. 4. Avionics (Radar, Displays etc) The most time consuming aspect of developing in FG are the avionics and cockpit displays (CRT). OPRF has modules that can be integrated into aircraft to help. 5. Integrate with combat Bombable is OK but really you need to look at the OPRF aircraft (F-14, F-15, F-16, Mirage-2000) (http://opredflag.com/forum_threads/2412191) as these have the armaments, damage code and radar. Viggen is probably the most complete example. However given that SF2 aircraft are standard I'd recommend looking at writing some sort of importer / converter / loader that will do most of the work. Expect to invest a fair amount of time on 2, 4, 5 in the above list - unless there is an importer or some sort of conversion tool. Looking at the aero notes[1] if you have these coefficients it should be relatively easy to put together a JSBSim model - as that's what JSBSim is designed for; it's fortunate that SF2 uses the 'standard' way of doing things. Making an importer is the best way of converting SF2 models to FlightGear. The way that OPRF aircraft work is to do all of the combat simulation within the aircraft model; with the hit notifications being transmitted over the multiplayer system OPRF aircraft must have radar simulation that has correct ranges and can't see through terrain; accurate weapons simulation, damage modelling. Most of this is implemented in FlightGear's Nasal scripting language. Damage works over MP and currently uses the MP text chat to inflict damage. AAA/Flak could be simulated using the same system - but what we don't have (yet) in the OPRF is much in the way of missions or automated enemies - but this area is under development. The automat aircraft opponents are reasonable and work is ongoing. Remember that OPRF was originally about enabling dogfights between people, then we had organised events - and now we're moving towards more AI and hopefully one day we'll have missions and even campaigns. The development is slow - but because it's all opensource we can pretty much do anything that we have the time to implement. There is a python AI system under development that integrates with the Multiplay and provides targets and will provide opponents. Bombable is an alternative way of giving and receiving damage, but it also provides AI opponents; however it isn't as fully featured as OPRF. ---------------------- [1] Although some of what you refer to as derivatives are in fact just coefficients; the real derivatives are those that are due to the output from the aero model (p,q,r, alphadot, betadot) I've highlighted the derivates in green

I'm a core contributor to FlightGear, responsible for the the F-15, F-14 in FlightGear, have made aero models for the Mirage2000, Tornado F2, SupermarineSwift and a member of OPRF (opredflag) which is the biggest FlightGear military community. OPRF aircraft can damage each other, we have automated enemy aircraft, SAMS and we have work in progress that will hopefully one day allow a full combat scenario. I've also got experience building computational aerodynamics models for FG using the excellent OpenVSP http://chateau-logic.com/content/using-vspaero-generate-aerodynamic-model-jsbsim-flightgear and https://forum.flightgear.org/viewtopic.php?f=49&t=30832 http://zaretto.com/f-14 http://zaretto.com/f-15 http://zaretto.com/a320 http://zaretto.com/Panavia-Tornado https://github.com/Zaretto/fg-aircraft https://github.com/Zaretto/Supermarine-Swift https://github.com/Zaretto/Aircraft/tree/master/Mirage-2000 http://chateau-logic.com/content/emesary-nasal-implementation-flightgear http://chateau-logic.com/content/deferred-rendering-rembrandt-performance http://chateau-logic.com/content/flightgear-using-canvas-3d-instrument I'm posting here to state my interest in assisting with anything FlightGear military related; and I can also provide assistance on "how things work" In FG.