FlightGear wiki

Frequently asked questions: Difference between revisions

Page Discussion

Frequently asked questions (view source)

Revision as of 07:08, 31 October 2017

18,956 bytes added ,  31 October 2017
→‎Where can I get FlightGear?
(19 intermediate revisions by 4 users not shown)
Line 4: Line 4:
=== Where can I get FlightGear? ===
=== Where can I get FlightGear? ===
The official download page is http://www.flightgear.org/download/. Precompiled binaries are available for Windows, and most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be <tt>fgfs</tt> or <tt>flightgear</tt>.)
The official download page is http://www.flightgear.org/download/. Precompiled binaries are available for Windows, and most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be <tt>fgfs</tt> or <tt>flightgear</tt>.)
You can also download using torrents at https://flightgearjp.online/torrents - mainly Mac & Win, but also the large data file used when building from source.


=== How do I install FlightGear on Linux? ===
=== How do I install FlightGear on Linux? ===
Line 150: Line 152:


=== How do I add an airport? ===
=== How do I add an airport? ===
This process includes creating the airport layout in [[WorldEditor]], testing it (you might want to generate part of the scenery, but this is not mandatory) and then, if your data sources are GPL compatible, send it to Robin for inclusion in the shared airport database. The airport will be available in the next full rebuild of the scenery, unless you want to generate your own scenery. More at [[Howto:Make an airport]].
This process includes creating the airport layout in [[WorldEditor]], testing it (you might want to generate part of the scenery, but this is not mandatory) and then, if your data sources are GPL compatible, use [[WorldEditor]] to upload it to the gateway. The airport will be available in the next full rebuild of the scenery, unless you want to generate your own scenery. More at [[Howto:Make an airport]].


=== Can I generate my own scenery? ===
=== Can I generate my own scenery? ===
Line 200: Line 202:


Some will resort to delete the entire <code>$FG_HOME</code> directory or even reinstall FlightGear.  However neither is needed and may cause you to lose any custom preferences you have set up.
Some will resort to delete the entire <code>$FG_HOME</code> directory or even reinstall FlightGear.  However neither is needed and may cause you to lose any custom preferences you have set up.
A further SQLite related problem indicator is the error message
<tt>
  Sqlite error:attempt to write a readonly database (8) while running:
      INSERT OR REPLACE INTO stat_cache (path, stamp) VALUES (?,?)
</tt>
In this case a previously started FlightGear instance might still be running and locking the navdata.cache file. Check for a running fgfs process and terminate it.


=== My aircraft has grey windows? ===
=== My aircraft has grey windows? ===
Line 208: Line 219:
* If you are using an aircraft from one of the [[FlightGear_hangars#Unofficial_sites|3rd party hangars]], it is best to contact the original aircraft author or the person in charge of the 3rd party hangar.
* If you are using an aircraft from one of the [[FlightGear_hangars#Unofficial_sites|3rd party hangars]], it is best to contact the original aircraft author or the person in charge of the 3rd party hangar.
* If you are using [[Project Rembrandt|Rembrandt]], try turning this rendering system off.  Aircraft that use <code>model-default.eff</code> for the windows (at the simple expense of doing nothing) rather than <code>model-transparent.eff</code>, <code>model-combined-transparent.eff</code> or <code>glass.eff</code> (which instruct Rembrandt to not use deferred rendering for the glass) will have grey windows when using Rembrandt.
* If you are using [[Project Rembrandt|Rembrandt]], try turning this rendering system off.  Aircraft that use <code>model-default.eff</code> for the windows (at the simple expense of doing nothing) rather than <code>model-transparent.eff</code>, <code>model-combined-transparent.eff</code> or <code>glass.eff</code> (which instruct Rembrandt to not use deferred rendering for the glass) will have grey windows when using Rembrandt.
=== My screen becomes completely red right after starting FlightGear ===
The red screen is the visualization of the "Redout" effect. If it occurs right after starting FlightGear, it might be caused by a problem with scenery loading. FlightGear loads scenery on the fly and if scenery cannot be loaded, eg. due to network problems, there might be no ground for the aircraft to be located on. As a result, the aircraft falls through the non existing ground starting to tumble. This in turn causes the readout effect. For verifying the problem you should start your flight in KSFO, whose scenery is already included in the base package.


== The FAQ ==
== The FAQ ==
Line 227: Line 241:


=== Content Protection ===
=== Content Protection ===
{{See also|FlightGear Plugins}}
{{See also|FlightGear Plugins}} DRM
{{Cleanup}}
{{Cleanup}}


Line 236: Line 250:
   |date  =  Aug 25th, 2011  
   |date  =  Aug 25th, 2011  
   |added  =  Aug 25th, 2011  
   |added  =  Aug 25th, 2011  
  |script_version = 0.37
  }}</ref><ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=217378#p217378
  |title  =  <nowiki> Encrypted aircraft dynamics </nowiki>
  |author =  <nowiki> Soitanen </nowiki>
  |date  =  Aug 28th, 2014
  |added  =  Aug 28th, 2014
  |script_version = 0.37
  }}</ref><ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34559749/
  |title  =  <nowiki> [Flightgear-devel] External FDM to protect propriety data in a GPL
