Turbo Ben

I submitted a bug report for this a few weeks back and did a bit of investigating. The issue applies to normal, anti-normal, radial in and radial out. I will refer to these four as "X" to save time. So, notice that X is always 90 deg away from prograde. Always. As you burn towards X, prograde changes. Therefore, to remain 90 deg from prograde, X must also change. You can see this easily in game. Point at X marker and lock SAS (Basic SAS hold, not hold on X). Burn your engine and watch the X marker wander off. When you plan a maneuver node with an X component, it doesn't account for X moving as you burn. The bug lies in SAS "hold to maneuver" which tracks X as it moves, when it should remain stationary. For small burns towards X, you'll hardly notice, but the error will get larger the more you change your direction, such as in large inclination changes. The reason pro/retrograde are not affected is because they don't change your direction as you burn towards them. The only thing changing is your speed. Hope that's not confusing, it's quite difficult to put into words.

I had some joystick functionality (pitch and roll) until patch 3 removed it. I can't bring myself to go back to keyboard control, so it's back to KSP 1 for me. Hopefully we'll get HOTAS support before 1.0 but at the moment I'm not convinced we'll even make it that far.

They've just released a patch that we've all been waiting 2 months for, and put the game on sale, and have trippled their player numbers. Great. If they can tripple them again they'll be getting close to KSP1, a game that's over a decade old. Looking at the reviews since patch 3 and the sale though, it's not looking so rosy. 38 positive to 50 negative, or 43% positive. Even though it's the weekend and the game is now on sale, numbers are still down since Thursday. Maybe they'll get a bump next weekend when everyone's had a pay day. FPS might be king to you, but as someone who has had playable FPS from day 1, watching your ship spontaneously vanish is no better at 60 FPS than 6. I want to see KSP2 succeed, but it looks dead in the water to me. Hopefully they can pull a No Mans Sky, but from what I've seen so far, I can't see it happening.

I've lost all faith in the devs. So far, each patch has broken as much as it fixed. At this rate we're looking at at least 4 or 5 patches before the game is anything even close to playable, at 2 months per patch, that's 10 months. Then there's all the bugs that will come with science, which will be another 6+ months to fix. Then colonies... We've gone from a game that just needed polish to years of development. I think they've bitten off more than they can chew. I tried patch 3 for 15 minutes before uninstalling the game again. That's all it took to realise my joystick didn't work any more and the sound kept dropping out. And they haven't even fixed any of the game breaking bugs yet.

I raised a bug report for this weeks ago where I explained the problem. It also applies to radial in/out maneuvers. The problem is SAS maneuver hold tracks the normal/radial marker as you perform the burn, instead of staying fixed. (for example, the radial out marker will move as you burn towards radial out. Maneuver hold tracks this movement when it shouldn't, as this movement isn't accounted for when you create the maneuver node) To get a much better result, set SAS to maneuver before the burn, and then switch SAS to hold before you start the burn. It's not perfect as you won't get the minor corrections towards the end of the burn, but you'll get a much better result.

Can't remember where I saw it, but someone (dev or community manager) said that hotas support will be after 1.0 release. Console will be long after 1.0 release, so it could be years before joystick is working again.

The only reason to remove these reviews is to hide the truth. Seen as many are talking about re entry heating, could you point to where this is mentioned on the road map? Price sets expectations. Leaving a review that your expectations were not met is a perfectly valid review. Didn't read anything? The only thing to read to find out is the reviews, and you've just said most the negative ones should be removed. Ok I get it, I'm a mug. Serves me right for trusting the devs.

I admire your optimism, but losing joystick control is a deal breaker for me. I guess I was lucky that it ever worked, but I can't go back to using the keyboard for flight controls. It's already been said that joystick control isn't a priority, so I'm not expecting to get it back any time soon. I wasn't around for KSP1 EA, I came in at 1.7, but I know enough about early KSP1 to know it can't be compared. KSP2 has a full studio of professional developers, they've had 4 years and it's not like they didn't have a good template to start from. How much did they charge for KSP1 EA? I had pitch and roll control working, with yaw and throttle mapped to a hat switch. Not perfect but good enough. Patch 3 broke pitch and roll.

