(1).png.5ea7b391799ff91870afabe85e6332a4.png)
Skywavestar
-
Posts
40 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Skywavestar
-
-
2023年10月19日上午1点46分，Skywavestar 说道：
是的WF☞瀑布
我安装了Waterfall和Realplum
但是引擎的Flame都和原来的版本一样我试着写一个。cfg 文件，但我没有基础。
您需要删除：
DECQ LEM
DECQ PROJECT APOL这两个文件夹
On 2023/10/18 at PM11点31分, Cheesecake said:WF是什么意思？瀑布？我认为不会，因为这个模组已经很老了。最新版本适用于 KSP 1.4.x
和 RP？RP-1 还是 Realplume？Realplume 应该可以工作。但要小心，这个 mod 非常旧，不能保证一切都能在 KSP 1.12.x 中真正运行。
I added a. cfg for F-1 and J-2 engines with the help of others
（waterfall）
-
On 2020/3/11 at PM12点27分, Nittany Tiger said:
还有其他人对RSS / RO版本的 F1 发动机、J2 发动机和 sep/ LES发动机感到奇怪的羽毛吗？就像出于某种原因，RealPlume 会在 DECQ F1 上放置一个 Hypergolic-Upper 羽流。
如果是这样，我确实为 F1 编写了自己的 RealPlume 补丁，它应该适用于绝缘 F1。我只是不知道哪个配置文件将 DECQ F1 标记为“hypergolic”。
稍后我将纠正 J2 发动机和 sep 电机/ LES 的问题。
wow wow I really need Waterfall and realplum configurations
-
2 hours ago, Cheesecake said:
WF是什么意思？瀑布？我认为不会，因为这个模组已经很老了。最新版本适用于 KSP 1.4.x
和 RP？RP-1 还是 Realplume？Realplume 应该可以工作。但要小心，这个 mod 非常旧，不能保证一切都能在 KSP 1.12.x 中真正运行。
Yes WF☞Waterfall
I installed Waterfall and Realplum
But the flames of the engine are all the same as the original versionI tried writing a. cfg file, but I don't have the foundation.
On 2023/10/7 at AM9点08分, Arcade Duck said:刚拿到这个模组，每当我启动游戏时，它就会卡在 Kerbal Space Program\GameData\ATS\SATURN_V\DECQ_PROJECT_APOLLO\SUBSAT
You need to delete:
DECQ LEM
DECQ PROJECT APOLThese two folders
-
On 2018/7/6 at AM12点40分, DECQ said:
只是添加了土星五号火箭的制造细节，仅此而已。
有关此附加组件以及推荐和强制附加组件的所有信息都位于 ZIP 文件中。 请阅读，否则某些功能将无法使用。
经 Bimu (F-1) 和 DennyTX (J-2) 许可，将发动机添加到套件中
v1.0.1
1.将J-2重命名为J2_Engine for RO ..
v1.0.22
1.修复F1和J2的FX RealPlume。
2.更新了工艺文件。
3.稍微改变了Apollo CM/SM/Engine的纹理。v1.0.3
1.游戏中添加了新的登月舱上升阶段模型
2.添加了新的发动机模型aj10-137和LMDE
3.ApolloCM中的玻璃和新的LEM有发光动画，以取代透明玻璃
4.添加了隔热F1，它位于第一级的中心
5.纠正了Cherbams错误地离开LEM的问题
6.改变了火箭的质心，现在它在大气层中控制得更好附加作者：
DECQ
Dragon01没有RO / RSS支持，我的歪手做不到这个......
如果您不怕的话，请下载： https: //spacedock.info/mod/1902/SaturnV
许可证：GPLv2
Is this mod compatible with WF or RP? KSP: 1.12.3
-
On 2020/9/21 at AM1点22分, Gameslinx said:
Parallax
Parallax completely recreates the surfaces of the planets, from the environment all the way down to the terrain detail. It combines a tessellation and displacement terrain shader as well as a completely new scatter system to vastly improve the planet surfaces. Parallax uses GPU instancing for surface objects in order to render massive amounts of geometry at amazing performance.
See Installation Instructions below. Also see the Troubleshooting section below, and direct users here if things are not working!
Watch the new trailer here:
Features Overview
Parallax completely replaces the terrain shader used in the normal game as well as its scatter system for placing thousands of objects over great distances. Here are some of the key features of this mod:
- High quality terrain tessellation shader, like in No Man's Sky
- Trees, grass and many other types of foliage
- Procedural rocks and objects
- Collisions with surface objects
- Self shadowing
- Completely new planetary surface textures
Improvements
The shader that Squad uses for Kerbal Space Program's terrain is extremely limited. Parallax's original feature was a brand new terrain shader, but the scope has expanded to surface objects as well.
Parallax improves upon the stock shader in a number of ways, for example:
- Normal mapped lighting is accurate and faces the right way on a surface at any angle
- Tessellation allows surfaces to have much more complexity, allowing for the creation of lifelike planet surfaces
- No lines/artifacts, unlike the stock shader
The scatter system is also a massive improvement over Squad's implementation:
- 使用计算着色器几乎可以立即生成数百万个对象
- 每个对象都是使用 GPU 实例绘制的，这意味着绘制调用显着减少。这极大地提高了渲染性能
- 每个对象的视锥体剔除
- 物体是可碰撞的
- 按需加载
可用性
系统要求：
最小值 - 禁用散射：
- CPU：视差对 CPU 没有太大影响，所以这并不是一个真正的问题
- GPU：必须支持着色器模型3.0，
- RAM：4GB（禁用分散对象）
最小值 - 启用分散
- GPU：必须支持着色器模型5.0
-
渲染器：推荐使用DX11，但支持OpenGL。由于限制，由于 Apple 放弃了对 OpenGL 的支持，因此不支持 Mac OSX。Linux 运行 OpenGL。
- 必须支持异步GPU读回（如果你不知道这是什么，不用担心）
- 内存：6GB
推荐：
- GPU：DirectX 11、着色器模型 5.0
- 内存：8GB
您可以在这里关注 Parallax 的开发： https://github.com/Gameslinx/Tessellation/
安装
安装视差及其散射的说明：
- 从 GitHub 发布页面下载 Parallax、Parallax_StockTextures 和 Parallax_ScatterTextures。
- 下载并安装哥白尼。最低版本发布 139 或更高版本。
- 打开 Parallax zip 并将 Parallax 文件夹移至 GameData。
- 打开 Parallax_StockTextures zip 并将 Parallax_StockTextures 文件夹移至 GameData。
- 打开 Parallax_ScatterTextures.zip 并将 Parallax_StockTextures 文件夹移动到 GameData，将其与现有文件夹合并。 是的，它们的名字相同。这是故意的。不要错过这一步。
- 启动游戏，并将地形质量设置为“高”。将地形着色器质量设置为“高”或“超高”。Ultra 将启用曲面细分。
可选：此补丁将禁用夏娃的气泡/生命： https ://drive.google.com/file/d/16-nTUbRgQescq4ajQtka1cJnaOzPcgPy/view
需要视频吗？检查下面
故障排除
安装没有按计划进行吗？展开此剧透以查看安装时的常见错误以及如何解决这些错误。
I'm getting a Kopernicus error on the main menu!
You have likely failed to install the two textures folders correctly. You must merge the two Parallax_StockTextures folders from both zip files into GameData. Once you've done this, the Parallax_StockTextures folder in GameData should look like this:
I'm getting an infinite loading screen - the planets in the bottom right corner are moving freely and nothing is happening!
This is usually due to a bad Kopernicus install, but in some cases can be due to a bad KSP install.
- First, try reinstalling Kopernicus. You need version 139 or later, and must also have the Harmony folder in GameData.
- If that doesn't work, reinstall KSP 1.12.3. Some files may have become corrupted or changed over time after previous mods. This is the best way to ensure the mod runs.
There are no trees or grass in the Space Center view!
This is intentional. Right now, scatters don't work in the space center view, and I've not yet figured out how to get them to show.
You will see trees and grass in Flight.
Performance is really bad, my FPS has tanked!
This has been reported to help massively boost framerates, and I advise you share these steps with anyone suffering from the same problem. These are the settings I use to ensure the game runs smoothly:
Step 1 - Update your NVIDIA graphics drivers
Step 2 - Replace the settings.cfg in your Kerbal Space Program folder with this: https://mega.nz/file/JEEgTZ5a#BDhp8Vm8WvcbYd3lO2VCIg_3_8xr1I4ns8-He8pQ_PY
Step 3 - Use these NVIDIA settings:
- Right click on your desktop
- If on Windows 11, choose "show more options", otherwise see next step
- Click "NVIDIA Control Panel",
- Click "Manage 3D Settings".
- Click on the "Program Settings" tab
- Find, or add, the KSP_x64.exe in your Kerbal Space Program folder
- Use the following settings. Not all of these settings will appear for you, but that is fine
I'm seeing weird flashing artifacts that look like Z-fighting on the ground, how do I fix that?
There are two things that cause this.
- City lights are not compatible with Parallax at the moment. Delete the city lights config from the visual pack that provides them.
- If city lights are not causing this, Scatterer might. In the scatterer config, make sure "merge depth pre pass" is set to false. If this does not fix it, a reinstall of Scatterer will.
I have a planet mod installed, but Parallax isn't working and/or I'm getting a Kopernicus error on the main menu!
If this planet mod supports Parallax 1.3.1, it will not support Parallax 2.0.0.
You will need to remove the Parallax configs for those planet mods until they are updated.
常问问题
目前，有一些常见问题。我希望我能在这里回答其中的一些问题：
-
对性能有何影响？
- 您可以预期在 GT 960M 或更高型号上可以很好地运行 Parallax。
-
这是做库存的吗？
- 是的！这也适用于支持它的行星模组。
-
为什么很多灯都滞后？
- 由于某种原因，KSP 使用 Unity 的“前向渲染”路径而不是“延迟渲染”路径。这意味着对于场景中的每个像素光，都会重新计算曲面细分。如果有很多灯光，这会很快增加。在 KSP 移动到延迟渲染路径之前，我对此无能为力。
-
我需要 NASA 超级计算机吗？
- 不
-
这适用于EVE和 Scatterer 吗？
- 是的。Parallax 是与 Scatterer 一起开发的，因此我建议您同时使用它们以获得最佳效果。
-
我可以更改设置吗？
- GameData/Parallax 文件夹中有一个配置。这控制地形着色器的质量以及散射系统的选项
-
你们会为模组制作者发布文档吗？
- 是的，文档正在编写中，并将在 github wiki 上经常更新。
-
这可以与 Rescale / Sigma Dimensions 一起使用吗？
- 是的，但请检查配置，因为必须调整某些值才能看起来正确。
-
我可以在自己的配置中使用 Parallax_StockTextures 中的纹理吗？
- 虽然许可证确实允许您使用它们，但我更 希望您不这样做。 库存纹理是为了改善库存游戏。我不想看到大量使用这些纹理的配置包，因为它剥夺了我为库存行星创建的配置包的独特性。请 - 不要偷懒，自己做。
下载
您可以在此处下载 Parallax for KSP 1.12.x：
- 视差： https: //github.com/Gameslinx/Tessellation/releases
- 请阅读安装说明。
如果您报告错误（如果适用），请让我知道重现错误的步骤。这非常有用。
捐款
如果您想捐款以表达对该模组的感谢或支持其开发，请点击下面我的 Patreon 的链接。您也可以通过捐赠来解锁一些很酷的福利！
捐款绝不是要求的，但我们非常感谢。感谢您下载该模组，或者如果您是长期支持者，感谢您在整个开发过程中坚持使用它
许可
Parallax 根据Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) 获得许可。
这意味着您可以 在以下条件下以任何媒介或格式自由共享、复制和重新分发该材料：
- 归属 - 您必须给出适当的信用，提供许可证的链接，并表明是否进行了更改。您可以以任何合理的方式这样做，但不得以任何暗示许可方认可您或您的使用的方式。
- 非商业性 — 您不得将该材料用于商业目的。
- 禁止衍生品 — 如果您重新混合、转换或在材料的基础上进行构建，则不得分发修改后的材料。
Does it not support RSS?
-
于 2019/4/23 于 12:04, flart 说道：
在KSC海岸附近添加 2 个新生成点 ：船在水面上，潜艇在水下（仅在 SPH中）。
我忍不住在岸上添加了一些东西：一座塔和码头。
您还可以在 Kerbin 上找到 2 个新*水下异常（使用 KerbNet 或SCANsat定位它们）。船的生成点是 mod 的目的，所以我不会添加很多静态对象。
Kerbal Konstruct和Module Manager是依赖项。
KK 支持库存启动站点列表。
此外，KK 有自己的 KK 发射点列表，您可以在其中打开/关闭发射点，它们将分别出现/消失在库存列表中。
默认情况下，海平面启动站点是打开的。
该模组应该在重新缩放的系统或那些“升级的KSC ” 模组 上工作。
推荐DLC Making History，没有DLC，就会有另一个塔，没有码头KottabosGames视频 (v0.9.1)：
下载：
发布页面： https: //github.com/yalov/WaterLaunchSites/releases
支持本地化。
捐赠： Patreon
This MOD may encounter a situation where the KK interface cannot be opened under RSSRO
-
On 8/20/2020 at 3:29 AM, blackrack said:
EVE-Redux
This is my continuation of EVE (Environmental Visual Enhancements). This started as a performance-enhanced version of EVE.
See here for EVE (thanks for everything @rbray89).
This build also integrates @R-T-B's and @BIOZ fixes for 1.10.
Information about current EVE-Redux
This version uses a few more modern rendering tricks:
- Cloud shadows are rendered using the depth buffer instead of re-rendering most of the scene's geometry with a projector (saves a lot of CPU time, culling the scene+sending draw calls)
- Celestial shadows are also rendered using the depth buffer instead of re-rendering most of the scene's geometry with a projector (saves a lot of CPU time, culling the scene+sending draw calls)
- All the particles in a volumetric cloud layer are rendered at once in a single draw-call, instead of one draw-call per particle, saving CPU time
- One MeshRenderer and one GameObject per volumetric layer instead of one per particle
- Volumetric particles are rendered at 1/4 the screen resolution then upsampled with a depth-aware filter and composited into the scene, saving GPU power
So how fast is it really?
My test results:
My own results with an i5-3470 and a GTX 1080 at 1440p, very CPU-bound in KSP. Left is last release, right is this build, framerate can be seen in the corner:
At runway with EVE only, 98 vs 121 fps:
At runway with scatterer+EVE 68 vs 97 fps:
Zoomed out with scatterer+EVE 45 vs 69 fps:
EVE surface with scatterer+EVE, an absolutely ridiculous 27 vs 87 fps (this scales much better with a higher number of clouds and volumetrics)
Full comparison album: https://imgur.com/a/gl2Yonq
Test results from users:
@Poodmund's test results with stock EVE configs and modified density configs:
Full post:
Test results with spectra:
@airtrafficcontroller results (15% performance increase in-game): https://forum.kerbalspaceprogram.com/index.php?/topic/196411-110x-eve-redux-performance-enhanced-eve-build/&do=findComment&comment=3841285
@RyanRising's results (no significant performance difference in-game) https://forum.kerbalspaceprogram.com/index.php?/topic/196411-110x-eve-redux-performance-enhanced-eve-build-v11111-26082020/&do=findComment&comment=3844819
Test results with SVE:
@TheKurgan's results (~6% performance increase in-game) : https://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip110x-scatterer-atmospheric-scattering-v00630-19082020/&do=findComment&comment=3840894
Known issues:
-You might notice a bit of aliasing now that all effects use the depth buffer
-Volumetrics may appear visible from underwater with scatterer
Downloads
Spacedock: https://spacedock.info/mod/2631/Environmental Visual Enhancements Redux
Github: https://github.com/LGhassen/EnvironmentalVisualEnhancements/releases/
Configs:
Configs are to be downloaded from the default EVE config:https://github.com/WazWaz/EnvironmentalVisualEnhancements/releases/download/EVE-1.2.2-1/EnvironmentalVisualEnhancements-Configs-1.2.2.1.zip or your favourite visual pack
Changelogs:
***********Redux 1.11.7.1*********** - Fix flickering city lights with Parallax (added a small depth offset) - Fix volumetrics in VR (thanks @JonnyOthan) for Kerbal-VR https://github.com/JonnyOThan/Kerbal-VR - Fix a nullref and some game event leaks (Thanks @BrettRyland and @GotMachine) ***********Redux 1.11.6.1*********** -Fixed flickering clouds in reflections (most noticeable on TU parts) ***********Redux 1.11.5.1*********** -Fix compatiblity with 1.10-1.11 (recompile shaders with older unity version) ***********Redux 1.11.4.1*********** -Fix clouds shadows breaking TAA (scatterer/tufx) in low orbit -Fix BuildManager exception during load (Thanks @al2me6) -Add terrain ultra material support for 1.9+ (Thanks @Bioz) ***********Redux 1.11.3.1*********** -Fix cityLights not appearing with latest scatterer versions (0.0770+) ***********Redux 1.11.2.1*********** -Fix depth precision issues on cloud shadows -Cloud shadows are visible all the way instead of only ~20 km around camera -Fix 2D clouds fading into the planet when zooming out -Fix issue where clouds are stuck when loading savegame from KSC ***********Redux 1.11.1.1*********** -Volumetrics fade near the camera, more natural transition -Fix flickering on volumetrics -Disable mixed-resolution volumetric rendering on OpenGL (buggy) ***********Redux 1.0*********** Performance improvements: -Cloud shadows are rendered using the depth buffer instead of re-rendering most of the scene's geometry with a projector -Celestial shadows are also rendered using the depth buffer instead of re-rendering most of the scene's geometry with a projector -All the particles in a volumetric cloud layer are rendered at once in a single draw-call, instead of one draw-call per particle, saving CPU time -One MeshRenderer and one GameObject per volumetric layer instead of one per particle -Volumetric particles are rendered at 1/4 the screen resolution then upsampled with a depth-aware filter and composited into the scene, saving GPU powerDiscord:
I don't have an official Discord but I usually hang out in the EVE and scatterer channels of the kopernicus discord so you can find me there: https://discord.com/invite/uA69S3zZqf
Donations:
I do this in my spare time, if you like what I do you can support me here:
Patreon:
Paypal:
Awesome!！！！！！！！！❤！！
-
12 hours ago, Vanamonde said:
您的图片链接似乎无效。
Do you know how to delete a statement? I want to resend it.
My display is normal -
在 2013/4/19 在 AM5 点 58 分，NuclearWarfare 说道：
你好截图的一个而而而
以下是旧线程序中列出的一些规则（因为Skunky说得最好！）：
F1在游戏中截图。
只在剧透标签中张贴超过1920x1080的图片。（这是规则的例子外情，并经工人批准）这是一个屏幕截图告示程序了6，堵截了。
最好先将您的照片上传到在线主机，如imgur、photobucket等。
尝试以您可以运行KSP的最大分辨率拍摄屏幕。
F2允许您隐藏HUD。没有它，一些（但不是全部）图片如环境照片看起来更好。
在.14中，鼠标中键将允许您在相机轴而不是中心点上俯仰和偏航
欢迎来到酷炫任务的按时间顺序排列的蒙太奇！
天宫空间站
型号：KIU
-
On 4/19/2013 at 5:58 AM, NuclearWarfare said:
你好截图的一个而而而
以下是旧线程序中列出的一些规则（因为Skunky说得最好！）：
F1在游戏中截图。
只在剧透标签中张贴超过1920x1080的图片。（这是规则的例子外情，并经工人批准）这是一个屏幕截图告示程序了6，堵截了。
最好先将您的照片上传到在线主机，如imgur、photobucket等。
尝试以您可以运行KSP的最大分辨率拍摄屏幕。
F2允许您隐藏HUD。没有它，一些（但不是全部）图片如环境照片看起来更好。
在.14中，鼠标中键将允许您在相机轴而不是中心点上俯仰和偏航
欢迎来到酷炫任务的按时间顺序排列的蒙太奇！
1099 components. When my KSP opens this archive, it may not respond for 1 minute, and then it returns to normal, but the frame rate becomes very low after startup; I can only play this "brick" in SPH/VAB
I5-12490F
iGame RTX-3060-12GB-L
32GB memoryhttps://t.bilibili.com/758474676158595120#reply223149052
Modify:
2.0 some errors
Quote1099 components. When my KSP opens this archive, it may not respond for 1 minute, and then it returns to normal, but the frame rate becomes very low after startup; I can only play in SPH / VAB
I5-12490F
iGame RTX-3060-12GB-L play with this "brick" -
On 2023/1/10 at AM5点25分, Ryaja said:
我看不到图片，所以我翻译了文字，上面写着“图片来自QQ空间，未经允许不得转载”，我不知道那个网站在中国以外的地方工作。
I don't know what caused this for the time being
I tried to check it, but there were no mistakes
It may be due to the censorship of the network
（ Machine Translation）
-
This is a satellite I made. It runs in synchronous orbit
-
在 2014/7/1 于 PM11 点 10 分，arc5555 说道：
不知何故，所有图像都不起作用
---------------------------------------------- ----------------------------------
所有零件都在这里>链接<
---------------------------------------------- ----------------------------------
所有图像都调整为 1380x2048
---------------------------------------------- ----------------------------------
最高捐赠：
亚历克斯·克拉克
艾伦·克里斯滕森
---------------------------------------------- ----------------------------------
社区创作
FishInferno 制造的真正酷炫的 kerbal 火箭（图片可点击）
MoffKalast 完成的很棒的 Mk3 穿梭机：
---------------------------------------------- ----------------------------------
如何制作自己的模板：
---------------------------------------------- ----------------------------------
更新 1.8
http://www.mediafire.com/convkey/ff02/mpb1r7811cv8n7gzg.jpg
添加了新的起落架、氙气罐和散热器：
LY-01 固定起落架
LY-05 可操纵起落架
LY-50 中型起落架
LY-99大型起落架
PB-X750 氙灯容器
散热器面板（大）
散热器面板（小）
热控系统（大）
热控系统（中型）
热控系统（小）
---------------------------------------------- ----------------------------------
更新 1.7.9
添加了除起落架和新氙气罐外的所有 1.0 部件：
减速板
高级鸭式
高级鼻锥 - A 型
高级鼻锥 - B 型
AE-FF1 气流保护壳 (1.25 m)
AE-FF2 气流保护壳 (2.5 m)
AE-FF3 气流保护壳 (3.75 m)
大气流体光谱变差计
基本款
大 S 三角翼
大 S 升降机 1
大S升降机2
Big-S航天飞机尾翼
大S翼板
Ch-3 电传飞行电子设备中心
圆形摄入量
“Drill-O-Matic”矿用挖掘机
发动机舱
发动机预冷器
FAT-455 飞机控制面
FAT-455 飞机主翼
燃料电池阵列
燃料电池
隔热罩 (1.25 m) + 罩
隔热板 (2.5 m) + 盖板
隔热罩 (3.75 m) + 罩
ISRU转换器
大型储罐
M700 测量扫描仪
M4435 窄带扫描仪
Mk1 直列式驾驶舱
NCS适配器
冲压进气口
RT-5“跳蚤”固体燃料助推器
服务区 (1.25 m)
服务区 (2.5 m)
小型储罐
小鼻锥
标准鸭
表面扫描模块
后掠翼
尾部连接器 A
尾部连接器 B
尾鳍
---------------------------------------------- ----------------------------------
更新 1.7
调整了所有图像的大小 + 添加了这些新的库存部件：
2.5m 转 Mk2 适配器
C7 品牌适配器 - 2.5m 至 1.25m
C7 品牌适配器倾斜 - 2.5m 至 1.25m
Mk3 货舱 CRG-25
Mk3 货舱 CRG-50
Mk3 货舱 CRG-100
Mk3驾驶舱
Mk3 液体燃料机身
Mk3 火箭燃料机身
Mk3 至 2.5m 适配器
Mk3 到 2.5m 适配器倾斜
Mk3 至 3.75m 适配器
Mk3 到 Mk2 适配器
---------------------------------------------- ----------------------------------
更新 1.6
添加了这些新的库存零件：
三角翼
升降舵
Mk1驾驶舱
Mk1 机身 - 进气口
Mk1 机身 - 喷气燃料
Mk2双耦合器
Mk2 货舱 CRG-04
Mk2 货舱 CRG-08
Mk2 夹紧式 O-Tron
Mk2驾驶舱
Mk2 乘员舱
Mk2 无人机核心
Mk2 直列式驾驶舱
Mk2 LF +O 机身短
Mk2 LF +O 机身
Mk2 液体燃料短机身
Mk2 液体燃料机身
Mk2 单组元燃料罐
Mk2 转 1.25m 适配器长
Mk2 至 1.25m 适配器
激波锥进气口
小三角翼
结构机身
结构摄入量
结构翼
后掠翼
翼板
Z-100 充电电池组
---------------------------------------------- ----------------------------------
更新 1.5
添加了这些 RLA Stockalike 零件：
双模 Arcjet 推进器
双峰阻力喷射推进器
Boostertron l 固体火箭助推器
Boostertron ll 固体火箭助推器
FL-R15单组元燃料罐
FL-R50单组元燃料罐
FL-R200单组元燃料罐
FS-L12油箱
FS-L25油箱
FS-L50油箱
FS-L100
ION Type-2 静电推进系统
LV-Nc 原子火箭发动机
LV-T5液体燃料发动机
MMRTG
MPR-1单组元发动机
MPR-1R单组元发动机
MPR-5单组元发动机
MPR-5R 单体推进剂发动机
MPR-45单组元发动机
MTS-20 堆栈双适配器
MTS-30 堆栈三适配器
MTS-40 堆栈四路适配器
PB-x450 氙灯容器
PE-3 径向连接点
防护火箭鼻 Mk1
Rockomax 'Spinnaker' 液体发动机
Stratus-V 封装单组元燃料罐
TR-1V 堆栈解耦器
TT-16 径向解耦器
TtH-2B“翠鸟”液体发动机
TtK-6A“信天翁”单体推进剂发动机
TtKH-6B“鸬鹚”单体推进剂发动机
TVR-50R 径向齿条扩展器
TVR-100R 径向堆叠扩展器
---------------------------------------------- ----------------------------------
更新 1.4
添加了这些 KSOS 部分：
先进的大型太阳能电池阵列
ChemKorp Mystery Goo Light
对接端口，标准
对接端口，八角形
对接端口，小
对接端口，方形小号
绿色实验室
栖息地
卡尔巴实验室
KSO 辅助燃料供应
模块耦合适配器
观察模块
八角形 6 路框架集线器
八角形 6 路集线器
八角桁架
QA-2× 联轴器，扩展
QA-3C联轴器，T
QA-4× 联轴器，4 路
QA-6× 联轴器，6 路
QA-D12 对接模块
QA-D24 对接模块
单块太阳能电池板
太阳能电池板桁架
方形桁架枢纽
标准，太阳能电池板阵列
车站对接模块
电站电源模块
车站服务拖轮
---------------------------------------------- ----------------------------------
更新 1.3
添加了这些 KSOS 部分：
EWBCL CSE
EWBCL机身
EWBCL 齿轮
EWBCL之翼
EWBCL RCS模块
EWBCL 舵
EWBCL 尾翼
QA-900 液体燃料增压器
QA-1200 外置油箱
推力最大 300
---------------------------------------------- ----------------------------------
更新 1.2
添加了这些 KSOS 部分：
KSO 货舱
KSO驾驶舱
KSO 升降机
KSO 发动机支架
KSO齿轮
KSO 尾翼
KSO之翼
KSO 垂直控制面
全能40t
QA-850 液体燃料增压器
推力最大 200
Thrustmax 外部油箱
TT-750
---------------------------------------------- ----------------------------------
更新 1.1
添加了所有“Spaceplane Plus”部件：
Mk2双耦合器
Mk2 货舱 CRG-04
Mk2 货舱 CRG-08
Mk2 夹紧式 O-Tron
Mk2驾驶舱
Mk2 乘员驾驶舱
Mk2 无人机核心
Mk2 机身LFO短
Mk2 机身低频振荡器
Mk2 机身短
Mk2机身
Mk2 直列式驾驶舱
Mk2 转 1.25m 适配器长
Mk2 至 1.25m 适配器
激波锥进气口
SP+三角翼
SP+ 升降机 1
SP+ 升降机 2
SP+ 升降机 3
SP+ 升降梯 4
SP+ 升降机 5
SP+ 小型三角翼
SP+ 结构翼 A 型
SP+ 结构翼 B 型
SP+ 结构翼型 ¡
SP+ 结构翼型 â€
SP+ 翼型连接器 A 型
SP+ 翼型连接器 B 型
SP+ 翼型连接器 C 型
SP+ 翼型连接器 D 型
SP+ 翼型连接器 E 型
SP+ 翼板
结构摄入量
---------------------------------------------- ----------------------------------
更新 1.0
添加的部分：
立方八角支柱
（重做）LT-1 着陆支柱
LT-2 着陆支柱
LT-5 微型起落架
冲压进气口
传感器阵列计算鼻锥
TT18-A发射稳定性增强器
XM-G50 径向进气
---------------------------------------------- ----------------------------------
更新 0.9
新的部分是：
BZ-52 径向连接点
EAS-1外置指挥座
FL-A5 适配器
FL-A10 适配器
NCS适配器
PB-ION电力推进系统
PB-X50R 氙气容器
PB-X150 氙灯容器
（重做）Rockomax 品牌适配器 02
---------------------------------------------- ----------------------------------
更新 0.8
全新零件：
2.5 m 扩展整流罩底座
2.5 m 扩展整流罩半
2.5 m 扩展墙半
通讯 DTS-M1
Communotron 16
Communotron 88-88
Telus 移动增强器
Telus-LV Bay 移动增强器
---------------------------------------------- ----------------------------------
更新 0.7
新零件：
高级抓取单元
发射逃生系统
LFB KR-1x2
S1 SRB -KD25k
Kerbodyne ADTP-2-3
Kerbodyne KR-2L 高级发动机
Kerbodyne S3-3600 坦克
Kerbodyne S3-7200 坦克
Kerbodyne S3-14400 坦克
KR-2L 盖
S3 KS-25x4 引擎集群
TR-38-D
---------------------------------------------- ----------------------------------
更新 0.6
添加 ：
液压分离歧管
M-1x1 结构面板
M-2x2 结构面板
M-Beam 200 I-Beam 袖珍版
M-Beam 200 工字梁
M 型梁 650 工字梁
O-10单组元发动机
OX-4L光伏板
探针体HECS
探针体 OKTO2
探测体QBE
RT-10 固体燃料助推器
小挂点
Stayputnik Mk.1
结构塔
Not-Rockomax 微节点
TT-38K 径向解耦器
TT-70 径向分离器
---------------------------------------------- ----------------------------------
更新 0.5
具有这些部分：
探测体RoveMate
RoveMax 型号 M1
RoveMax 型号 S2
RoveMax 型号 XL3
TR-2L 加固车轮
---------------------------------------------- ----------------------------------
更新 0.4
什么是新的 ：
SC-9001 小科学
Mystery Goo 遏制
双C地震加速度计
PresMat 晴雨表
GRAVMAX 负重液检测器
2HOT温度计
Mk1 着陆罐
LV-1R 液体燃料发动机
Rockomax 24-77
Rockomax Mark 55 径向安装液体发动机
LV-1液体燃料发动机
洛克玛克斯 48-7S
LV-T30液体燃料发动机
LV-T45液体燃料发动机
LV-N 原子火箭发动机
环形气塞火箭
分离子一号
弗诺引擎
Rockomax 48-7S 盖
LV-T30 液体燃料发动机罩
LV-T45 液体燃料发动机罩
LV-N 原子火箭发动机罩
Oscar-B 油箱
ROUND-8 环形油箱
---------------------------------------------- ----------------------------------
更新 0.3
这带来了：
不知道（TT）
---------------------------------------------- ----------------------------------
更新 0.4
完整展开列表：
Mk1驾驶舱
Mk2驾驶舱
Mk3驾驶舱
剑杆发动机
涡轮喷气发动机
基本喷气发动机
Rockomax BACC 固体燃料助推器
径向发动机体
圆形摄入量
发动机舱
标准数控
气动鼻锥
防护火箭鼻 Mk7
三角翼
后掠翼
结构翼
翼连接器
AV-T1 小翼
尾鳍
AV-R8 小翼
标准鸭
高级鸭式
标准控制界面
小型控制面
Delta-豪华翼梢小翼
小齿轮湾
Z-1k 充电电池组
照明器 Mk1
照明器 Mk2
---------------------------------------------- ----------------------------------
更新 0.1
所以，我整个六月都在努力工作，我想我可以发布我项目的 Alpha 版本 =) 这里有一些照片：
那是我妈妈的生日，你可能已经看到了
呜呜
和荣耀对接
所以我已经展开了所有游戏部分的大约 1/3，我的工作还在继续。
所有零件都可以在这里下载>链接<
我打算每周或更长时间更新主题
希望在评论中看到你的作品！
---------------------------------------------- ----------------------------------
如果您想用一点点钱来支持我的项目，这是我的网络货币钱包：Z115199211496（美元）；E411998938718（欧元）；R339054727082（擦）
或者 ->
---------------------------------------------- ----------------------------------
您也可以通过Twitter与我联系
I really want to see what it looks like, but it's raining all the time
-
On 4/19/2013 at 5:58 AM, NuclearWarfare said:
你好！由于屏幕截图的最后一个线程由于还原而消失了，让我们将此作为我们当前的屏幕截图。请为大量屏幕截图制作画廊，以免它们阻塞页面并使屏幕截图加载时间更长！
以下是旧线程中列出的一些规则（因为 Skunky 说得最好！）：
F1在游戏中截图。
如果图片超过 1920x1080，请仅在剧透标签中发布图片。（这是规则的一个例外，并由工作人员批准）这是一个截图线程，因此给出了 56k 警告。
最好先将您的图片上传到 imgur、photobucket 等在线主机。
尝试以您可以运行 KSP 的最大分辨率拍摄屏幕。
F2 允许您隐藏 HUD。没有它，一些（但不是全部）图片（如环境照片）看起来会更好。
在 .14 中，鼠标中键将允许您在相机的轴上而不是中心点上俯仰和偏航
欢迎来自酷任务的编年蒙太奇！
1
-
On 4/19/2013 at 5:58 AM, NuclearWarfare said:
你好！由于屏幕截图的最后一个线程由于还原而消失了，让我们将此作为我们当前的屏幕截图。请为大量屏幕截图制作画廊，以免它们阻塞页面并使屏幕截图加载时间更长！
以下是旧线程中列出的一些规则（因为 Skunky 说得最好！）：
F1在游戏中截图。
如果图片超过 1920x1080，请仅在剧透标签中发布图片。（这是规则的一个例外，并由工作人员批准）这是一个截图线程，因此给出了 56k 警告。
最好先将您的图片上传到 imgur、photobucket 等在线主机。
尝试以您可以运行 KSP 的最大分辨率拍摄屏幕。
F2 允许您隐藏 HUD。没有它，一些（但不是全部）图片（如环境照片）看起来会更好。
在 .14 中，鼠标中键将允许您在相机的轴上而不是中心点上俯仰和偏航
欢迎来自酷任务的编年蒙太奇！
1
-
-
在 2013/4/19 在 AM5 点 58 分，NuclearWarfare 说道：
你！截图最后一个个而消失消失了，让消失消失消失消失消失消失我们将将将此此此作为作为我们我们当前当前的屏幕屏幕屏幕截图截图。。请请为制作制作制作制作
以下是旧线程序中列出的一些规则（因为Skunky说得最好！）：
F1在游戏中截图。
如果图片超过1920x1080，请只在剧透标签中发布图片。（这是规则的一个例子外，并由工人批准）这是一个截图梯队6。
最好先将您的图片上传到imgur、photobucket等在线主机。
尝试以您可以运行KSP的最大分辨率拍摄屏幕。
F2允许您隐藏HUD。没有它，一些（但不是全部）图片（如环境照片）看起来会更好。
在.14中，鼠标中键将允许您在相机的轴上而不是中心点上仰仰和偏航
欢迎来到酷任务的编年蒙太奇！
1
-
On 2017/12/22 at AM3点24分, The White Guardian said:
坎巴拉太空计划
后期处理模组
介绍 KS3P (KSP Post Processing -> KSPPP -> KS3P)，一个旨在为 Kerbal Space Program 带来后期处理效果的模组。
有没有想过'为什么虚幻引擎游戏与 Unity 引擎相比总是看起来如此流畅？嗯，这就是后期处理的结果。请参见下面的示例：
这是我自己电脑上的另一个演示。
没有后处理：
带后处理：
截图
他们说一张图片能说出一千个单词。多亏了 KS3P，他们甚至可以说更多。这里有几个并排比较。
特征
- 使用后期处理效果让 KSP 看起来比以往任何时候都更好！
- 低 CPU 和 GPU 成本！
- 与所有你最喜欢的模组一起使用！（包括 CameraTools！）
但是越来越好...
- KS3P 是完全可配置的，这意味着每个后处理效果都可以微调。模组制作者甚至可以将效果配置设置为特定于场景
- KS3P 有几个功能可以玩：
下载
模组： SpaceDock [V6.1 for KSP 1.7.X]
源代码：GitHub
文档：
https://docs.unity3d.com/Packages/[email protected]/manual/index.html _ _
游戏内编辑器：
使用 Left-Alt + 3 打开-关闭。文档在路上。
It looks good, but can it run in 1.9.0?
-
I successfully installed and run this module in 1.9.0
However, there will be some "magical" errors in this module
For example:
The slewing platform cannot rotate
Explosive rocket card -
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）已发布。
有关更多详细信息，请参阅更改日志。
为了方便我们的中国用户，二进制文件可以从 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），新版本（哥德巴赫）已经发布。
有关更多详细信息，请参阅 更改日志 。
为了方便我们的中国用户，二进制文件可以从 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），新版本 ( Гельфонд ) 已发布。
有关更多详细信息，请参阅 更改日志 。
为了方便我们的中国用户，二进制文件可以从 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:
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
2016-05-20
Буняковский 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
Terminology
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?
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
-
On 2022/1/25 at AM7点00分, jimmymcgoochie said:
屏幕截图在这里很有用。地图视图中、飞行中甚至地面上是否没有城市灯光？检查您是否已正确安装所有模组，并且您的模组版本是否适合您的 KSP 版本；或者，更好的是，使用CKAN为您完成！
-
10 minutes ago, Skywavestar said:
所有必要的模组都已正确安装，但 rssve 的黑暗面没有城市之光
这是什么原因？还是rssve没有配备城市灯？
I download files in GitHub. The steps are as follows:
RSSVE➡texture➡Detail texture➡
I found many files. What should I do if I want to add city lights?
I hope I can get help. I don't know how to add or set it
#RSSVE
-
All necessary mods are installed correctly, but there is no city light on the dark side of rssve
What's the reason for this? Or is rssve not equipped with city lights？
-
34 minutes ago, ameerkat said:
if you use ksrss/rss you can install KSC switcher (https://github.com/KSP-RO/KSCSwitcher/releases) to set the ksc to wenchang. If you're looking for the launch tower idk where that is from
I installed KSC. What should I do next?
But it doesn't seem to have Wenchang
) 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.
).
[1.10.x] Grounded - Modular Vehicles R5.0 (Mining Modules, Rotor Emergency Light) (Jun 5 2019)
in KSP1 Mod Releases
Posted
I really hope to play this excellent MOD on 1.12