Draradech

That might be a side-effect of the lower TWR and thus longer burns (which increases the difference of the current orbit direction relative to the orbit direction at the node). It is also more noticeable for burns other than pro- and retrograde, because you are directly changing your orbit direction (and not just velocity). This is the reason my example in the top post uses an inclination change.

This is still a problem in KSP2 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) The behavior changed slightly: It is no longer timing-dependent. Engines radially on the smaller of two tanks in a stage will now always show the wrong dv value, in the VAB and in flight.

Exactly. This bug report is for the fact, that while the maneuver is supposed to have constant pointing, the maneuver indicator on the navball (and thus SAS in maneuver mode) is drifting.

I edited the title and added additional information to the top post of that thread. I hope it better matches the conclusions of the thread now.

While experimenting at different planets I first noticed (at moho) that it isn't just a flip prograde / retrograde. Moho showed radial out for what should be prograde. At Jool I noticed that the rotations are not multiples of 90 either (Jool has a mix of prograde and radial out for what should be prograde). I also noticed that the camera orientation changes when switching focus from the parent body back to the vessel and determined approximate angle differences for all bodies: Moho -85 Eve -15 Gilly -90 Kerbin 0 Mun 0 Minmus -115 Duna -135 Ike 0 Dres -10 Jool -50 Laythe 0 Vall 0 Tylo 0 Bop -35 Pol -15 Eelo 50 I edited the top post and changed the title.

@cocoscacao Apologies, it looks like I misunderstood you. I just wanted to point out that the nodes themselves are actually precise already (and for low-twr craft much more precise than KSP1 was). The problem in execution is the discrepancy between the burn direction the node has planned (which is fixed), and the direction indicated on the navball and followed by SAS (which drifts during your burn).

The maneuver node problems are discussed in length in at least three threads: In short: You can currently get accurate maneuver execution by switching SAS to direction hold (instead of maneuver follow) before the burn start. The 2nd problem (node resetting when switching between map and flight view) should be already fixed.

Yeah, that would be nice. Until they fix it, you can launch KSP2_x64.exe with the option -popupwindow (via shortcut, batch file or command line). If you then set KSP to windowed, you'll get borderless window. If you want to launch via Steam (for overlay or time tracking, idk), you can set the launch options in Steam to the following (adapt if your steam is installed somewhere else) "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" -popupwindow %command% I'm not aware of any way to do that while also using the PD launcher, though.

Yah. My unicycle was 50kg lighter in the VAB before the flight. After revert to VAB it had the currently stated mass. Adding the parts up by hand delivers another number entirely. Something's off. In your table in the top post, I believe most stated wet masses include the Kerbal. If so, mine should be 0.65 wet. Edit: I see what's going on. The wings do change mass when resized, but only when launched. The engineers report doesn't update until revert to VAB. I think I might be able to get an even lighter craft. Experimenting with wing masses now. Edit2: Yeah, it'll end up just like Flaze's design.

You can go around the launcher by just launching KSP2_x64.exe directly, or putting "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" %command% into the launch options in Steam. I'm additionally using -popupwindow like so "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" -popupwindow %command% which gets you borderless window, if you set KSP to window mode (takes up the full screen, but stays open when you click away from it - like using a second monitor). As far as I know, this is not possible using the launcher. Edit: If your Steam is installed somewhere else, adjust accordingly...

This is obviously an extreme example, the first time I noticed was on a lander more similar to the following (both the lander and the transfer stage lose more than 200 m/s dv). I know that the struts aren't technically needed in either of these examples - I just don't like them floating there. But given how noodely the rockets currently are, putting a few dozen struts in a bigger project is often necessary, and shouldn't increase the dry mass by multiple tons.

I don't like to compare it to KSP1, because "it has always been this way" is not a good argument against change. But since you started that: in KSP1 only the first placed connector has weight, so I can strut from the lower stage to my satellite without affecting its dv at all. What sort of heavier-than-lead material are the connectors supposed to be made of? It doesn't make sense visually compared to the other parts. How is that much mass supposed to be in that tiny thing? That's why I included the comparison picture in the top post. Edit: This also makes KSP2 struts currently twice as heavy as KSP1 struts (both ends weigh 50kg each). I actually like the fact, that both ends are real parts in KSP2, it allows much greater control over the positioning and orientation of both ends. They just need to be much lighter.

So you think it's reasonable that 4 strut connectors weigh more than a fully functional micro satellite, dropping its dv from 2369m/s to 861m/s?

KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Can confirm. Last time it happened it was also wrong in the ESC-Menu. That was after a restart loading directly into a craft on Duna surface. Loading into a save at KSC then loading the Duna save, the flag in the ESC-menu was correct now, but newly planted flags on the surface were still incorrect.

I can't remember where, but I have seen claims that it doesn't work for very low accelerations. That matches my experience, I had it failing exactly once, and that was with a heavy ship and a nuclear engine.