Radical2638 Posted January 24, 2022 Share Posted January 24, 2022 (edited) 6 hours ago, eberkain said: i see the same, the suggestion i got was either setup a kos script or do burns manually. The odd thing is I had a kOS script that I found on Reddit called "burner" that I was trying to use, but it just isn't working. It just isn't picking up some variable due to principia being installed I guess? Edited January 24, 2022 by Radical2638 Quote Link to comment Share on other sites More sharing options...
scimas Posted January 24, 2022 Share Posted January 24, 2022 15 hours ago, Radical2638 said: The odd thing is I had a kOS script that I found on Reddit called "burner" that I was trying to use, but it just isn't working. It just isn't picking up some variable due to principia being installed I guess? Principia does not mess with what is available to other mods. If you're using a random script you found somewhere on the internet, you need to understand what it is doing and what it is expecting. As for mechjeb not working, and the node disappearing before the burn is over: Principia's flight planner is just that, a planner. It does not help you execute a burn. The timings and predictions shown there are ideal cases - they assume you execute the burn perfectly. If mechjeb (or anything else) is not starting and ending the burn at the exact moments, or if something else like thrust variation, spool up time etc implemented by RO is messing with the engine thrust, Principia is not going to take that into account. You have to take care of that yourself. Quote Link to comment Share on other sites More sharing options...
Radical2638 Posted January 25, 2022 Share Posted January 25, 2022 9 hours ago, scimas said: Principia does not mess with what is available to other mods. If you're using a random script you found somewhere on the internet, you need to understand what it is doing and what it is expecting. As for mechjeb not working, and the node disappearing before the burn is over: Principia's flight planner is just that, a planner. It does not help you execute a burn. The timings and predictions shown there are ideal cases - they assume you execute the burn perfectly. If mechjeb (or anything else) is not starting and ending the burn at the exact moments, or if something else like thrust variation, spool up time etc implemented by RO is messing with the engine thrust, Principia is not going to take that into account. You have to take care of that yourself. First of all, I'm not using RO, I have no idea where you got that from. Second, it's giving me a timing, and the timing works. The issue (or if it isn't an issue, sure, whatever) is that it starts counting down normally and then out of nowhere spazzes out along with the navball itself. I didn't have this happen to me the last time I had an install that uses principia. I am well aware that it doesn't help me execute it - I just haven't encountered the node disappearing, the UI spazzing out, or the other factors before this install, to the best of my recollection. Mechjeb is also not just burning late - it isn't burning AT ALL. Quote Link to comment Share on other sites More sharing options...
Skywavestar Posted January 28, 2022 Share Posted January 28, 2022 On 2014/2/5 at AM8点19分, eggrobin said: 源代码在MIT 许可下 可在 GitHub 上获得。 抽象的 这个模组旨在用高阶辛积分器代替 KSP 不稳定的物理积分，在这个过程中加入n体牛顿引力。 首字母缩略词 揭示隐藏内容 ACS: Attitude Control System AMD: Advanced Micro Devices AMP: Accelerated Massive Parallelism ARG: Ada Rapporteur Group API: Application Programming Interface BIPM: Bureau International des Poids et Mesures CR3BP: Circular-Restricted 3-Body Problem CGPM: Conférence Générale des Poids et Mesures CIPM: Comité International des Poids et Mesures CIL: Common Intermediate Language CLI: Common Language Infrastructure CLR: Common Language Runtime CLS: Common Language Specification CPU: Central Processing Unit CRTP: Curiously Recurring Template Pattern CTS: Common Type System DFT: Discrete Fourier Transform DLL: Dynamic-Link Library ER3BP: Elliptic-Restricted 3-Body Problem ETHZ: Eidgenössische Technische Hochschule Zürich EVA: Extra-Vehicular Activity FAQ: Frequently Asked Questions FAR: Ferram Aerospace Research FFT: Fast Fourier Transform FMM: Fast Multipole Method FPU: Floating-Point Unit FSAL: First Same As Last GPGPU: General-Purpose Computing on Graphics Processing Units GPU: Graphics Processing Unit GR: General Relativity ICC: Intel C++ Compiler IDE: Integrated Development Environment IEEE: Institute of Electrical and Electronics Engineers IMCCE: Institut de Mécanique Céleste et de Calcul des Éphémérides IRC: Internet Relay Chat JPL: Jet Propulsion Laboratory KSO: Kerbin-Synchronous Orbit KSP: Kerbal Space Program LKO: Low Kerbin Orbit MET: Mission Elapsed Time MIT: Massachusetts Institute of Technology NASA: National Aeronautics and Space Administration OBE: Overcome By Events ODE: Ordinary Differential Equation OP: Original Post PDF: Portable Document Format PFCE: PlanetFactory Creator Edition PGO: Profile-Guided Optimization PSA: Public Service Announcement RCS: Reaction Control System RHS: Right-Hand Side RK: Runge-Kutta RSS: Real Solar System RT2: RemoteTech 2 SAS: Stability Augmentation System SI: Système International SIMD: Single Instruction, Multiple Data SOI: Sphere Of Influence SPRK: Symplectic Partitioned Runge-Kutta SSE: Streaming SIMD Extensions VB: Visual Basic VS2013: Visual Studio 2013 WIP: Work In Progress 文档和下载 Principia 的构建方式与大多数其他 mod 不同（大部分是本地代码，具有薄 C# 接口层），因此可能会出现兼容性问题，具体取决于平台。 二进制文件可用于 Windows、Linux（建立在 Ubuntu 上，在其他发行版上使用这些文件时，您的里程可能会有所不同）和 Macintosh（感谢 @吉姆·迪格里兹）。请注意，该模组仅适用于 64 位版本的 KSP。 请仔细阅读详细介绍这些概念的 wiki 页面；使用principia 时，很多事情的行为都会有所不同，特别是地图视图和飞行计划。mod的许多方面尚未完成，该页面上对此进行了详细说明。 此外，请阅读 常见问题解答和错误报告指南。请注意，由于我们的自定义日志系统、致命故障的使用以及我们的日志系统（如果激活，允许我们重播导致崩溃的事件以供以后调试） ，错误报告程序与其他 mod 的程序有很大不同. 一个教程是关于以各种方式去 Mun的主题，应用上述概念。还有一个低轨道会合指南，应该有助于理解目标 LVLH 框架。 由于原理根据牛顿万有引力使所有物体相互吸引，因此太阳系的稳定性是一个问题。当使用股票 KSP 时，Principia 修改了 Jool 系统，使其稳定。使用定制系统（例如使用 Kopernicus）时，您需要确保系统稳定。 如果您想提问，您可以在 EsperNet 上的#principia IRC 频道、KSP - RO Discord上的#principia 频道或#principia:matrix.mockingbirdnest.com 上提问。您的疑虑可能会比在论坛上更快地得到解决（但请记住，并非总是有人可以立即回答您的问题；如果周围没有人，您可能希望在频道上停留一段时间尽管）。 下载二进制文件（Macintosh、Ubuntu 和 Windows）： Principia Hardy 用于 1.8.1、1.9.1、1.10.1、1.11.0–2 和 1.12.2；或来自腾讯微云： Principia Hardy 用于 1.8.1、1.9.1、1.10.1、1.11.0–2 和 1.12.2。 或者，如果您不信任我们的二进制文件，请从 Hardy 版本构建 mod。 我们提供补丁转 @GregroxMun的 SLIPPIST-1 进入 TRAPPIST-1 系统；请参阅安装说明。 地位 日期是 ISO 8601 扩展格式。 2021-12-03 对于新月（月球编号 272），新版本（哈代）已经发布。 增加了俄语本地化；谢谢@冯克尔曼 贡献翻译并回答了关于俄语语法的层出不穷的问题。 已修复一个问题，如果现役船只处于低空，该问题会导致绘图框架中的摄像机旋转缓慢。 修复了自 KSP 启动后在未显示 UI 的情况下绘制轨迹时发生的崩溃问题。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-12-04 对于新月（月球编号 271），新版本（汉密尔顿）已经发布。 修复了导致视觉异常的内存泄漏； 文本密集型窗口的性能问题，特别是参考帧选择器，已得到修复。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-11-04 对于新月（月数 270），新版本（哈雷）已经发布。 这次没有什么新鲜事；我们一直在努力改变船只轨迹的内部表示，但这还没有准备好。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-10-06 对于新月（月球编号 269），新版本（Hadamard）已发布。 报告的一些错误 @贝拉邦 和@lpgagnon 已修复。 持续时间解析器稍微宽松一点。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-09-07 对于新月（月数 268），新版本 ( Haar ) 已发布。 参考帧选择器已经过改进以占用更少的空间，允许在任意帧之间更快地切换，并更好地解释各种帧的使用。谢谢@Al2Me6 用于将新 UI 翻译为 zh-CN，并向 @Zaikarion寻求语言帮助。 添加了特定于天体的术语（近地点而不是地球近点，月球轨道而不是月球轨道等）。 Principia 已本地化为法语。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-08-08 对于新月（新月号 267），新版本（格洛腾迪克）已经发布。 添加了对 KSP 1.12.2 的支持。 保存兼容性错误已得到修复。使用 Cardano 或更高版本创建的保存现在应该是可读的。 中文翻译中的一个术语错误已得到纠正。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-07-10 对于新月（月数 266），新版本（格罗斯曼 ) 已发布，修复了由@Flibble 和@Al2Me6. 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-06-10 对于新月（月球编号 265），新版本 ( Gröbner ) 已发布。 它解决了#2400 的一部分，即在没有船只的情况下，场景变化与 1951 年相差甚远。这意味着@scimas的自定义初始状态 不再需要后期启动游戏。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-05-11 对于新月（月球编号 264），新版本（绿色）已发布，修复了一些错误（两次崩溃和暂时但可能很长时间的冻结）。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-04-12 对于新月（月球编号 263），新版本（Grassmann）已经发布。 添加了对 KSP 1.11.2 的支持。 覆盖版本检查以便在我们支持新版本之前尝试新版本的机制已记录在案。请注意，使用此覆盖时将不提供支持。 中文版中部分字符串未翻译；这已得到修复。感谢@WC12366的贡献。 导致内存使用量稳步增加直至内存不足 ( #2919 ) 的错误，由报告@Al2Me6 和@hxl11211， 已修复。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-03-13 对于新月（月球编号 262），新版本（哥德巴赫）已经发布。 性能得到了显着提升，尤其是在 macOS 上。感谢@rnlahaye的这一重大贡献。 发现的一个错误@Robot_V1，这影响了一些飞机的处理，是固定的。 中文本地化得到改进。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-02-11 对于新月（月球编号 261），新版本（哥德尔）已经发布。 添加了对 KSP 1.11.1 的支持。 Principia 已本地化为简体中文。谢谢@CindyRing 感谢这一重大贡献，感谢@Zaikarion 帮助解决语言问题。 一些导致崩溃的错误已得到修复。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2021-01-13 对于新月（月数 260），新版本（日耳曼）已经发布。 添加了对 KSP 1.11.0 的支持。 最终轨迹的轨道分析现在可以在飞行计划中使用，从而可以计划准确的轨道插入和修正。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-12-14 对于月全食 的新月（月数 259），新版本 ( Гельфонд ) 已发布。 轨道分析器现在提供当前轨道的简短描述，例如“高度偏心半同步”。地球轨道”。 现在可以配置轨迹颜色，这要归功于 @Flibble （#2816）。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-11-15 对于新月（月数 258），新版本 ( Гельфанд ) 已发布。 由于@rnlahaye 的贡献，基于轨迹迭代的操作性能得到了改进 。 有关更多详细信息，请参阅 更改日志 。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-10-16 对于新月（月球编号 257），新版本（高斯）已发布。 修复了零件爆炸时偶尔会导致崩溃的错误 ( #2716 )。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-09-17 对于新月（月球编号 256），新版本 ( Gateaux ) 已发布。 添加了对 1.10.1 的支持。请注意，在彗星存在的情况下，Principia 的行为很难测试；邀请在彗星出现时遇到问题的用户报告错误。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-08-19 对于新月（月球编号 255），新版本（伽罗瓦）已经发布。 现在可以在飞行计划中插入和删除机动；特别是，这使得可以在变基后插入校正操作。 机动可以折叠和扩展，从而更容易管理具有许多机动的飞行计划。 计划RCS时涉及不正确推力的错误机动谢谢@Flibble 贡献此修复程序。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-07-20 对于新月（月球编号 254），新版本（Gallai）已经发布。 如前所述，此版本不支持 KSP 1.7.3 及更早版本。 飞行计划中添加了一个rebase按钮，可以将实际轨迹的更改考虑在内，而无需重新创建飞行计划。 与高度相关的信息已添加到轨道分析器中。 一些错误已得到解决：EVA 碰撞导致荒谬的运动、EVA 降落伞被破坏、船只以荒谬的速度解体、船只在脱离亚空间时变形。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-06-21 对于新月（月球编号 253），新版本（伽利略）已经发布。 其他 KSP 模组的外部 API 引发的异常现在包含一条错误消息。 其他错误已得到修复（最值得注意的是，现在考虑了质心偏移）。 有关更多详细信息，请参阅 更改日志 。 我们支持两组 KSP 版本：可下载 1.9.1 和 1.8.1，以及 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 这是支持 KSP 1.5.1、1.6.1 和 1.7.x 的最后一个版本，因为 Realism Overhaul 和 Real Solar System 现在支持 1.8.1。 2020-05-22 对于新月（月球编号 252），新版本（Fuchs）已经发布。 Frobenius 和 Fubini 中引入的旋转问题（不受控制的旋转、急动、振荡等）在很大程度上已得到解决。我们知道剩下的一个异常旋转案例，由@scimas，但目前这似乎是一个非常罕见的问题。 在点火之前，导航球上用于引导燃烧的操作节点标记现在指向点火方向，而不是遵循当前的 Frenet 框架。这对于手动燃烧更有用（航天器可以在点火之前正确定位，而不是在机动开始之前就必须引导）。或许更重要的是，结合更改 MuMech/MechJeb2#1264 （在 MechJeb 开发版本 ≥ 958 中可用），这意味着 MechJeb 可以执行所有 Principia 操作。 添加了新的 API 供以下用户使用@莫蒂默爵士的 KerbalismContracts。 有关更多详细信息，请参阅 更改日志 。 我们支持两组 KSP 版本：可下载 1.9.1 和 1.8.1，以及 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 这是支持 KSP 1.5.1、1.6.1 和 1.7.x 的最后一个版本，因为 Realism Overhaul 和 Real Solar System 现在支持 1.8.1。 2020-04-23 对于新月（月数 251），新版本（Fubini）已经发布。 添加了对 1.9.1 的支持。 飞行计划和轨道分析窗口现在可在跟踪站中使用，与地图视图保持一致。 已进行一些更改以缓解上述问题 #2519。疯狂的旋转似乎不再是一个问题，但是在某些情况下会出现一些意想不到的振荡。我们将继续调查这个问题。 一些会导致崩溃的问题已得到解决。 有关更多详细信息，请参阅 更改日志 。 我们支持两组 KSP 版本：可下载 1.9.1 和 1.8.1，以及 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-03-24 对于新月（月数 250），新版本（Frobenius）已经发布。 经过近一年的工作和96 个拉取请求，Principia 现在强制执行角动量守恒，正如前面提到的那样。 除其他外，这意味着： 长期存在的错误#1639，由报告@Damien212 2017 年，解决了船舶在进行 SoI过渡时改变方向的问题； 血管将按照欧拉方程在时间扭曲中作为刚体旋转；特别是它们可能会在时间扭曲中表现出Джанибеков 效应，如下面的短视频所示； 容器内质量分布的变化，例如由于燃料转移，将影响角速度，如下面的短视频所示。 有关更多详细信息，请参阅更改日志 。 我们支持两组 KSP 版本：可下载 1.8.1 和 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-02-23 对于新月（月球编号 249），新版本（Frenet）已发布。 这次没有什么新鲜事；我们一直在努力保持角动量，但还没有完全准备好。 有关更多详细信息，请参阅更改日志 。 我们支持两组 KSP 版本：可下载 1.8.1 和 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2020-01-24 对于新月（月 数 248），新版本（弗雷格）已经发布。 天体历史现在按照过去的要求显示（如果有的话），而不是仅限于发射时间。 杂项错误已得到修复（也许最明显的是，Fréchet 中引入的暂停菜单中的狂野相机旋转）。 有关详细信息，请参阅更改日志；特别注意显示菜单时地图视图相机旋转的已知问题。 我们支持两组 KSP 版本：可下载 1.8.1 和 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-12-26 对于新月（月球编号 247），新版本 ( Fréchet ) 已发布。 添加了对 KSP 1.8.1 的支持 。 相机在地图视图和跟踪站中定向，以便水平面是所选绘图框架的参考平面。此外，相机随着标绘框旋转，使得标绘的轨迹不会随着时间的流逝而旋转。 有关详细信息，请参阅更改日志；特别注意显示菜单时地图视图相机旋转的已知问题。 我们支持两组 KSP 版本：可下载 1.8.1 和 1.5.1、1.6.1、1.7.x。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-11-26 对于新月（月数 246），新版本（פרנקל）已经发布。 Principia 现在绘制天体的轨迹。这关闭了一个古老的功能请求（#942，2016年 3 月），并建立在许多干预工作的基础上；特别是，这是基于在 Чебышёв（2017 年 8 月）中引入的船舶轨迹绘制方法。 历史长度设置现在隐藏历史而不是忘记它；这意味着您可以在视觉上分散注意力时缩短历史记录，同时在您想要概览您的任务时保留将它们带回的能力。它还使用 Principia UI 中其他地方使用的相同持续时间格式和选择器，而不是科学计数法中的秒。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-10-28 对于新月（月球编号 245），新版本（傅立叶）已发布。 涉及飞行计划版本的两起坠机事故（由@Neph) 已修复。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从谷歌驱动器或腾讯微云下载 2019-09-28 对于新月（月数 244），新版本（斐波那契）已经发布。 添加了一个轨道分析工具，用于计算平均元素和轨道递归属性。自二月以来一直在进行这项工作；稍后将添加更多功能，例如上升节点的平均太阳时间（用于控制太阳同步性）。请参阅下面的轨道分析工具在 Молния 轨道上运行的屏幕截图。该工具相当复杂；文档将很快提供。 报告的崩溃 @延迟 已修复。 一个会阻止 Principia 启动的依赖问题已得到修复。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-08-30 对于新月（月球编号 243），新版本 ( del Ferro ) 已发布。 为水星、金星、火星、木星、土星、天王星和海王星添加了更高阶和阶的重力模型；这些行星的卫星现在将具有更逼真的运动（此更改仅对新的保存生效） 报告的一些错误 @莫蒂默爵士,@scimas， 和@科比丸 已修复。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-08-01 对于新月（月球编号 242），新版本（法拉利）已经发布。 添加了对 KSP 1.7.3 的支持。 报告的一些错误 @scimas 已修复。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-07-02 对于新月（月球编号 241），新版本（费马）已经发布。 增加了对 KSP 1.7.1 和 1.7.2 的支持；如前所述，此版本不支持 KSP 1.3.1 和 1.4.x。 一个长期存在的功能请求（#1936，由 @王小谦同学) 已解决：可以编辑飞行计划的所有机动，而不仅仅是最后一个。 机动现在将推力限制器考虑在内（#2128，由@Kinexity）。 有关更多详细信息，请参阅更改日志。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-06-03 对于新月（月数 240），新版本（发头）已经发布。 添加了对 KSP 1.7.0 的支持。请注意，1.7.1 是在我们构建版本之后发布的，因此不支持。另请注意，我们对新的轨道信息显示没有特别支持，因此，就像 MechJeb 或 Kerbal Engineer Redux 一样，它将显示当前大部分无用的密切元素，而不是某些适当理论的平均元素。此外，请注意我们对新的机动节点编辑器没有特别支持，因此它可能无法使用。 这是支持 KSP 1.3.1 和 1.4.x 的最后一个版本，因为 Realism Overhaul 和 Real Solar System 现在支持 1.6.1。下一个版本将仅支持 1.5.1 及更高版本。 现在，如果中心体足够靠近，则在以体为中心、以体固定的坐标系中以及以体为中心的惯性坐标系中相对于赤道显示上升和下降节点（#1841）。 Fáry 中的 UI 更改以及 Fano 中 UI 代码的底层重组过程中引入的许多错误已得到修复。 有关更多详细信息，请参阅更改日志。 我们感谢@奇迹魔术师 用于报告本版本中会引入的严重错误。 我们支持两组 KSP 版本：可下载 1.4.x、1.5.1、1.6.1、1.7.0 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 为了方便我们的中国用户，二进制文件可以从 Google Drive 或腾讯微云下载。 2019-05-04 对于新月（月球编号 239），新版本 ( Fáry ) 已发布。 UI 现在根据 KSP UI 缩放设置进行缩放，并且变得更加紧凑； 那些由滑块控制的飞行计划设置现在也可以通过文本输入进行编辑（这包括 Δv 分量和机动时间）； TRAPPIST-1 补丁已更新为@GregroxMun的 SLIPPIST-1 v0.7.x。 有关更多详细信息，请参阅更改日志。 我们支持两组 KSP 版本：可下载 1.4.x、1.5.1 和 1.6.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2019-04-05 对于新月（月数 238），新版本 ( Fano ) 已发布。 预测现在是异步计算的，使得长预测可用；这在具有复杂重力模型的物体附近尤其明显，例如RSS中的地球和月球。 一些涉及地图视图标记的错误已得到修复。 有关更多详细信息，请参阅更改日志。 我们支持两组 KSP 版本：可下载 1.4.x、1.5.1 和 1.6.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2019-03-06新月（月数237），新版本（欧拉）出来了。 在Erdős中引入的 问题 #2072已解决，该问题表现为在 RealSolarSystem 中不受降落伞或 8.4 m 高度以下发动机影响的自由落体（导致粗暴的溅落）。 添加了一个 API 以允许 @吉姆·迪格里兹访问位势系数的指导算法；见#2074。 有关更多详细信息，请参阅更改日志。 我们支持两组 KSP 版本：可下载 1.4.x、1.5.1 和 1.6.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2019-02 -04对于新月（月数 236），新版本（ Εὐκλείδης）已发布。 添加了对 KSP 1.6.1 的支持。 此版本修复了一个长期存在的问题（2017 年 11 月由@奥古斯丁，于 2018 年 6 月在 GitHub 上作为#1868 由@scimas，并由@延迟 在 2018 年 1 月），在某些情况下，SAS不会将船舶指向标记（而是将船舶指向标记在库存中的位置）。 它还修复了一个相对罕见的问题，即在再入时船只碎片靠近天体中心（#2056）。 有关更多详细信息，请参阅更改日志。 我们支持两组 KSP 版本：可下载 1.4.x、1.5.1 和 1.6.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2019-01-06新月（月数 235，偏食），新版本（ Εὔδοξος）已发布。 我们在RSS中添加了增强的硒电位，完成度和顺序 30；这意味着月球现在有了吉祥物，使得一些低月球轨道不稳定。请注意，您只会在进行新保存时获得新的硒电位。作为一个具体的例子，考虑这个月球轨道的屏幕截图，由于月球引力场的不规则性，它的近点在 18 个轨道的过程中减少了 3400 m（另外十几个轨道之后，航天器在斯宾塞陨石坑之间与月球相撞）琼斯和斯宾塞琼斯 W)。 保存现在以base64编码而不是十六进制编码，使它们更小，加载速度更快。 我们重新运行了 TRAPPIST-1 优化，这一次具有足够小的积分时间步长，使我们能够准确地模拟系统的动态。谢谢@芦荟 用于发现时间错误的过境。由此产生的系统具有类似于 Grimm 等人报告的残差。, χ² = 358.79 vs. χ² = 342.29。 有关更多详细信息，请参阅更改日志。 我们支持两组 KSP 版本：可下载 1.4.x 和 1.5.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-12-07 对于新月（月数 234），新版本 ( Erdős ) 已发布。 最终可以支持任意角度的真实位势建模，RealSolarSystem 中的地球位势的 10 度模型；其他天体（月球、火星等）的更高级建模将在未来版本中添加。 #1955是 macOS 上的一个性能问题（ #1908的延续），已通过使用不同的同步库得到解决。 报告的问题@芦荟 上述 ( #1999 ) 已通过使用用于优化的相同积分器配置临时解决。我们将在未来版本中使用更合适的配置重新进行优化，因为此问题可能表明集成器尚未完全收敛。 有关更多详细信息，请参阅更改日志 。 我们支持两组 KSP 版本：可下载 1.4.X 和 1.5.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-11-07 对于新月（月数 233），新版本（Ἐρατοσθένης）已经发布。 添加了对 KSP 1.5.1 的支持。 我们致力于将地势模型扩展到扁率之外（mascons 等），但这还没有准备好；有关更多详细信息，请参阅更改日志 。 我们支持两组 KSP 版本：可下载 1.4.x 和 1.5.1 以及 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-10-09 对于新月（月球编号 232），新版本（Διόφαντος）已经发布。 这次没有什么新鲜事；我们一直在努力改进重力模型，但还没有准备好。 有关更多详细信息，请参阅更改日志 。 我们支持两个版本的 KSP：可下载 1.4.5 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-09-09 对于新月（lunation number 231），新版本（笛卡尔）已经发布。 Mac 用户的重要提示：Principia 不再支持 macOS El Capitan，因为 Apple 不再支持该版本。我们现在需要 macOS Sierra 或更高版本。 因此，macOS 用户应该会有明显的性能改进。 我们添加了广义 Runge-Kutta-Nyström 方法，可以更准确地预测 Frenet 框架中固定的烧伤。 有关更多详细信息，请参阅更改日志 。 我们支持两个版本的 KSP：可下载 1.4.5 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-08-11 对于新月（月球编号 230），新版本（Desargues）已发布。 这个版本除了1.4.5升级后没有新功能了，因为我们一直在放假。 有关更多详细信息，请参阅更改日志 。 我们支持两个版本的 KSP：可下载 1.4.5 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-07-13 对于新月（月球编号 229），新版本（Δημόκριτος）已经发布。 船只在大气中时现在由 Principia 管理，这意味着大气飞行在地图视图中具有 Principia 历史和预测。 改进了“Trappist-1 for Principia”迷你模组，以更好地反映天体的物理特性。 有关更多详细信息，请参阅更改日志 。 我们支持两个版本的 KSP：可下载 1.4.4 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-06-12 对于新月（月数 228），新版本（Dedekind）已经发布。 此版本修复了内存泄漏，该泄漏可能导致在使用飞行计划时内存使用量增加至 1 GiB / min。此外，我们正在发布一个迷你模组，它可以转动@GregroxMun将SLIPPIST -1 转化为真正的 TRAPPIST-1 系统；从n体引力的角度来看，该系统的 7 行星共振链使其变得有趣。该配置是根据最近发表的论文The nature of the TRAPPIST-1 exoplanets by Grimm 等人 的过境时间变化来计算的 。 有关更多详细信息，请参阅 更改日志 。 我们支持两个版本的 KSP：可下载 1.4.3 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-05-15 对于新月（月球编号 227），新版本 ( Darboux ) 已发布。 本次发布： 使用 立方根的新实现， 它比大多数更准确、更快，作为 Principia 使用其自己的基本函数实现的持续努力的一部分； 在保存和加载时添加Gipfeli压缩和竞技场分配，将保存文件大小减少约 2.5 倍，场景加载时间减少约 2 倍以进行大型保存； 添加了对KSP 1.4.3 的支持。 有关更多详细信息，请参阅 更改日志 。 我们支持两个版本的 KSP：可下载 1.4.3 和 1.3.1。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 Darboux 不支持 KSP 1.2.2，因为 Realism Overhaul 和 Real Solar System 现在支持 1.3.1 。 2018-04-16 对于新月（月数 226），新版本（Cramer）已经发布。 本次发布： 修复了导致机动节点在点火时跳跃的错误，尤其是在弹射和捕获燃烧时。谢谢 @科比丸 和@EstrelaGaliza 报告和帮助诊断此错误。 添加了对 KSP 1.4.2 的支持。 请注意，您可能需要安装更新的 C++ 运行时；有关更多详细信息，请参阅 更改日志 。 我们支持三个版本的 KSP：可下载 1.4.2、1.3.1 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 Cramer 将不支持 1.4.3，因为 Principia 具有特殊处理来解决与梯子相关的错误，因此我们需要测试新版本以查看是否需要更改。 这是支持 KSP 1.2.2 的最后一个版本，因为 Realism Overhaul 和 Real Solar System 现在支持 1.3.1。 2018-03-17 对于新月（月球编号 225），新版本（Coxeter）已发布。 本次发布： 使用 SSE2 内在函数来提高性能； 解决了 Jool 系统中的数值稳定性问题，由 @埃里克森; 介绍了一个 API @吉姆·迪格里兹的引导算法； 引入了对 KSP 1.4.1 的支持，感谢 @awang. 有关更多详细信息，请参阅 更改日志 。 我们支持三个版本的 KSP：可下载 1.4.1、1.3.1 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-02-15 对于新月（月球编号 224），新版本（科恩）已经发布。 星历表现在使用 Estrin 方法计算以单项式基表示的多项式，而不是使用 Clenshaw 方法计算以 Чебышёв 基表示的多项式，从而提高了性能。 有关更多详细信息，请参阅更改日志。 同样，我们支持两个版本的 KSP：可下载 1.3.1 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 2018-01-17 对于新月（月球编号 223），新版本（克利福德）已经发布。 据报告，DoublePrecision 实现中的一个错误导致 Macintosh 上的测试失败@awang 和@吉姆·迪格里兹，已修复。 太阳系设计师现在可以根据@GregoxMun 的要求选择更适合他们太阳系的积分器，其出人意料地稳定的Alternis Kerbol Rekerjiggered 与 Principia 的默认积分参数（在 Cartan 中）选择用于库存 KSP 和真正的太阳系。 有关更多详细信息，请参阅更改日志。 同样，我们支持两个版本的 KSP：可下载 1.3.1 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 谢谢@awang 在这个lunation期间的贡献（clang警告清理）。 2017-12-18 对于新月（新月号 222），新版本 ( Christoffel ) 已发布。 船只不再像库存中那样在足够高的时间扭曲通过未受到伤害的行星，并被 Principia 检测为与行星相撞并被摧毁。尤其是解决了陈景润发生的一艘船毫发无伤地穿越行星的事故（#1628，由@awang 和@约翰外汇）。 已放弃对 KSP 1.3.0 的支持。我们支持两个版本的 KSP：可下载 1.3.1 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 有关更多详细信息，请参阅更改日志。 2017-11-18 新月（月数221），新版（陈景润）出炉。 此版本解决了轨迹存储方式的长期问题 ( #228 )，该问题导致在高时间扭曲计算的历史记录中出现尖峰或循环。 同样，我们支持三个版本的 KSP：可下载 1.3.1、1.3.0 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 有关更多详细信息，请参阅更改日志。 谢谢@awang 在这个lunation期间的贡献（修复了一个UI错误）。 2017-10-19 对于新月（月数 220），新版本 ( Chasles ) 已发布。 一个长期存在的错误，#1413，最初由 @maccollo，并且还报告了 @克里斯蒂,@DaMichel, @goldstarstickergiver,@lyttol, @纳米图像, @Parafaragarmus,@rsparkyc, et al., 是固定的。在 RealSolarSystem 的当前版本 (12) 中，此错误阻止了在某些天体（尤其是 Minmus）和月球上的着陆。修复包括让 Principia 处理容器，即使 KSP 的物理在旋转参考系中运行，一直到地面；一旦 Kerbal 跳上 Minmus，Principia 就会计算它的轨迹。请注意，大气中的容器不受影响；我们打算也处理这些问题，但这需要更新@ferram4的FAR，因为我们希望保持FAR兼容。 此外，Principia 现在支持 KSP 1.3.1；可下载 1.3.1、1.3.0 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 有关详细信息，请参阅更改日志。 谢谢@awang 在这个lunation期间的贡献（clang警告清理）。 2017-09-20 对于新月（月球编号 219），新版本 ( Cesàro ) 已发布。 现在并行计算船只的历史，加速多核处理器上的高时间扭曲。 修复了在两艘船相互碰撞时导致崩溃的错误。 同样，我们支持两个版本的 KSP：可下载 1.3 和 1.2.2。确保您下载了正确的（如果不下载，游戏将在加载时崩溃）。 有关详细信息，请参阅更改日志。 2017-08-21 对于月全食的新月（月数 218），新版本 ( Чебышёв ) 已发布。 The speed of the plotting of histories has been improved by about an order of magnitude. The slow plotting in previous versions was responsible for most of the slowdown in map view. Further, the predictions are now plotted smoothly even when they are integrated with a large tolerance. The flight plan now supports burns that guide themselves to follow the Frenet trihedron, e.g., tracking the tangent (prograde), or the binormal (the normal to the orbital plane). Select "Inertially fixed" in the flight planner to use an unguided burn instead, e.g., for spin-stabilized burns. For the first time, Principia supports two versions of KSP: downloads are available for 1.3 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). A couple of bugs reported by @panourgue and @scimas were fixed. See the change log for details. Thanks to @Iskierka and @Jim DiGriz for testing the Linux and Macintosh builds respectively. Note to RSS users: Principia correctly simulates the motion of the moon, so the eclipse occurs as expected when using Principia, even after more than 66 years of numerical integreation, see below. Conversely, without Principia, the Moon's motion cannot be simulated with the requisite accuracy to get correct eclipses, since it is a heavily perturbed orbit. 2017-07-23 For the new moon, the new release (Cayley) is out. It brings trajectories in map view, an update reminder driven by the Moon, a fix to a whole class of off-by-one physics bugs, and further bugfixes. Further, the build includes a binary for Macintosh, thanks to @Jim DiGriz. Note that the version string on Macintosh will mention Cayley-4 instead of Cayley-0. This will be resolved in future versions. See the change log for details. 2017-06-24 For the new moon (lunation number 216), the new release, Cauchy, is out. It brings relative speed markers on nodes, the unification of navball speed mode and reference frame selection, and displaying the trajectory of the target vessel if it moves in the plotting frame. This addresses requests by @lawndart, @maccollo, and @scimas. This release fixes: physics bugs: 1307 reported by @Damien212 and @maccollo, 1404 reported by @Bocian and @lawndart, 1415 reported by @scimas, 1421 reported by @NathanKell and @rsparkyc; a UI bug, 1402, reported by @lawndart and @maccollo; crashes: 1422 reported by @maccollo, 1441 reported by @rsparkyc. See the change log for details. NOTE: due to a forum mishap (stares at @technicalfool ) this thread has changed address, and all followers have been lost; if you had bookmarked the thread or followed it, you may want to do so again. 2017-05-25 For the new moon (lunation number 215), the new release, Catalan, is out. It brings no new features, but fixes a number of bugs and improves the underlying libraries. See the change log for details. 2017-04-26 For the new moon (lunation number 214), the new release, Cartan, is out, bringing with it a utility for rendezvous: the target local vertical local horizontal reference frame. There is a guide to low orbit rendezvous using the new reference frames (screenshots to be added in the near future). See the change log for details. Please read the concepts page carefully, it has been expanded since Cardano. Remember to also have a look at the FAQ if you have a question. Thanks again to @Iskierka for testing the Linux build. 2017-03-28 For the new moon (lunation number 213), the new release, Cardano, is out, bringing with it axial tilt, new reference frames, and timewarp-independent free fall. It marks the beginning of lunar releases. See the change log for details. In particular, note that Cardano is save-incompatible with Cantor. Please read the concepts page carefully, it has been expanded since Cantor. Thanks to @Iskierka for testing the Linux build. 2016-08-13 Cantor is out. This version is mostly the same as بوژگانی (see the change log), the intent is to make sure it is as stable as بوژگانی was: this is the first broadly available release, with a link to binaries outside the IRC channel (see the OP). In the meantime, progress has been ongoing (note that this is about a future release, Cantor contains none of the features below). Regarding our internal libraries, we have clarified the way we handle time (which is always an extremely confusing thing), with our Instant type aligned with Temps Terrestre (TT), and support for date literals in TT, Temps Atomique International (TAI), Coordinated Universal Time (UTC), and UT1 (based on the rotation of the Earth). This allows us to specify dates more cleanly in our tests. We tested the difference between the orbits of Mercury predicted by our ephemeris and by JPL's over a century, and we find the expected error in perihelion precession due to general relativity. On the side of flashier features, we seem to be well underway to having working axial tilt, by tilting universe the current main body (with terrain) is aligned with the axis used by KSP, and rotating the other ScaledSpace models appropriately; in a future release of Principia, the Jupiter, Saturn, and Uranus systems should look much nicer, with the planet properly aligned with its satellites. 2016-06-26 بوژگانی is out. A change log can be found here. 2016-05-20 Burnside is out. A change log can be found here. 2016-05-05 Буняковский is out. A change log can be found here. 2016-02-24 There is a bug in Buffon (2016022220-Buffon-0-g0455d0cb0e4b0b584a84caf40520cf7993903e0c) that causes a crash when starting a new save with RSS (loading an existing save works fine). The hotfix "2016022220-Buffon-12-g1298cffba22d90119bd59e9933a9ef261922a423" (let's call it "Buffon + 12") resolves that, so if you run into this issue just go back to the IRC channel to get the latest build, it will be Buffon + 12. There are no other changes between Buffon and Buffon + 12. 2016-02-22 Buffon is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Changes: The integrators now limit the number of steps they perform, and terminate if their step size vanishes. This avoids issues where the plugin would hang when the trajectory would accidentally get very close to the centre of a celestial body or spend a long time in a low orbit. A use-after-free bug has been fixed which caused a variety of crashes (#872, #881, #889, #896) when the historical trajectory was shortened in a way that would cause it to start after the beginning of the flight plan. The version identifier of the plugin is now displayed in the UI to make it is easier to assert what version is running. A verbosity option has been added to the journalling which makes it easier for us to reproduce crashes. The first two items above are illustrated by the following two reports. For more details see all 19 pull requests between Brouwer and Buffon. 2016-02-11 Some clarifications regarding reference frames and flight planning. 2016-02-09 Brouwer is out, you can get it by asking on IRC (#principia on EsperNet), as usual. User-facing features: The whole Frenet trihedron is now displayed in the correct reference frame when "fix navball in plotting frame" is selected. The initial state (and thus the evolution) of the system is now deterministic even when not using RSS. Tidally locked bodies no longer spin back and forth madly (on the other hand, they may not be tidally locked if their mean period differs from their Jacobi osculating period). When using stock, the Jool system is modified, cancelling the apocalypse. Specifically, we make the inner Jool system nonresonant, since we have been unable to replicate the results (Manley, priv. comm.) according to which some interpretations of the orbital elements yielded a stable Laplace resonance, despite systematic searches of the Jacobi osculating elements. In addition, at Scott Manley (@illectro)'s and @UmbralRaptor's suggestion, we put Bop in a surprisingly stable, though highly precessing, retrograde orbit. The modified system is stable for upwards of a century. Flight planning has been implemented. Modder-facing changes: When a Cartesian initial state cfg is not given, the KSP orbital elements are interpreted in a hierarchical osculating Jacobi fashion; for instance, the orbital elements of Jool are the osculating elements at game start of the orbit of the barycentre of the Jool system around the barycentre of the (sun, moho, eve, gilly, kerbin, mun, minmus, duna, ike, dres) system; the elements of Laythe are the osculating elements at game start of the orbit of Laythe around Jool; the elements of Vall are the osculating elements at game start of the orbit of Vall around the Laythe-Jool barycentre. Optimizations: The Windows build now uses profile-guided optimization (we estimate that this improves performance by ~20%); in theory this could be extended to other platforms. The evaluation of the Чебышёв series has been significantly optimized. @sarbian made trajectory rendering faster (as he pointed out, there is still lots of room for improvement). Other features: Everything that crosses the interface can now be journalled if the right flag is set, allowing us to replay the C++ side of a session; this is useful for tracking down tricky bugs, and it enables profile-guided optimization. Highlights of miscellaneous library changes; beware, this gets technical: In order to get the full Frenet trihedron, which in turn was needed for manœuvres, since the Δv is defined in the Frenet frame at the point of ignition, geometric acceleration (the acceleration of a free-falling trajectory) in any reference frame was needed. To that we created two abstractions, RigidMotion, the derivative of a RigidTransformation, and DynamicFrame, the definition of an arbitrary reference frame. The navigation frames (the frames in which the trajectory is drawn, or with which the manœuvres are defined) implement that (see BodyCentredNonRotatingDynamicFrame and BarycentricRotatingDynamicFrame). In order to interpret the orbital elements of KSP in the hierarchical Jacobi fashion described above, support was added for Kepler orbits (implementation), Jacobi coordinates, and hierarchical systems. Discrete trajectories were reworked, with a heavy dose of CRTP. In preparation for the surface frame in the future, RotatingBody was added. The C++ interface headers and C# extern declarations were repetitive and error-prone, this was exacerbated by the addition of journalling code and replaying code, so a generator was written to produce all of that from an annotated proto. @UmbralRaptor contributed some tests of lunar eclipse timings. For both Kepler orbits and lunar eclipse timings, a simple root finder was needed, bisection does the job for now. A bibliography was written, at @UmbralRaptor's request (it is somewhat out of date). SolarSystem, a class for initializing ephemerides from protobuf text format configuration files for testing purposes was written. A script for generating the initial state configuration files from the emails sent by JPL's HORIZONS system was written (the gravity model configuration file is hand-curated). An utility turns the protobuf text format configuration files into KSP ModuleManager configuration files for RSS support. Various geometric utilities were added: angles (implementation), spherical coordinates (more are needed). More C++11/14 features were used as they became available (for instance, the units are now constexpr), in addition we now use std::experimental::optional. C++14-related improvements were made to not_null. For more details, see all 195 pull requests between Bourbaki and Brouwer. 2015-08-16 Bourbaki is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Please bear in mind that the channel operators may be away from keyboard, so you should wait until you're noticed (it also helps to say the name of the channel operators since that pings them). As of 2015-08-16T15:38Z, the build for Win32 is ready, we're waiting for Norgg and armed_troop for the Linux and Macintosh builds respectively. Note that you should read the FAQ before installing principia. Rough changelog: Reimplemented integrators: the symplectic Runge-Kutta-Nyström integrator was reimplemented more cleanly, an embedded explicit Runge-Kutta-Nyström integrator was implemented. Abstractions for differential equations were created. Ephemeris: the celestial bodies are integrated on their own, with their own (much larger) timestep (45 min); their trajectories are then fitted using чебышёв series, yielding continuous trajectories. This means that when there are no vessels (including asteroids, see the FAQ), timewarp at very high speed (6'000'000x was tested in RSS) is smooth. The predictions are computed using an adaptive step size, so they're faster and less fiddly (you still get a tolerance setting, but it doesn't need as much attention as the step size setting; the step size will shorten near periapsis and lengthen near apoapsis on its own). The histories are still in fixed steps of 10 s, that will likely change in Brouwer, since it is one of the biggest performance costs now. There is an initial configuration for Real Solar System: the planets will start in the right places as given by the JPL HORIZONS service, and they are given gravity models using the freshest data available (Vesta's model is from Dawn data, some Cassini data gets used). Please note the RSS-specific recommendations in the FAQ. A side effect of that is that the moon becomes far more accurate: since the motion of the moon is very much a 3-body problem, it cannot be accurately represented in RSS alone. In particular, real-life eclipses can be observed in principia + RSS (please note the unexpected inaccuracy mentioned in the FAQ). This initial configuration also includes J2 for the Sun, the planets, the Moon, and Vesta, so the resulting effects are felt (precession of Earth orbits, the possibility of heliosynchronous orbits, etc.). Bourbaki is save-compatible with Borel, for RSS users, please note that unless you reset the plugin, the new initial state and gravity model configuration files will not be taken into account. 2015-05-07 The new version, Borel, is out (you can get it on IRC, as previously; the same caveats apply). Rough changelog: ported to 1.0.x (that only took a couple of lines); custom navball settings, so that the navball can be fixed in the reference frame in which the trajectory is plotted; the IVA navball is unaffected; when using the custom navball, the prograde/retrograde vectors are now in the correct reference frame, consistent with what is shown is map view; the rest of the Frenet trihedron (the radial and normal vectors) are unaffected at the moment and will be fixed in another version; fixed a few bugs (the tetrydsbug, the melonbug, the thutmosebug); less memory-hungry; added a setting to clip histories; added a toolbar button to show/hide the UI; the UI now acknowledges the F2 key; other things that I forgot. Moreover, Norgg and armed_troop have made good progress on Linux 64-bit and Macintosh 32-bit builds respectively, so if you're on these platforms you can go on IRC and ask for a build or for build instructions. With Windows 32-bit, Linux 64-bit and Macintosh 32-bit, we should be covering most users (I don't think it's worth doing a Linux 32-bit build). 2015-03-22 Serialization has been implemented, and rudimentary predictions have been added. The predictions are currently using the same integration method (McLachlan and Atela's 1992 optimal 5th order method), with the same splitting of the Hamiltonian (kinetic + potential energy), this is somewhat usable but unacceptably slow. I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings (as as nonsymplectic methods in use for computing ephemerides). I will probably write a post about these at some point (probably an advanced one, rather than an elementary introduction, this is quite a complicated topic). It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be. If you want to try out the current version of Principia (Bolzano) for the Windows 32-bit version of KSP, go the IRC channel linked below and ask me for a build (my nickname there is egg, or sometimes something of the form egg|<status>|egg). CAVEAT: The current version is not stable, it can corrupt or otherwise destroy saves, it has been known to crash, and predictions are horrendously slow. #principia IRC channel on EsperNet. 2015-01-22 The refactoring of the physics bubble has been done (and some tests have been added), as well as some cleanup in the C# adapter (including some performance improvements, a lot of the performance issues occur on the C# side since the implementation is a bit careless there). More refactoring occurred (use of a not_null template for non-null pointers). The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. (currently loading a save or reverting will result in either a crash or a loss of consistency due to the planets having moved around). Persistence of our types will be achieved using protocol buffers, stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy. We'll probably also use protobufs for caching when implementing trajectory predictions later on. Some work has already been done in that direction. Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point (the reference frame for each screenshot is indicated in the "Traces of various description" window). Javascript is disabled. View full album antedated 2014-12-13 Support for intrinsic acceleration has been added. Refactoring will be needed, but it works, as demonstrated by the following plane change manÅ“uvre: 2014-11-07 Some work has been done on better abstractions for rendered trajectories, nothing significant yet (in particular there still is something in Õ(n) which could be in Õ(1), runs at each frame, where the constant factor involves evaluating trig functions, and n~10_000 is the number of rendered points, so that rendering trajectories in the barycentric rotating frame is slow), but some pretty pictures. This shows a vessel near the L5 point of the Kerbin-Mun system. In the first image, the trajectory of the vessel is displayed in the nonrotating reference frame centred on the Mun, in the second it is displayed in the nonrotating reference frame centred on Kerbin, and in all subsequent images it is displayed in the barycentric corotating reference frame of the Kerbin-Mun system. Javascript is disabled. View full album Work on intrinsic acceleration is ongoing. 2014-10-28 Code has been written to plot the trajectories in nonrotating body-centred reference frames (and barycentric corotating, not reviewed yet). While abstractions will have to be written to do that more cleanly and efficiently, this yields some pretty pictures. Caveat lector: While some of the following orbits may look very wild, bear in mind they are in non-inertial reference frames. Two of these wilder trajectories are followed by the same trajectory in a more pedestrian reference frame. In the Kerbin-centric non-rotating reference frame, they would all look like two or three elliptic orbits connected by strange segments where the perturbation by the Mun is to blame. The last picture below (in the barycentric corotating frame of the Kerbin-Mun system, that is, the unique frame in which the Kerbin-Mun barycentre as well as the line through Kerbin and the Mun are invariant) shows a trajectory that differs strongly from what stock KSP would have yielded: in stock this would have been a circular orbit around the Mun near the edge of its SoI. Instead it is a transfer to an eccentric Kerbin orbit, which is picked up by the Mun again after a while and ends with a crash on the Mun. Javascript is disabled. View full album With the addition of plotting, the C++ plugin has caught up with the features of the initial C# prototype. After the abstractions for plotting are written (we will add the remaining interesting reference frames in the process), the next step will be to take care of altering the trajectory when, e.g., engines are used. It is apparent that the C++ plugin is significantly faster, much more reliable, and easier to debug than the C# prototype (it is also correct; some hasty shortcuts were made in the prototype that resulted in unreliable initial states and other problems). 2014-09-30 Trajectory, an abstraction for a tree of trajectories that can be forked into child alternatives (useful i.e. for predictions, manoeuvre nodes, but also simply computations at different precisions), has been written (part of the physics namespace) The plugin has returned, first as a simple orbit-freezing plugin, then as a plugin that actually integrates the motion of vessels (only on-rails for the moment). Is does not plot yet, so it is still behind the C# prototype in terms of features, but it is significantly faster. As was previously mentioned, all calculations are done in a native assembly, called by P/Invoke via a (cdecl) interface. It should be noted that the plugin uses glog everywhere for logging (since logging from native code is needed). Of course, this means Principia will have its own log files (in <KSP directory>/glog/Principia, with a log of the last session in <KSP directory>/stderr.log. Another interesting aspect is that there will be no silent exceptions as in managed plugins, instead, the game will either segfault (when dereferencing an invalid pointer) or abort (SIGABRT) if a glog CHECK macro fails (on Windows the latter yields the "KSP.exe has stopped working" message). I have been informed by Sarbian et alii that this will result in Fun support. 2014-07-04 I wrote the second explanatory post, on Hamiltonian mechanics (PDF). Prerequisites are chapters 4, 8, and sections 11-4 and 11-5 of Richard Feynman's Lectures on Physics. The next post will be on symplecticity and the leapfrog integrator. 2014-06-27 The integrator (still a 5th order SPRK, same as in the C# prototype, the Saha & Tremaine stuff isn't here yet) has been implemented, tested and benchmarked (using a Windows port of google/benchmark) in C++, as well as the first level of abstraction above it, principia::physics::NBodySystem (header, body, test, header for test data, test data, test of test data (which is also a nice example of the use of principia::quantities and principia::geometry, benchmark (using the test data)). A significant change of plans has occured: As Unity uses the .NET Framework v2.0, it is not possible to use plugins compiled for the Framework v4.5. This means C++/CLI projects need to be compiled using the platform toolset v90 (from VS2008), rather than VS2013's v120. Of course v90 does not support C++11 nor C++14, so it is not an option for this code that strongly depends on C++11 features. As a result, we will keep using the C++11 codebase, compiling it to a native DLL, and using P/Invoke to call it from a C# adapter. The C# adapter will perform no calculations, only transmit data from KSP to the native plugin and apply the changes/render the trajectories returned by the plugin. A simple test P/Invoke plugin can be seen on the repository (header, body, C# adapter) and works in KSP. This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap). Moreover, this will allow a switch to clang in the near future, so that we can have saner error messages and better compliance with the standard. 2014-05-12 I now have a collaborator on Principia, https://github.com/pleroy (my father). This means the code gets reviewed and that development is faster. We have decided to completely switch to C++/CLI due to better test tools and useful language features. Most of the code will actually be written in standard C++, with the implementation inlined in header files, so that they are seen by the eventual C++/CLI managed assembly (If we were to use C++/CLI everywhere, we would need managed boundaries between the assemblies, which is quite inconvenient). As an added advantage, using standard C++ enables putting performance-critical parts into a native assembly if needed at a later time, without requiring a significant rework of the code. We have started switching to gmock, gtest and glog for mocking, testing and logging. These tools are more convenient and powerful than the Visual Studio testing framework and are open source, so that users of Visual Studio Express (which does not support Microsoft's testing framework) will be able to build and run tests if they want to. Here is the first test to be converted to gtest: https://github.com/mockingbirdnest/Principia/blob/master/geometry/sign_test.cpp. 2014-04-03 The Quantities library (C++) is pretty much done and tested. I am currently porting the C# Geometry assembly mentioned previously (now called CTSGeometry) to C++ in order to enable its use with these quantities. 2014-03-15 The Geometry assembly seems to be mostly feature complete, so I'll start writing tests tomorrow (Saturday) after changing a few access modifiers, replacing the ugly switch statements in Permutation by something nicer, and a few optimisations. See here for an overview of its features. 2014-03-04 I have investigated the feasibility of using other languages for KSP plugins: The following languages can be used on their own to write a plugin: C#(unsurprisingly), F#, C++/CLI (with no calls to native code). VB.NET can be used, but wrappers in one of the above languages are needed due to its case-insensitivity. Unity does not support mixed-mode DLLs, so calls to native code have to be made using DllImports in one of the above languages. I have started doing some refactoring since the sphaghettiness of the code was getting on my nerves. I have written strongly typed wrappers for the numerous reference frames spawned by KSP (direct vs. indirect, rotating vs. inertial, world vs. body-centric, etc.) as I have had numerous bugs due to a misplaced xzy, rotation, translation, scaling, inertial force etc. Of course, since KSP has the brilliant idea of using both direct and indirect reference frames, I needed distinct types for vectors, bivectors and trivectors (basically I had to strongly type Grassmann algebras; there can be no cross product, only wedge products, commutators and left and right actions of alternating forms---where is identified with through the inner product, and is identified with ). I do not think I will implement strong typing for physical quantities yet (though I'd like to), since C# generics are not powerful enough for that; I would need C++ templates. I'll do that when I rewrite things in C++/CLI. The next step is to implement my own versor, since Unity's Quaternion is in single-precision float and KSP's QuaternionD is broken. The rest should be more straightforward refactoring. 2014-02-24 It turns out I have trouble properly setting the position when off-rails (finding out where the reference frame actually is is hard). However, there are some nicer news: I seem to have found the source of the phantom acceleration bias (not the ones arising from rotation, the bias that is removed by timewarping). The floating origin sometimes floats several km away from the ship, so that's probably just floating-point inaccuracies (the usual Kraken). If that hypothesis turns out to be true, this particular acceleration bias will be easy to fix, just reset the floating origin often enough. 2014-02-19 I have successfully implemented the integration of proper acceleration for the active vessel when off-rails. Further experimentation on proper acceleration has led me to the following conclusions: There is a bias in proper acceleration coming from some improperly initialised variable in KSP. Indeed, when loading a vessel in LKO, I observe a strong bias in proper acceleration (~20 mm s-2). This bias is observed independently of the way proper acceleration is computed (differentiating position twice, differentiating any of the numerous velocities, etc.) and geometric accelerations have been checked from first principles (the difference in geometric acceleration depending on the point of the vessel it is computed at is negligible). The bias is reduced to below 1 mm s-2 when warping then coming out of warp. It should be noted that the strong bias is not seen in Vessel.perturbation, but Vessel.perturbation consistently has a bias of 4 mm s-2. As I have attempted to compute the proper acceleration in many different ways and all were consistent with each other and inconsistent with Vessel.perturbation, I assume Vessel.perturbation is mostly nonsense. Accelerations below 1 mm s-2 are biased, unavoidable, unusable in stock, and should be clamped to 0. The acceleration from low-thrust engines will have to be fetched by hand. It had previously been mentioned that spinning the ship accelerates it. If spinning the ship with angular velocity É produces a phantom acceleration a, then spinning it with angular velocity -É produces a phantom acceleration -a. It seems a is either prograde or retrograde. 2014-02-17 I have finally managed to work on this a bit over the weekend. Extensive experimentation has failed to yield a better velocity, so we are stuck with computing the proper acceleration from the rather mysterious Vessel.obt_velocity for now (for some reason in whatever reference frame this velocity is in, the geometric accelerations are as expected, except for the Coriolis acceleration which is halved ). This yields roughly the same results as Vessel.perturbation without the moving average. The same experiments have further shown that a naïve low-pass filter will not be enough to remove Unity's silliness. For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship. Smarter post-processing will be needed. I shall now attempt to actually integrate whatever proper acceleration I have managed to grab. I also wrote the first explanatory post, which describes ODEs and Runge-Kutta methods (PDF). I have tried not only to explain how Runge-Kutta methods work (this can easily be found on Wikipedia) but why they have this structure. Hopefully you will find it interesting. 2014-02-08 I fixed a bug or two since 2014-02-05, added a few TODOs, but have not cleaned up the code to any measurable extent. I am, however, publishing it on GitHub (under the MIT license). Caveat Compilator: As previously stated, this is just a proof of concept with a bunch of traces. Pressing the wrong buttons in the wrong order will result in lots of NullReferenceExceptions and off-rails crafts will behave weirdly. Using HyperEdit to set up initial conditions, then switching to Newtonian physics and fooling around with reference frames can be entertaining though. You might learn something from looking at the Integrators part (which admittedly contains only one integrator), the rest was quickly hacked together, has no tests, is badly structured &c. The 'Simulator' project probably won't compile, it's leftover from my Alternis Kerbol simulations. It's not needed. 2014-02-05 This is currently hardly more than a proof of concept. The simulation only affects on-rails vessels, thrust is ignored (thus you can't actually play while the simulation is running) and the integrator is too slow. However, it shows a few interesting things: Near-unit-roundoff (using IEEE 754 binary64) errors can be achieved while sustaining 100_000x timewarp with B = 17, V < 5. Handwavy asymptotic calculations indicate that for V = 100, this integrator would slow down to about 20_000x timewarp. Using better integrators (and saner tolerances), performance could easily be increased by a couple of orders of magnitude, making the simulation usable for RSS as well as stock. Trajectory plotting in rotating reference frames, or reference frames centered around a body other than the primary, can be useful even for near-Keplerian orbits: it allows for visualisation of RT2 satellite coverage, easier landing prediction, etc. The stock integrator is terrible, and will have to be overriden at all times while in space (when near a Lagrange point, a fraction of a second under stock integration will turn a Kerbin capture into a Mun collision). If you think floating SOIs (or worse yet, SOIs with repulsive gravity) are a half-decent model for Lagrange points, you don't really understand how Lagrange points work. Expect a slow development cycle, due to a combination of laziness, exams, and this actually being a complicated project. I'll put the source on GitHub as soon as I can clean things up a bit (there are quite a few traces that were too hastily implemented for my taste). This might take a few days, see above. Nonetheless, here are some pictures that illustrate the fun trajectories in the N-body problem. The second and third pictures have a misplaced trajectory, this bug has been fixed. Some pictures have three strange red, green and blue lines, which indicate the origin and axes of world space. Javascript is disabled. View full album Notations Reveal hidden contents B: number of massive bodies. V: number of massless bodies. Terminology Reveal hidden contents The main integration refers to the integration of celestial dynamics in the absence of thrust, both for the propagation of the vessels and for the predicted trajectories of passive vessels and planets. It also includes the real-time integration of vessels under thrust and, when this is added, the integration and trajectory prediction for planned burns under timewarp (e.g. ion engines). The dynamic integration, or integration for vessels under thrust, refers to the predicted trajectory of a vessel assuming thrust is cut immediately (what happens is stock KSP when you fire your engines). This integration has to be very fast, as the initial conditions change quickly and prediction over several years may be required for planetary transfers &c. Fictitious forces in any reference frame are those proportional to the mass of the object upon which they act. This includes gravity. This convention only really makes sense in GR, which I do not currently intend to implement, but it's more convenient. The geometric acceleration is the acceleration due to fictitious forces. The proper acceleration is the acceleration not due to fictitious forces. Considerations on numerical integration The current prototype uses a straightforward fifth order SPRK method. The coefficients used are from (Atela & McLachlan 1992). The increments are accumulated using Kahan summation. The integration is performed with a constant 10 second timestep (numerical experiments suggest that the error is close to an unit roundoff with a 5 second timestep for LKO). Regarding implementation details, the integrator is written in C# (compiled with VS2013) and uses double (IEEE 754 binary64) for all computations. Scott Manley suggested using hybrid symplectic integrators (Chambers 1999) in order to speed things up. It should be noted that the concerns that the Chambers paper attempt to alleviate might not be critical for gameplay purposes (the main integration can probably be done with a very small timestep compared to the ones commonly used in astronomy. Moreover, timestep reduction occurs de facto when getting out of warp, as the game cannot conceivably be played with timesteps of several seconds). It could become relevant for trajectory predictions in vessels under thrust, which has to be done in a few hundred milliseconds over several years. For those predictions, the timestep would have to be increased to durations comparable to those used in the paper, and similar concerns would arise. The results from the papers quoted by Chambers, namely (Saha & Tremaine 1994) and (Holman & Wisdom 1991), will probably have to be used in order to make the main integrator faster. Experiments will have to be carried out in order to find out whether a higher order (> 2) integrator is worth using, and how the added cost of Keplerian evolution (which requires numerically solving the Kepler equation for all bodies, which is very costly due to the trigonometric functions) affects performance at acceptable time steps. Open questions for the interested reader Regarding KSP modding The method I currently use for drawing trajectories (LineRenderers, object in layer 9, transform.parent = null, useWorldSpace=true, updated every time the GUI is drawn) has some issues: when rotating the camera in map mode, the lines lag behind. Does this have a known solution? (I guess so, RT2 doesn't have this problem). And indeed, the RT2 code contained the solution. Thanks, Cilph! Is there a way to directly set the position and velocity of the planets and vessels in world coordinates? OBE, the API does not make sense in highly original ways. Can anybody think of a way to mod in axial tilt (even a hacky one; remember that I'm the one moving the planets around anyway)? OBE (done in RSS, we actually have axial tilt, it's just that all planets rotate around parallel axes). Regarding aerodynamics Could somebody help me with the implementation of orbital decay drag when I get to implementing that? ferram4 told me he'd help. Thanks! Would it be conceivable to predict the results of aerobraking/aerocapture/ballistic reentry with FAR (within some error margins, to be displayed on the predicted trajectory)? How slow would that be? Answered by ferram4. This might end up happening. Regarding astrophysics and astrodynamics The uniformly rotating reference frame around the barycenter with respect to which the two massive bodies are fixed is very useful when looking at trajectories in the CR3BP (Lagrange 1772). What would a good reference frame for the ER3BP (for bodies with highly eccentric orbits, e.g., Eeloo in stock, Pluto in RSS) be? the uniformly rotating one around the barycenter that follows the mean anomalies, the nonuniformly rotating one that follows the true anomalies, or something else entirely? In the rotating-pulsating reference frame that fixes both bodies, the equilibrium points are fixed. Is there a way to draw things in that reference frame on the in-game map that's not too confusing? Can it still be useful to draw the potential for the parts of the equations of motion that derive from a potential, given that the independent variable is true anomaly rather than time? Should long-term trajectory predictions for vessels under thrust be inaccurate, is there a good way of estimating the uncertainty (for instance, would predicting a few perturbed trajectories and plotting them all give a representative idea of what might happen)? ferram4 suggested a few interesting things. Would drawing the gravitational potential in the current orbital plane (together with the centrifugal potential if orbits are drawn is a rotating reference frame) be useful? Answered by ferram4 with visualisation suggestions. The answer is 'yes'. How should stationkeeping be implemented? In particular, how should the user set the orbit they want to maintain? Regarding the KSP fora Do we have LATEX support? If that isn't the case, is it conceivable to have it in the foreseeable future? Further modding Once the mod gets to a functional state (taking thrust into account), I shall attempt to solve the problem of trajectory prediction for vessels under thrust. In the process, the smarter integrators mentioned above will be implemented, and the most efficient one will be kept. This should significantly increase computation speed. This will also enable instantaneous-burn maneuver nodes (the kind of maneuver node we have now). The barycenters will be fixed in order to stabilise the Jool system. Scott Manley (illectro)'s predictions indicate this will make it stable over at least 1_000 years (Pol was not part of those predictions, its stability remains to be determined). Speed will be further increased by rewriting the numerical integration in (unmanaged) C++, interfaced with C# through C++/CLI. The unmanaged C++ (compiled with clang) will use 80-bit extended precision 'long double' (64-bit mantissa instead of 53-bit) for added precision. Once the mod becomes playable with N-body gravitation with point masses, the following effects should be relatively easy to add: Conservation of angular momentum through timewarp and outside timewarp (allowing for spin-stabilisation and thus fixed RT2 antennae if Cilph decides to implement that); Thrust through timewarp, for ion engines and the like, together with maneuver nodes for non-instantaneous burns; Orbital decay drag, with ferram4's help; Stationkeeping, to deal with orbital decay and unstable weakly bound orbits; Gravitational moment (quadrupole) for planets, enabling such amusing things as Sun-synchronous orbits; Insert crazy idea here... Acknowledgements I would like to thank (in alphabetical order of forum usernames) Anatid for his attempt at documenting the KSP API, armed_troop for his help in making the codebase clang-compatible. Ezriilc, Forecaster, khyperia, Payo and sirkut for their HyperEdit plugin, which is really useful for setting up initial conditions, Scott Manley (illectro) for his help with numerical integration of the N-body problem, Matt Roesle (Mattasmack) for writing an integrator which was far better than the one I used, thus prompting me to write my current SPRK integrator, NovaSilisko for his Alternis Kerbol mod, which piqued my interest in the simulation of the N-body problem, The entire KSP modding community (especially the subset which writes clean, well-commented code) for providing code examples from which one can learn the subtleties of dealing with the KSP API. If I forgot you in the above list, please complain! Bibliography Mathematica documentation on SPRK methods. [Atela & McLachlan 1992] Robert I McLachlan and Pau Atela, The accuracy of symplectic integrators, 1992. [Chambers 1999] John E. Chambers, A hybrid symplectic integrator that permits close encounters between massive bodies, 1999. [Holman & Wisdom 1991] Jack Wisdom and Matthew Holman, Symplectic maps for the N-body problem, 1991. [Kenniston 2002] Michael Kenniston, Dimension Checking of Physical Quantities, 2002. [Lagrange 1772] Joseph-Louis Lagrange, Essai sur le problème des trois corps, 1772. [saha & Tremaine 1994] Prasenjit Saha and Scott Tremaine, Long-term planetary integration with individual time steps, 1994. [Tao 2012] Terence Tao, A mathematical formalisation of dimensional analysis, 2012. Eric Weisstein's World of Physics, Gravitational Moment. [Yoshida 1990] Haruo Yoshida, Construction of higher order symplectic integrators, 1990. [Yoshida 1992] Haruo Yoshida, Symplectic Integrators for Hamiltonian Systems: Basic Theory, 1992. Unfortunately, this mod doesn't seem to support 1.9.0 I used to run 1.9.1 on 1.9.0, but failed Quote Link to comment Share on other sites More sharing options...
pleroy Posted January 28, 2022 Share Posted January 28, 2022 8 hours ago, Skywavestar said: Unfortunately, this mod doesn't seem to support 1.9.0 I told you so a week ago. No point in trying and trying and trying. You need 1.9.1 (no idea why you would not upgrade). Quote Link to comment Share on other sites More sharing options...
JeromeHeretic Posted January 30, 2022 Share Posted January 30, 2022 Thank you for fixing of GUI crash. It was real pain in ass... Quote Link to comment Share on other sites More sharing options...
eggrobin Posted January 31, 2022 Author Share Posted January 31, 2022 For the new moon (lunation number 273), the new release (हरीश चंद्र) is out. Support for KSP 1.12.3 has been added. Load times of saves with old vessels (especially ones in low orbits) have been improved by reducing save file size (specifically making the histories more compact), fixing the long-standing issue #2400. Note that trajectories computed prior to upgrading to हरीश चंद्र will not be made more compact; only trajectories computed from its installation onwards will be compact. Load times of saves with many flight plans have been improved by deferring the reconstruction of flight plans until they are actually needed. The trajectories drawn in map view are now correctly hidden by terrain, instead of being cut off at sea level regardless of topography. The performance of trajectory plotting has been improved. Thanks to Quadrupole, @Al2Me6, @lpgagnon, and @scimas for reporting bugs in test versions of this release. Thanks to @rnlahaye for contributions improving the performance of some operations on trajectories. See the change log for more details. Quote Link to comment Share on other sites More sharing options...
Makrom Posted February 12, 2022 Share Posted February 12, 2022 On 1/31/2022 at 3:41 PM, eggrobin said: For the new moon (lunation number 273), the new release (हरीश चंद्र) is out. This feels more smooth on my Pc, it was already becoming painfully slow, but with this release is feeling better, so far I like it. Thanks! Quote Link to comment Share on other sites More sharing options...
Jefftheguyperson Posted February 20, 2022 Share Posted February 20, 2022 I am having quite a strange issue. I am playing the Beyond Home planet pack with Principia, and for some reason, the trajectory history of the celestials doesn't show all the time. When the trajectories do show, only 5 or 6 of them show at all. Is it a problem with the Beyond Home Principia patch? What could be causing the problem? Quote Link to comment Share on other sites More sharing options...
Rach Posted February 20, 2022 Share Posted February 20, 2022 Hi guys. I 'm trying to get a 9:2 NRHO (Near Rectilinear Halo Orbit) in RSS with principia. i dont get the orbit will be stable. This is the proposal orbit for Gateway (Artemis program) https://www.youtube.com/watch?v=X5O77OV9_ek No problems with other "halo orbits" like DRO or orbits in L4/L5 (earth-moon) There is any trick/advice? Is possible this orbit with principia/rss??? Someone got it? I'm searching in the forum but i haven't found something like this. By the way...what a wonderfull mod!!! Thx. (sorry for my english) Quote Link to comment Share on other sites More sharing options...
VladTonk Posted February 22, 2022 Share Posted February 22, 2022 Hello. You have a very interesting mod, I especially liked the ability to calculate the trajectory in relation to the surface of the target celestial body. only some of the features available in the stock version are missing. for example, the ability to select the desired point of the trajectory and create a maneuver in it, or speed up time to it. Thanks. Quote Link to comment Share on other sites More sharing options...
eggrobin Posted March 2, 2022 Author Share Posted March 2, 2022 For the new moon (lunation number 274), the new release (Hausdorff) is out. Thanks to @rnlahaye for contributions improving the performance of operations on trajectories on macOS. No new features in this version beyond rnlahaye’s contributions; we have been working on some cleanups and investigating bugs. See the change log for more details. Quote Link to comment Share on other sites More sharing options...
pleroy Posted March 2, 2022 Share Posted March 2, 2022 On 2/22/2022 at 4:18 PM, VladTonk said: only some of the features available in the stock version are missing. for example, the ability to select the desired point of the trajectory and create a maneuver in it, or speed up time to it. The KSP manœuvres are instantaneous, which is not sufficient for the realism that we try to achieve. We are not in the business of reinventing a UI to extend the KSP manœuvres nodes, that's just too much hassle. Regarding speeding up time to reach a manœuvre, you can do that with "Warp to manœuvre" in the flight plan UI. Quote Link to comment Share on other sites More sharing options...
GudPiggeh Posted March 30, 2022 Share Posted March 30, 2022 On 2/20/2022 at 4:18 AM, Rach said: Hi guys. I 'm trying to get a 9:2 NRHO (Near Rectilinear Halo Orbit) in RSS with principia. i dont get the orbit will be stable. This is the proposal orbit for Gateway (Artemis program) https://www.youtube.com/watch?v=X5O77OV9_ek No problems with other "halo orbits" like DRO or orbits in L4/L5 (earth-moon) There is any trick/advice? Is possible this orbit with principia/rss??? Someone got it? I'm searching in the forum but i haven't found something like this. By the way...what a wonderfull mod!!! Thx. (sorry for my english) How close are you getting? That orbit is not fully stable. Wikipedia says "less than 10m/s delta v per year" for gateway's station keeping, so you may have to settle for an orbit that lasts a long time, while setting alarms every few months to manage the orbit slightly. Quote Link to comment Share on other sites More sharing options...
eggrobin Posted April 1, 2022 Author Share Posted April 1, 2022 For the new moon (lunation number 275), the new release (Heine) is out. Thanks to @rnlahaye for contributions improving the performance of the mechanism that rebuilds histories. A save corruption bug which would lead to crashes in map view or when selecting a vessel in the tracking station has been fixed. See the change log for more details. Quote Link to comment Share on other sites More sharing options...
Antares777 Posted April 11, 2022 Share Posted April 11, 2022 Hello everybody, I've encountered a couple of bugs once installed Principia and need help to fix this. I'm on KSP 1.12.3 and the game has ran smoothly, I then installed RO/RSS and still the game runs with no major problem for now. After I installed Principia the the game doesn't let me to set the SAS on maneuver hold after I created a flight plan with principia. I've tried on a sandbox save with the best pod avalaible and full radio signal, I can click SAS pro/retro, normal/antinormal, radial in/out and target/antitarget but the maneuver hold is always greyed out so I can't point my craft in the right direction to execute the maneuver; even Mechjeb fails to work on this matter. I would do it by hand but even the navbal doesn't show the usual blue indicator so I'm out of luck in that sense too. Obviously this function is necessary to progress beyond the Earth orbit so for now I'm stucked. I used Principia with no flaw on the KSP 1.8 so, if no huge changes have been done, it shouldn't be a problem of me not knowing how to use principia. An image is worth more than a thousand words so here's a link to see the problem: https://imgur.com/a/A1D9VE9 Quote Link to comment Share on other sites More sharing options...
Razgriz1 Posted April 11, 2022 Share Posted April 11, 2022 1 hour ago, Antares777 said: Hello everybody, I've encountered a couple of bugs once installed Principia and need help to fix this. I'm on KSP 1.12.3 and the game has ran smoothly, I then installed RO/RSS and still the game runs with no major problem for now. After I installed Principia the the game doesn't let me to set the SAS on maneuver hold after I created a flight plan with principia. I've tried on a sandbox save with the best pod avalaible and full radio signal, I can click SAS pro/retro, normal/antinormal, radial in/out and target/antitarget but the maneuver hold is always greyed out so I can't point my craft in the right direction to execute the maneuver; even Mechjeb fails to work on this matter. I would do it by hand but even the navbal doesn't show the usual blue indicator so I'm out of luck in that sense too. Obviously this function is necessary to progress beyond the Earth orbit so for now I'm stucked. I used Principia with no flaw on the KSP 1.8 so, if no huge changes have been done, it shouldn't be a problem of me not knowing how to use principia. An image is worth more than a thousand words so here's a link to see the problem: https://imgur.com/a/A1D9VE9 You have to click the "Show on navball" button on the Principia Flight Plan window. That will put a maneuver marker on your navball for you to follow. Quote Link to comment Share on other sites More sharing options...
Antares777 Posted April 12, 2022 Share Posted April 12, 2022 Thank you so much, this solved my problem and I really feel so dumb to not have noticed it earlier. I guess I had completely forgot about it after years from first time. In my previous comment I forgot to ask for another minor issue I have after principia (although now afraid to look even double dumb), anyway I can't click on the Moon to set it as target. I can use KER to set targets so it's not a big deal, still I missed something again in some options? Quote Link to comment Share on other sites More sharing options...
Razgriz1 Posted April 13, 2022 Share Posted April 13, 2022 8 hours ago, Antares777 said: Thank you so much, this solved my problem and I really feel so dumb to not have noticed it earlier. I guess I had completely forgot about it after years from first time. In my previous comment I forgot to ask for another minor issue I have after principia (although now afraid to look even double dumb), anyway I can't click on the Moon to set it as target. I can use KER to set targets so it's not a big deal, still I missed something again in some options? I believe it's in KSP Features on the main Principia window. There should be an option somewhere there to "Select Target" which after clicking that should let you click on a vessel or planet/moon to set it as a target as you would in stock. Quote Link to comment Share on other sites More sharing options...
Yaivenov Posted April 16, 2022 Share Posted April 16, 2022 As a navigation aid would it be possible to add a feature to the flight planner to display markers for lagranian points based on frame selection? Quote Link to comment Share on other sites More sharing options...
pleroy Posted April 22, 2022 Share Posted April 22, 2022 On 4/16/2022 at 8:29 PM, Yaivenov said: As a navigation aid would it be possible to add a feature to the flight planner to display markers for lagranian points based on frame selection? This has been proposed before. It's hard. Quote Link to comment Share on other sites More sharing options...
eggrobin Posted April 30, 2022 Author Share Posted April 30, 2022 For the new moon (lunation number 276), the new release (Hermite) is out. The rotation of vessels is now adjusted using Davenport’s Q method, instead of the least rotating part of the vessel; this is not noticeable in most circumstances, but might yield more realistic physical effects for vessels on which large forces (notably, aerodynamic) are exerted. Performance has been slightly improved. Thanks to @rnlahaye for helping with the investigation of an incident in the macOS build. See the change log for more details. Quote Link to comment Share on other sites More sharing options...
SquirrelBomber Posted May 7, 2022 Share Posted May 7, 2022 (edited) Hello, I am running Principia Hermite on Ubuntu 22.04 with the 5.15.0-27 kernel. After Loading my game I received this error message: The Principia DLL failed to load. An unknown error occurred; detected OS Unix 5.15.0.27 64-bit; tried loading dll at 'GameData/Principia/Linux64/principia.so', 'GameData/Principia/MacOS64/principia.so'. Note that libc++abi1-8 and libc++1-8 or later (Linux) or Sierra or later (MacOS) are required. Warning: don't load a Principia save before you have fixed this error; it might get damaged. I cannot see what would have caused this conflict my log is attached via google drive link. If you would prefer I sent it a different way due to security reasons please tell me. KSP log: https://drive.google.com/file/d/1glGuB3EZGflZYv9pF_skAM-9v7ikIDiR/view?usp=sharing Any help at all would be appreciated! Thank you Edited May 8, 2022 by SquirrelBomber accidentally copied wrong part of message Quote Link to comment Share on other sites More sharing options...
WilliamRiker2701 Posted May 9, 2022 Share Posted May 9, 2022 Hi!, i'm having a difficult time trying to complete satellite positioning missions. I'm using RSS as well as Principia.These are the kind of missions where you must position spacecraft at a specific orbit around a celestial object, and i find it very hard to accomplish one specific mission objective: stay in the orbit within reasonable deviation. Since with principia the orbit doesn't stay the same all the time, it's harder to stay at specific Pe and Ap points and also inclination, but looks like no matter how close i managed to make it, the objective doesn't get green ticked. Is it possible to do it? if i try harder i will accomplish the objective, or i'm just going to waste time? Quote Link to comment Share on other sites More sharing options...
MaltYebisu Posted May 10, 2022 Share Posted May 10, 2022 12 hours ago, WilliamRiker2701 said: Hi!, i'm having a difficult time trying to complete satellite positioning missions. I'm using RSS as well as Principia.These are the kind of missions where you must position spacecraft at a specific orbit around a celestial object, and i find it very hard to accomplish one specific mission objective: stay in the orbit within reasonable deviation. Since with principia the orbit doesn't stay the same all the time, it's harder to stay at specific Pe and Ap points and also inclination, but looks like no matter how close i managed to make it, the objective doesn't get green ticked. Is it possible to do it? if i try harder i will accomplish the objective, or i'm just going to waste time? Hi and welcome to the forum. I'm no expert on RP-1 or Principia, however, @NathanKell is currently playing with Principia and a dev version of RP-1. I haven't seen the entire playlist, but I think all missions are supposed to be doable with Principia installed. If you skip ahead in the playlist and videos, perhaps you can see how he did the missions where he needs to position a satellite. I hope it can help you. @SquirrelBomber I don't know anything about how to troubleshoot Principia, but the experts will most likely help you when they have time. I hope you figure it out soon! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.