BComFly

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!