Draradech

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) KSP2 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Stock vessels are listed in the launchpad dialog, even if stock vessels are disabled in the current campaign:

You may have been in docking mode. Happened to me multiple times, press "Del" to switch back to normal. (I think this toggles even if you are using Del in textboxes, for example in the save craft dialog in the VAB...)

I believe that is a bug. As a workaround for now, go to the vab and launch another vessel (single pod works). This is now the active vessel (landed) and allows for fast time warp....

KSP2 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Summary: Predicted trajectories leaving the SOI of most bodies are incorrect. This affects the manuever plan trajectory as well as the trajectory displayed after burn. The trajectory flips to the correct one after leaving the SOI. I noticed that the map view camera rotates by the same amount as the perceived wrong angle of the trajectory relative to the bodies affected when switching focus between the vessel and Kerbol (or the parent body for moons). The following are the approximate rotations relative to the parent body, these match my experiences for Kerbin, Mun, Minmus and Duna, as well as the screenshots of others I have seen in this thread: Original report: KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) (Save file link removed, this affects all craft). History: This craft launched from Kerbin, landed on Duna, picked up a stranded Kerbal, and launched from Duna to the east. Now in 200km Duna Orbit. Problem: As can be seen in the video, a maneuver node set up to leave Duna retrograde leads to a planned trajectory of a Kerbol orbit with an AP further out than Duna and PE at Duna (this is wrong). This will also be the case for the displayed trajectory after the burn, right until the craft exits Duna SOI. At Duna SOI exit the trajectory flips to the correct one, with a Kerbol AP at Duna and PE further in (see images - images from a different run than video).

Actually, you do need to do that for prograde maneuvers as well. All maneuvers are assumed to have constant pointing. Your prograde changes during your burn, leading to inaccurate results if you turn with it. That's weird if coming from KSP1 (with half before half after burning - which is an approximation), but viewed without that frame of reference it makes sense (and is more accurate). For the maneuver direction I agree it's a bug. If the maneuver is supposed to have constant pointing, the indicator and SAS shouldn't drift.

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) Observed / Repro Steps: 1) Start new campaign 2) Observe smooth cloud movement 3) Time-warp ~2y to the future 4) Observe clouds moving in steps (~1s per step) This can be done completely in the KSC scene, but flight scene is affected as well. I noticed in flight after I returned from Duna, which obviously needed time-warp. Expected: Smooth cloud animation independent of campaign time.

Yes, that's the problem. The node direction as indicated on the navball, and followed by SAS, drifts away during the burn. If you look at my images in here, it works with SAS hold (the padlock icon):

Not SAS maneuver. That has its own bug. SAS hold works for me:

The maneuver reset with map toggle already has multiple reports. The maneuver direction indicator drifting resulting in failed burn with SAS pointed at maneuver is now here:

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) KSP2 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Observed: The maneuver direction indicator on the navball drifts during maneuver execution. SAS pointing at maneuver results in failed burn. Switching SAS to hold before the burn results in correct maneuver execution. Expected: SAS pointed at maneuver results in accurate maneuver execution, ideally compensating for alignment errors (unbalanced craft, etc). SAS pointed at maneuver: before: after: SAS hold: before: after:

There are multiple bugs with the nodes, but I have found them to be accurate if: - you switch to SAS hold directly before the burn - you don't toggle map mode during the burn (resets the node) Some discussion in here:

There are multiple bugs with maneuver nodes. They appear to be accurate if you switch to SAS hold directly before the burn, and don't toggle map mode. Longer discussion in here:

Lengthy discussion in here:

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) The game calculates an incorrect dv value in the VAB and flight when the craft has 2 differently sized fuel tanks in the same stage and the engines are radially attached to the smaller tank. Note that the re-calculation in the editor can be tricked to produce the correct value, by moving the engines quickly to the smaller tank. If you wait a second before placing it'll calculate the wrong value (which is also used in flight and after re-loading the craft into the VAB). (Also can be tricked to calculate the wrong value by quickly moving to the bigger tank).

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) Problem shows even with minimal rocket build (one stage). Adding and removing stages, as well as moving the engine between stages confuses the readouts. Saving and reloading the rocket fixes this.

Right. Maneuvers are assumed to have constant pointing. If you execute them as such (with SAS hold) they will be correct (and that will work during warp as well). Prograde changes during burn, but the planned maneuver has a fixed direction. So burning with SAS set to prograde (for prograde-only maneuvers) will also end up wrong.

These might be the result of another bug I've encountered: the maneuver pointing shifts during the maneuver, so SAS pointing at it results in wrong burns. It has been very accurate for me by letting SAS point at the maneuver, then switch to SAS hold before starting the burn. The example screenshot above was executed that way and ended up on point, despite the relatively long burn. I'll write a separate report for that later if no one else has by then, but I have quite the list to report, and I like to provide screenshots and as detailed descriptions as I can, so it'll take a while.

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) On multiple occasions kerbals have fallen through the ground while walking (see images). In the mun example Bob (on the Mun) was sinking into the ground further and further while walking forward, then fell through. Valentina (on Duna) just suddenly fell through. https://imgur.com/a/n47sVYz

Same here, happened on the Mun and on Duna. Abandoned the Mun craft, the Duna craft was the target of an ongoing rescue mission: 1) Quickload rescue vehicle 2) In map view, "control" landed craft 3) Exit map view 4) For repeated execution of 1-4, the landed craft is clipped into the ground by a different amount each time: - completely underground followed by falling to the planets core - significantly in the ground, jumping up high into the air, unrecoverable - slightly in the ground, jumping a bit, then stable KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49)

Same here. While annoying, there is a work around: Go to the VAB, new craft (anything, single capsule works..), and launch. This is now the active vessel (landed), which allows higher time warp in tracking station (even after it is recovered or destroyed - before switching back to the craft in orbit).

Same here. Got stuck at pitch down, because I was to gentle and tapped it multiple times, until I was starting to point nose down, pitched back up, tutorial stuck.

While I agree that it is currently hard to place precisely, the new method (acceleration over distance integrated) is far superior to the old (instantaneous, burn 50%) one, especially with low thrust engines. Planning it this way also allows for the semi on-rails warp during burns, which is another new mostly overlooked feature... (I still would like to see burn time before starting the burn. Also haven't experimented enough with the new system regarding where it is taking its acceleration values - thrust limiter settings for example.)

Default all fairings to 2 sides, clamshell, 400 ejection force

I would have used this earlier (I used to rotate the rocket before launch), nowadays I just build facing north and then do a roll maneuver during launch (then pitch down). I agree that yawing right does feel weird. Edit: Not to diminsh your effort, I appreciate having the option! Thank you!

It breaks with the engine plates (from the DLC), because they act as decoupler, but sit between engine and fuel tank. So KER thinks, the engine will be gone. Have not yet seen any problems with the base game.