Wetzelrad

I don't know where you got "Resource Nodes" from, but I think it's a good idea. My expectation is that resource availability will vary by biome like KSP1. I question whether your description of building rovers and separate mining sites will be a necessary part of colonies. I expect resource extraction and conversion to mostly come in the form of colony buildings, to be completed entirely on the site of the colony. This would be more simple, perhaps in a way that's less interesting, but also less tedious. I bet we unlock large parts by or before we get colony parts. Or maybe they will be on entirely separate branches on the science tree. But more importantly, the best engines regardless of size will depend on mid- to late-game science unlocks and on resources extracted from colonies. That's basically how Nate described it, yes. The first time colonizing a new star system will undoubtedly be the most interesting part of KSP2. Will it be sufficient just to plop a colony module down on the first planet you see? Or is it better for the player to send out probes and scanners to find ideal conditions? Can colonization be brute forced merely by producing hydralox? Or will it be necessary to manage resources carefully? How difficult should it be? Many questions for Intercept to consider. I can feel that, and it's probably too late to speculate and make suggestions, but how would that work? Maybe I can imagine recovering samples from the oceans of Eve, bringing them back to Kerbin, and making an exciting discovery that enables the construction of new pressurized parts. There could even be a text blurb or cutscene to talk about the chemical makeup of the ocean and how it led to the discovery. Is that how visiting each body should work? There might be something interesting to that, it might even be educational, but would it be grounded or realistic? In the real world, I think improvements in space technology come more by trial and error than by observing celestial bodies. KSP1 concedes on realism there and I don't see how or why KSP2 should do any different. Ultimately whatever the player discovers about the universe is going to be logically disconnected from the part unlocks that he gains by those discoveries, no matter how talented the writing team is. Beside that, the type of science that you're imagining would risk harming gameplay. To my mind it would look like a rigid checklist of tasks for the player to complete. Probably no one wants that. KSP1 is fun because it is open ended. I would like to see a new vision of science as much as anyone, but the more time I spend thinking about it, the more I feel that Squad got it right the first time. KSP1 science never forces the player into narrow gameplay constraints, and it rewards the player for milestones, for missions, and for direct science gathering while hopping from biome to biome. It is far and away better than any implementation of research gameplay that I've seen in other games or in any of the suggestions that I've read on this forum.

It is good for precision. C key is the shortcut to toggle snap. But what OP is pointing out is that you can only offset a limited distance, which I would estimate to be about 5 meters. There is a trick to go beyond 5 meters: With the offset tool, and with snap enabled, select your part and grab one of the handles. Drag the part past the maximum distance it will go, to approximately where you want the part to be. Now, without moving the mouse at all, disable snap by pressing C and release left click. The part will have teleported to your cursor. Obviously this is a bug, so use with caution. It could mess up your save file or have other negative effects.

This seems to be a consistent problem with engine plates AKA multi engine mounts. When my vehicle is on the launchpad, I can try the decoupler and it works as expected, but at some time shortly after taking off, the decoupler won't decouple. After launching the same vehicle a few dozen times, I was unable to determine what the trigger was for this glitch. Here's the workaround I came up with. Use two decouplers. The first one may remain stuck to the engine plate, but the second should detach as expected. @Poppa Wheelie Not sure if this will help you. In my case, there is no visible separation. In one case, save and load did fix the problem.

The workaround is to burn during timewarp, or burn with SAS set to lock/hold. As long as you don't rotate to follow the marker, you should stay on course for the manuever as it was planned.

I noticed that if I ctrl+z, all struts will break, but if I ctrl+z a second time, they all return to positions. Not a perfect solution but it works when I need it to. Yeah, I have to make do by only applying struts to upright parts. I don't see how that would happen unless you placed them unevenly or unless the center of your vessel is so heavy that it's bowing. I think this might be the autosave, but I never checked to confirm. I dock the same way in KSP2 that I did in KSP1. My suggestion would be to turn off SAS while using RCS, because SAS wastes a lot of monoprop and tends to reverse your attempts to manuever.

Try alt+click. This seems to be a bug. Action groups sporadically don't work, and there are other systems at play that can break action groups in novel ways. You might be able to fix it by saving and loading or by reloading the vessel in some other way.

Is Eve also shorter? I flew around for a bit and found the cloud cover to be at around 3000m. The highest hills I saw did not penetrate the cloud cover and only rise to around 1600m above sea level. By comparison, the wiki for Eve in KSP1 says this under updates:

Engine test.

I'll add that I also saw similar black artifacts once, but it didn't come back after a restart. On PC.

It's a limitation of the physics engine. There's a "high fidelity" physics bubble around your active vessel that's only a few kilometers wide. Hopefully this problem will improve with time, because vehicles shouldn't disappear so easily. Maybe someone else can give you more advice on how to work around it. This is definitely a bug. One thing that happens to me is where a lower stage follows my current vessel on the map. I'll start a transfer burn, then time warp, and some piece of debris or other object will go hyperbolic like it's trying to keep up with me. Also related to the physics bubble, I'm sure.

Looks like I have that one, plus another copy of it in my steam directory.

@ManuxKerb I noodled around with it for a while. What I got out of the proton log is this: I checked my GStreamer plugins, and I seem to have every codec in the world. Beside that, I have no problem playing a mpeg-4 aac file on my desktop. I tried reinstalling plugins, installing other codec programs through protontricks, and several other hopeful solutions. Not having any luck so far, but I think I'll get by okay without videos anyway.

