Lyneira

This analysis is great! All of these suggestions would help make maneuver planning much smoother.

A nod to political prestige in the backstory of the game (however it is told) couldn't hurt. We'll have multiplayer, and the different launch sites that will exist would presumably also be used by other space agencies. Prestige was definitely a big driver for the push towards the first human in orbit and the first moon landing. Which is not to say the game must have AI space agencies to compete against in single player. But acknowledging it as one of the drivers, I see no problem with.

Thank you Nate, for sharing a bit more about what you're internally working on. When I look for the dev updates every week, I'm not necessarily looking for early hints about what the next patch will contain, but also hope to learn what you'd like to do with the game in the medium and longer term, and how that evolves over time. I hope you'll continue with this new style of writing and wish you and the team the best in stamping out those bugs you mentioned! I'm also intrigued by these new extensible-nozzle engines. They look like they'd have great vacuum efficiency in extended mode, but also viable for use on landers in retracted mode. Maybe even usable in a similar ground-to-space launch profile as the aerospike. Looking forward to trying them out in the next patch!

Does the hype train have a sleeping carriage? I'd be on the train, just conserving my hype for the upcoming stops.

@JoeSchmuckatelli Your description in the OP is pretty much how I had the gameplay loop for KSP2 in mind for the Colony and resources part of the game. It resembles Factorio (going to reference the original here ) in that you'll be setting up steady streams of raw and refined resources, though I think the gameplay loop itself will feel quite a bit different from Factorio. This model, along with science, allows for a progression of unlock, explore, expand, exploit and repeat which is tried and true for many other games. Challenges to overcome, goals to achieve and to be rewarded with progression of your available tools is what differentiates a game from a pure simulator. There's nothing bad I see about this, and it doesn't have to preclude showing the science side of things that you highlighted well in your quote: I for one would absolutely like to see observatories and labs be a part of colonies and taking a role in the science progression side of things as well as giving real life-inspired context for how, what and why the Kerbals are learning.

It looks like your vessel is in the "landed" state where gravity stops applying. Retracting the communotrons might not trigger physics to update. What happens when you try to rotate the capsule while floating?

This is probably due to the inverse square law used for solar radiation. Each time you halve the distance, you get 4 times the radiation. From the numbers you gave, it should work out that you're at about 1/37th (2.73%) the distance to Kerbol that Kerbin is. Even if that's correct though, real life solar panels don't work this way because they don't work as well (or can even be damaged) when they overheat. To keep solar panels from degrading or overheating, they're sometimes angled so they receive less radiation, like BepiColombo. I don't think that solar panel overheating or degradation necessarily has to be a thing in the game, but it could be abstracted as a soft or hard cap on EC generation from solar panels. When heating is implemented, the panel efficiency could be reduced by high temperatures to act as a soft cap. This could also be an incentive to provide active cooling for solar panels by radiators to raise the soft cap and tap into the huge EC potential from being close to Kerbol.

Agreed. Some workflow inspiration from productivity tools like document editors could make for UI improvements here. And especially consistency in that when I open a document (workspace), I expect the name of the workspace and the vehicle to remain the same as long as I don't make any active effort to change it. iirc, that currently happens silently if you merge a workspace into the one you're working on. Then there is the split between workspace name and vessel name. I originally thought the vessel name was supposed to be saved per assembly, but that is not the case. If it's not per assembly, it should be linked to the workspace. But this seems to be inconsistent as well, as there are situations where your vessel name gets silently changed too. Maybe it's when I switch the active (launch) vessel, or again when merging workspaces. Document editors also helpfully show whether you have unsaved changes with a little asterisk next to the file name: Copy of Untitled Document.ods* Coupled with the above suggestion of making open -> modify -> save require no user interaction, this allows the user to quickly save the workspace and open something new without being presented with a dialog like "you have unsaved changes, are you sure?" Speaking of which, if the user does have unsaved changes, the editor should warn the user when attempting to start a new workspace or open another one. If there are no unsaved changes, there should be no warning prompt.

Something about apples and oranges...

Agreed on the tooltip, would prefer the tooltips to be placed diagonally so the other controls remain visible. I never even noticed the changed order since I haven't played KSP1 for ages. I don't mind the changed order, I feel that's easy enough to get used to if the icons are clear. I also think there is a good reason for the new order of the indicator buttons. Both thrust and pressure have a relation with the center of mass. When you're tweaking your craft, you'll often want to toggle mass and thrust (for tweaking engines) or mass and pressure (for tweaking wings). With this order, mass is next to both and it won't require you to skip over the thrust icon when toggling mass and pressure together. If this was a conscious UI decision, this was well thought out and my compliments to Intercept.

