Limiting maneuver nodes to current vessel delta-v is the most absurd idea ever

[BComFly]

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!
 

[18Watt]

One comment I have regarding the DV calculator:  Right now there does not appear to be a way to specify the environment you would like DV values for.  For example, DV on the surface of Kerbin, DV in vacuum, DV on surface of Eve.  TWR is the same.  I'd like to be able to see my DV and TWR in the VAB for various conditions.  It's basic math, so I'm sure this will come eventually.

 

[机械主教71号]

Can't agree more.

[dr.phees]

So true, completely bonkers.

[Blue_Point]

I have no idea why the team added this terrible feature at all.

[JIKL04]

I am now playing KSP 1 , just trying out one of the far future engines (I think its from the far future mod, not relevant though) and it requires manual activation a deactivates completely when the throttle is set to minimum.
This means that the game can't properly calculate the actual deltaV of the ship = doesn't show any.

.

So, what I am trying to say. Even if the base game might have some justification for this behavior, I think once someone creates mod with more creative engines, that have modular deltaV under some circumstances (just EC dependency maybe?) this manuever node limitation will become extremely annoying and not at all usefull. (And even warnings might become annoying at that point)

So it would be great if it was toggleable somewhere at the very least if it has to be present.

[pandaman]

1 hour ago, JIKL04 said:

warnings might become annoying at that point)

So it would be great if it was toggleable somewhere at the very least if it has to be present.

I can't think of a reason it needs to exist at all.  If I haven't got enough fuel I want to have an idea of how much by.

[whatsEJstandfor]

I really, really do not want to sound cynical because it's ultimately not helpful, and because this is (presumably) an easily reversible decision, but there's no other way to express how I feel about this; that it indicates some deep, incorrect assumptions the devs are making. The fact that this "feature" was suggested internally, not vetoed during design, implemented, and made it past QA implies that the devs have a fundamentally different view of how to play KSP than we do. OP's example of a vessel that just inherently has inaccurate dV calculations even in the best of times (because it's not being used in the way the game assumes) is a perfect one, and it's as if the devs assume that every vehicle will be a traditional stack of staged tanks and engines.

Edited April 20, 2023 by whatsEJstandfor

[EvelynThe Dragon]

Excellent post, I agree on all points.

And the trip planner is really useless., for one-way trips, it's OK, but still not great. For two-way trips it just mirrors the outbound steps with incorrect dV values. The needed dV to return from Minmus or Mun is far less than needed for getting to LKO in the first place. And there's no way to incorporate something like aerobraking. I get that it's a simple tool, but right now, it is a broken one for all but the simplest mission plans for many of the reasons others stated above.

[dr.phees]

3 hours ago, whatsEJstandfor said:

that it indicates some deep, incorrect assumptions the devs are making.

They are making a game that appeals to the masses, not to hardcore space nerds. I seriously doubt at this point that continuously repeated statement, that they were all KSP players. Sure, they might play it, but in a very beginner way, not really doing the weird stunts, that KSP 1-players are famous for. The time they put into the tutorials for a game, that is ultimately in alpha state shows it: They are not expecting to change any basic functionality or their tutorials will have to be redone again and again.

The current thing is what we get with a 'multiplayer experience' bolted on and a very simplified base building, probably with large premade parts that are basically physics-less.

I also have serious doubts about the interstellar ships: Will we really be able to fly them or will we get a nice animation, showing a departure and an arrival, making those things basically static/star orbiting stations?

Mac and Linux ports will not be available at any point - adding that at a late stage will cause so many issues from early decisions that the small audiences will be a good excuse not to provide them.

Somehow I still am not convinced this game is really targeting KSP 1 players as an audience.

With every single chance I give KSP 2, I am again and again going back to 1.12. The new try feels so far off that I have huge doubts it can be made better than its predecessor, which absolutely shines with a couple of mods.

Edited April 20, 2023 by dr.phees

[Kerbart]

“the most absurd idea ever”

Don't get me wrong, I agree with you that it's a bad idea for all the reasons you list. But most absurd idea ever? A brief look at the response to KSP2 would suggest that it's not that. Not by a long shot.

[dr.phees]

Maybe just "a spendid example of a very absurd idea"?

[BComFly]

On 4/20/2023 at 1:59 PM, Kerbart said:

“the most absurd idea ever”

Don't get me wrong, I agree with you that it's a bad idea for all the reasons you list. But most absurd idea ever? A brief look at the response to KSP2 would suggest that it's not that. Not by a long shot.

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. 

[pandaman]

Having just read Nate's reasoning behind it I understand the logic, but still think it's a poor idea.  Or rather a very poor implementation.

For starters, the Dv and TWR information needs to be sufficiently reliable for this to be if any use, which it currently isn't.

 

[dr.phees]

For starters, the Dv and TWR information needs to be sufficiently reliable for this to be if any use, which it currently isn't.

 

Also: I might want to drop something before a stage has burned out. KSP is a game that allows all kinds of things, especially not-traditional rocket designs.

[pandaman]

21 hours ago, dr.phees said:

Also: I might want to drop something before a stage has burned out. KSP is a game that allows all kinds of things, especially not-traditional rocket designs.

Yes, though I certainly wouldn't expect the game to mind-read my ever changing intentions 

I know they are aware of the problem, and I can certainly appreciate the difficulties of what they are trying to achieve, but currently it doesn't even seem to use information it demonstrates that it has.

Eg.  A simple probe (core, tank & engine plus comms and RTG) in Mun orbit detached from its transfer stage (about 3k Dv in VAB).  Tank full and green bars showing it, engine activated and working, and it tells me I have ZERO Dv so can't plan a manoeuvre.  

[caipi]

On 4/22/2023 at 12:14 PM, dr.phees said:

Also: I might want to drop something before a stage has burned out. KSP is a game that allows all kinds of things, especially not-traditional rocket designs.

It also allows for vessel refueling, I've heard! How would I know where, when, how often, and by how much I have to refuel my rocket/spaceship when I cannot make a proper flight plan? I find that idea particularly short-sighted when you consider that colonies are planned! What are they for if not for refueling? And I might not always want to completely refuel my rocket, just enough to get to the next stage or point.

Yet another example of a seemingly narrow-minded development which thrives on disimprovements of the original game and where it seems like the current devs had a very special way of playing KSP and want to force it onto everyone. :-( I miss so much basic features in KSP2. This is just another one in a long list.

Is there a way to "abort and return to VAB" for the development of KSP2? o.O Just port KSP1 to the latest unity engine and make improvements and rework the design without loosing functionality?