herbal space program

Different strokes I guess. I got to the point with KSP1 where my correction burns were generally done using RCS with the lightest touch possible. I'm nowhere near that with the new system.

Not in KSP1, but in KSP2 there is! In KSP1, the radial component is baked in after one does just what you said, because your maneuver vector at the start of your burn won't actually be prograde, but somewhere inward of that. In KSP2 it doesn't actually work that way, hence all this blablabla on my part.

I appreciate what you're doing here, but for the record, if you look down-thread in the linked discussion, you'll see that I already retracted my initial statement about how the KSP2 maneuver node behaves, although it still doesn't do what it's supposed to do perfectly IMO. I also stated in that thread (as you should know) that for an optimal ejection burn using this new system, especially if it is a longer one, you will have to add a radial inward component to your maneuver node, as you have shown here. I still however stand by my contention that at least for advanced levels of inter-body navigation, especially if multiple periapsis kicks are required, this system is not as easy to work with as the KSP1 system for generating the most efficient possible burns. That's because if you really know how to use the KSP1 node system, you can figure out how to closely approach the optimal burn profile considerably more easily, because 1) you don't have to fiddle about a bunch to optimize how far inward of prograde you need to aim at the outset to put your burn vector on the optimal secant to approximate an instantaneous impulse at the best spot, and 2) If you need to do multiple periapsis kicks, the KSP2 node is really unhelpful in terms of where to place those, whereas the KSP1 node pretty much tells you exactly where that should be right off the bat. As to why I made my original, incorrect statement of what the KSP2 node does, I think it's because it gets confused and doesn't really give you the right trajectory in some situations, like space planes that have multiple parallel engines that can be toggled on and off for very different TWR (my most common vessel), and burns where two stages with widely disparate TWRs are used sequentially. At any rate, in order to dispel any notion that I just live to disparage KSP2, I will see what I can do to adapt my navigational approach to the new system and report on what I find here. I will also investigate what situations might confuse the trajectory prediction algorithm. And AFAICT that maneuver node controller you use above is not a part of stock, so I will not make use of that. ...And the last thing I'll say, before coming back with some documentation of these efforts, is that the Devs could instantly make my problem as a player with ingrained KSP1 habits go away by allowing us the option to arbitrarily set the TWR when placing nodes, rather than only using whatever value it decides. Then I could set it to infinity to determine the ideal instantaneous impulse and multi-kick burn center, ala KSP1, and also to its actual value according to my specific configuration to determine my trajectory after any particular burn.

Well that's actually not bad, although it's not the same as what you said before. Regardless of that, when I'm looking at an initial TWR of 0.15-0.4 on LKO, which is usually how it is for my long-range transfer stages and space planes, I'll generally divide the dV required to get up to just short of Munar capture (~830 m/s) into at least 3 separate periapsis kicks of 2.5 minutes or less. If you divide those evenly across your point of ideal instantaneous ejection, i.e. where you'd place the node in KSP1, your cosine losses up to that point are pretty trivial. If you're going to Duna or Eve, you can set up a Munar assist from there that will get you an intercept for less than another 100m/s. If you're not going to bother with that, you can do the rest for a little over 200 with just another final kick, still losing very little from boosting off prograde. If the destination is further out however, requiring more than ~400m/s above a minimal Kerbin escape trajectory, there are other things you can to reduce wasted dV on the long final burn that's required. One of these is to raise your PE to 500-1000km from your distant AP, which costs you a little in dV terms due to Oberth losses, but more than pays for itself with the reduced cosine losses you'll suffer doing that long burn out of a slightly slower and significantly higher-radius orbit. If you're doing a Munar assist, you can also divide your final burn into two shorter ones at your Kerbin and Munar PEs, taking maximum advantage of the Oberth effect in both places. As I said before, I have done a whole lot of this sort of thing in KSP1, and planning such maneuvers under that system is something I can do in my sleep. In KSP2, I have still not figured out how to do it anywhere near this precisely. Lastly, for Tylo or any other vacuum body, the most efficient possible (theoretical) landing plan is to set your PE to zero and do an instantaneous retrograde burn of exactly your surface velocity at exactly that point. As this is of course impossible, the best physically plausible approximation of that is to plot a purely retrograde, continuously full thrust "suicide" burn, starting at whatever point prior to that tangent PE that will bring your velocity to exactly zero when you reach the ground. This is not an easy thing to do, especially for Tylo, and definitely not something you want to attempt with a marginal TWR, but to the extent you can approximate that descent profile, you will make it more efficient. TBH, I never really use a maneuver node to try to set this up, because neither system will have you boosting in the most efficient, continuously retrograde manner. So I usually just seat-of-the-pants it, giving my F9 key some exercise if I come in hot or stop too short. On that score, I'd say that stopping at 2km up on Tylo would probably be a do-over for me, as even a near-instantaneous braking burn near the ground from there will cost you over 210m/s, and in practice you'll probably spend closer to 400-500 to put yourself down safely.