eviirenment </nowiki>
  |author =  <nowiki> Alan Teeder </nowiki>
  |date  =  Oct 21st, 2015
  |added  =  Oct 21st, 2015
  |script_version = 0.37
  }}</ref>
FlightGear in its current form is a product of numerous people working voluntarily on a joint effort to create an open and extensible flight simulator platform. Your very idea of introducing DRM, is against all principles of open source in general.
You're free to create a non-GPL plane for FG - that's data from the perspective of the sim and doesn't trigger the license. You can sell that without ever allowing to re-distribute the source code. You're required to stay clear of a few things (you can't use Generic instruments, Nasal libs,...) but that should be doable. You can charge license fees for such a plane, and nobody may legally re-distribute it.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>
the data is parsed from the XML into dynamic look up tables (IE. STL).  The only resources used beyond that needed to make the FDM function is the overhead of pulling the data out of the XML into memory.  That would have to happen no matter what form the data was in.
Although there may be better ways to store the data than XML if you are unconcerned about human interaction with the data.  I think that making the data human readable/editable is the main point of using XML.  It may be overly verbose but it works and there are standard libraries for reading/parsing XML files so this makes using it for data input fairly simple.  This benefits both FlightGear and JSBSim in terms of limiting the complexity of handling configuration data.  In addition there are a limited number of standardied formats for this type of thing such as JSON and all of those that are human readable/editable have many of the same issues as XML.
Full function FDMs are complex and understanding the XML used to configure a complex FDM is a very minor issue and anyone who actually understands a full function FDM will have very few issues with the XML part of this.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=217408#p217408
  |title  =  <nowiki> Re: Encrypted aircraft dynamics </nowiki>
  |author =  <nowiki> hvengel </nowiki>
  |date  =  Aug 28th, 2014
  |added  =  Aug 28th, 2014
  |script_version = 0.37
  }}</ref>
FG itself is OpenSource, so whatever protection scheme we may code in, anyone is free to remove (and that's quite legal). It'd be a no-brainer to generate a no-copyright-protection version of FG and distribute it on which your content just runs without the key (or whatever). Given that people usually succeed in cracking DRM schemes in the absence of an open source code, trying to do this with the source code open for anyone seems just a waste of time. Second, whatever format OSG reads, before it arrives at the renderer, it's bound to be an array of vertices. The renderer needs this, there's no decryption at the GLSL stage. So chances are that since we run on *Open*GL, again anyone who really wants can write out an unencrypted format.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>
as FlightGear is open source, it is incredibly simple to add some code to access the 3D scene graph and extract the full aircraft model (scripts excluded, though they could be reverse engineered). The information is just sitting there, fully visible, and ready to be picked off the OSG branch like a big juicy peach. I could probably write this code in half a day, but converting into AC3D format, PNG textures, etc. to recreate a new copy of the aircraft would take a little longer. If FlightGear was closed source, it would be much harder to write OSG extractor code, but nevertheless still doable.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35076297/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  May 10th, 2016
  |added  =  May 10th, 2016
  |script_version = 0.39
  }}</ref>
We have support for catalogs and external hangars for precisely this reason. We obviously want to encourage GPL aircraft, but not every aircraft developer wishes, or is able to, release their work under the GPL. FlightGear both respects and supports that option. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35076199/
  |title  =  <nowiki> Re: [Flightgear-devel] botom line: if i don't my aircraft to be
subject to GPL FGAddon clauses </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  May 10th, 2016
  |added  =  May 10th, 2016
  |script_version = 0.39
  }}</ref>
You could certainly run the FDM model externally and use one of the many Network I/O options in FlightGear to pass data back and forth. Quite a few research projects have done this in the past to use FlightGear as a visualiation tool. By extension you could do the same for scripting - have the scripting run externally and interact with FlightGear via one of these protocols.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35076187/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  May 10th, 2016
  |added  =  May 10th, 2016
  |script_version = 0.39
  }}</ref>
