steveman0

I think you are misunderstanding the quote. I only read it as the fact the game is in EA / not complete / still under development is as a GaaS in that the challenges of resources constraints and interstellar will come later as these parts get finished. It's nothing intentional beyond the shear reality that these will take time and thus can't be released immediately. So your conclusion is the exact opposite of what I think. I think it is clear they still aim to complete and release content as quickly as possible while meeting their quality standards. For Science! Shows this. There was nothing in the quote to suggest anything has changed.

I never said you're playing the game wrong, I said you are failing to optimize your mission. There is no wrong way to play the game. There is however several ways to optimize your mission. Principally, lowest mass / highest dV. You are making the claim that these engines are terrible yet are failing to recognize they are a more optimal engine choice in a number of scenarios. You are of course free to ignore the optimal strategy and build some other Kerbal solution, but it's incorrect to say that the engines don't have a purpose. In several of your engine comparisons, the deep space engine will provide more dV for less ovall craft mass. Taken to the largest craft designs, the ISP advantage will result in higher dV, lower mass, and higher craft TWR in vacuum due to the efficiency advantage. This makes them absolutely worth the science spent on them when you build craft for these scenarios. It's important to note that tier 4 is entering part scales for colonies and early interstellar. Analyzing all of these parts in only the context of simple interplanetary missions will give the wrong impression. You must remember the context for their use. The deep space engines as their name implies are optimized as a kind of methalox equivalent to a higher thrust version of the ion engines for carrying payload efficiently to deep space.

Adding my feedback from weekly challenge #48 using ion engines to Dres. During the challenge I had two or three cases where I did not have thrust under warp. The case I'm 100% sure on was in Dres' SOI while trying to capture, i.e. I was on an escape trajectory. When I was in Kerbol's SOI, I did several burns with thrust under warp without issue. Earlier in the mission I recall one or two other scenarios where this occurred. Neither significantly jeopardized the mission so I didn't note them as carefully. Comments and Discord and here made me think back and I believe the scenarios could have been both in Kerbin's and Duna's SOI on escape trajectories.

This seems to demonstrate that you dom't know the value of isp for optimizing your rocket and mission. While a higher TWR can help in some cases, the extent of this is far less than you are thinking. Certainly far less than the benefit of 20% overall fuel efficiency especially since the increased fuel efficiency allows you to carry less fuel for a higher mission TWR. The example you originally cited with the skipper would have the skipper having far longer burn times because you'd have to carry more fuel (mass) for an equivalent journey. You can't look at engine thrust on it's own.

Not sure why you so haphazardly gloss over the massive ISP difference. The tuba example compared to the skipper has nearly 20% more ISP. This translates to roughly 20% lower fuel consumption. This means if your rocket is carrying any more than 10t of fuel in the stage it will be more fuel efficient overall than the 2t lighter skipper and only gets better the more fuel you have. This can allow a reduction in total craft weight for a given dV budget enabling a better overall TWR than the skipper for a larger scale rocket.

I too am going to highlight this for more attention. I have always been annoyed by the name changes but didn't have a good suggestion on how to solve the handling of it. Binding the name to the control module is the perfect solution!

Well, I'm going to consider this one as good as complete. There was no objective for wrestling with game breaking bugs, so I can say I did all of them as far as I'm concerned even if I had to use a teleport to complete the last capture. No way was I going to wait a day real time to complete that capture burn because thrust under warp was broken. I easily had the time to complete the capture burn even being limited to 20% thrust. It's a shame because it was otherwise a fun little challenge until the bug put a damper on the whole process. It was my first time using ion engines. I really could appreciate the massive dV they offer if I could count on them reliably working. I don't think I'll be using them again until the bug is certainly fixed. The mission was at least useful to me. I need to upgrade my satellites to all use the long range antenna for comms. Dres was the first on the list as I hadn't left a probe behind when I last visited.

Hardly unplayable. I've encountered the bug only once or twice in several dozen landings and take offs. Sure it's annoying when it happens, but it's rare enough to not be game breaking. I have far bigger issues with interplanetary ships shaking themselves to pieces that I'd sooner like to see prioritized.

An orbiter probe that flies just small dips into the atmosphere to collect the samples is great practice in space flight experience. It teachs valuable lessons in the degree of aerobraking by atmosphere depth and strategies to manipulate your orbit efficiently with aerobraking support. These lessons could be useful in other space flight missions even where atmospheric sample collection is not required.

As has been said multiple times, none of the atmospheric collections require an airplane. Every single one can be done with a simple orbiter probe like the one I used for Jool:

It's already been said. Using it on the ground trivializes the challenge and makes it just another environmental survey by a different name. Also, parachutes can be set to open at higher altitudes. It's entirely possible to get several minutes under canopy.

Planes are optional and even then only on two bodies. The orbital techniques you'd learn to use for Jool or Eve can apply equally well to Kerbin or Laythe. So if you prefer building a rocket... just build a rocket for this science collection. The fact you haven't thought of this is a very good demonstration why this science exists: it gives you an interesting challenge that you wouldn't have thought to pursue if it wasn't for the objective it provided.

Is it? Average update pace has been roughly once a month. If colonies lands in summer, there is easily time for at least another 2 small bug fix and minor feature patches. Still hoping to see at least the first draft of the new maneuver node editor before colonies. Edit: Admittedly, I'm really hyped for colonies and would like to understand more how they are going to work in their first implementation. It would be great to start hearing how this will work and to begin providing feedback on our thoughts on how it will integrate.

