Linguofreak
Well-known member
This isn't about OVP per se, but related, as it deals with the Physics Engine/Graphics client split.
Time and again, people will request features such as non-metric units or Linux support that Martin has made clear aren't on his priority list or in his skill set. Might it be possible for the community to write physics engines that will work with the same graphics clients (OGLAclient, etc.), and implement the Orbiter API, but be based on totally different code (since the code for the standard core is closed source)?
This would especially make sense for Linux, as there exists a graphics client that runs on Linux (OGLAclient), but the Orbiter core is heavily dependent on Microsoft libraries and doesn't work well under Wine. It would be nice to have a core (even a simple and underfeatured one) that would run natively on Linux and interface with OGLAclient.
Some thoughts on such alternate engines:
1. The biggest use I can see for such engines, as implied above, is cross-platform support for Orbiter. They need not, however, be limited to this, and could also be used for implementing features that Martin does not plan to implement.
2. They need not be Orbiter engines, per se. I could imagine that someone might wish to use an OVP graphics client for another sim or game.
3. They can use whatever source model the designers wish, but I would recommend they be open source, but not GPL. Martin may (or may not) at some point wish to use code from such an engine in the primary Orbiter core, but to be able to do so, he must first be free to use that code (open source), and second, because his own engine is closed source, he must be able to use that code without open sourcing his engine (and thus alternate clients should not be GPL, since GPL would carry that obligation).
Time and again, people will request features such as non-metric units or Linux support that Martin has made clear aren't on his priority list or in his skill set. Might it be possible for the community to write physics engines that will work with the same graphics clients (OGLAclient, etc.), and implement the Orbiter API, but be based on totally different code (since the code for the standard core is closed source)?
This would especially make sense for Linux, as there exists a graphics client that runs on Linux (OGLAclient), but the Orbiter core is heavily dependent on Microsoft libraries and doesn't work well under Wine. It would be nice to have a core (even a simple and underfeatured one) that would run natively on Linux and interface with OGLAclient.
Some thoughts on such alternate engines:
1. The biggest use I can see for such engines, as implied above, is cross-platform support for Orbiter. They need not, however, be limited to this, and could also be used for implementing features that Martin does not plan to implement.
2. They need not be Orbiter engines, per se. I could imagine that someone might wish to use an OVP graphics client for another sim or game.
3. They can use whatever source model the designers wish, but I would recommend they be open source, but not GPL. Martin may (or may not) at some point wish to use code from such an engine in the primary Orbiter core, but to be able to do so, he must first be free to use that code (open source), and second, because his own engine is closed source, he must be able to use that code without open sourcing his engine (and thus alternate clients should not be GPL, since GPL would carry that obligation).