if you actually try to charge 100$ for a FG plane, you won't find too many customers... because FG is mainly popular in the OpenSource community. If you make it too cumbersome with DRM schemes, maybe someone will try to circumvent it just as a matter of principle (people do this for sport...) - but across multiple platforms, it's actually not easy to make this not an annoyance for the user.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
   |script_version = 0.37  
   |script_version = 0.37  
   }}</ref>
   }}</ref>


The thing to keep in mind is that no matter what your source format is (dll, encrypted+signed, binary, etc.), ultimately your model mesh and textures and logical structure are read into internal OSG class structures. Once that has process has completed so the model can be rendered on screen, a person could call the appropriate write*File() function to save out your model's subtree into any of the supported formats. The only thing that is needed is access to the FlightGear source code to insert the function call in a strategic location. Ultimately, you can't completely protect your content work if you don't also completely control the situation at the application source code level. And this is a classic copy protection hacking strategy, insert the magic in the code after the distribution format has been authenticated/loaded/decoded and then write it out in a 'decrypted' format. People do it all the time, even with proprietary code. The value of the target usually determines how hard they are willing to work to steal it.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074534/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.38
  }}</ref>
Adding support for DRM to FlightGear is not going to happen - Nasal scripts are provided in plain text format by default (similar to JavaScript), while obfuscation is of course possible - it doesn't make any sense in the context of FlightGear as an open source project.
Also, scripts can be easily shared and run by users just by exchanging or copying them.
Even if you were to dump intermediate Nasal bytecode to an object file and execute this using the Nasal VM, there would be no way of enforcing DRM.
Of course, FlightGear being open source, you could also just add support for DSOs/plugins to a fork of FlightGear and base all your work on this fork - on the other hand, your modifications would still need to be made available.
there's is a way to make legal closed-source add-ons: You can write all your "secret" c++ as an external application, and let that communicate with FlightGear via sockets. This should work reasonably well. But I don't expect that you'll get many customers. First of all, at least on Linux, nobody is keen to run binary blobs, which could easily wipe out your home directory while you are toying around in FlightGear. And then, there's so much Free aircraft development going on, with a lot of momentum, that you'll probably always be behind. And those developers have close ties to the (or are) FlightGear coders, so they have the advantage that they can change the FlightGear code to their liking, at any time. They can change the interface at will, and you have to catch up ... and deal with customer complaints, who suddenly sit on a broken binary blob that doesn't work with the last FlightGear release. And finally, this socket approach works only via property system, and that's open for inspection to anyone (apart from the recently added semi-secret vector property garbage).


FlightGear has no provision to load aircraft from shared libraries. You can distribute your aircraft under a proprietary license, like Vitos does, but not as a shared library. It would take a lot of work to change FlightGear so it can load aircraft from shared libraries. Who would do that work and why would anyone do that when their time could be spent improving free software? And why would the core developers of FlightGear accept such a "contribution"?<ref>{{cite web
FlightGear has no provision to load aircraft from shared libraries. You can distribute your aircraft under a proprietary license, like Vitos does, but not as a shared library. It would take a lot of work to change FlightGear so it can load aircraft from shared libraries. Who would do that work and why would anyone do that when their time could be spent improving free software? And why would the core developers of FlightGear accept such a "contribution"?<ref>{{cite web
Line 310: Line 437:
   |date  =  May 9th, 2016  
   |date  =  May 9th, 2016  
   |added  =  May 9th, 2016  
   |added  =  May 9th, 2016  
  |script_version = 0.37
  }}</ref>
The key for an open source project is not if you can win a legal argument or not. Rather, it is to avoid any legal argument in the first place, and at all costs. Meaning  to stay out of court. To use something like this safely in an open source project, I would suggest something along the following lines:
* Making your derivative product public, in full (but unlicensed, saying it is copyrighted material),
* Going to the owners of the original data product, giving them a link to your derivative product,
* Asking them to make a public statement that the derivative product can be licensed using the "GPLv2 or later version" licence,
* Make sure to ask them to identify the public derivative product as a link, and identify all its parts (to avoid them saying at a later date that you included bits of the protected material),
Any statement they make on the web can be backed up on the web archive ( http://web.archive.org/ ). To simplify the process, you could draft part of the statement detailing the derivative product in full, with all details. With this, there will no longer be any shades of grey! If they are happy to do this, then it is legally no problem to use (i.e. the grey situation has shifted to white). If they are not happy with your proposal, then they could turn around one day and sue (i.e. the grey situation has shifted to a clear black).<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34561220/
  |title  =  <nowiki> Re: [Flightgear-devel] External FDM to protect propriety data in a
GPL eviirenment </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Oct 22nd, 2015
  |added  =  Oct 22nd, 2015
  |script_version = 0.37
  }}</ref>
The open-source world depends on license terms and copyrights and cooperation and trust to protect our work. We put up with a small subset of people who willing abuse those terms and hope that larger group peer pressure will keep the bad actors in check. Sometimes there is legal recourse, sometimes it is tough to do anything about it when problems span country boundaries (or when someone just wants to break the rules for their own self serving reasons.) My feeling though is in the long term, most people are honest and do wish to do the right thing, and the small group that is truly there to cause problems or just serve themselves at the expense of others will never endure as long as the larger group of people with good intentions. In the end, you have to make your own determination of how much effort you put into a model, versus how much money you could make selling it, versus the risk of someone copying and distributing it themselves, versus the legal costs to try to stop them.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074534/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.38
  }}</ref>
