Jump to content

Recommended Posts

1 hour ago, swambast said:

In my opinion, I could not disagree more and hate the way this is heading...The Developer of this Sim created an encrypted .LOD file format for a reason - to prevent theft and unauthorized distribution.  I have never seen a post where the Developer has made a claim about not caring about reverse engineering - why do you think he ended up locking certain .LODs and other game components away then if he didn't care?  Anyone can justify anything if they want, but it doesn't make it right.  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.  

TK posted this in Sep. 2007 in his forum. See this forum thread: LOD file format. - Third Wire Forums.htm. And I wrote already that he used obfuscation methods later.
Just to clarify: I don't want to distribute any assets. I only want to use assets from the game I purchased or assets from this community within FlightGear. For this I plan to write a tool that automatically converts the SF2 data ini files into FlightGear files (Edit: the .lod file itself can be directly loaded into FlightGear via the OSG pluging, so no conversion of lod files needed). Again: no distribution of any assets! I think that's legal within TWs EULA and CombatAce Freeware License Agreement.
And I see benefit for Thirdwire and the community: Maybe some will buy SF2 games if they know they can use the aircraft in FlightGear too. And maybe FlightGear can be enhanced to be a fully community driven open source air combat simulator. Then why not use the already by this community created assets?
And yes, everybody has access to FlightGear assets. Most FlightGear assets are released under GPL or other "free" licenses. I was told recently, that FlightGear aircraft were already converted to SF2.

Edited by mue
added info about lod file loading; grammar
  • Like 3

Share this post


Link to post
Share on other sites

13 hours ago, RichardH said:

The python code isn't generally available (due to the risk of griefing)

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.

Edited by mue

Share this post


Link to post
Share on other sites
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

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.

  • Like 2

Share this post


Link to post
Share on other sites
25 minutes ago, RichardH said:

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.

Ok, now I understand. I forgot/haven't considered that you use the official multiplayer network with it's civilian traffic.

Share this post


Link to post
Share on other sites
Quote

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.

ahh ok...thnks...will have look at whats involved in depth and see how I get on...do my bit so to speak lol   hopefully we can get this to work...

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites
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=

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.

 

Edited by RichardH

Share this post


Link to post
Share on other sites

Wow!! That's awesome! Hope that someone make this job. It' s out of my skiils. Thanks Richard and keep with us!

Share this post


Link to post
Share on other sites
36 minutes ago, RichardH said:

and remember that this model licenced under the GPL v2.

For those who don't know the GPL: If you use GPL content for your aircraft then the derived work, i.e. your aircraft, is also automatically licenced under the GPL. That means you can not distribute your aircraft under the CombatAce Modders License Agreement, because the CombatAce Modders License Agreement forbids the sale of the content (as payware). However the GPL doesn't allow those restrictions. Under the GPL the user has the right to sell the content!

Share this post


Link to post
Share on other sites

Easy enough to get it started...

 

LOL

@Mue, so under the GPL if I made this available I or anyone else can then subsequently take it and sell it?  Or am I totally misunderstanding...  

 

image.png.9ae1051c95c6641928933fb9ffe19126.png

Edited by swambast
GPL question for Mue

Share this post


Link to post
Share on other sites
44 minutes ago, swambast said:

so under the GPL if I made this available I or anyone else can then subsequently take it and sell it?  Or am I totally misunderstanding...

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.

Edited by mue

Share this post


Link to post
Share on other sites
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). 

Edited by RichardH

Share this post


Link to post
Share on other sites

With GPL then adding models,might make people release them as Payware...if I do,i for one might consider this....if others make £££ $$$ off my free model,then why shouldnt I first ?....lol

is this GPL obligatory for Flightgear...? maybe we could if it happens....create a group that is strictly freeware. ?

I assume GPL means General Public License ?

Edited by russouk2004

Share this post


Link to post
Share on other sites
33 minutes ago, russouk2004 said:

With GPL then adding models,might make people release them as Payware...if I do,i for one might consider this....if others make £££ $$$ off my free model,then why shouldnt I first ?....lol

is this GPL obligatory for Flightgear...? maybe we could if it happens....create a group that is strictly freeware. ?

I assume GPL means General Public License ?

