herbal space program

All I meant is that the first response to what I said above was for a forum moderator to come and tell me I asked a dumb question, when I really don't think it was, as Take Two owns both this forum and KSP. Anyway, this is not worth debating anymore, especially since I now know how to solve my problem.

I actually think it's more like asking "why does a Microsoft game require people to have an Apple account to report its bugs?", but I can see just from the fact that I am getting "moderated" over this post that I might as well argue with the wind.

No problem! I'm glad my advice was helpful.

1) If you're so keen on everybody using your bug tracker instead of discussing the issues they're having in the forum, why have you erected an additional wall of authentication between us and that process? Why must we work so hard for the privilege of beta testing your already-released game? Maybe you could bring up that question at a meeting some time. Besides, It's sad to say, but often the really knowledgeable people in this forum are faster and more reliable at fixing the problems we find than Squad is, as we have just seen. 2) For my part, I'm not even sure this is something you would define as a bug. Somebody in your outfit must have decided what the value of that static friction coefficient, which is apparently very easy to find and edit, should be. They seem to have chosen a number that causes the legs to slide all over the place in situations where they did not before. I personally am playing on a generic PC/Windows platform, through Steam, with no mods other than KER and your DLC installed. That and the fact that 3-4 others are reporting the same thing in the last few days tells me this is not some platform-specific weirdness. You guys changed a number that was fine before and apparently didn't thoroughly investigate the effects of that decision on gameplay. Meanwhile, some resourceful person in this forum has already found the offending number, and has not only told us we can fix the problem by editing it, but has even shown us exactly how to do it with a video! Based on your "I'm not saying it will get fixed, even if you jump through all our hoops" response, it seems pretty clear I'm much more likely to get my problem solved by talking about it here than I am by doing it your way. This is in fact the second time in as many months that this has happened for me, the last being the unfulfillable repair contract bug. Just something to think about! 3) The person who already fixed the problem for us in the post immediately above yours also said in that post that they made a formal bug report, for whatever that is worth.

Based on that, I would guess that you didn't do a burn at your orbital node to change planes, which would have you coming into Kerbin's SOI either far above or far below it. WHat you need to do to fix that if you try again is to look for the little yellow marker that says "AN" or "DN", and boost either normal or anti-normal to reduce the angle between your orbit and Kerbin's. That should put your PE much closer to Kerbin and by extension solve all your other problems. Just find that spot in your transfer orbit, place a maneuver node there, and pull on the purple N/AN handles until the two orbits are in the same plane. If you double-click on Kerbin to make it the map focus with that node open, zoom in to Kerbin, and rotate the view so you can see your node behind it, you should be able to make adjustments to the node and clearly see how that will change your Kerbin encounter.

Not sure how you converted your Kerbin flyby into that orbit, but you definitely don't want to circularize with such a high PE if your goal is to get to the ground. Whichever of those altitudes was the PE of your original Kerbin flyby, if you had boosted retrograde from there until you were just in orbit, i.e. with an AP near the edge of Kerbin's SOI, you could probably have taken your ship to that high, slow spot in its orbit and from there dropped your PE inside Kerbin's atmosphere for a couple of hundred m/s at the most.

If you are near Eve with Kerbin encounter that has a 250km PE already dialed in, then it should take just a tiny amount of dV to lower that to just inside Kerbin's atmosphere. In fact, you may want to warp forward until you're about halfway there so you'll have better control. Did you do a plane change burn anywhere? That would be a good spot to do this. Either way, place a maneuver node just in front of your vessel and twiddle the handles until you see a PE of say 60km. Then advance the game to where you're just outside of Kerbin's SOI and quicksave (or alt-quicksave) again. From there, you can adjust your PE up or down as needed to get a safe aerocapture, starting at ~55km. Even if you can't get to Kerbin orbit purely by aerobraking, any retrograde boosting you do from that lower PE will be significantly more efficient than trying to slow down into orbit from 250km, and will be added to whatever slowing you can get from drag. Those two things combined should leave you plenty of dV when you first make orbit to manage your subsequent aerobraking passes and safely lower your AP until you're in low orbit.