Docking is super easy if you know how to do it right, and I saw a couple of major mistakes in there. Clearly you were able to navigate to a decent, low-velocity orbital intercept, which is probably the hardest part, but there were two major things missing: 1) As soon as you get your two ships in physics range of each other, have each one set the other as its target and have them both lock to each other with the SAS. It looks to me like only one of your craft, the one you were controlling, was set to do that. and 2) Use your RCS translate buttons to make the final approach! If you are reciprocally locked with your target wrt heading, those buttons make it very easy to both line up your target and prograde markers and control the speed at which you close. Just do those two things and you'll never think of needing a computational crutch to dock in orbit again! ...Having said that, there were horrible bugs around docking in the earlier versions of KSP2, which would cause all kinds of unpredictable bad things to happen, but happily it seems those have been slain.

Yes, but exactly how much inward? It's really much easier to have the game figure that out for you!

So I will admit that I was wrong about one thing, which is that the KSP2 maneuver node does not in fact calculate your trajectory based on an instantaneous impulse at that spot, but rather tries to calculate your trajectory from wherever you placed your node if you start burning right there in the selected direction. That may seem like an improvement to some, but IMO it is most definitely not one, because it actually makes figuring out the optimal burn profile to achieve a particular final trajectory much harder instead of easier. That's because the the most dV-efficient possible way to eject from orbit to some other (in-plane) destination is to deliver an instantaneous, exactly prograde impulse to your craft at just the right spot. As that is not physically possible, the next best thing is to point your craft in the direction that would be exactly prograde at that spot, and then burn along that heading in a manner that more or less evenly splits your burn time between before and after you hit that spot. So the problem with this supposed improvement is thus that while it's very easy to specify a purely prograde trajectory from some particular spot, that's not actually the direction you need to be boosting in when you start your burn. Instead, in the new system you have guesstimate some radial inward component to your burn that will be just enough to have you going parallel to the prograde direction halfway through your burn. How exactly do you do that? Worse, if you are doing multiple periapsis kicks, you'll have no real idea where to place your first node or what direction to boost in to put your initial periapsis at the right spot for subsequent kicks. In KSP1, that was pretty much a no-brainer, because you could optimize your total impulse right at the outset, so you knew exactly where to place the next node. YMMV, but I have executed countless SOI transfers in KSP1 and quite a few also now in KSP2 my friends, and if you really want to do things efficiently the KSP1 way was definitely better.

1700 m/s to go to Duna? It takes nowhere near that much dV to go to Duna from LKO. It takes a bit more than 1km/s if you go straight there (go read what it actually says at your link), and you can do it for around 900 m/s if you use a Munar assist on ejection. If you have really lousy TWR, you can do about 80% of your ejection burn in a series of short periapsis kicks, so you only have to boost the last 200m/s or so on the final kick, even less if you want to deal with the possibility getting captured by Mun. Of course the way the KSP2 maneuver node works is very ill-suited to that, so I'm not surprised it caused you to expend almost twice as much dV as you would have actually needed if you did it right. But by all means, keep telling me about how great it is!

No, it is not some hard-to-reproduce bug. If I start my burn at half its duration before the node, I end up more or less exactly where it said I would go. If I do it right where I place the node, which is what it tells me to do, that totally doesn't happen. Try it with a long burn sometime!

Like every time! Seriously, you can take my word for this. It still doesn't work right. It always tells you to start right where you placed the node, even though it pretty clearly calculates where that node will take you based on an instantaneous impulse at that spot. And that does not work, especially for longer burns. See what happens when you need to do a 4-minute Jool ejection burn for example.