It is precisely designed to encourage you to build a craft designed to perform the science. Parachutes, a plane, or a shallow suborbital dip on a rocket. Allowing you to use it on the ground would eliminate a substantial design challenge around using it (and compromise the precious science result with those nasty dirt particles!) That said, the science value maybe should maybe be a bit higher with that in mind since it is more challenging to use.

I previously speculated that they were planning to include resources in the colonies update, just not resource gathering. From the recent interview with Nate, it is clear we aren't getting automated resupply missions which makes it very likely that we aren't getting any new resources. It really isn't clear then what is the purpose of colonies until resource gather is added. You could still launch fuel and deliver it to the colony manually, but this is something Nate expressed they didn't want players to have to grind out. So will colonies just have infinite fuel? If so, this would be quite lame and a pointless feature for another year as estimated. That said, he also indicated they have some ideas in mind to make them interesting, but I just don't see any solutions that don't involve resources or automated resupply that aren't the grindy repetitive launch missions that he expressed they want to avoid. So my takeaway is that they still aren't 100% clear themselves what the plan is. I hope they'll come around to the idea of adding resources and automated resupply from Kerbin before interstellar if what they had in mind doesn't hold up to internal testing.

The Kerbolar system is littered with science opportunities. The tightest point in progression for me was the Duna mission, but I still did this with a Kerbal land and return with the limited parts available. There are a ton of options for ome-way science probes to many places for transmitted returns that ensure you can't hit a dead end. You definitely don't need the tier 4 parts to do this either. Just practice / experience.

I suspect they plan to implement a transfer window planner / alarm clock directly into the game. When they do this, it will make sense the tutorial teaches how to use it specifically to plan a mission to Duna or elsewhere.

I think we need more reasons to launch satelites around other bodies, but I'd advise against anything that imposes a barrier to new players like this. Having the trip planner is a huge benefit to players who have never done this before. The game shouldn't leave it up to them to have to do the math for the first mission. It is bad enough the game doesn't give transfer windows yet. It needs to offer more, accurate guidance to players, not less if it is to continue to draw a wider audience of new players.

This mod looks great. I agree something like this would be an invaluable addition. The target marker is great for the translation to target, but alignment by eyeball alone is inconsistent.

Define "buggy". Aside from craft center of mass not lining up properly resulting in instability in how the game reports the navball target vectors, I haven't found rendezvous or docking any more or less difficult than my experiences in KSP1. I've heard there can be issues with undocking, although I have not encountered this myself.

I don't have any video on hand for this, but it basically is a spontaneous wobble of a ship in orbit that oscillates with increasing magnitude until the craft shakes itself into pieces. At first I suspected SAS, but I've seen it on craft with SAS disabled. Time warping can suppress the effect as this halts the physics sim for this motion. Some stray calculation is causing a runaway feedback loop until the craft tears itself apart. It's most prone on large interplanetary craft. My largest had 3 instances of this effect in one game session. I'd have to see about setting up OBS again to try to record it. It's quite random when this occur so it might not be something that can be easily reproduced.

The new joint physics are a massive improvement. Most "traditional" rockets I build never need struts. Only some really massive asparugus staged rockets might need a strut or two to reinforce the boosters to keep them from flexing and colliding with other parts. This seems perfectly reasonable to me. There's definitely some remaining physics instability with craft in orbits though. I too have seen craft shake themselves to oblivion spontaneously. This suggests the algorithm for the wobble is still mathematically unstable. A stable craft would have mechanical dampening from friction and bending stresses that should prevent spontaneous shaking to pieces unless a substantial input force was involved. These flexing forces should include some kind of dampening factor to ensure the runaway wobble isn't possible.

I don't think about ejection angle. I just ensure ejection is aligned with planetary prograde or retrograde on escape. I think that's good enough not to worry about angle to the nearest degree.

This is making the rather substantial assumption that you have a simple surface to surface contact that you can continue to slide over. Realistically, if the legs of the craft were sliding on a dry, gravel surface, the legs would begin to dig into the surface/become covered in rocks increasing the friction until firmly planted. I would go so far as to say they would be designed to do this. From this point of view, the landing legs themselves should function as a kind of anchor if the craft shifts more than a short distance.

I think KSP2 as a game is shaping up nicely compared to KSP1. The tutorials, tech progression, and missions are great. Colonies, resources, and interstellar all are very promising to leapfrog the foundation that KSP1 laid. And of course multiplayer for those who are looking to that. I still find it odd how they released the game in the state that it was in and how even now there are many gameplay breaking bugs that will turn off all but the most dedicated player from playing even in a sandbox context. It's kind of baffling that it remains this way as I can't imagine how frustrating all the bugs are from a development perspective and how much these would interfere with new development. Trying to troubleshooting new bugs and work on gameplay balance is surely less efficient when there are many existing bugs that can regularly impact gameplay as to interfere with basic testing. Despite being an Early Access title, there is still an expectation that the game is playable given the publisher/studio size and price tag. The number of game breaking bugs certainly puts this status in question for a non-negligible fraction of players. It doesn't help that they maintain a relatively low turn-around on patches compared to other EA titles that many would come to expect especially from a game with the magnitude of some of the issues. There is an intrinsic expectation that large issues get resolved quickly before returning to content development. It really didn't help that they hyped up the game prior to EA announcement as being something that would be released as a 1.0 product giving the impression they were much further along than they were. The marketing team simply did a terrible job managing expectations.