Burn timer = Perfect.

[JoeSchmuckatelli]

I regularly had trouble following the Burn Timer over the last few weeks.

Not today.

I've tested it in Flight View, Map View and (intentionally) switching back and forth between the two.  This thing is 'All Systems Go."

Case in point: set up a MN to circularize an orbit at 85,000m with an ascent stage Mammoth II.  Ran the burn exactly as the Timer suggested.

Perfect.

 

Edit: I have also tested the Burn Timer doing a warp while burning.  Had a 6 minute burn lined up - and did not want to sit and stare at the computer for the whole thing.  Used the warp buttons at the bottom and, again shifted in and out of Flight/Map view.  The burn was spot on (or rather, the timer was!)

burn starts around 3:30

 

Edited March 17, 2023 by JoeSchmuckatelli

[Fullmetal Analyst]

yeah its much more accurate now, though i would prefer a readout for dV to reach node 

[LameLefty]

Yeah the burn timer seems pretty accurate and usable now. I also noticed a low-volume beep - beep -beep tone with the countdown dots. I'd actually prefer those to be louder - perhaps a volume setting or toggle for that would be useful?

[JoeSchmuckatelli]

I've tested burn under warp as well.  Timer is working great!

Good job Dev Team!  -- This is something I never knew I wanted in KSP - but what a QOL improvement!  

@Dakota -- Let the team know they've accomplished one milestone: A guy who only left Kerbin's SOI twice in all the years I played KSP... has now doubled that number with KSP2 in 60 hours.  The addition of the Burn Timer and the way the game is working post-patch is very 'Duffer' friendly!  

I'm predicting KSP2 players leaving the SOI and getting out to the other good stuff will blow away KSP's numbers.

Edited March 17, 2023 by JoeSchmuckatelli

[Fluke]

28 minutes ago, JoeSchmuckatelli said:

A guy who only left Kerbin's SOI twice in all the years I played KSP...

I only managed a flyby of Duna in KSP1 and probably played over 500hrs. I've now landed on Eve and Duna. @Dakota add the same sentiments for me!

[TiggerTailz]

I don't care much for the for the maneuver burn timer UI.

It doesn't really match that well with the other HUD elements and overall I wish it a bit was larger with bigger numeric timer fonts. Information wise it seems fine but could use a redesign IMO. 

[JoeSchmuckatelli]

40 minutes ago, TiggerTailz said:

I don't care much for the for the maneuver burn timer UI.

It doesn't really match that well with the other HUD elements and overall I wish it a bit was larger with bigger numeric timer fonts. Information wise it seems fine but could use a redesign IMO. 

What resolution are you playing at?  

Because I think the Burn Timer is perfectly sized; although I would like to be able to move it a bit down.  Main UI thing I want to do is shrink the NavBall by 25%.  Probably some of the others as well - but I'm on a 32 inch 4k.  Navball is HUGE.

[LeroyJenkins]

Though I see a huge improvement in the dV burn timer UI, there are still some accuracy issues. Its stable/accurate initially but over long and multiple burns/stages (To Minimus and back) it was getting less accurate. i am collecting info before I submit a bug report. The slider bar reduces only based on 100% thrust. it does not slow down if you throttle down. I need to double check, but the timer also only counted down at a rate to a constant 100% thrust. So if you throttle down during the burn the time remaining and slider bar are off. KSP1 did adjust this, if I remember correctly.
 

3 minutes ago, JoeSchmuckatelli said:

Main UI thing I want to do is shrink the NavBall by 25%.

The Scale UI mod is helpful for this. I have it set at 60% and I wouldn't go any smaller. I am on a 65" 4k monitor.

One improvement the burn time UI i would request is the that total dV burn has a number count down. KSP1 had this an was helpful. Example at start of a 1000 m/s dV it would show 1000/1000 m/s. The bottom would be static as it is now, but top number would reduce as you burned/throttled. I'll put this in the suggestion thread shortly.

[TiggerTailz]

4 minutes ago, JoeSchmuckatelli said:

What resolution are you playing at?  

Because I think the Burn Timer is perfectly sized; although I would like to be able to move it a bit down.  Main UI thing I want to do is shrink the NavBall by 25%.  Probably some of the others as well - but I'm on a 32 inch 4k.  Navball is HUGE.

I'm on a 27" at 2560 x 1440. I totally agree some of the UI HUD elements are too large. I tried out the UI Scaler mod and dropped the UI to 75% which was really nice for the Nabvall and staging etc but then the burn timer was tiny in comparison and pretty hard to read. 

If its possible a mod to reposition and scale HUD elements up/down individually would be great. 

[Streetwind]

While I agree that the maneuver planner is much improved, there is definitely room for more work. Indeed, there are large issues remaining with long burns, which go all the way to "the spacecraft burns retrograde on a node that only contains prograde dV".

(Example screenshot)

