Maneuver Nods with No Fuel

[Gainsboreaux]

Hello, 

I would like to suggest that you should still be able to create maneuver nodes without any engine fuel. I was in a situation where I was launching a lander from the surface of the Mun to rendezvous with my command module in orbit. I had just enough liquid fuel to get into close orbit to the command module, and had plenty of monoprop left to adjust the orbit to rendezvous using only the RCS thrusters, but it would not let me use maneuver nodes. This is something I did all the time in KSP1, and was a little irritating when I discovered it here. It wasn't a game stopper for me - I just reverted to my Mun surface launch again and made sure to leave a couple of Delta V so I could use the nodes. But it would still be appreciated.

 

Thanks. 

[Deadly_Laser]

Seconded. For  small moons like Minmus or Gilly you can easily build an exploration vehicle that *only* uses RCS, currently a craft like that just cannot create maneuvers, making things like docking with the main ship after collecting science from the surface extremely difficult to do. There should at least be a toggle for it!

[hatterson]

I posted this elsewhere, but I'll say it here again:

I totally understand the developers (presumed) goal of not teasing a player by allowing them to make a maneuver plan that they can't actually complete, however it still needs to let me do it anyway. They can still warn players either via a setting they have to explicitly toggle off (so you can only get yourself in that situation if you really want to) or via a warning message when making the node along the lines of "your current vehicle does not appear to be able to compete this node. Are you sure you're doing what you want to do?"

Aside from the use cases mentioned above of RCS, another option is something I do somewhat frequently when I don't have something like transfer planner in game. I have a satellite in something like an 80x80 orbit around Kerbin. I want to go to Duna with a heavy payload or something so saving dV is nice. As such I want to know if there's a way I can do something like a Mun gravity assist to get me there.

My options are: 1.) Build and launch a vessel assuming it can happen and then potentially spend hours fiddling with maneuver plans trying to get it to work; or 2.) Load that satellite and create a node. Spend ~2 minutes seeing if it can happen. If so, cool build and launch the real rocket. If not, oh well, just strap on another few boosters.

That also applies to things like asteroid captures where you're trying to figure how much dV you need to intersect it and what your relative speed will be at encounter.

[FuelX]

Thirded. I like to use every single milligram of monoprop from my small vehicles. Sometimes I also build small probes only propelled with RCS thrusters. 
Edit: Looks like I'm fourth. Fourthed.

Edited December 29, 2023 by FuelX

[Aevitas]

Fifth'ed

I understand the reason; but it's always been very clear when you do not have enough fuel to do a projected manuveur.

Trying to dock or just see how much extra fuel you need to complete something to redesign/fix, or using RCS for the last little bit, are all valid reasons to allow this feature imo.

[Superfluous J]

Negative one'd

I understand the reason you want this, but I think it's misguided. You don't want to make a maneuver node you don't have fuel for. You want to make a maneuver node that isn't restricted by your ship.

And that's what I want. I also want it to be a separate thing than the maneuver node, because after using KSP2's maneuver nodes for a while I find them to be far superior to KSP1's maneuver node in every way.

...except in implementation. The UI sucks for it, but the mechanics of how the node work are so much better than the instantaneous node in KSP1.

[cubinator]

I think they should just make the deltaV bar red to indicate where the fuel is projected to run out, and put a little "/!\" sign by that spot. 

Especially when the game fails to determine that my full tanks have any deltaV at all as soon as I toggle engine groups.

[ttikkoo]

On 1/10/2024 at 1:38 PM, Superfluous J said:

Negative one'd

I understand the reason you want this, but I think it's misguided. You don't want to make a maneuver node you don't have fuel for. You want to make a maneuver node that isn't restricted by your ship.

And that's what I want. I also want it to be a separate thing than the maneuver node, because after using KSP2's maneuver nodes for a while I find them to be far superior to KSP1's maneuver node in every way.

...except in implementation. The UI sucks for it, but the mechanics of how the node work are so much better than the instantaneous node in KSP1.

I'd really like something like your Planning Node mod idea to be native in KSP2. Let us go to the tracking station, plop down a virtual ship, make some maneuvers and save them. "Kerbin -> Mun slingshot -> Duna (xxxy, xxxd,)".

Pardon my ignorance but what exactly do you mean that the maneuver nodes are superior to KSP2 except for the implementation? I almost exclusively used the advanced maneuver node editor in KSP1 so not sure what's better in KSP2.

 