@Nate SimpsonI'm glad to see you taking on board some recent feedback from the forums, the writing style of this post reads much more clearly to me. I'm equally glad to read that the team also shares the little frustrations when playing the game and are continuing to work on those as well as the big stuff. I emphasize little, because in the face of all the feature milestones still ahead of you, the little frustrations are most easily underappreciated for their impact on long term enjoyment of the game loop. Regarding your intent to communicate the timing of patch 0.1.3.0 next week and taking into account the risk of communicating a patch date earlier and having to let it slip: I think a mention in your weekly update is an improvement over not knowing anything until a few days out, so thank you for that. Keep up the good work and I look forward to seeing more improvements in the coming patches!

It'd be much nicer if you could view both the full and empty CoM at the same time. That really helps with tweaking your CoM and balancing thruster and RCS placement. See also this post about features from RCS Build Aid I'd like to see implemented: Screenshot:

I'm also curious about those and I think Intercept do want to show the Kerbals of the agency discovering these and figuring out for themselves what it all means. I don't expect that part of the Kerbal story for the science update, rather for the final release out of Early Access. I see those artifacts as a separate story to tell from the science we'll get in science mode though, and I hope that the science experiments we do will also get their own reason for being, beyond just points to unlock parts.

Not sure if there was a misunderstanding here but I feel I should clarify,@Observe's question wasn't rhetorical in calling science missions to the moon and other planets into doubt. Rather, to make you think about what reasons humans had to send them, and implore Intercept to apply those reasons to the Kerbals for doing the same. Let the Kerbals tell the story of why we want to go to these places and what we learned and hope to learn from it. It will give players a sense of purpose beyond "I clicked the science doohickey and now I get points to unlock new parts."

Making large dV burns in KSP1 with the ion engines could already easily result in burns of 30 minutes or more. On top of that, the KSP1 maneuver nodes do not account for the length of time it takes to complete the burn. For short, high-TWR burns the difference is usually low enough that it's easy to correct afterwards but for longer burns this becomes a huge problem. That's why they added the new maneuver system in KSP2 that can work with low-TWR engines in timewarp and account for the burn length in the prediction. You may have missed this but with one of the patches, the thrust of the Ion engine in KSP2 was slashed from 2 kN (its original value from KSP1) to 0.2 kN while keeping EC consumption roughly the same. They did this to do justice to the ion engine's unique place in the engine lineup as a huge efficiency, low TWR engine that must be used for very long burns and eats a ton of power. Still far above the thrust of real ion engines, but already it means a burn of 30 minutes in KSP1 would now take 300 minutes (5 hours) in KSP2. In return, KSP2 has much better wet:dry mass ratios on the Xenon tanks than in KSP1, making it much more feasible to reach high dV numbers with the ion engine... If your planned trip allows for enough time to make good use of it and you have enough power generation. Battery storage as a primary EC source for Ion vehicles was sort of viable in KSP1, but not so in KSP2 because it takes nearly 10 times the EC for the same dV. The near future interstellar engines they want to add will also similarly work as very high efficiency, low TWR engines that need this system.

I think what @cocoscacaomeant by "solved analytically" is a solution whose accuracy doesn't vary with the timestep size chosen. I'm not mathematically versed enough to know whether Tsiolkovsky's rocket equation would be sensitive to this, but it's not the only factor. The orbit you're on also factors into this and both need to be analytically solvable for the whole to be accurate at a high timestep : burnlength ratio.

Speaking of surface rocks, this is more of a suggestion than an expectation, but as a former Elite: Dangerous player that spent a lot of time driving the Scarab SRV I can't pass it up to mention this thought: Roving around the various worlds (especially airless ones) looking for meteorites or outcrops to scan or sample. In Elite: Dangerous, you had a wave scanner that would give you a signal based on a rock's composition and your distance to it. The signal would become clearer and narrower as you got closer to it. These meteorites and outcrops could be procedurally scattered across the surface and have different compositions, allowing the player to tangentially learn something about real ones when they succeed in finding and sampling one.