I don't know if you have a quicksave that you could go back to, but how did you determine that you had just enough dV to get to Kerbin orbit but not to land? Specifically, how did you set up your transfer? From an optimal Eve-Kerbin transfer, most craft can enter Kerbin's SOI with a low enough velocity that they can aerobrake all the way to the ground. I think an initial PE of 52-55km should be about right to get you aerocaptured on your first pass, but you may have to fiddle a bit. Once you're in some kind of high-AP orbit, you can adjust your PE as needed from that AP for next to nothing, keeping it at a height that slows you down significantly on each pass but doesn't make you burn up. If you can't quite get captured without boosting, then you should do so as close to your PE as possible and stop as soon as you see yourself no longer escaping Kerbin.

I'm playing a hard* career game, and that seems to be the default setting. I don't know where in lower difficulty levels that changes. *except with quicksave enabled

@xRaffle, Do you by chance have crossfeed enabled on your decouplers? That combined with incorrect flow priority settings might result in what you're dealing with. I don't really consider them a relic myself, because disabling crossfeed and using those is considerably simpler (at least to me) than managing flow priority across a complicated vessel is. Also, as you pointed out, having to keep an eye on the fuel level of the side tanks while managing your ascent profile can be kind of a pain.

I don't know about factorio, but I can say with confidence that when I started playing KSP in 2013 with 0.18, gameplay was nowhere near 90% of what it is now.

A fair point, but I'm trying to be nice about it!

I'm all for paying full fare and then some for KSP2, but the truth is KSP1 didn't get a decade of support, as it didn't actually come out until 2015! What happened before then is that the community willingly paid for the privilege of beta testing it.

I'd be happy to pay full price for my copy of KSP2 right now if it would speed up the development process! And the Jeb plushie too!

Like you, I can make the new wheels work OK in the update by changing settings, but unfortunately it seems they've greased up all the landing legs too! Here' s a screenshot of my Duna ore mining ship, which was perfectly stationary on around a 9-degree slope before the update, cutting loose and starting to slide so fast I couldn't time warp to stop it or switch away: Of course unlike wheels, the legs don't have any handy physics adjustment sliders, so I had to wait about 20 minutes for it to travel to a spot that was flat enough to bring it to a halt. Luckily there were no bumps or steeper spots to flip it over on that that little journey! Anyway, I don't know how the KSP community at large feels about these slippery landing legs, but I don't personally think that level of traction is acceptable.

People are saying this is the first stock weapon, but I thought people had already made high-velocity cannons out of stacked decouplers at some point. Is that not so? It's also not clear to me why this would be superior to just sticking a bunch of Sepratrons onto a probe core/battery/reaction wheel stack and making that into a guided missile. Does the shell have some property that ordinary objects don't?

I did quicksave that plane under high aerodynamic stress, and then had to invoke "unbreakable joints" in alt-F12 to avoid it breaking up on reloading. But at the same time I'm pretty sure that my weird rotor displacement didn't happen because of that, because as I was driving around looking for rocks to scan, the plane was already starting to take off at ~30 m/s and would pitch up easily, which is normal behavior based on my sandbox testing. After the update is when I first noticed it didn't want to take off anymore. Anyway, due to 1.12 or not, I want them to fix it too! ...So I went and looked at what it said there, and it sure does sound similar! Except that I also quicksaved/quickloaded a number of times while flying upside down, which reverses all the stresses, and it didn't change anything. Maybe it is something that only happens sporadically?

The wheels on my Eve plane were definitely completely different when I loaded it in the new version. On mine they spontaneously started shaking with a very high frequency as the plane turned down the hill and started sliding. I was able to make it stop in my case by increasing the brake strength and manual friction control while lowering the damper strength. There's still less traction than there was before, but in my case that was a good thing. In other news @KerikBalm and @MechBFP, I figured out a totally simple solution to my rotor angle corruption problem, which in retrospect I should have thought of before: the way it is now, the plane actually flies pretty well upside down ! Thanks nonetheless for your suggestions!

