Orbiter Space Flight Simulator 现已开源

您使用的是过时的浏览器。它可能无法正确显示此网站或其他网站。您应该升级或使用其他浏览器。已经有一段时间了……亲爱的 Orbiter 用户和开发人员，我已经有一段时间没有来过这个地方了，而且由于个人原因，几年来一直无法推动 Orbiter 的开发。为了让 Orbiter 保持活力并允许其他人使用它，我决定在开源许可下发布源代码：Orbiter Space Flight Simulator 的开源存储库 - GitHub - mschweiger/orbiter：Orbiter Space 的开源存储库飞行模拟器 这本质上是 2016 版，有一些小（和至少一个主要）修复。我希望这对某人有用。代码有点杂乱无章，文档也很少，但它应该可以编译并为您提供一个可以运行的 Orbiter 安装。请注意，存储库不包含所有必需的行星纹理，因此您需要单独安装它们（例如，通过重用现有的 Orbiter 2016 安装 - 这在自述文件中进行了解释，并且只需要在配置构建之前设置 CMake 选项）。我仍然希望在 Orbiter 的未来增强方面工作，但我不能做出任何承诺或承诺。最紧迫的问题之一是将代码切换到 64 位，但这需要放弃对 DX7 的依赖（最好用 DX11 替换它），但这是一项重大任务，我可能会也可能不会这样做）。请让我知道任何编译问题或存储库的任何其他问题，在这里或通过在 github 上提出问题。我也很乐意考虑合并请求。快乐编码！嘿，很高兴再次见到你！这是相当多的消息，我很高兴看到这将为 Orbiter 的未来带来什么！我们真的是时候完成新的 OHM 了 ^^ 感谢分享并保重！嗨马丁！很高兴见到你，即使是在这种有限的意义上！感谢您打开源代码。希望这将使 Orbiter 能够继续成长和发展，即使个人生活变得更加复杂和难以管理！ * 创建 github 帐户 *... 好，几天后首先，欢迎回来，谢谢！我的时间很短，但我相信我会找到一些贡献。那么，这是在 svn 存储库中的 r90 上构建的还是更早的分支？另外，未来的版本将如何处理？您能否在 Github 上创建一个项目以迁移到 x64 和 DX11？然后，将与此相关的问题进行分组并对要完成的工作进行排序会更容易。我完全赞成采用非常保守的方法来扩展 Orbiter，但迁移到 x64 也可能会破坏一些较旧的附加组件。在这种情况下，开源方法可能非常适合确保附加开发人员的声音被听到并且可以为下一代 API 做出贡献。

之前OF版本贴的Orbiter门票能不能插入github？您能否在 Github 上创建一个项目以迁移到 x64 和 DX11？然后，将与此相关的问题进行分组并对要完成的工作进行排序会更容易。我完全赞成采用非常保守的方法来扩展 Orbiter，但迁移到 x64 也可能会破坏一些较旧的附加组件。在这种情况下，开源方法可能非常适合确保附加开发人员的声音被听到并且可以为下一代 API 做出贡献。分行不行吗？ github 中的“票证”似乎非常灵活，一个分支将防止将来出现“版本分裂”，人们将继续使用 32b 版本而不是转移到 64b。 OF中用于一般性讨论的专用线程确实有意义。哦，马丁斯，这对个人来说是一个非常悲伤的消息，因为您在创建和维护轨道飞行器方面做得非常出色。您在与我们比较僵尸打交道时的谦逊非常出色。非常感谢！对未来的美好祝愿。我希望您能解决困扰您的任何问题，并期待在可能的时候见到您。我已经有很长一段时间没有来过这个地方了，而且由于个人原因，几年来一直无法推动 Orbiter 的开发。为了让 Orbiter 保持活力并允许其他人使用它，我决定在开源许可下发布源代码：Orbiter Space Flight Simulator 的开源存储库 - GitHub - mschweiger/orbiter：Orbiter Space 的开源存储库飞行模拟器 令人难以置信的消息！非常感谢你，马丁！我希望你和你的亲人在这几天里一切都好，身体健康，无论是什么个人原因，我都祝你现在和未来一切都好。所以我将能够在未来几年继续改进库鲁航天中心（和法属圭亚那）。非常感谢您这些年来与 Orbiter Martin 一起度过的快乐时光！很高兴看到你回到这里。鉴于世界现状，我希望一切都好。毫无疑问，Orbiter 对几代模拟器用户和开发人员产生了深远的影响。我完全支持转向开源。我非常尊重和钦佩您在过去 21 多年里对轨道飞行器发展愿景的奉献，我希望这种情况可以继续下去。谢谢你。

之前OF版本贴的Orbiter门票能不能插入github？分行不行吗？ github 中的“票证”似乎非常灵活，一个分支将防止将来出现“版本分裂”，人们将继续使用 32b 版本而不是转移到 64b。 OF中用于一般性讨论的专用线程确实有意义。嗯，我认为今天没有什么理由继续留在 x86 架构上并绑定到 Windows 和模拟器的遗留子系统。但是可以肯定的是，如果有人可以维护它，那么拥有一个 x86 分支就可以了。如果我们的人力和承诺有限，一个分支就够难了。我想，我宁愿支持马丁斯的愿望。嗯，我认为今天没有什么理由继续留在 x86 架构上并绑定到 Windows 和模拟器的遗留子系统。但是当然，如​​果有人可以维护它，那么拥有一个 x86 分支就可以了。如果我们的人力和承诺有限，一个分支就够难了。我想，我宁愿支持马丁斯的愿望。 Orbiter 2016 及更早版本可以作为旧版 x86 Orbiter。一路64位，为了以后，同意。嗯，我认为今天没有什么理由继续留在 x86 架构上并绑定到 Windows 和模拟器的遗留子系统。但是可以肯定的是，如果有人可以维护它，那么拥有一个 x86 分支就可以了。如果我们的人力和承诺有限，一个分支就够难了。我想，我宁愿支持马丁斯的愿望。我认为你让我倒退了：我认为如果 64b 开发是在一个新项目中进行的，正如你所建议的那样，它会允许“2 个轨道飞行器”存在（这是不好的 IMO）。将 Orbiter 保持在一个屋檐下，并在一个分支中完成 64b 工作，最终合并到主干/主并成为标准，这是 IMO 的方式。一直到合并都会有 32b 支持，并且可以在合并之前发送“最后的 32b 版本”作为发送。我认为你让我倒退了：我认为如果 64b 开发是在一个新项目中进行的，正如你所建议的那样，它会允许“2 个轨道飞行器”存在（这是不好的 IMO）。将 Orbiter 保持在一个屋檐下，并在一个分支中完成 64b 工作，最终合并到主干/主并成为标准，这是 IMO 的方式。一直到合并都会有 32b 支持，并且可以在合并之前发送“最后的 32b 版本”作为发送。

我想你误解了项目这个词。在 github 中，您可以将多个问题、功能、用户故事等分组到一个总体项目中，以跟踪它并为工作分配一些优先级。这与分支或分叉不同，它只是一种跟踪事物的方式——通往 x64 的道路将是复杂的，沿途会发现许多复杂的问题并需要解决。为此，一个项目可以更容易地发现该目标存在哪些任务以及整个项目的位置。它看起来几乎是r90。对于 API（以某种方式定义版本），它是 r90，除了 Lua 更改和 GraphicsAPI.h 中的一个新方法： class OAPIFUNC GraphicsClient: public Module { // ... bool PlanetTexturePath(const char* Planetname, char* 路径) const; // ... 所以也许更像 Orbiter 2016-P1