Yeah, IMO that's just about the most game-killing bug that's left at this point. Still seems to happen almost every time you take a Kerbal or rover out of the physics range of an inactive lander and then bring it back. I had the same problem on my Duna monument mission, in which I landed a probe core-controlled rover separately from my crewed lander and drove it first to that and then to the monument with crew. Seems like that was a popular solution based on just a cursory look upthread! At any rate, when I came back from tagging the monument, my lander was on its side as well, with the hatch facing down. Luckily, I was able to rotate it by pushing it with the rover, then prop it semi-upright by deploying the (phenomenally strong!) solar panels in the weak Duna gravity. Probably not gonna work on Laythe. That mission was also strongly affected by another bug, which is the weird tendency of the VAB interface to slip unwanted Kerbals into your craft at the last second. Because of that, I belatedly discovered I had a Kerbal stowaway in my supposedly fully autonomous rover stack, for whom there was no berth for the homeward voyage on on the 1-Kerbal crewed lander. He fortunately got to ride back to orbit on the ladder of the lander, and now has a berth in same for the ride back home, although the original mission plan was to discard the lander at Duna. It has parachutes, but it remains to be seen if it can handle Kerbin re-entry...

I've been playing through a science game recently, after taking a lengthy break out of frustration with all the bugs, and in general I have to say the game is a lot more playable than it was before. Rockets don't bend like wet noodles, orbits are generally stable, and larger craft don't just go off the rails in orbit and shake themselves to pieces apropos of nothing. The framerate is also markedly better for me, and I kind of like the direction they are going with the science missions. There are still countless little annoyances though, and among them is the still-not-correctly-implemented maneuver node system. I don't actually have any trouble working around it, since if you just ignore when it tells you to start boosting and do it KSP1-style, it seems to work fine. Still, it also doesn't seem to me like fixing it would be particularly difficult -- like changing one or two lines of code to calculate the burn start time correctly. How many hours of dev work could that possibly take? Another similarly easy-to-fix issue that should really have been taken care of by now is the hilariously wrong info in the planetary stats panel in the tracking station. That too couldn't require more than an hour's worth of work to fix. Again, for me that's not a big deal because I know where I can look the correct info up, but still stuff like this creates a real barrier to enjoyment for people who are newer to the game and don't expect it to just lie to them like the Soviet Politburo. They are doing themselves a significant disservice by letting such easily fixed, off-putting-for-newbies bugs linger. ...Note to anyone who takes issue with what I said here: I retracted my statement above on how the KSP2 node works below, although I still don't think it works quite right even so. But the bottom line at this point is that I consider it a mostly correctly implemented, but still wrong-headed change rather than a bugged one, for reasons elaborated upon down-thread and elsewhere.

I honestly don't think this bug requires any further documentation.

I'm sorry to say that while the orbital decay part may be much improved, I'm still getting game-killing phantom motions around docked-together modules. I was trying to build a big interplanetary colony ship with something like 50km/sec dV and capacity for 72 Kerbals plus a bunch of other stuff, the idea being it would be a SWERV-based baby version of the interstellar ships we expect to get someday. The engines were mounted out to the side, near the front, and it was supposed to have a string of 4Xjumbo tank modules docked behind it, which could be jettisoned as their fuel was used up. Unfortunately, after I docked up the first 4-tank module to the large core ship, exited the game, and came back a few days later to continue my orbital build, the 2-module ship would just start oscillating harder and harder around the docking junction, until it tore itself apart. That's with no thrust or SAS inputs of any kind being applied. Just phantom motions out of nowhere, building slowly from the moment I loaded the ship until it flew apart maybe a minute later. Same thing every reload, and quicksaving and loading that save yields the same result, so the corruption is somehow baked into the save file. I must say that with that episode I have finally had it. The game is still completely broken 8 months after its initial release, to the point where even exploring the limited content available so far just isn't any fun. I am going to go into hibernation now, and hope that the game is in better shape in anther six months. As it stands now, it really just offers me nothing but frustration.

I'm very interested to see if this fix of the orbital decay bug has also fixed some of the other issues with phantom oscillations, randomly displaced parts, and docking catastrophes. Those things all seemed to be very tightly correlated when I was doing my Jool5 mission, as in all the other stuff only seemed to start happening after one of the craft involved had experienced orbital decay.

