BComFly

A Chinese version of this release description is attached after the English version. 该帖的中文版附在英文版之后。 What this mod does This mod is a tool where you can compare and choose the most suitable engines for your ship. What does “most suitable” mean? Basically, it means that your ship meets a certain dv and TWR requirement, while having the lowest total weight. You may choose and compare between at most 3 engines from the game (except SFB), each categorized by their fuel types. To use the “Engine Performance Chart”, you must specify the payload of your ship (payload must contain all necessary part excluding the engine and the fuel or fuel tanks that may be utilized by the engine). Then, you may choose to draw the x-axis by setting a target dv or a target TWR. You may now use the chart generated to choose the “most suitable” engine. If you speak Chinese, you can watch this video for more details on how this mod works. What this mod does NOT The calculation assumes that all the fuel tanks you are using have the same wet-to-dry ratio (which is true for stock liquid fuel and oxidizer, excluding MK2 and MK3 parts). Therefore, if you use fuel tanks with variable w/d ratios, or have w/d ratios different from what is showing in the mod menu, the calculation will be inaccurate. Fortunately, w/d ratio is normally not very impactful, so the calculation would still be close enough to the actual results. In the future, a feature where you can input custom w/d ratio will be implemented to compensate for this issue. As of now, not all modded fuel types are supported (especially Real Fuel). If you see an engine showing a w/d ratio of 1, it means that the fuel type of this engine is not supported, and it will not be shown in the graph. More mod compatibility will be added in the future. However, I personally do not plan to add Real Fuel compatibility myself, because I am not familiar with RF. For engines with multiple modes (Rapier, for instance), only its first listed mode can be used in calculation. Engines with variable specific impulse (for example, some engines in Far Future Technologies have this feature) will not be supported. Engines embedded with fuel tanks (Twin-boar, for example) will also generate false results. Download CKAN recommanded https://spacedock.info/mod/3849/Ship Engine Optimization Source Below is the Chinese version of the above description. 以下为上文的中文版。如有错漏请以英文版为准。 这个mod是干什么的？ 您可以先观看这个视频了解这个mod的基本原理和使用方法。 这是一个用于为您的飞船选择最合适发动机mod。什么叫做“最合适”呢？基本上就是指您的飞船能够达到一定的dv和TWR指标，同时还拥有最小的总质量。 您可以选择游戏中的至多3个发动机（固推除外），所有发动机都依据它们所使用的燃料分类。要使用“Engine Performance Chart”，您需要指定飞船载荷的质量（载荷需要包含除了发动机自身、以及发动机所使用的燃料或燃料罐之外的所有必要组件）。然后，您还可以选择用指定dv还是指定TWR的方式来绘制该图像的x轴。在这之后，您就可以通过显示的图像来选择“最合适”的发动机了。 这个mod有什么限制？ 所有计算都基于一个假设，即发动机使用的燃料罐都拥有相同的干质比（对于原版的液体燃料和氧化剂这个假设是成立的，MK2和MK3的部件除外）。如果您混用不同干质比的燃料罐，或者您使用的燃料罐与菜单里显示的干质比不同，该mod的计算就不准确了。幸运的是，干质比的影响一般比较小，所以计算的结果仍然会与实际结果相近。未来会加入自定义干质比的功能来解决这个问题。 目前非原版燃料的支持还不完善（尤其是RF）。如果您看到某个发动机干质比数据为1，就说明该燃料还不支持。未来会加入更多的非原版燃料数据，但由于作者对RF不熟悉，作者自己可能不会做RF的支持。 对于拥有多模式的发动机（比如Rapier），只能读取配置中的第一个模式。 不支持拥有可变比冲的发动机（例如Far Future Technologies中的一些发动机就有这个功能）。 不支持自带燃料罐的发动机（例如“双猪”）。

I agree, we need an option to lay heat tiles on wings and other parts. Otherwise, we can't even recover a space shuttle at current state.

I think you got the point. They unified the internal/external temperature, but it doesn't seem they adjust the max temp accordingly. The re-entry environment became very harsh as a result. My SSTO has its wing (mid-size) melted at 60 km and 2.1 km/s at Kerbin, at which it is definitely a safe situation in KSP1. As of now, SSTO is merely implausible because of re-entry heating. The only way to reduce temperature during re-entry at this moment is to use ablator, which wings just doesn’t have.

