RichardH

1 hour ago, mue said:

Correct! But the buyer/recipient also get the same rights as you from the GPL. He can use/modify/distribute/sell the content under the GPL. His right to modify the content also means that you have to give him the "source code" of your content. The GPL says about the source code: "The source code for a work means the preferred form of the work for making modifications to it." I think (maybe Richard can confirm or correct me here) that means, that if you sell the lod file then you must also include the e.g. *.3ds or equivalent file.

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). 

2 hours ago, Wilches said:

I wonder if it's possible to import planes from FlightGear. There are some very interesting subjects there like Ar 234B with cockpit among others. Could it be?

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.

13 hours ago, swambast said:

 I'd personally prefer to see Thirdwire continue to go on it's own way and FlightGear do the same - I don't see what benefit Thirdwire or the community has in this arrangement - for example, do we suddenly get access to FlightGear assets?  But I'm sure I'm again in the minority - seems to be just a free for all these days.  

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.

Quote

Q. Are you going to continue to support the game?

A. We wish we could continue to support the game forever, but again, these things takes a lot of money, and we simply can not afford to keep supporting old games for years and decades....

Q. Can we add <xyz> features and fix <abc> bugs?

A. We'd love to be able to do everything everyone is asking for, but unfortunately, all these take a lot of time and money....

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.

13 hours ago, russouk2004 said:

Im sticking with SF2 too....flightgear has some good terrains and features,but too long and complcated method of importing a model...think I will stick to what I know lol

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.

8 hours ago, mue said:

Since the multiplayer protocol is open, you always have the risk of cheating. I don't understand how releasing the python code increases the risk of griefing?
I assumed the FlightGear combat community isn't that big, means you know each other, and therefore cheating isn't that much of a problem.

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.

8 hours ago, mue said:

I've  implemented an OSG file loader plugin for the SF2 3D model file format (*.lod). So the SF2 3D models can be directly loaded into FlighGear.
I'm still not sure if I should make the LOD loader plugin open source.

If I understand correctly, only hit notifications are transmitted, but no bullet or missile positions? Does that mean, that no tracers or missiles from other aircraft are visible?
Is damage calculated by the "receiver" or "sender"?
Do you have a link or pointer to the "automated enemy" code and the Python AI system?

In my opinion the OSG file loader should be OpenSource; 

1. 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. 
2. FlightGear is multi platform (Windows, OSX, Linux) and this becomes hard when working with binary distributions.
3. 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.
4. 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)

23 hours ago, russouk2004 said:

I dont mind making hi def models if someone who is used to getting them in game does that bit...must say...some of our modders models look far better quality so would benefit flightgear community too

Richard...you think,someone new to flightgear would take to doing the data files for models easy?...how long would you say it takes to do the data files for a newly completed 3d model.?

cheers  need to know if its worth me studying the method of importing models etc.

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.

10 hours ago, mue said:

Richard, thank you for coming to CombatAce and offering assistance regarding (military) FlightGear.
I'm fascinated by the flexibility of FlightGear and JSBSim.
Currently I'm implementing the Strike Fighters 2 FDM  and the (very light) systems in JSBSim. The developer of SF2 has an aerodynamic engineering background and therefore his FDM uses "standardized" aerocoefficients (My notes about the SF2 FDM: sf2_fdm_notes.pdf). Because of the "openness" of SF2 the aerocoefficients of each component (LeftWing, RightWing, LeftOuterWing, RightOuterWing, LeftStab, ...) are easily accessible from aircrafts data text (*.ini) files. Currently I'm doing the FDM/systems "conversion" to FlightGear/JSBSim manually, but I think this could be done later automatically by a tool.

As I wrote, I haven't looked in detail at the combat stuff in FlightGear yet. Maybe you can give a short overview of the features of the "OPRF" combat system (and maybe "Bombable")?
What weapons are supported (guns, rockets, (guided) missiles, bombs)?
I assume it works in multiplayer?
How is the damage modelling?
Since you mentioned SAMs, do you support AAA/Flak too?
How sophisticated are the automated (AI?) enemy aircraft?

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.