In addition to the IVA issues mentioned above, procedural wings address high part counts for planes in flight and the need to have a large amount of wing component parts in the parts catalog. That issue is far less present for command modules as there's only one strictly needed per ship and there aren't that many different command modules. If you want more kerbals, you normally add passenger modules instead. And a good fraction of command parts have unique designs like the rover and plane cockpits that don't lend themselves well to a basic procedural system. If the developers were to take the often suggested procedural tanks and implement a more general procedural ship hull system where you can design your own ship hulls and put modular components in them, being able to add command modules with IVA enabled seats and windows to the hull would definitely be an amazing thing to have though.

Implementing a form of procwing tip/root snapping could neatly solve the contrails appearing in the middle of a composite wing as well, as the engine can detect a snapped wing and skip making contrails for wingtips that have another wing snapped to them.

More complex wing geometries where the wing edges aren't just a line from root to tip. This aids creativity and recreations of RL craft. Allow delta wing configurations to have separate control surfaces for pitch and roll, like this: Can give you more control over where you attach a wing to the fuselage vs where most of the lift is generated. See also this discussion for some of my past suggestions about procwing tip/root snapping, which would make it much easier to make and adjust composite wings.

This bug is pretty extreme when making large plane change maneuvers, such as turning an equatorial orbit into a polar orbit. Would appreciate the maneuver marker staying in place so that targeting it while executing the burn actually result in the planned trajectory.

I remember following along the arrival of the Rosetta mission at comet 67P and the subsequent landing of the Philae lander, which didn't manage to grapple onto the surface on touchdown. The lander was sent tumbling and iirc it took many hours for the lander to hit the ground again after that, and it bounced several more times before finally coming to a stop in a place where it didn't get enough sunlight to keep running for long. I agree Kerbals sent tumbling should regain control soon after the impact but, aside from that, bouncing around higher and longer on low gravity worlds should be a thing!

I hadn't considered those particular statements in my previous post, but I do remember comments of that nature being made in the KSP2 developer update videos before release, and on the forums. And indeed those statements not turning out true at launch contribute to the parallel with NMS. I made a broad categorization to make my point but of course the points where KSP2 is simply lacking features from the roadmap and points where KSP2 delivers less than players expected are more nuanced and varied than that.

There are some similarities betweeen the launch of NMS and KSP2, but also important differences, mainly stemming from KSP2 being an Early Access release. Undelivered features and broken promises The NMS team made statements about features, direct or implied, that were not delivered on at launch. Those were promises broken. For KSP2, it was clear from the very start that most of the features that expanded KSP2's scope beyond that of KSP1, and features that actually make it a game and not just a sandbox, would not be present in the early access release. So the main features currently undelivered are ones that are promised for later roadmap milestones, not the version at EA release. This does not constitute a broken promise, not unless development were to stop before they are delivered. (within a subjectively reasonable amount of time, but I don't believe we're there yet) Stability and performance NMS did have a number of bugs and crashes on release, but it was still possible to experience and enjoy the gameplay loop as it was designed. I can't remember having serious framerate issues with the game, but if someone has a different experience, please do chime in. KSP2's stability and performance at EA release left much more to be desired and after 2 patches, many issues persist that impact the enjoyment of the basic gameplay loop. This is to be expected to a degree with a game in early access, but there has definitely been a huge mismatch between the quality level players expected of a successor to a well-established game, and what was actually released. So where does that leave us? Conclusion I agree with posts above that the story of NMS, while remarkable, is an exception that can't be expected to automatically apply to other games with launch complications, even if that is the next best hope those who wish for the game to be the best it can be. On the topic of undelivered features, I see no parallel with NMS because it was made abundantly clear in the roadmap that roadmap features are not yet complete. On features, KSP2 is on the track to follow a normal early access cycle of expanding its scope with updates until it reaches roadmap completion. On the topic of stability and performance though, the parallel with NMS is much more apparent. The resolution of this mismatch in expected vs delivered quality in the coming updates will determine whether KSP2 could be said to make the same journey as NMS in turning opinions around.

Can you explain how? I just tried this, and if there is a way to make changes to part rotation with the arrow keys I haven't found it. I most certainly would! I think the ability to precisely set part orientation is pretty important for the high end of a player's plane building skill growth. Whether text input or a very fine snap grid using arrow keys or something else, this makes it much easier to set a wing angle of incidence to a known good value without excessive trial and error. And when you do have to iterate and test, it makes it much easier to home in on the ideal angle of incidence for the flight profile you're designing it for.