Glad patch 3 is working out for you. For me it broke joystick control. Massive step backwards in playability for me, I uninstalled again after 15 minutes. I suspect the moaning will begin to subside as more like me give up and move on.

I was running the game from the .exe. Steam wasn't even running in the background. Roll and pitch worked well, other than a couple of initialisation bugs. I had to enter and exit the input menu on start-up or the joystick didn't respond (including all the buttons), and on first entering flight view SAS was working opposite to how it should until I manually applied the joystick controls, but after that it was fine until restart.

I received the game as a birthday gift, so it's not even about the money for me. It's the image it portrays. The launch of the game has been an unmitigated disaster and this is just taking a big steaming dump on those that stuck with them from the start. I tried patch 3 today. It sucks. I've uninstalled and requested a refund. I doubt I'll get it, but either way I'm finished with this joke.

This is an insult. I came close to refunding in February but decided to give the devs the benefit of the doubt. 4 months later the game is still unplayable, there has been zero progress on the roadmap, and now you're offering discounts. I regret buying the game. I regret putting trust in the developers. I regret not refunding. I regret all the time I've spent researching and submitting bug reports. Now I just feel like a mug. I'm done.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 Home 64bit | CPU: Intel 11700KF | GPU: Nvidia 3090FE | RAM: 32GB DDR4 3600 Since launch of KSP 2 I have been able to map and use the roll and pitch axis of my joystick. Yaw and throttle would not map. Since 0.1.3 I can now also map yaw and throttle. However, none of the controls work during flight. Severity - probably low to most, but personally this has made KSP2 unplayable. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 Home 64bit | CPU: Intel 11700KF | GPU: Nvidia 3090FE | RAM: 32GB DDR4 3600 Weve all come across the orbital decay bug, we all now what it is. In the last dev update, Nate said they had it down to being caused by compounding part wobbles. So, I decided to put a command pod around the Mun and stage away all other parts leaving just the command pod. As it's a single part, there should be no wobble, and orbital decay should stop, right? Well, unsurprisingly, orbital decay continued unchanged. However, there were a couple of funky goings on that might help shed some light on this. Firstly, there was a wobble, a big one. Once all other parts were staged away from the command pod, it immediately began to wobble uncontrollably. Turn SAS off and the wobble stops (orbital decay continues though). Turn SAS back on and the wobble returns. I also started getting the camera mode change notification being spammed, so rapidly that it is unreadable. Pausing the game shows the modes to be ground and orbital. I have repeated this test with 2 seperate missions and loading up a quicksave after the inevitable crash into the Mun. It does it every time. To recreate, send an "explorer" command pod to a low orbit of the Mun (I went for about 10Km). Make sure you stage away all other parts of the craft leaving just the exploror command pod. P.S. I wouldn't recommend this for those that are sensitive to flashing images. Included Attachments: .ipsImage { width: 900px !important; }

Been away for a while waiting on this patch. It's a regression, my joystick no longer works. Oh well, guess I'll have to wait another 2 months for 0.1.4.