I don't know. Do you perhaps have a link to a description of that? I have seen some strange behavior with the robotic parts, but never anything quite like this. FWIW, I reloaded it several times in that situation in the previous version, and while I'm not sure I would have noticed the rotor issue per se, it definitely seemed a lot more inclined to take off on several of those occasions, as I was rolling it around in search of rocks to scan, than it was when I ultimately tried to take off for real in 1.12. That's cool, thanks! Alas when I checked it out, I was reminded that I would have to remove each and every fan blade and nosecone from my rotors individually before it would let me rotate them, and then of course replace them all. With 10 rotors and 40 blades, I don't think I quite have the patience for that. Also, it seemed that the angle snap tool on the one rotor I did try it on was messed up, so that it would not snap to a straight placement in either local or absolute mode, which was definitely not the case in the SPH. At this point I think my easiest means of continuing to play as if this hadn't happened will be for me to make another uncorrupted copy of that plane with a probe core in it, teleport it in right next to the messed-up version, use EVA repair to transplant the old science container to the new vessel, and then teleport the old one back to the KSC to recoup my funds. I just hope none of my other fancy ships with robotic parts do the same thing when I switch to them!

Of course that all stands to reason, but what I meant was it seemed like the wheels were actually holding me to the ground when I was trying to take off. Turns out that was not really happening, but rather that opening the ship in the new version somehow changed the angle of my rotors so they were no longer parallel to my fuselage, causing my propellers to apply their thrust at a somewhat downward angle, constantly pushing my nose down. It's still flyable, but just barely, and it definitely had no such problem before the update. My plane before update: Note how all the propellers point straight forward. Pre-update, it looked just like that on the ground on Eve as well, I just don't have a screenshot. Now compare to my plane post-update: You can see how the propellers now point more downwards, and in close-up how the rotors are now displaced and angled relative to the mounts. They're not broken either, nor are they drooping from the high gravity, because neither the "hack gravity" nor the "fix repairable parts" cheats under alt-f12 did anything to fix them. Sending my engineer out to rotate it back didn't work either, because it's too heavy. Regardless, I would say that this is an actual bug in the update that borked my plane, so I would caution those who have big career games going in the previous version to finish any technically complex missions like this one before installing the update. Anyway, as to the wheel code, this feels just like the last time they revamped it, which is to say things that worked fine before now produce all kinds of bizarre behavior and phantom motion. Hopefully they will get that all worked out in the next patch.

Mmm. This new wheel code is not working so well with my Eve prop plane. Seems like the wheels are somehow sticky wrt the ground. Plane also shimmied wildly with all kinds of phantom oscillations until I turned down the damper strength manually.

Halelooooyah!!

Well hunting for Easter eggs in this new version is almost sure to be more fun than flailing away at my impossible rover arm scanning mission on Eve, so I'll be downloading it as soon as I get done working today!

As has been said, a screenshot would be very helpful here, but when I got a mission like this what I did was launch into a polar orbit so that I could exit Kerbin's SOI in the normal direction to a solar orbit that's the same shape but in a slightly different plane. Getting back from that is pretty easy, because all you have to do is more or less "boost towards Kerbin" like you said, which is why I suspect that's what you did as well. As a matter of fact, if you actually exit Kerbin's SOI in a perfectly normal direction, all you need to do is wait until you approach your Kerbin nodal point and you will re-encounter Kerbin automatically. In fact if you don't see that encounter in the map view right after you exit Kerbin's SOI, then you know you had some non-normal component to your motion when you exited, which means your orbital shape/period is no longer identical to Kerbin's. In that case, if you wait too long to get back down to Kerbin's orbital plane, you will come in either ahead of it or behind it, potentially requiring a whole bunch more solar orbits before your intersect and Kerbin's position line up again. So it's not really an anomaly so much as an artifact of trying to encounter a body that is in nearly the same orbit and position as yours. Of course if you boost significantly more towards Kerbin from this situation, so that you reach its plane again before you have time to get too far ahead or behind of it, this won't be an issue. Anyway, does that make sense to you or have I got the wrong idea?

This threw me as well on the last career game I started. I thought they had just somehow decided to scrap all that.