herbal space program

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.

I feel your pain. I'm finding with my Jool 5 mission that I'm having to repeat just about every major mission phase 4-5 times, because something always bugs out. The worst thing IMO is that some of the bugs have a prolonged latency, so you don't realize that you're snake-bit until much later when you try to undock or re-dock your lander and everything explodes. Lather, rinse, repeat, repeat, repeat, repeat, repeat. Still, I've managed to do Laythe, Tylo, and Vall now, and surprisingly of the three Vall, which I finished this morning was the most maddeningly difficult. It was ridiculously hard for me to get a good encounter coming from Tylo, but worse, it seems like in the Vall SOI the orbital decay bug happens every time you take two things that are docked together to less than 20km from the surface. It took me quite a while to figure it out, but I also determined in the process that the orbital decay bug and the docking insanity are somehow tightly linked. Every time the combined ship would start to drift in its orbital path, any future attempt to dock or undock my lander would prove disastrous. Any attempt to focus elsewhere and come back, or f5-f9 from that situation, would also have the ship come back like some tremendous jolt had gone through it, with everything flailing around. These three things seem to all be inexorably linked together, and AFAICT once that happens to a craft, the only remedy is to go back to a save from before the point where the drift bug first appeared.

No worries, pedantry is a baked-in feature of this whole forum community . And yes, I have a whole lot of learned behaviors to shake wrt KSP1 maneuver nodes. I've played around 4,000 hours of KSP1 total, and a whole lot of that time was spent plotting complicated multi-gravity assist ways of getting from here to there by twiddling maneuver nodes.

Sorry, I misspoke there. What actually I meant was the "maneuver" marker all along. That's what I was talking about. So you place the node, dragging the handles in whatever direction you want to go, and then boost on that maneuver marker. Obviously in KSP, the " target" marker literally means something else. I am just carelessly mangling the terminology.

Fair enough, but I only actually invoked the term secant because somebody else did first. I could qualify what I said more to make that representation more accurate terminologically, but the simple way of explaining it is that in the old system, your target marker always closely approximated the same absolute spatial direction as the one you defined where you placed your node. In the new system, it doesn't work like that anymore, which is going to take some getting used to for me since I have spent thousands of hours doing it the old way.

Not actually talking about the trigonometric function. In basic geometry, a secant is any line that intersects a circle or ellipse in two spots, dividing it into two separate areas. In this context, I was saying that if you have a prograde maneuver node placed in KSP1, the vector defined by boosting on your target marker anyplace other than exactly at the node will be a secant of your orbit that is parallel to the (tangent) vector that would be defined by boosting exactly at the node. It actually works the same way for boosting in any direction in the prograde/radial plane, except that both vectors would be secants if the node is in any direction other than pure prograde or retrograde. Anyway, in the KSP1 system, that means that boosting on your target vector a short time before and after the node does a pretty good job of maintaining the optimal attitude to actually achieve the trajectory you want. I'm not quite sure how that idea translates to the KSP2 system, since if you are boosting prograde at the spot you placed your node, you won't be boosting prograde anymore at the midpoint of your burn.

Wow, I was totally unaware that such things were available in that interface. I will take another look at 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.

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.

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. Well then they way they've defined them is dumb, as I said above.

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.

I have to believe that this feature is just not properly implemented yet in KSP2. It tells you to start right where you placed your node, and we all know that's not how it works. 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. But I guess we'll have to wait for that.

I'm very glad to see these issues getting knocked off in real time rather than having to wait for months. Now if you can get the orbital decay bug and all that crazy weird stuff about docking fixed, the game will start to become playable for real!

Good decision to issue a hotfix for that one!