[Superfluous J]

39 minutes ago, ttikkoo said:

Pardon my ignorance but what exactly do you mean that the maneuver nodes are superior to KSP2 except for the implementation? I almost exclusively used the advanced maneuver node editor in KSP1 so not sure what's better in KSP2.

What I mean is that in KSP1, maneuver nodes assumed your ship was capable of delivering the entire required thrust in a single impulse that lasted 0 time. It's a fine approximation and got us through KSP1 with no issues, and I'd be totally happy if KSP2 did it... if only I'd not seen the KSP2 maneuver node as it now is.

In KSP2, where you place the node on your orbit is where you start burning, and then as you drag the little pully-arms* around a red line shows up on your new orbit, which indicates where your ship will travel as you burn. This is more accurate than KSP1's node because it simulates your ship moving along the course of the burn, and in particular on long burns it can show you ahead of time just how bad an idea it is to burn for 20 minutes straight from low Kerbal orbit. One limit of this is that it is actually based on your ship and what it can actually do, and one thing it can't actually do is burn more fuel than it has. Hence, the limitation we're discussing in this thread.

*do those things have a name?

Edited January 12 by Superfluous J

[ttikkoo]

27 minutes ago, Superfluous J said:

In KSP2, where you place the node on your orbit is where you start burning, and then as you drag the little pully-arms* around a red line shows up on your new orbit, which indicates where your ship will travel as you burn. 

*do those things have a name?

Oh what?? I never noticed that red line - that's a very good feature.

I've always called them handles. Prograde handle, retrograde handle, etc.

[pg17]

There is another use case where the actual behavior is problematic. The other day I activated the "infinite fuel" option because I ended up with a lot less fuel than what the DeltaV calculator told me I would get on my return stage from Duna (I'm pretty confident a bug was involved). I suffered the same limitations on maneuver nodes. Despite having infinite fuel, it only took into account what fuel was left in the tank  and I had to eventually kind of guess / eyeball my Kerbin intercept.

 

On 1/11/2024 at 9:12 PM, cubinator said:

I think they should just make the deltaV bar red to indicate where the fuel is projected to run out, and put a little "/!\" sign by that spot. 

I think this would be a good implementation. And for those who don't want this behavior, it could be implemented as a game option.

[neistridlar]

I think the way to deal with this in KSP2 would be to  give players to enable "override mode", which would essentially revert to KSP1 style maneuver nodes. Should be plenty good for most purposes, without the game having to know the thrust and mass of your ship.

[whatsEJstandfor]

I believe the maneuver planner takes a vehicle's TWR into account as it does its burn, doesn't it? If this is the case, then how would the maneuver plan treat a vessel that runs out of fuel? It can't just keep increasing the predicted TWR throughout the burn, because it could potentially just increase unbounded and lead to physically impossible burns, which'd be of no use to the player. Should it just assume the vessel's TWR remains constant after it runs out of fuel? I suspect that it's this nonlinearity in the TWR's change that makes the current system not able to handle out-of-fuel trajectory calculations. In other words, I'd bet that the current trajectory calculations require that d/dt of the TWR remains constant throughout the burn.

If this is indeed what makes it currently impossible to calculate burns beyond out-of-fuel-events, then maybe, while editing a plan, you should be able to toggle between KSP2's non-instantaneous maneuver plans and KSP1's instantaneous maneuver nodes. The instantaneous one would be less accurate, but would sidestep the issue of taking a changing TWR into account.

[mikeman7918]

I don't know how feasible this even is from a technical perspective.  In KSP2, maneuver nodes account for the time it takes you to accelerate.  This means accounting for not just your current thrust to weight ratio but also how it changes over time as you burn fuel and get lighter.  The behavior of maneuver nodes is different depending on what engine you have and how its fuel consumption impacts your craft's mass.  If you think about it, it's not really clear what the intended behavior of this system should be if you have no fuel.  The system in place right now where you can't plan maneuvers over the amount of fuel you have makes sense, I would argue.

[Retro Starship]

(from someone with over 3000hrs of 1)

Edited January 16 by Retro Starship

[Periple]

I just built a mini lander that only uses RCS. I can’t plan maneuvers because the game thinks its dV is zero although in reality it’s about 1400. This is annoying. 

Letting us plan them with an indicator that there’s no fuel would be much better, since accounting for RCS dV would likely make things too complicated.