As we all know, in KSP 2 celestial bodies can have tilted rotational axis. However, there is currently no way to know the rotational axis of your target, unless you time warp and watch it with your own eyes. This may be okay for a simple exploration mission, but for a colonization mission later on, knowing the rotational axis becomes a valuable information, as your orbital inclination relative to the equatorial plane dictates whether or not you can land at your target. It is also a pain to guess whether you are in an equatorial orbit or not when tilted axis are in play. Please consider adding some display for the tilted axis. It would be better if it could be set as a display option. I have some suggestions on how this information could be displayed. 1. Show the axis. Simple and easy. We can also add an arrow to indicate the north. 2. Highlight the equator. In my opinion, knowing the equator is much more valuable than knowing the axis. Most of the time, we are more interested in finding the equator. Although the highlighted equator can be a bit distractive when you are trying to look at the surface near the equator, we can always fade it out just like how we fade out a planet’s orbit when zoomed in. Below is a simple sketch showing my two suggestions.

Recently I found that performing plane-changing maneuvers using the maneuver planer will give very inaccurate results. I noticed that the maneuver marker was changing its position during the burn. After a little investigation, I can finally confirm that there is currently an inconsistency between a planned maneuver node and the maneuver marker. When you are planning a maneuver node, the system assumes you will be accelerating in a fixed direction relative to the celestial body. However, when you are performing the planned maneuver, the maneuver node marker (on the Nav ball) is calculated relative to current velocity. So if you are following the maneuver marker during a plan-changing burn, the result will be significantly different. If you want to perform a burn similar to your plan, you will need to change to SAS lock when the burn starts. Surprisingly, this inconsistency does not apply to prograde/retrograde burns, because a prograde/retrograde maneuver in the planner will actually consider the velocity change during the burn. I can see that this is a good addition to prepare for the very-low-thrust spacecraft in the future, but why does this feature only apply to prograde/retrograde burns? We at lease expect some consistency in all directions.

So to be more accurate, I will rephrease it as "the most absurd idea in my opinion". Everyone will think of KSP 2 differently, but this idea was so bad that I had to join the forum for the first time and post a feedback immediately.

As you all might have known, in 0.1.2 there is a new “feature” that you can no longer plan a maneuver node exceeding the total delta-v of the current vessel, which in my opinion is the most absurd idea ever. There are two main reasons why I think we should not be banned from an “impossible” maneuver. 1. Planning a maneuver, even if it’s beyond the vessel’s capability, is the most accurate method to gain information on how to traverse between celestial bodies. You will learn a lot about the timing, the trajectory, and most importantly the delta-v requirement by just playing with the maneuver planner. This practice cannot be replaced simply by a delta-v map. The current in-game Trip Planner is Kerbin-centric, meaning that it only provides information assuming you are starting from Kerbin. For example, if you want to land on Tylo, you will know that the total delta-v requirement staring from Kerbin’s surface is about 9 km/s. However, if you are doing a Jool V mission, and want to transfer to Tylo from a low Laythe orbit, the current Trip Planner will not give you an accurate result. In KSP1, if a player is presented with a new celestial system without a delta-v map, this practice is the only way for them to obtain the delta-v requirement and plan their trips ahead. Blocking access to imaginary maneuver nodes makes it harder for player to obtain delta-v information from a new system or in a new situation. Even if your mission failed because you ran out fuel, you still want to know how much delta-v you are short on, so you don’t fail the next time! 2. The current delta-v calculator is already a mess, and you are building a game influencing mechanics on a disaster. The delta-v calculator does not always return you the correct delta-v for a vessel, so now you won’t be able to plan an actually possible maneuver simply because the system thinks “you can’t”. Veterans from KSP1 won’t just rely on the displayed delta-v to travel, because there are numerous cases where the in-game display just aren’t correct. Firstly, your staging must be correct for the systems to recognize the correct delta-v. In a complex vessel, such as a satellite hub with many satellites designated to be dispatched in different orbits, you will want to use the part menu to manually release the payload, because staging every satellite in its correct order is just tedious. In addition, the current delta-v calculator does not recognize any docking port at all, so if you have an Apollo style spaceship, you are doomed. In a more complicated design, such as a mothership docked with several landers and/or shuttles, the current delta-v calculator will never consider the fact that these payloads are detachable! Not to mention the fact that the timing and order by which these payloads are dispatched and returned will dramatically influence the final delta-v outcome of the mothership. Finally, there are also various ways a player can generate delta-v besides the main engine. For example, you can use RCS or separator to generate a small amount of delta-v that may just be enough to send you home. You cannot simply place a hard limit on maneuver planning based on what the system thinks the limit is. This is just absurd. I honestly don’t understand at all why this “feature” went into the 0.1.2 update. This feature is awful and stupid. KSP2 is a sandbox game, and force a player to play in a certain style is the last thing you want from a sandbox game. Remember, maneuver node is only a plan! Nobody expects a space travel will go according to plan! If you truly want this feature so that “new players” will not accidentally plan an impossible trip, please at least makes it an option!