This is the "new" Dawn ion engine in 0.1.1, with 0.2 kN instead of 2 kN of thrust. With just 700-odd dV in the node, all of it prograde, the test probe simply deorbits itself instead of raising its apoapsis. The reason for this is that the spacecraft is required to burn at the maneuver in a straight line, while it is on a curved path. At the start of the burn, the maneuver marker is directly on top of the prograde marker, but with each second that passes, the spacecraft will "nose up" more with respect to prograde. After a quarter of an orbit, the spacecraft will be facing fully radial-out, and not burn prograde at all anymore. If the burn continues after that, the spacecraft will begin to turn retrograde and lower its orbit instead of raising it, which eventually causes it to crash.

The correct strategy here is either a spiral trajectory, or periapsis kicking. Unfortunately, the maneuver planner doesn't just not support either - it actively interferes with both, because (a) you cannot plan any trajectory that doesn't follow the maneuver marker in a straight line, and (b) you cannot plan any trajectory that the spacecraft cannot execute in a single burn. As a result, any spacecraft which cannot reach Kerbin escape velocity in roughly 10-ish minutes cannot plan any interplanetary trips from low Kerbin orbit; they need to be manually piloted to escape velocity and enter solar orbit before maneuver nodes become usable once more.

I'm currently working on a large, detailed feedback report which I will submit through the launcher; cross your fingers it won't get lost...

[The Aziz]

This is what the path along the burn will look like, it's correct. Going all prograde won't help you much unless you just want to increase your orbit everywhere. I had a planned burn to escape Kerbin, it took like two hours - and the planned and final trajectory looked like a snake. And it put me where I wanted. If you see you won't make it in single burn, do what most low thrust spacecraft do. Multiple burns.

[Snips]

10 hours ago, Fullmetal Analyst said:

..., though i would prefer a readout for dV to reach node 

I second this.

[Streetwind]

17 minutes ago, The Aziz said:

If you see you won't make it in single burn, do what most low thrust spacecraft do. Multiple burns.

But how does the player plan the multiple burns? How is it represented in the UI, how is the new player taught to do it?

This isn't an issue of being entirely unable to get where you want to do. This is an issue of the tool the game teaches you and expects you to use being actively counterproductive. Therefore, the tool has room for improvement.

I mean sure, I can just eyeball where my apoapsis should rise towards for a successful Moho transfer, and manually periapsis kick it up there until I reach escape velocity, and then lower my orbit to around Moho's semimajor axis, target Moho, and fish for an encounter while burning in different directions. But then why do we have the maneuver planner in the first place? Might as well throw it out, right? No, of course not. It exists because it is meant to pre-plan these things. To give me a preview of my trajectory before I light my engines. So even if I, with a four-digit number of hours in KSP, can in fact fly a low-thrust probe to Moho without making a maneuver node, that doesn't excuse the maneuver planner from being unable to calculate this trajectory for all the players who don't have my experience.

Acceleration under timewarp for low-thrust propulsion is one of the headline promises of KSP2. The game can't very well then turn around and not support it in maneuvers.

 

Edited March 17, 2023 by Streetwind

[LameLefty]

I would prefer the bar be accompanied or replaced by a numeric countdown of the dV remaining to add. Right now I’m just sort of playing a rhythm game for the end of each burn.  A bit like Rock Band trying to hit that last drum beat of the song, lol. I’d rather see the numbers, please.

 

[JoeSchmuckatelli]

1 hour ago, LameLefty said:

I would prefer the bar be accompanied or replaced by a numeric countdown of the dV remaining to add. Right now I’m just sort of playing a rhythm game for the end of each burn.  A bit like Rock Band trying to hit that last drum beat of the song, lol. I’d rather see the numbers, please.

 

I'm seeing both.  In fact there are 3 ways to know when to stop.  The numeric timer above the bar, the bar and the 4 dots ‐ which now also have audio cues (beeps).

[LameLefty]

2 minutes ago, JoeSchmuckatelli said:

I'm seeing both.  In fact there are 3 ways to know when to stop.  The numeric timer above the bar, the bar and the 4 dots ‐ which now also have audio cues (beeps).

I don’t mean time numbers - I want the integrated change in velocity over time (e.g., the ACTUAL delta-V incurred during the burn). 

[PakledHostage]

9 minutes ago, LameLefty said:

I don’t mean time numbers - I want the integrated change in velocity over time (e.g., the ACTUAL delta-V incurred during the burn). 

Yes, this is important. And if what's written above about the countdown only being correct when full throttle and it not taking into account throttle reductions is repeatable, then that needs to be fixed too. I haven't used the manoeuvre nodes very much yet, but they have seemed inaccurate when I have. That'd explain why.

[Picard2]

Agree it's much better in my brief testing.

Love how it now shows the burn length, which was a crucial missing feature.

Really like the new subtle audio cues - I think they're new? - for when you're a few seconds away from burn.

Would be improved by adjusting the top line - required deltaV before burn -> required / remaining deltaV during burn (or maybe just remaining deltaV) so you can easily see how much deltaV you have left in the manoeuvre as you're going.

