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/)

Well the current tool has its limitation : what if I take some time to stage? If I start later or earlier? If I don't burn at 100% thrust? If I burn with RCS? Besides, the direction of thrust computed by the tool is completly wrong for a lot of use cases. For apoapsides rising/decreasing, lunar trajectories, or planet encounters, I do a much better job in terms of Delta-V than the maneuver tool by controlling my vessel to burn prograde or retrograde, something the current tool is not capable of. By doing so, I can achieve almost the same Delta-V an instant impulse tool would compute. So yes, I continue to affirm KSP1 maneuver tool is a better planning tool in terms of Delta-V optimality than KSP2. The trip planner in the VAB only gives the Delta-V necessary (Delta-V computed as instant impulse I guess...). When I launch an interplanetary mission I like to know the orbital elements of the required escape trajectory, because it is inclined in most cases. With a separate spacecraft as a trip planner, I can launch from KSC directly aligned with the escape trajectory because I can see it in map view when I set the satellite as target. Therefore I do not need to perform a plane change combined with the escape burn, and so the whole trip is less Delta-V consuming

Yes, I don't think the current KSP2 maneuver tool should be totally discarded. The ideal maneuver tool I would like is similar to the one present in the KSP1 mod Principia : you can switch between three calculation mods : Instant impulse. Similar to the vanilla maneuver calculation. Not realistic for long duration burns but good enough for planning trips. Inertially fixed. It computes a continuous burn with a fixed direction of thrust. Similar to the current KSP2 tool, useful for plane change maneuvers or changing the apsides direction. Not inertially fixed. The continuous burn is computed in the orbital frame along the predicted path. Useful for apsides rising/decreasing If only one solution should be kept, I'd rather have the instant impulse of KSP1 than the current KSP2 one, but I agree it is less than ideal.

That's just another reason why the current maneuver planner system is so bad. Why have a maneuver planner that does not let you plan maneuvers? In KSP1 I often place a small satellite in Kerbin orbit with the sole purpose to plan interplanetary maneuvers. For instance I set a maneuver to Duna with it, so that I know the departure time, and the direction of the burn (inclination, ascending/descending node...), and it allows me to launch an interplanetary mission from KSC directly on the correct path, as well as planning it with the correct Delta-V. In KSP2 this not possible anymore, because it would require the satellite to have enough fuel for any burn I want to perform, and have the TWR of my future mission... KSP1 maneuver tool is better than the current KSP2 one. However, KSP2's tool lacks just little things that would make it so much better. It's just a question of design choice

Loved all your suggestions. Your Trip Planner version 1 is already self explanatory, I don't think the second version is needed

Situational music seems to be the most reasonable fix haha!

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 build 22631.3155 | CPU: AMD Ryzen 7 5800H | GPU: NVidia GeForce RTX 3060 Laptop GPU | RAM: 16Go What happened: The electricity of my spacecraft decreases while the Infinite Electricity button is switched on, when the ion engines are throttled. The electricity is however not consumed when the button Infinite Fuel is switched on. Expected behavior: When Infinite Electricity is switched on, the electricity should be infinite whatever the use case. The current behavior is misleading.

I haven't seen comments about the trip planner, and I almost never use it. What is the problem with it? Are the dv numbers wrong?

You know the planets of our solar system weren't discovered with orbital telescopes, right? An orbital telescope in KSP would be ok (and cool!) for extra solar objects, when interstellar will be brought to the game. But it does not make sense for the known planets of Kerbol, because all the observation and math can be done from the ground. In reality, interplanetary and lunar probes did indeed help to plan the next missions, but it was about improving the precision of transfers to an extent that is not achievable in KSP. Sure KSP is a game, so it should be fun, but it is a simulation game and should stay coherent to the reality. And I wouldn't want more missions that just slow the game pace by adding barriers. However, orbital telescopes to discover the usual planets is typically a good idea for a mod. It already exists for KSP 1, it works great with modded solar system!

This might be just a bug. It does not make sense for a gas giant to have a surface, so it will be removed from the game before a biome is set But for the sake of the thought experiment, precise landing next to a landmark and then getting back to orbit would be the ultimate challenge!

Well I didn't read the bug reports before playing this mission, so it was an obvious solution to me for a Jool-5 capable probe. Too bad this propulsion technology is not ready yet in this game. I've been reading the KERB updates, and they talk about acceleration under time warp bugs, but without specifically pointing the Dawn engine Thank you for the link. From my uninformed point of view, there seem to be multiple unrelated bugs affecting ion engines and time warp. I will read the full thread when I'll have the time, and maybe I'll share my save. It might help the devs and the QA dep.