Double click on vessels to take control of them. This is handy when the switch vessel keys [ ] aren't working. If the mission failure interface pops up, it's a good idea to immediately pause the game. This gives you the chance to take back control of the vehicle, assuming it hasn't vaporized, or at least to get a visual of what went wrong. I hate to state the obvious, but aren't some of these reported SAS problems the result of trim? Right alt+x to reset trim.

Sounds like you have it handled. Normally you want the decoupler triangle to be pointing away from the engine so it doesn't stay attached to the engine. With tri-couplers, in the way that you used them, only one of the three branches is being used structurally. The other two branches are hanging on by their top node. And in fact you only need one decoupler there, because the other two decouplers are not attached in full. Am I making sense? If you hover over with your mouse, you should be able to see by the green outline which parts are connected. So with that type of design, the critical issue is build order. It's very easy to attach parts in the reverse order such that they end up on the wrong side of the decoupler. This is not so much a bug as it is a design quirk carried over from KSP1. Frankly it's much easier to use the engine plate instead.

After a bit of testing, the cause of this glitch is decoupling while in a Landed state. The game is not recognizing that your vessel has left the ground when you decouple. While your vessel is considered Landed, no trajectory line shows up. It needs to switch to Suborbital for the trajectory to appear again. In order to trigger that, your vessel must touch terrain momentarily. It is sufficient to simply slide off of the descent stage and touch down for a fraction of a second. Alternatively, fire up the descent stage just enough to get above the ground, then decouple. From my attempts, staging order isn't making a difference.

I will confirm that videos are still not working for me even with Proton 8 and even with your launch options. Weird to see Kerbin so barren too, but it does boost my framerate slightly. Same thing here. Annoying to deal with. Hold middle click and drag. Alternatively, middle clicking on a part centers the camera on it. Sometimes you do both together without meaning to. Middle click and drag also works on the map.

My understanding is that, when placing a part, it will only attach to the one part you place it on. So you can place C on top of B on top of A, but you can't stick B in the middle of A and C and expect all three to be connected. The bottom half of your assembly is attached to the top of the assembly only through that one Dart. It would appear from your comments that the other two Darts are attached to the bottom half. So while they may be touching the engine plate they are not connected to it. To fix this, you would need to pick up those Darts and place them on the engine plate by hand. Then they would be connected to the engine plate but not to the stack separators, or not to the three-way adapter. That is, assuming it's not a bug.

Brute force is fine when you're starting out, but I would encourage you to soak up everything the tutorials have to say about orbits. Learning the right way to fly to the Mun is key. Once you have that mastered, applying the same principles to fly to Duna is not so hard, only complicated by the change in frame of reference. Transfer windows are a problem for sure, and it remains to be seen how KSP2 will hold the player's hand through that. I'm sure more tutorials are planned.

Today I finished my mission to Tylo which ended up going slightly further. Kerbal's orbital mechanics really shine around Jool.

Yep. Of course that is the same reason some of the contracts are bad. Contracts like "build a surface outpost on the surface of Duna with room for 12 kerbals and 4000 monoprop fuel and 2 pilots". It's fun once or twice and that's it. Contracts are much better when the objectives are not overly strict. Same. In KSP2 it's all too easy to build a SWERV rocket for every mission, with a massive booster stage below that to get it out of Kerbin's atmosphere. We can speculate that unlocking SWERV will require some serious scientific achievements. After that, what will inhibit the player from using SWERV? Only the production of Hydrogen fuel. As with all resources, I expect Hydrogen will either be produced by KSC itself or produced by a player-built facility and shipped to a VAB. Once that production line is built, the player can time warp to get as much Hydrogen as they need. Point being that resources will quickly become practically infinite in KSP2. In the same way, KSP1 is hard-going early on, but Funds become meaningless by the time you finish upgrading every building. In both cases, career mode turns into sandbox mode. Hopefully Intercept has some brilliant ideas on how to keep resource management meaningful for the player. Which I think they will, just not with a replication of KSP1's contracts. For anyone that needs reassurance, here's a transcription of something Nate said in the 3/24 AMA.

You have to download the full 16GB zip file for each new version. Hopefully they handle updates better some day, but I'm sure it's not a priority issue.

Worth noting the manuever planner does take the engine thrust sliders into account. If you need a slower burn, you can adjust your engines to 50% thrust and touch the manuever to update it. I do think the manuever planner needs a lot of work. The precision issue should be fixed first and foremost by showing the player the real numerical dV difference between their current trajectory and the planned trajectory. Preferably with precision to the tenth of a m/s. Personally I dislike automation because I prefer playing the game. Piloting is fun. Still, autopilot would be a good career goal unlock.

In other words, you have a full tank of gas? That is probably a massive weight. Try testing with less fuel in the tank or bigger landing gear. That said, I've had some troubles of my own. My spaceplane disintegrates instantly at speeds of higher than 50 m/s. It's difficult to grasp what is going wrong because the plane vanishes and the mission failure screen pops immediately.

Something about Parallels.

This might be because you're assigning the same action twice for parts that are in symmetry. If I have two symmetrical antennae, I only need to assign one of them to an action group. If I assign both, they toggle twice. The UI needs some clarity on this. However, on one mission I had docked and undocked, and at that point I noticed symmetrical parts were no longer working as expected. I had to manually assign every part to an action group.