Release KSP2 Release Notes - Hotfix v0.1.3.2

[KUAR]

59 minutes ago, herbal space program said:

That's not how it works period. If you place a maneuver node, your burn needs to be symmetrically timed around it for maximum efficiency  regardless of the game version.  Putting it all on one side of the node is never the best. That's just orbital mechanics, not the game.

No, not true. The two games have literally defined what the nodes mean differently. It was the first thing I noticed when planning nodes in KSP2.

[herbal space program]

4 minutes ago, KUAR said:

In KSP2 it tries to factor in the duration of the burn as well as the velocity vector change to give a more accurate prediction. The most intuitive way to plan this therefore is to specify the START of the burn time. Perhaps this is important for future interstellar engines which might have crazy long burn times.

If that's really the way they tried to design it, then it's pretty dumb, because if you're trying to do a series of periapsis kicks, you have to estimate for yourself where to place the node so the burn is symmetrical around your periapsis.  It would be much better they let you place the node as if it was an instantaneous impulse at a given point, and then spread it out before and after that point,  maybe even trying to correct for the additional dV, and giving you some kind of warning if your cosine losses are going to be excessive. This system is actually significantly harder than what KSP1 had for no good reason I can see.

8 minutes ago, KUAR said:

No, not true. The two games have literally defined what the nodes mean differently. It was the first thing I noticed when planning nodes in KSP2.

Well then they way they've defined them is dumb, as I said above.

[The Aziz]

5 minutes ago, herbal space program said:

you have to estimate for yourself where to place the node so the burn is symmetrical around your periapsis.

You don't have to estimate anything when you have all the indicators at hand. Simply set it up so the new Pe stays in the same place. It's supposed to be more precise than the actually estimated "halfway to the node" because there's no way your trajectory will look like planned.

[KUAR]

1 minute ago, herbal space program said:

If that's really the way they tried to design it, then it's pretty dumb, because if you're trying to do a series of periapsis kicks, you have to estimate for yourself where to place the node so the burn is symmetrical around your periapsis.  It would be much better they let you place the node as if it was an instantaneous impulse at a given point, and then spread it out before and after that point,  maybe even trying to correct for the additional dV, and giving you some kind of warning if your cosine losses are going to be excessive. This system is actually significantly harder than what KSP1 had for no good reason I can see.

I do appreciate what you're saying.

It's definitely how it's set up though. Next time you're in it, check the orbital lines closely. There are three parts to your trajectory when you plan - one old orbit, one predicted orbit, and one non-conic trajectory which represents your predicted path under acceleration.

I think it adds more benefits than drawbacks personally but I see your point about periapsis burns.

As long as you keep the burn time short with respect to the orbital period, it shouldn't be a real issue - and if the burn time isn't short, then you'll have inefficiencies no matter which planning style is used.

However if I were worried about it then I could plan an ideal periapsis kick by aiming to keep the new periapsis at roughly the same position as the old one. Alternatively I could set the node to start on the Pe, see how long it is, and bring it back by that many seconds using the Manoeuvre Node Planner mod.

I think we'd have found the drawbacks of symmetric nodes an issue when it comes to interstellar engines and the new properly scaled Xenon engine though

[herbal space program]

30 minutes ago, KUAR said:

It's definitely how it's set up though. Next time you're in it, check the orbital lines closely. There are three parts to your trajectory when you plan - one old orbit, one predicted orbit, and one non-conic trajectory which represents your predicted path under acceleration.

I think it adds more benefits than drawbacks personally but I see your point about periapsis burns.

Maybe it will just take some getting used to on my part, since I'm so familiar with the old system. It would certainly help me a lot if they had an indicator for the midpoint of the burn, so I could line that up with my PE. I don't actually recall seeing two different versions of my PE when  did this before, but maybe they were right on top of each other. Actual numbers instead of that clunky bar indicator would also be quite helpful, as would some provision for serial periapsis kicks, but of course KSP1 didn't have that  either.

[Wheehaw Kerman]

Nice to see that hunt end successfully, but the taxidermist bill is going to be huge!

 

[MechBFP]

Once the decaying orbit issue and wobbly rocket issue is resolve, and assuming no regression occurs, it looks like people will mostly be able to play the game as intended without bug related mission failures.
 

Don’t get me wrong though,  there are still TONS of annoyances that need to be fixed, and tons of missing QoL features, and hopefully when the science update comes out a large chunk of those will no longer be issues. 
 

One thing I will say is that the longer it takes the science update to come out, the higher our expectations will be, so keep that in mind with your planned time line. 

[whatsEJstandfor]

20 minutes ago, MechBFP said:

Once the decaying orbit issue and wobbly rocket issue is resolve, and assuming no regression occurs, it looks like people will mostly be able to play the game as intended without bug related mission failures.

I would add incorrect dV calculations (and the knock-on effect it has on maneuver planning) to that list, but, def, this hotfix is big time massive good news

[SethM]

Yayyyyyy!

[Vanamonde]