=== DRM workarounds ===
For one of my past projects I had to deal with a proprietary flight dynamics model. I initially used the ethernet interface so it could run as an external stand alone application. Then later I switched to a unix two-way pipe arrangement so I could have tighter synchroniation with the execution order, but still the external program was completely independent and stand alone. I'd love to make everything free and open-source, but this was a case where I didn't have a choice and it was something purchased from a 3rd party company with strict terms. I felt that two independent self sufficient programs (that could talk to each other and exchange information) created sufficient license separation to honor FlightGear's gpl license terms. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34559783/
  |title  =  <nowiki> Re: [Flightgear-devel] External FDM to protect propriety data in a
GPL eviirenment </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  Oct 21st, 2015
  |added  =  Oct 21st, 2015
  |script_version = 0.37
  }}</ref>
For what it's worth, the "ExternalPipe" fdm was setup to cover much of the areas you have touched on. It's probably not exactly what you want but here was some of my logic in how/why I setup it up the way I did.
* Using a network interface adds some indeterminism ... sometimes network packets are delayed or stack up depending on what is going on with the machine so there isn't a guaranteed lockstep relationship between the simulator the the flight dynamics.
* Usually the network interface is good, but I observed times when it had extra delays in packets getting where they needed to go. * As an alternative, I setup a pair of "named pipes". Pipes are a unix construct, they look like a file to the program, but what you write into them is collected and held for some other application to read out. Unfortunately these are not supported in windows. Pipes are single direction, thus the need for two of them for bi-directional communication. A pipe is really simple: you open it up like any other file, and one process writes into it; the other process reads from it. In between the OS can buffer some amount of information until the reader grabs it. You can use blocking reads (carefully) to ensure FlightGear and your external FDM run in exact lockstep.
* Pipes imply both processes will run on the same machine, a network interface would allow the processes to live on separate machines. - The ExternalPipe interface supports a flexible property interface, so the external FDM process can send any name/value pairs it wishes to send and the interface will dutifully copy them into the FlightGear property tree. The FDM side can also send a list of property names it would like to receive in reply and the interface will dutifully send them over the outgoing pipe every frame. This was a nice addition, and there is plenty of bandwidth through a named pipe to do this in clear text, even with a lot of extra property values. History: I used this as part of a project I did with ATC flight sim. They had their own proprietary flight dynamics applications that modeled specific aircraft in the code itself. These models had all the necessary source documentation and flight test data to satisfy FAA certification testing requirements of the final simulator. In addition, this external code modelled many of the aircraft systems for one of their high end sims. This required the ability to be flexible in what values were sent back and forth and enabled me to drive some instrument gauges directly from the external code.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/31900851/
  |title  =  <nowiki> Re: [Flightgear-devel] Feeding FlightGear data through the Protocol
Pipe </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  Jan 29th, 2014
  |added  =  Jan 29th, 2014
   |script_version = 0.37  
   |script_version = 0.37  
   }}</ref>
   }}</ref>
Line 321: Line 500:
[[it:Domande frequenti]]
[[it:Domande frequenti]]
[[ja:FAQ]]
[[ja:FAQ]]
[[nl:veel gestelde vragen]]
[[pl:FAQ]]
[[pl:FAQ]]
[[pt:FAQ]]
[[pt:FAQ]]
Fstltna
7

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/98015...111501"