Skywavestar

I really hope to play this excellent MOD on 1.12

I added a. cfg for F-1 and J-2 engines with the help of others （waterfall）

wow wow I really need Waterfall and realplum configurations

Yes WF☞Waterfall I installed Waterfall and Realplum But the flames of the engine are all the same as the original version I tried writing a. cfg file, but I don't have the foundation. You need to delete: DECQ LEM DECQ PROJECT APOL These two folders

Is this mod compatible with WF or RP? KSP: 1.12.3

Does it not support RSS?

This MOD may encounter a situation where the KK interface cannot be opened under RSSRO

Awesome!！！！！！！！！❤！！

Do you know how to delete a statement? I want to resend it. My display is normal

天宫空间站 型号：KIU

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 memory https://t.bilibili.com/758474676158595120#reply223149052 Modify: 2.0 some errors

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

---------------------------------------------- ---------------------------------- 如何制作自己的模板： ---------------------------------------------- ---------------------------------- 更新 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

1

1

There are pictures on my side. What is the reason? There is nothing wrong with me. The picture is loaded normally.

1

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

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. 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. 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. Notations Terminology 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

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？

I installed KSC. What should I do next? But it doesn't seem to have Wenchang