Some comments removed. Keep it on-topic, please. 

[Heretic391]

Thanks for the great effort here  

[schlosrat]

5 hours ago, herbal space program said:

Maybe it will just take some getting used to on my part, since I'm so familiar with the old system. It would certainly help me a lot if they had an indicator for the midpoint of the burn, so I could line that up with my PE. I don't actually recall seeing two different versions of my PE when  did this before, but maybe they were right on top of each other. Actual numbers instead of that clunky bar indicator would also be quite helpful, as would some provision for serial periapsis kicks, but of course KSP1 didn't have that  either.

The new approach is necessitated by the more accurate way KSP2 handles the orbital calculations. While it’s certainly possible to set up well timed periapsis kick maneuvers manually, you might want to take a look at Flight Plan. It will set them up for you so they start at the precise correct time to have the midpoint of the burn on the periapsis. You can still execute the node manually if you prefer, but FP can take the guesswork out of sizing and placing the node if you like.

[Lyneira]

13 hours ago, Spicat said:

You can move the node to do exactly that, it's just a visualization change

Besides, if you start at the node, the projected maneuver will be what you will have, so it's not a question of efficiency or not, the feature is properly implemented. If you want them to make the node in the middle, make it a suggestion.

If I'm doing an ejection burn and want to mimic KSP1's way of burning halfway before the maneuver and halfway after, I set the maneuver a little earlier than normal and add a radial in component. My goal then is to keep adding more prograde and radial in while keeping the Pe marker roughly in the middle of the projected burn. Seems to work more efficiently than just placing a maneuver with a lot of prograde and ending up burning far off my orbit trajectory towards the end of it.

Edited July 12, 2023 by Lyneira

[Ace27]

Congrats on this one, I know it's been a long time coming. Looking forward to science mode!

[Sea_Kerman]

8 hours ago, Lyneira said:

If I'm doing an ejection burn and want to mimic KSP1's way of burning halfway before the maneuver and halfway after, I set the maneuver a little earlier than normal and add a radial in component. My goal then is to keep adding more prograde and radial in while keeping the Pe marker roughly in the middle of the projected burn. Seems to work more efficiently than just placing a maneuver with a lot of prograde and ending up burning far off my orbit trajectory towards the end of it.

A mode to have the node automatically do this and calculate a sort of secant to your trajectory centered around the node would be nice. Perhaps that would be the default mode, and the current mode would be the "long burn" mode.

[Mitokandria]

Wooo! Thank you for the hotfixes!!

[herbal space program]

20 hours ago, schlosrat said:

you might want to take a look at Flight Plan. It will set them up for you so they start at the precise correct time to have the midpoint of the burn on the periapsis. You can still execute the node manually if you prefer, but FP can take the guesswork out of sizing and placing the node if you like.

Wow, I was totally unaware that such things were available in that interface. I will take another look at it.

6 hours ago, Sea_Kerman said:

If I'm doing an ejection burn and want to mimic KSP1's way of burning halfway before the maneuver and halfway after, I set the maneuver a little earlier than normal and add a radial in component. My goal then is to keep adding more prograde and radial in while keeping the Pe marker roughly in the middle of the projected burn. Seems to work more efficiently than just placing a maneuver with a lot of prograde and ending up burning far off my orbit trajectory towards the end of it.

The nice thing in KSP1 is that if you set the node at the spot that would give you the most efficient trajectory change as an instantaneous impulse, aligning to that target marker  automatically points you along the  secant parallel to your optimal burn vector wherever you are in your orbit.   I am certain that there are even more efficient ways to calculate your optimal start time and attitude through the burn, but that was really pretty good, at least in short burns that involved small changes in heading. I don't really understand how to do that in the KSP2 representation yet, so it seems worse to me, but maybe once I figure it out it will be as good.

Edited July 13, 2023 by herbal space program

[Mitokandria]

I got a probe to the Mun and everything acted as expected. There is still orbital decay, but it seems like the trajectory fix may have also resolved one of the sources of orbital decay.

Edit: Except for EC usage. That's still borked, but not game breaking or enjoyment ending.

Edited July 13, 2023 by Mitokandria
clarification

[DunaManiac]

Happy to see that the KSP2 team is adopting a better approach for bugfixes, and that these gamebreaking bugs that have been since day 1 are being resolved.

My one complaint is that hotfixes weren't done since the beginning, and that this is a U-turn from the team's "we're slowing down update cadence" statement.

I would also like to see Intercept commit more on time. Their pre-launch delays and the state of the game at launch do little to inspire confidence. Even for a patch, intercept didn't commit on timing, finally releasing a date, only to delay it for another 1-2 days for unexplained reason, only for the patch to release with serious drag bugs, requiring a hotfix, which required another fix because it was "misconfigured..." etc.

It shows to me that there are serious problems with quality control at intercept, and the reason they don't commit to a timeline and release on time is because they are unable to.

[whatsEJstandfor]

50 minutes ago, DunaManiac said:

My one complaint is that hotfixes weren't done since the beginning, and that this is a U-turn from the team's "we're slowing down update cadence" statement.

I think @Dakota has warned to not take this to be a sign that they're going to start dropping hotfixes on the reg. As I understand it, these were only released because the bugs they addressed were egregious and game-breaking; not because IG has, in general, moved away from the large and infrequent patches.

[Periple]

1 hour ago, DunaManiac said:

It shows to me that there are serious problems with quality control at intercept, and the reason they don't commit to a timeline and release on time is because they are unable to.

Few teams are able to consistently release where neither the scope nor the schedule flexes, and the ones that do are almost certainly working on something that’s relatively simple and well-understood. Just getting to a regular release cadence with flexible scope is very hard and it takes time for even experienced teams.

To give a concrete example, it took my current project about a year from initial release to get to a more or less stable 4-week cycle. And we still occasionally slip. Which is why we don’t announce exact dates either.

IG clearly still has work to do to improve their process but they’ve already made significant strides and I don’t see any reason to think they won’t continue to do so. This is hard and it takes time.

[Lyneira]

13 hours ago, Sea_Kerman said:

A mode to have the node automatically do this and calculate a sort of secant to your trajectory centered around the node would be nice. Perhaps that would be the default mode, and the current mode would be the "long burn" mode.

That's an excellent suggestion! Perhaps we could expand this suggestion to also affect the tracking mode for a maneuver when you set SAS to target it.

• A "short burn" mode that calculates said secant and uses a fixed orientation for the burn while executing it. This burn mode is centered on the node and starts roughly half of the burn time before it.
• A long burn mode for things like ion engines. This burn mode starts at the node and the maneuver uses a relative orientation to the current trajectory, so you can do a "burn prograde while spiralling out" plan for low TWR engines. Ideally, the vessel would also keep tracking the maneuver correctly during timewarp.

Edited July 13, 2023 by Lyneira
Refine suggestion

[Sir Eskomaz]

One step at a time! Keep going team 

[farelinho]

On 7/11/2023 at 8:07 PM, herbal space program said:

It would also be great if like in KSP1, the dV countdown showed you what is actually left on the burn rather than just statically what the initial dV was.

This lack of remaining dV sometimes really gets on my nerves! KSP1 is far more precise, and this change has no benefits whatsoever, imo. Hardly ever I can make a very accurate maneuver. On this case, prettier is definitely not better. 

Regarding the maneuver node placement, I think KSP2 is having a broader view and going the right way: even though you need to loose some extra time in placing simple short burns, it feels much better for longer burns. I sent a small probe to Moho with xenon engines and I liked the way it worked out. (I used metalox engines to get out of kerbin SOI).

@Sea_Kerman's idea could be a simple QOL improvement

Looking back to February, there's a lot o progress already done and I still keep high expectations for this game

Edited July 13, 2023 by farelinho

[DunaManiac]

9 hours ago, Periple said:

Few teams are able to consistently release where neither the scope nor the schedule flexes, and the ones that do are almost certainly working on something that’s relatively simple and well-understood. Just getting to a regular release cadence with flexible scope is very hard and it takes time for even experienced teams.

To give a concrete example, it took my current project about a year from initial release to get to a more or less stable 4-week cycle. And we still occasionally slip. Which is why we don’t announce exact dates either.

IG clearly still has work to do to improve their process but they’ve already made significant strides and I don’t see any reason to think they won’t continue to do so. This is hard and it takes time.

Interesting, out of curiosity, what are some of the reasons why its so difficult for even experienced teams to stay on time? Is it just unpredictability of the code, or other reasons?

I also wasn't asking for precise dates per say, but broader milestones. Like Science, for instance, will be released by the end of 2023, Colonies will be released by the end of the first half of 2024, etc.

Regardless though, for the playerbase who are laypeople and are unaware of the problems game devs deal with, Intercept has burned through all of its good will and really needs it back if they want to bring back their mostly disgruntled playerbase. You'll know this if you look at replies to delays prior to the Early Access update and post release.

I'm also concerned about the smaller issues that intercept has trouble with. For instance: the first hotfix. Apparently the build was "misconfigured," which forced players to launch from the launcher at all times. One could say its a small error with a quick fix, mistakes are made, etc. etc. but the fact that it is an easily fixable error that made it into the release version still shows they have issues with quality control, same with the drag bug the hotfix was made to solve in the first place. It seems like Intercept oscilates from moving very slowly with extreme caution, to rushing as fast as it can, and I think it hurts both the game and player confidence. To me, the "middle ground" would be to make broader milestones for big updates that the team is capable of meeting, with smaller, more frequent patches on a more regular schedule to fix burning bugs. But the fact that it has taken nearly 5 months for the game to reach a relatively stable state does not give me confidence for the future, especially the fact its been 4 years since announcement and we know no more about colonies and multiplayer than we did in 2019. It shows to me that they don't really have a solid plan for colonies at all, or one that's constantly being shifted. If so much time and work is being spent fixing bugs from launch, how are we ever to get to that point?