20,741
edits
Frequently asked questions: Difference between revisions
Jump to navigation
Jump to search
→Content Protection
| Line 381: | Line 381: | ||
|date = May 9th, 2016 | |date = May 9th, 2016 | ||
|added = May 9th, 2016 | |added = May 9th, 2016 | ||
|script_version = 0.37 | |||
}}</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> | ||