This is happening around all celestial bodies. My grand tour visited and landed on Duna, Ike, Dres, Laythe, Vall, Tylo, Bop, and Pol, it was the same on all of them. I think it happened at Eeloo too, but another bug ended the mission before I could land. It looks like a phantom radial in force (you'll notice one of PE or AP goes up while the other goes down, depending on where you are in your orbit). It even happens at Kerbol (the sun). In fact, I glitched inside Kerbol a while back and decided to see how close I could orbit the gravitational point at the center. I was unable to circularise the orbit because the radial in force was extreme as I got close to the center, eventually yeeting me out of the solar system when I got too close. I've also noted that avoiding the use of timewarp with a lander seems to make any orbiting craft more stable, as long as they were stable when you undocked.

Just to add I've had this happen at Duna while doing an aerobrake. After it happened, I loaded the nearest autosave. It happened again, and this time I don't even think I was under timewarp (it was a while back so not %100 on that). The third time it worked.

What am I expecting from the science update? Bugs. Lots of bugs.

I've done some further testing and updated my original post.

Radial out is always 90 degrees from prograde whether in orbit or during ascent. If your prograde is up, radial out is horizontal. Just try launching a ship using the up setting and watch it all go wrong at 36Km if you don't believe me.

Yes, the marker will try to adjust to keep the burn on track. It's generally pretty stable though except maybe at the very end of the burn. This is something different. The maneuver marker tracks the normal marker as it moves. In a high orbit at low velocity, this tracking is very rapid. Try setting up a maneuver node to create an escape trajectory using only a normal vector. The node will predict your orbit changing to head north and then leaving the SOI. What will happen is the ship will start to perform loops as it tracks the normal marker, and you'll finish up pointing in a random direction with hardly any speed added.

When setting up a maneuver node with a normal/antinormal element, SAS in maneuver mode gives the wrong result as the maneuver marker moves as normal/antinormal moves. Steps to recreate: To see the problem clearly, it would be best to recreate the following steps in a high orbit with a low orbital velocity. High over Minmus would be ideal but the Mun would be fine. 1. Set up a maneuver node with a purely normal vector. 2. Set SAS to track the maneuver. 3. Perform the burn as instructed. Expected result - the maneuver marker on the navball should be fixed during the burn and the resulting trajectory should match the maneuver node prediction. Observed result - the maneuver marker follows the normal marker as it moves during the burn. The final trajectory is not what the maneuver node predicted. This may also apply to radial in/out maneuvers, but I haven't checked. Edit: Just done some testing and can confirm this also happens with radial in/out. Also, the maneuver doesn't need to be purely radial in/out or normal/antinormal. Any maneuver that contains any of these elements will not be accurate, though won't be noticeable in most cases. The larger the radial/normal element, the less accurate the burn will be. For example, I set up a 45 degree inclination change in a 400Km minmus orbit. Performing the burn using the SAS maneuver hold and following the burn timer resulted in a 57 degree inclination change. Another sign that something isn't right is the yellow bar below the burn timer never reaches it's end point. It stops at about 1/3 and then starts going up again.

Radial in/out (and normal/anti-normal) are perpendicular to your direction of travel (prograde), irrelevent of speed. They move as you thrust toward them because you are changing your direction of travel, unlike thrusting prograde/retrograde where there is acceleration but no change in direction. Radial in/out is only the same as up/down in a circular orbit, or at AP and PE in an eliptical orbit. In a highly eliptical orbit, away from AP and PE (such as during launch), radial out and up are very, very different. If you launched using the up setting, your direction of travel is, well, up. When it switches to radial in/out at 36K, SAS immediately tries to turn the rocket 90 degrees from prograde to almost horizontal (almost because when it switches to orbital, the momentum you carried from the rotation of the planet is taken into account. That's why prograde moves when switching between ground and orbit modes, and why your orbit line in the map view isn't a straight up and down line.) I usually set SAS to hold before 36K, switch back to ground mode and switch SAS back to up. It's also possible to just switch to prograde before 36K (as long as your rocket is stable enough to handle the ground/orbital prograde shift and the inevitable SAS overshoot when moving to it). It can be a pain and it's easy to forget if you're concentrating on a staging event though.

It's not symmetry, at least not in my case - I have a Laythe lander that uses 3 Panther jet engines. I had engine mode set to 1 action group and then shut down to another. The mode change works fine, the shutdown doesn't.

I've been able to map analogue controls for roll and pitch to my HOTAS setup. I set yaw and throttle to one of the hat swiches. Have you tried mapping your joystick to roll and pitch in the input menu?