Mutex

Just pointing out the latency is measured in cycles, not units of time. So as memory gets faster, the length of a cycle gets shorter, hence the latency becomes a higher number of cycles. Memory isn't getting slower

That's possible yes, roll requires less energy usually so it's probably more sensitive.

Yeah it's always seemed like a problem to me too, but there's literally no other way to do it. Having different people at different points in time is literally impossible unless they're planning on programming actually general relativity into the game, which seems unlikely.

They're not intending that, all players will be in the same point in time hence timewarp controls are shared. This is why time doesn't pause when you open settings, or when you're in VAB, because time needs to keep flowing at the same speed for everyone. Saves are ballooning to GBs because of a save corruption bug that is apparently fixed in the next patch, according to Nate's point the other day.

Basically you can mitigate the issue by reducing pitch authority, which is effectively what you're doing here. You can also reduce the maximum angle of control surfaces.

AFAIK in KSP2 currently, a fuel line will only transfer fuel from one tank to another, not a cluster of connected fuel tanks to another. Say for example, if you have two fuel tanks in your core stage, and two side boosters each with two fuel tanks, you want to connect fuel lines from each booster fuel tank to the corresponding core stage tank. This is what I did yesterday and it worked fine. I haven't tried linking boosters to boosters (so that you can drop a pair of empty boosters each time you stage) yet.

I suggested that because I've seen the dV indicator break and show zero when it shouldn't. And it kinda has to work that way. Because maneuvers now take into account how long it takes to do a burn, it needs to know the thrust of each stage. Because each stage might burn out part way through the maneuver, it needs to know the dV of each stage, so you see the change in thrust when you stage reflected in the maneuver line. If you've no dV at all, then it'll show no change in your maneuver line.

What does the dV indicator say for your craft? Does it say you have zero dV? If so that's why you can't make maneuver nodes, the game thinks you've got no dV to burn.

I'm not sure that's what they mean by save corruption. I think they mean people's saves ballooning to GBs and not being able to load a save at all. Hopefully they do solve the issue you're talking about too though.

Maybe the ground-up redesigned physics system isn't ready, so they're using the default one as a placeholder.

When were procedural solar panels advertised? Nate Simpson specifically said they're NOT doing procedural solar panels. Just radiators (and wings).

There are G-force limits on the parts, but they seem to be quite generous.

I have to say I've never been a fan of auto-strutting. I've used it, but it feels like a band-aid over a problem that should have been fixed better. Maybe by keeping joints pretty rigid, and having them just break rather than flex if the forces are too great. That's how I'd expect it to work in real life. And if your ship still isn't stable, then it's a bad design and needs more internal supports.

I've seen a number of comments about KSP2 focusing on style over substance, or more specifically that more effort was put into the appearance, graphics and style of the game over the basic gameplay mechanics. Evidence for this idea is that manoeuvre nodes are incomplete and buggy, and the huge number of bugs in physics, staging, docking etc. Meanwhile the Kerbals animation is done and looks great, the art assets in general are high quality, nice effects with the sun shining through the atmosphere etc. I don't think this means the art had a higher priority. I expect both the art side AND the basic gameplay mechanics, were expected to be complete by the 24th Feb. What happened is the devs working on gameplay had a lot of unexpected complications and took longer to complete work than expected. Meanwhile the artists completed their work on time, since there were no hidden complications in what they were trying to achieve. When you're solving problems, you can't really estimate very accurately how long it'll take you to solve it. You really don't know how long it'll take until you've done it. Much of what has happened with KSP2's development/release history can be explained with this. In interviews I've seen the development leads say the existence of multiplayer, and all that it implies, has massively complicated basically every feature they've added to the game. Simply keeping track of where the spacecraft is, and where it's going, in a way that scales to interstellar distances, was a massive challenge. I think there's also an assumption going around that what we can actually see in the game right now is EVERYTHING the devs have worked on for the last 3+ years, and anything we can't see will have to be started from scratch. This does not seem to be the case. I've heard (I forget where, Scott Manley?) that multiplayer is almost done and the devs are testing builds with it. Some systems were nearly done and not yet enabled in the build like heat. I get the impression that once the base game stabilises, the features on the roadmap might be added quicker than we're expecting. In any case lets not be so quick to harshly judge the developers for their speed and ability to deliver features and a working game. There is far, far too much we don't know to make any accurate judgements. We're not even sure how long they've been working on the codebase, and none of us have ever developed a game like KSP2.

Resolution isn't screen size. They're using a 34 inch screen, which is pretty big.

I believe you click the velocity indicator, and it'll cycle through to target mode. I did a rendezvous the other day and think that's what I did.

Do you mean on Steam? Still £44.99 in the UK.

Exactly, they spent the last few months fixing thousands of bugs that didn't make it into the release.

I think I'd prefer to have control over the shape of the fairing tbh, especially since it'll affect aerodynamics, and also so you can make cool shapes if you want to. If they get fairings working like in KSP1 I'll be happy.

In your KSP1 screenshots the UI looks way too small. But I guess you're using a really big screen. I guess the issue is KSP2 doesn't let you scale the UI yet.

I *think* you can copy and paste a subassembly from one workspace to another.

Posted on Twitter about an hour ago: Fixes include: - Stuck on loading screen - Maneuver node irregularity - Docking controls misconfiguration - Save files corruption And will arrive in the "coming weeks". Hoping that means in the next week or so, and they're being vague to avoid over-promising in case things slip. Not a bad set of issues to focus on first, although I'm not 100% sure what "Docking controls misconfiguration" refers to - we have issues with not being able to undock, and undocking craft exploding or becoming debris, hopefully it covers some of those issues. And having the manoeuvre node not get messed up switching between map view would be nice.

Yes, it seems Vl3d expected saving a workspace with the same name as an existing workspace would somehow merge the workspaces together. I've checked the folder structure, there are no project folders. It's a flat hierarchy with just the workspace files. A workspace contains multiple vehicles. I'm not sure what the "vehicle name" field does when you save though.

Isn't that the workspace?

I don't think anyone understands what you mean by "projects", including me. You're not referring to craft? Something else?