Darta01

Are you referring to the Delta-V required from launch to orbit? If so, you should describe your launch process so that we can understand your problem. A really basic mistake I did when I first tried to go on a polar orbit in KSP, a long time ago when I didn't know anything about orbital mechanics, was to first launch into an equatorial orbit and then perform a 90° plane change maneuver to bring it in polar. I soon learnt a better way is to launch due North (or South), and perform a similar launch profile as for an equatorial orbit but with a different direction. This brings the spacecraft on an orbit close enough to polar so that correction maneuvers are cheap. The optimal launch profile is to compensate for the planet's rotation

Reading your comment, a scene popped up in my mind: a scene ala The Expanse, where a player would do a hard deceleration burn towards another player's spacecraft in deep space, then jumping on EVA at high velocity to reach it and copy the science, and returning to its own ship before the other player could react... And then burning hard toward Kerbin before the adversary could launch a conter-mission to stop the science-pirate kerbal... Competitiveness in KSP could lead to very interesting interactions

Rocket launches are automated too IRL, but here we are, manually launching rockects because it is both fun and challenging. If landings are fully automatable, it would not be a space simulation game, just a space simulation

You talk about the roadmap as a progression tree for players: "resources show up after we crack interstellar travel". It is not, it is a list of development steps. We won't crack interstellar travel, the devs will. And yes, interstellar is easier to implement than resources, because it consists basically in placing new stars somewhere and new planets around them. The difficulty is more in the design variations than in the game mechanics. In game development it makes sense to first implement a simplified version of the final product you want and then after to refine the game loop. When colonies will be here, we will build them because we will want to. The game is in early access, so the colonies are implemented in order for the players to test the new game mechanics brought with it: new parts, orbital construction, maybe ground-anchoring... Sure it would be nice to have other motivations to build colonies, but it is not the main goal of the update. Besides this point, I agree that KSP2 is (and wants to be) simpler than KSP1, which can be disappointing for seasoned players who seek a challenging experience. Sure the first early versions of KSP1 without maneuver tools were challenging! But the additions of tools in the game to simplify the user experience didn't make it less fun. Maybe you thought of the current state of KSP2 as a wannabe improved version of KSP1 final state. With this perspective, the simplified science gathering game loop can be disappointing. However, I think KSP2 game loop as planned by the devs will be different from KSP1 (launch, collect science, transmit/recover, spend points in the tech tree). They talked about it but I don't remember where. I think it will be a bit closer to an automation game: resource gathering improvement, supply lines improvement, and science gathering will be used to unlock parts but will be less significant than in KSP1. Some people will like it, some people won't, but for now we have to keep in mind the game loop is not complete, hence the lack of motivation for rocket launches

You're not playing the entire game wrong in the sense that you can play whatever the way you want. However you are complaining about the characteristics of an object that, indeed, you're using wrong, and then you say this object is terrible. To give an example in another game, it would be the same as using a shield in Skyrim to punch your ennemies with, and complaining it deals less damage than other weapons of similar value. Of course it is inefficient, because it is not meant for this purpose. In KSP as in real life, deep space engines are not meant to perform maneuvers requiring high TWR, that doesn't mean there are "terrible". If you don't want to perform 10 minutes long burns (even if you can burn under time warp), that's you're choice, and low TWR engines are not meant for you

I don't remember where they are placed in the tech tree, I guess there are further than deep space methalox engines, right? It would be the only way to balance it for now, since we don't have resource gathering nor radiators yet (nuclear engines should procude a lot of heat so your spacecraft would weigh more due to radiators) I'd say it's very realistic: IRL nuclear engines are OP in terms of ISP compared to conventional rocket engines. The reasons why we don't use them are engineering difficulties, heat management and the risk at launch if the rocket explodes. These difficulties don't exist in KSP, except for heat management but it is pretty easy to do in the game.