Yes GPL means General Public License.
Only if you want your aircraft included in the official FlightGear hangar "FGAddon", then the GPLv2 is obligatory. Otherwise you can license your model as you like (assumed the whole model is your own creation and don't contain or uses GPL content) and use it in FlightGear.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 2019-10-17 at 3:30 AM, 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?

There's a fine Deperdussin Racer of 1913 that I remember seeing several years ago, in FlightGear - would be nice to import that one into FE2. Also the Santos-Dumont Demoiselle comes to mind too. :smile:

Happy flying,

Von S

  • Like 1

Share this post


Link to post
Share on other sites

This is an interesting concept... looking forward to seeing this progress. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By VonS
      Recently I had an opportunity to re-install FlightGear (stable ver. 2020.3.19) on my 2013 Mac Pro and was pleasantly surprised - with no crashes, decent FPS for the most part, and various other improvements that were incorporated over the years. I had dabbled briefly in FlightGear a couple of times before (around 2013, and again around 2020) - but eventually removed the flight simulator from my hard drive on both of those occasions.
      Since my particular setup(s) are with dual AMD video cards, I thought I would post some (illustrative) tips below, as well as representative pics of the sim when at best, or very good, settings. I will this time around keep FlightGear on my hard drive - makes for a good, free flight simulator.
      For command line entries and tips that should be plugged into the "Additional Settings" option of FlightGear, see the info. immediately below. Make sure to remove the info. included in brackets if copying the commands into the relevant settings section.
      -----
      --prop:/sim/gui/current-style=0 (better GUI style for AMD cards)
      --prop:input/mice/mouse/mode/button[2]/binding/value=2 (gets rid of horrible mouse-as-yoke feature that sometimes automatically turns on)
      --prop:/sim/rendering/photoscenery/enabled=true (gives more photo-realistic scenery whenever possible; to be fully implemented in later FG versions)
      --prop:/sim/rendering/hdr/envmap/update-continuously=false (disables continuous siphoning and updating of terrains, to enable seconds command below)
      --prop:/sim/rendering/hdr/envmap/update-rate=5 (terrain refresh rate set in seconds; good values are 5 or 10, for minimal stuttering)
      --prop:/sim/rendering/max-paged-lod=1300 (stock max paged LOD no. is "200"; recommended is not to exceed about "1900" on AMD)
      --prop:/sim/rendering/plod-minimum-expiry-time-secs=60 (stock min expiry time is "180" secs.)
      --prop:/sim/rendering/multithreading-mode=DrawThreadPerContext (should improve multithreading capacity, at least slightly, and add a few extra FPS)
      --prop:/sim/rendering/database-pager/threads=12 (stock thread rendering no. is "4," with more threads improving ave. FPS; set as per your CPU threads no.)
      --prop:/sim/rendering/vsync-enable=false (force disables vsync to improve FPS)
      --prop:/sim/rendering/multi-sample-buffers=true (this is anti-aliasing; set to false to disable and remove entry immediately below it)
      --prop:/sim/rendering/multi-samples=2 (anti-aliasing value; lowest is 2, also good is 4; avoid 3)
      --compositor=Compositor/HDR/hdr (modern rendering pipeline for better graphics details and shaders; rarely breaks scenery; still mostly experimental on AMD vid. cards)
      --units-meters
      --disable-splash-screen
      --disable-horizon-effect
      --enable-distance-attenuation
      --enable-specular-highlight
      --enable-clouds3d
      --fog-nicest ("nicest" improves look of fog with more subtleties while "fastest" makes fog appear and disappear more quickly; no real impact on AMD FPS)
      --shading-flat ("smooth" apparently improves look or depth of shaders; preference is for "flat" since I have not noticed difference in quality on AMD)
      --texture-filtering=2 (this is anisotropic value; lowest is 1; also good is 4 or 2; avoid 3)
      --bpp=32 (can also use 24 but have not noticed an FPS improvement with 24; would say 32 is better for FPS overall)
      --terrain-engine=pagedLOD
      --lod-levels=3 2 5 3 1 (also good is 4 3 6 4 2 for best visual quality on AMD but still mostly FPS-friendly; recommended is 3 2 5 3 1 for balance between visual quality and solid FPS)
      --lod-res=2 (default is 1; also good is 3; avoid any other values besides 2)
      --lod-texturing=raster (better than "bluemarble" as far as I have been able to test, with smoother loading of textures)
      --lod-range-mult=3 (default is 2; also good is 1; avoid all other values besides 3)
      --enable-texture-cache
      -----
      On a broader note, it's important to tweak the rendering, shaders, and LOD range settings in FlightGear - to get the best experience on your AMD video rigs (be it a dual or single AMD setup).
      The frequencies, by the way, on my dual FireProD700s have been OC-ed, via MSI Afterburner, from a clock/memory of 850/1370 to 1024/1380 MHz.
      Be sensible with the rendering options - particularly with the maximum number of scenery and aircraft tiles - anything above a value of 1900 or so is both useless and an FPS hit. (The scenery/aircraft tiles no. may also be set via the relevant command line entry indicated above in this post.)
      Take note as well of cloud density and visibility values. Anything beyond a visibility of 35 km or so is questionable since it does not widen further the cloud carpet but is, once again, an FPS hit.

      Pic 1 - Sensible/Best Rendering Choices for AMD Video (in FlightGear)
      Next we look at the shader options that also require careful thinking and tweaking. Take note that "landmass," "urban," also "water" - give different visuals if they are set to the maximum level (of five). I personally prefer how the landscape/terrains look with those three settings at a value of four - with crisper graphics - but tweak according to taste. Also worth noting is that I always run the LOD value on my rig(s) at "-1," via the excellent little program "ATISetLod" that is available under the top post of this thread.

      Pic 2 - Sensible/Best Shader Options for AMD Video (for crisp and fairly realistic graphics)
      Also important is to tweak the LOD range settings to get a good balance between visual quality and decent FPS, with no stuttering or crashes. Focus in particular on the maximum distances for the detailed, rough and bare scenery ranges - I decided eventually on cutoffs of 3, 17.5 and nearly 45 km. Other cutoffs worth considering are 2.5, 15, and 40 (or so) km, as well as 3.5, 20, and 50 km. Anything beyond the latter values will, again, most likely not make much of a difference with the visuals but will contribute a noticeable FPS hit. Take note also of the "high detail" and "AI/MP interior" values. I'm getting good results with values of 250 - 260 pixels for those options; also good are values of 300 (or so) pixels. Those two values may be tweaked to taste, for the most part - but, again, be sensible since they may impact on FPS.

      Pic 3 - Sensible/Best LOD Range Values for AMD Video
      Last, let's not forget to tweak our custom FlightGear profile (in our AMD settings panel) as best we can, to minimize stuttering, pausing, or crashes. Take note in particular how the shader cache is set to "On," not to "AMD Optimized," and how, even though I have enabled CrossFire mode, frame pacing is set to "Off" (which eradicates stutters on my rig in FlightGear - had tried with frame pacing "On" and was not pleased with the results). If you have only a single AMD video card, experiment with leaving the CrossFire option on (set to "AFR compatible"), or turning it off entirely. (NOTE: I have not noticed any FPS downgrade with anti-aliasing set to 4EQ and edge-detect, anisotropic value at 8, and tessellation at 16. Tweak to taste obviously.)

      Pic 4 - Good AMD Settings for a Custom FlightGear Profile
      Recommended also, if having any instability with FlightGear on AMD video, is to stick with the "Pro" variant DLLs (drivers) for AMD, instead of the consumer/Adrenalin ones. I particularly like the ver. 19.x.x Pro series of drivers, as well as the venerable ver. 17.x.x ones (the latter of which I have installed on the 2013 Mac Pro). To find links to the Pro 19.Q3 DLLs (the last version of the Pro DLLs to support CrossFire, by the way), see this page.
      Below follow several representative pics with the settings illustrated above applied - FlightGear provides a nice selection of aircraft with usually very good monoplane FMs, especially for tricycle-gear (small) civilian aircraft such as Cessnas, also for airliners like the (classic) Boeing 707. For multi-wing contraptions on the other hand and more realistic/historical FMs for biplanes, triplanes, and the odd multiplane, the gold standard(s) remain heavily-modded First Eagles 2 and RoF, as well as recent iterations (UE edition onwards) of the excellent WoFF series.







      Happy flying,
      Von S 
×

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy, and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..