So in the opinion of the programming experts around here, is this bug going to leave a lot of residual pollution in the Windows registry if the game is uninstalled? I don't even know how to look at that.

Reinstalling UITK/SW/MicroEngineer totally fixed it for me. Thanks for the tip!

0.14 is hanging up in the same spot every time for me while loading, while it says "loading localizations from addressables". I tried uninstalling and re-installing and it still crashes in the same spot every time. ....Wow, after like 15 minutes I finally got the top menu screen. I sure hope it's not that slow every time. Anyway, at least I can play it now!

Under some circumstances, often related to the orbital decay bug, they produce wild, frequently craft-destroying phantom forces upon docking or undocking. Once a craft's internal momentum numbers get corrupted, even if the initial signs of it are subtle, you can never dock or undock it again without something very bad happening. It generally doesn't occur if all you're doing is docking stuff in Kerbin orbit, but if you try it in other places with different bug behavior, it happens all the time. I'm pretty sad it apparently didn't get fixed, because nearly all of my missions involve repeated docking and undocking around bodies other than Kerbin. ...There was also a bug where struts didn't break as they are supposed to upon undocking if they were connecting two docked parts . Not sure if they fixed that one yet either.

Do ships still explode and/or or fly off at absurd velocities when docking/undocking? I didn't see that on the list, and that's probably the biggest game-breaker for me. It's also definitely related to at least some modes of the orbital decay bug swarm based on my experiments.

I finally got around to finishing all my Jool 5 landings with my big interplanetary space station, seen here inbound at the beginning of the mission: First up was Laythe, the only landing destination for the big Mk3 space plane: Next up was Tylo, with a beefy, SWERV-based 2-stage lander: The upper stage did the better part of the ascent back to orbit, docked to the mothership, refueled, and served as a single stage lander for the other 3 bodies: Vall: Pol: Bop: After Bop, I re-docked the space plane to the mothership in a Jool orbit between Tylo and Bop, and then jettisoned the now empty center stage behind the truss structure. The remainder has something like 4 km/sec total dV if I exhaust all the methalox in the mothership and then dump it to go home with just the two landers docked together: That's probably enough juice to make a side trip to Duna or Dres on the way home, but I haven't decided about that yet.

I think I mentioned this before, but I determined on my lengthy Jool 5 mission that bugs #2, 3, and 13 all appear to be related. That is, whenever a ship starts to show signs of orbital decay, you can count on it to also have problems when docking/undocking, and moreover to exhibit various phantom motions, sometimes violent, whenever you exit timewarp inside of the decay-inducing altitude for a particular body. For that reason, I suspect that definitively fixing any of these bugs will actually fix all of them.

AlI can say is that if the game we ultimately get deals with all those issues in a consistent, rational manner that both requires attention to it by users and supports fun gameplay, I will be very pleased! In reality however, we are unfortunately still a long way from talking about stuff like that in a meaningful way.

One observation I feel I should add here is that if the orbital decay bug gets set off on any docked-together assembly, subsequent attempts to undock from or dock to the affected craft will unleash massive phantom forces that often destroy one or both craft. So the docking bug and the orbital decay bug seem to be causally linked.

I spent a fair bit of time analyzing this bug around Vall a couple of days ago, and what I concluded was that it will happen anytime you let a ship with two docked-together modules get closer than a certain distance, which varies from body to body, as @AstroClef documented early on. IOW, I'm not sure you'd actually get the decay bug if you staged everything off before you ever reached that critical radius around Mun. When I kept my Jool5 mothership at a safe distance from Vall, the lander (which is just one assembly) seemed to have no trouble going to the surface and coming back to that safe distance. Once you've got it though, your whole craft will remain affected permanently, and you can only get rid of it by going back to a pre-bug save file. The decay per se may actually go away if you leave the SOI where it happened, but whenever it happens it also corrupts your craft so that it will forever afterwards be plagued by phantom forces. These will become evident any time you go away from it and return or timewarp and then return to full physics. My Jool5 mothership would practically shake itself apart. I think it actually has something to do with aberrantly creating big pent-up forces in docking interfaces, because the orbital decay bug is also perfectly correlated in my experience with the docking disaster one, i.e. once the big ship started to drift in its orbit, any subsequent attempt to undock the lander would make something really bad happen.