To make a part procedural, its characteristics and appareance need to be easy to compute. Wings are parallelogram with a few equations to set their lift and drag ratio. I'm guessing radiators will be similar (I wonder why we don't have procedural tanks...). Gravity rings however have a very complex look, I'm not sure it would be possible to make them procedural. And if the devs want to render the interior (which they did for every parts containing kerbals), it means the interior would also be procedural, which is a pain to compute.

The idea of longer burns being less efficient is wrong and comes from the inefficient way the maneuver node is computed. I'm sorry for the shameless self-promotion, but I wrote a post about this with Delta-V examples : Change the maneuver tool to compute the predicted path in the moving orbital frame Basically, you can perform maneuvers with roughly the same Delta-V regardless of the TWR (except when the burn duration is critical of course, like landing phases), if you perform the maneuver well enough, which is NOT following the maneuver node. As was said by @The Aziz, the point of deep space engines is to maximize the Delta-V of your spacecraft, where you don't care about the TWR. There are well suited for lunar and interplanetary transfers, but not low orbit. Indeed nuclear engines may be more adequate, but hydrogen tanks are bulkier and don't use the same resources

That's right, I forgot about this method That would mean the dev team chose to temporarily fix a bug by adding another bug and never talked about it...

Ah yes! The maneuver planning tool that does not allow you to plan maneuver! This is a terrible design choice

For small inclination changes, it does not make a lot of difference I guess. With large angles but short burns (high TWR), the best thing to do is, as you said, to plan a maneuver in fixed direction with both a normal/anti-normal and retrograde direction. With very low TWR, the best method is to perform multiple plane change maneuvers, at both ascending and descending nodes, again in fixed direction. With semi-low TWR (long burn but still achievable in a single burn), I'm not quite sure what is the best method, but I would say it should be in fixed direction It could be a solution. I prefer the solution with three modes, but if there is a solution to overcome the fuel limitation and the two first modes are implemented, then the third one has little use. So if the devs have good reasons not to implement the last mode, I'm ok with that.

With the proposed method, you could set a purely retrograde maneuver node, and at some point the spacecraft would eventually kill its velocity. So that kind of landing would be easier to plan, and with greater fuel efficiency I'm not sure it would make any difference. The predicted path would rely on the same type of computation, just with a different formula for the direction of thrust. I don't know what concerned players describe as an accuracy problem, but if it is purely calculation accuracy (like floating point precision), the problem would not be solved by my proposition. Yes, I talked about that somewhere in the middle of my post. The main issue is that it was way faster, easier, more precise and more intuitive to do so with the instant impulse planning tool in KSP1