Also, watching the video, I wonder if the 'warp to manoeuvre' button might be enhanced by adding warp to 10-15 second before the end / before mid-burn staging once you're actually in the burn? So you can easily program in a warp to shortly before you need to terminate.

[JoeSchmuckatelli]

1 hour ago, PakledHostage said:

Yes, this is important. And if what's written above about the countdown only being correct when full throttle and it not taking into account throttle reductions is repeatable, then that needs to be fixed too. I haven't used the manoeuvre nodes very much yet, but they have seemed inaccurate when I have. That'd explain why.

MNs and Burn Timer were all over the place the last 3 weeks.  I got to the point where I just burned manually then 'fiddled' with adjustments simply using throttle and pro/retrograde - ignoring both the MN plot and BT, because I'd almost inevitably get a very, very wrong solution.  (Aside from just getting the general plan via the node, which was a huge PITA prior to this patch)

But I spent about half my time playing with them yesterday and found both to be quite accurate.  (The other half was spent trying to figure out what was going wrong with Spaceplanes and the VAB)

Edit - I just went back and watched my vid above: I still had some fiddling to do, but I always had to do that in KSP - so it did not bother me.  The striking change was that it was merely 'fiddling'.  During the previous three weeks, I'd almost always have to make gross corrections or simply be so far off I'd need to revert the save or dump the campaign entirely and restart a new game.  That's a pretty significant improvement.  (Not necessarily over KSP, but over the Alpha state we got the game in.)

I mentioned this elsewhere - but I have a strong suspicion that we only just now got a build that is similar to what the ESA preview players got.  This because of the way the MNs look (see a Scott Manley or Lowne / others vid) and the repeating yellow alert message has been introduced to us.  Both were seen in the preview videos - but I haven't seen either over the 3 weeks.  (Endlessly looping notification bug)

Edited March 17, 2023 by JoeSchmuckatelli

[Picard2]

55 minutes ago, JoeSchmuckatelli said:

Edit - I just went back and watched my vid above: I still had some fiddling to do, but I always had to do that in KSP - so it did not bother me.  The striking change was that it was merely 'fiddling'.

In the video it looked like the kind of minor inaccuracy caused by how difficult it is to perfectly time the start and end of the burn. We're always going to be some milliseconds out either end when we do it manually, and the fiddling looked to be mostly adjusting for that? To me at least.

[JoeSchmuckatelli]

12 minutes ago, Picard2 said:

In the video it looked like the kind of minor inaccuracy caused by how difficult it is to perfectly time the start and end of the burn. We're always going to be some milliseconds out either end when we do it manually, and the fiddling looked to be mostly adjusting for that? To me at least.

Yeah - in fact I was literally on auto-pilot when I did that while recording and only noticed it upon review (and after the recent conversation above).  It was so much like what I remember doing regularly in KSP that 'needing to refine the burn' via feathering the CNTRL/Shift keys was automatic.

I think the point to not forget is that we are comparing the 0.1.0.0 KSP2 functionality (which failed to replicate KSP, and did not live up to the promise of adding things/making it easier for duffers & beginners), and 01.1.0 functionality which does replicate KSP and does add something to STOCK functionality.

The promise of EA Sandbox was effectively a working rebuild of the basics of KSP.  It failed to do that, coming out in an Alpha state, not an EA state.  With the patch, a lot of the glaring, practically game breaking bugs have been cleaned up, if not fixed.  My limited play time gives me Beta vibes at this point.  There are still a lot of bugs, and Spaceplanes are acting weird, plus there's some new weirdness in the VAB - but having the ability to 'follow the instructions' and easily use things like MNs is working; thus Beta.

I'm not ready to acknowledge this as an EA title yet.  We're still in pay-to-play Alpha/Beta territory.   That said, if they do anything nearly as comprehensive with the next patch - I'm likely to declare it a worthy EA title - and meeting the expectations of this stage of the Roadmap.

Till then?  I'm still advising people to wait, unless they enjoy the Alpha/Beta experience.

[Picard2]

4 hours ago, JoeSchmuckatelli said:

-

Indeed - the size of the first patch and the number of things addressed does give me more hope now. Still a long way to go, obviously, but the brief time I spent with it last night it did feel like a step up in playability - and manoeuvre nodes, intercept planning were a couple of the big ones towards that.

[Rafael acevedo]

Much more accurate, congratulations 

[Tazooka]

I find that for Kerbin, its accurate. But I've ran into a couple of issues with manoeuvres around the Mun.

Eg, burn for 4 seconds, but in reality I only needed to burn for about 1.5s (my orbit was way past my target)

It seems to like large burns, but small correctional burns it isn't very accurate

[The Aziz]

Guys guys guys. While there may be some slight inaccuracies in timer, as it may have no idea about your reduced thrust or staging, there's one very super ultra simple solution.

Switch to map view and watch the damn trajectory. Cut the throttle when it's aligned with planned path.

Tada, problem solved.