Bej Kerman

IIRC Nertea is doing modelling on KSP 2 now.

same. Ok, cool. You're in the MP discussion thread, so I can't really suggest much else than enjoy the MP discussions.

This is the second time you've suggested they add something that's already present in KSP 1.

I'm confident in saying KSP 2 multiplayer is 99% likely to be co-op.

Yes, obviously, but what advantage is there to reducing the in-game time spent going from place to place? That's what I mean. Never thought of an answer because I never seen the point in actively thinking about how the time in-game does not really matter in the real world. I just play along with the in-game clock, that's all.

Because it takes less in-game time.

No-one said that.

Renders the thread useless if we have to leave the thread to discuss it.

That doesn't mean everything else isn't procedural. The devs aren't going to handcraft anything smaller than a crater with millions of square kilometres of land to work with. Procedural generation is still involved with smaller scales. What is handcrafted on a larger scale is pretty much irrelevant because we won't be seeing caves the size of large craters - we're discussing reasonably sized craters. And I'm still not convinced that it's possible to integrate individual objects into the terrain seamlessly.

Except that's not what I said, at all. Look at what Aziz said. I'm saying trying to procedurally integrate caves into procedural terrain. despite being a separate entity from the planet. will not look good.

There's just literally no way that's going to look good.

KSP 1's Tylo cave is an object and not a part of the terrain, and it looks as ugly as you'd expect it to look. So I'm not sure why that would sound like a good solution for KSP 2.

"no caves" is a big jump from "little gameplay". Even if you're right about a few obscure quotes confirming a massive gameplay feature that would require building and rendering planets in an entirely different way, it's nothing to be upset over if we don't get caves.

Does it need to be complicated? Maneuver nodes don't have to work any different from KSP 1, just highlight the bits in which thrust is applied using a different colour. No arrows, no complicated UI elements, it's just an additional bit of physics to take into account. Remember that KSP 1 already has constant burns, even if not accounted for in the UI. Maneuver nodes still worked without all this overcomplication. The trajectory UI element only needs to be adjusted to show the flight path curving into the new orbit as opposed to reflecting an impulse maneuver, maneuvers can work exactly as they've always done. Yes, then again our targets will be hundreds of millions (if not billions) of kilometers in diameter and we can always adjust course closer in where errors aren't as big.

Do explain.

Then it'd just be easier to launch stuff to orbit.

You're completely underestimating how difficult a space elevator is to build. Interstellar travel only requires you to build a structure that doesn't need to be much longer than the Burj Khalifa and invent rockets that can sustain propulsion and high thrust. A space elevator requires you to build materials millions of times stronger than those found in skyscrapers. You can't just stack bricks to orbit. It does not work like that. You won't be seeing space elevators until way after we've perfected interstellar travel, outside the scope of KSP 2.

Because a bipedal walking gun would be any more efficient than a car with a Canadarm strapped to the top.

That's like saying that we shouldn't say that making the atmosphere of Duna thinner won't affect new players getting to low kerbin orbit. A better analogy would be "we shouldn't say that tilting Kerbin won't confuse new players (starting on Kerbin) that have never seen a Porkchop plot". Kerbin is the start of every player's journey, and tilt could be disorienting.

1 month means at the start of the turn you're heading towards Kerbin, and at the start of the next turn you've already flown past it back into interplanetary space. Space isn't small enough for timewarpless to be practical either.

Which is exactly what I'm trying to say about timewarp and conflict. A system based on collaboration between players and exploration is going to block a lot of things that are needed for a system that allows for war and conflict. I'm not asking to take conflict into consideration, just merely stating that whatever timewarp system they implement is going to be problematic for players wanting to play with combat and war. There is absolutely no other choice. Coordinating between players with either an admin or a server-wide vote system would be nigh impossible in a small 50x50 arena with only 1-4x timewarp, let alone an entire Universe where many orders of magnitude of timewarp are necessary to traverse distances of many orders of magnitude.

Yep, but how does that go with hostile interactions? In how many ways can the timewarp be abused to either attack or become invincible and avoid damage? It has to be taken in consideration automatically if you don't want situations in which (for example) you can 2x timewarp for a few seconds and de-sync your instance from the missile that was about to hit you. KSP isn't a game about warfare so I find all those scenarios irrelevant. It's a game about exploration, everyone being able to fast forward their exploration missions on their own terms is more important than locking down timewarp just to curb scenarios that won't happen in the intended scope of the game.

I know for a fact the devs won't use that daft solution. Dark Multiplayer solved this issue ages ago with instancing.

Is having 'deploy panels with fairing sep' on Stage n+1 and 'retract panels for re-entry' on Stage n+2 not an option? Why should I not be allowed to have my panels open/close with other important parts that already have staging support? Again, I don't see the point in such pointless restrictions. You only have so many action groups, anyway.

well then you could open them with staging but what about closing them? Then assign the close action to a stage instead of an action group. I don't see the need to restrict stages just to engines and decouplers.