tl;dr: summary at the end of the post I am aware the problems of the current maneuver planning tool have already been discussed on this forum by multiple players: the prediction stopping when out of fuel, the inability to set the maneuver at the next orbit, the lack of number entries, the inaccuracy of the progress bar... Here I want to bring a mathematical insight to why, even with all these problems dealt with, the current maneuver planning system would still be inadequate. The current advantages of the maneuver tool are the ability to see the real trajectory followed by the spacecraft during the burn, and to evaluate its end point. It is a huge advantage, especially for long burns. However, the predicted path is computed by assuming the direction of thrust is constant, and set at the beginning of the burn, and that is the heart of the problem. Take for example the following vehicle, that has 4072m/s of ΔV and a TWR of 0.29, placed on a 100x100km orbit. I want it to transfer to a kerbostationary orbit at 2863km of altitude. Picture: Test vehicle With a theoretical instant impulse, the Hohmann transfer is 651m/s for the apoapsis raising (going from the 100x100km orbit to a 100x2863km one), and 424m/s for the circularization at apoapsis (from 100x2863km to 2863x2863km). The return trip costs the same, 424m/s for periapsis lowering and 651m/s for circularization at 100km. These are the ΔV computed by the maneuver tool in KSP1, because it was computed assuming an instant impulse. Picture: Principle of a Hohmann transfer Of course in a real situation the maneuver is not instantaneous, and the player has to find a way to perform the maneuver with this limitation. In KSP1, the usual technique was to point the spacecraft in the direction of the maneuver, and start the burn when the time before reaching periapsis is half the duration of the maneuver. So basically the node is approximately in the middle of the real maneuver. By doing this technique, the ΔV is 659m/s for the apoapsis raising and 424m/s for the circularization at kerbostationary altitude. The return trip costs 424m/s for the departure and 651m/s to circularize at 100km. With different spacecrafts, the ΔV cost varies according to their TWR. For this spacecraft in particular with an initial TWR of 0.29, the cost is very close to the theoretical Hohmann transfer (only 8m/s of loss). Picture: Direction of thrust with KSP1 method In KSP2, the new maneuver planning tool computes the predicted path of the spacecraft during the whole duration of the maneuver, assuming that it is pointing in the maneuver direction. This direction is inertially fixed, and computed in the orbital frame at the start of the maneuver. This means it is no longer possible to place the node at the middle of the maneuver. When planning an apoapsis/periapsis raising/lowering, if the player sets a prograde/retrograde maneuver (as was done in KSP1), the spacecraft will be pointing straight in prograde/retrograde direction at the start of the maneuver, and slowly drift away as the orbital frame changes along the trajectory. By doing this technique, the ΔV is 700m/s for the apoapsis raising and 426m/s for the "circularization", but the orbit is much more elliptic than KSP1's technique (2847x2880km instead of 2863km). And the return trip costs 424m/s for the periapsis lowering and 671m/s for the circularization but again it is impossible to circularize with this kind of maneuver. The resulting orbit is 59x151km. So the ΔV cost is much higher using this naive technique introduced by the new planning tool. This is due to the thrust direction being suboptimal. In these maneuvers (apoapsis/periapsis raising/lowering), the goal is to gain or lose orbital energy. The optimal way is to thrust in the prograde or retrograde direction, every other direction introduces a loss. The greater the direction difference, the higher the loss. KSP1's technique keeps the thrust direction pretty close to the optimal direction, therefore the ΔV is close to the theory. In the naive KSP2 method, the direction is prograde/retrograde at the beginning, but the difference is much higher at the end of the maneuver, therefore the loss is much greater. In this particular case, the loss is 81m/s, 9 times higher than with KSP1's planning tool. Picture: Direction of thrust with KSP2 naive method Picture: Resulting orbit after the periapsis circularization With KSP2 current tool, it is in fact possible to perform the same maneuver as with the KSP1 method, but the player needs to correct the direction of thrust with a radial-in/radial-out component. So the new method would look like this for a circularization at periapsis: set a maneuver at periapsis with a retrograde component so that the apoapsis is approximately at the good altitude; move the maneuver so that the the periapsis is in the middle of the path; add a radial-in component to the maneuver so the resulting orbit is closer to a circle; tweak all three parameters until the projected orbit is as close to a circle as you want. It takes only five minutes to do in KSP2 what took two clicks in KSP1. What an upgrade! Now what I'm proposing is to change the way the planning tool computes the maneuver direction. For these kind of maneuvers, I would like the maneuver to be computed in the orbital frame that moves with the predicted path. Which means, when a maneuver is set with a prograde component, the maneuver marker stays exaclty prograde during the whole duration of the maneuver. Picture: Direction of thrust always prograde This is what happens when you burn always prograde/retrograde in my example. The apoapsis raising costs 652m/s of ΔV. It is very close to the theoretical ΔV, but as a side effect it also raised the periapsis by 7km. Therefore less energy needs to be gained at apoapsis, and the circularization costs only 418m/s. The total is less than a Hohmann transfer. For the return trip, the periapsis lowering costs 417m/s of ΔV. For the circularization at periapsis, I start the maneuver at such an estimated time so it ends at the periapsis, and it costs 644m/s. As I don't have an adequate planning tool, the circularization is not perfect, so the resulting orbit is 97x105km, but still way better than with the current planning tool. Again the ΔV is less than the theoretical Hohmann transfer. The total gain is 19m/s, minus some ΔV needed to properly circularize. The difference is even greater between the KSP2 naive method and the one I propose when the TWR is lower or the burn longer (e.g. for interplanetary departure/arrival). So with this change, the planning tool would allow the player to negate the losses induced by a suboptimal direction of thrust. However I don't think the current planning tool should be totally discarded, because in some cases maneuvers need to be planned with an inertially fixed direction. Here are cases I can think of where the maneuver should have a fixed direction: - plane change (changing the inclination) - fly-by corrections (changing the orbit in another SOI) - target corrections (reaching another spacecraft) It is not anecdotic, so it is better to keep the current tool available to the player. But the default planning mode should be the moving orbital frame, because here are cases where it is essential: - orbit changes (periapsis/apoapsis raising/lowering) - circularization - rendez-vous - lunar/interplanetary departure - interplanetary arrival (injection burn) - targeted landing - suicide burns Theses maneuvers are the heart of KSP2 game loop, there are essential to go anywhere. Ideally, I would like to have an option on the planning tool to compute the path either: 1. In the moving orbital frame 2. In inertially fixed frame 3. As an instant impulse The third one can still be useful to plan certain maneuvers that are not possible with the current spacecraft. For example, the player sets a station in high altitude orbit of Kerbin (with no engine), and now he/she wonders how much ΔV it would costs to reach the Mun with a space tug or a resupply module. With instant impulse planning tool, he/she can have that information that is not available in the VAB trip planner. TL;DR The current maneuver planning tool computes the future path by assuming the spacecraft points in a fixed direction. This is useful only for some very specific cases. In most cases such as orbital raising/lowering, interplanetary trajectories or landing, it is suboptimal to say the least. A better way would be to compute the maneuver in the moving orbital frame. It would be easier to plan in terms of QoL, and cheaper in terms of ΔV cost for most maneuvers. P.S. This posts echoes @Superfluous J tutorial (Don't just burn prograde!), where he/she shows the prograde maneuver is nowhere near optimal in terms of ΔV for an interplanetary departure. However, I would say the title is misleading: you SHOULD burn prograde and stay prograde, just not in the direction of the maneuver

It's just that sometimes you want to have an estimate of the Delta-V required for a certain maneuver your ship is not capable of. It's a good thing to take into account weight loss and correct path, but stopping the prediction when out of fuel prevents you from getting that knowledge, which is a shame. I'd rather have a not perfectly accurate prediction (e.g. path computed with constant mass after fuel depletion) and with a warning note on the inaccurate path, than no information at all. Ok, I didn't know devs considered this as a bug. When it will be corrected I hope they'll implement option three. If we have options two AND three AND path prediction beyond fuel depletion, then yes option one is of seldom use

Ok, I haven't noticed for the thrust limiter, that's good. Yes yes, these are the minor details that make the prediction (or the player, if you want to say) less accurate. My point is not to say the current tool is worse on these points, just that both KSP1 and KSP2 have inaccuracies. But you are right, I'm dirfting away from my main point, which is the suboptimal direction of thrust of the current tool. Yes I'm aware there is a "maneuver direction" button, I've played KSP my fair share . However, I strongly disagree with you on this point. If the goal of your maneuver is to raise/lower an apsides (which is also the case for interplanetary departure and encounter), the optimal way is not to burn in the same direction. Apsides raising/lowering is all about gaining or losing orbital energy. The optimal way to do so is to burn prograde or retrograde. Every other direction is a loss of energy (except if you need to also do a plane change of course). If you want to perform an interplanetary departure with a very long burn, you should cut it in multiple burns at periapsis, but every burn should be prograde, never in a straight direction. I've been to Moho, and burnt retrograde at the encounter to circularize. I did that manually because I was incapable to plan a good circularization with the given tool. I must admit KSP1's tool was also no good in this situation. In both games, I only use the maneuver node to have an estimate of my burn duration. I'm not sure my point is clear enough, and I don't want to pollute more this post about UI design, so I will write a separate, more detailed post in a short time (https://forum.kerbalspaceprogram.com/topic/224064-change-the-maneuver-tool-to-compute-the-predicted-path-in-the-moving-orbital-frame/)