herbal space program

Looking at the above designs, I see I really overbuilt my Eve 10 lander! It looks lot a lot like what @astrobond posted above, but it has 4 large side boosters with 7 Vectors each instead of eight with just one each. I blame the completely Borked dV readout in the VAB! I have to re-install KER and see how much dV my lander really has. My guess now is it could probably make it all the way back to LKO without even aerobraking.

I haven't done an Eve return mission in KSP2 yet, but in KSP1 I found the Vector to be hands-down the best engine for lifting larger payloads from near Eve SL. The Dart may have the most favorable ISP profile, but it has a lower TWR than the Vector (OK, perhaps just about equal at Eve SL), but more importantly, a much lower thrust per cross-sectional area than the Vector, like 4.5 times lower. When you're trying to take off through that endless soupy atmosphere, lowering your drag is a very important consideration that is not addressed by these calculations, and that requires the lowest cross-sectional area possible. Unless of course you want to shamelessly clip engines into one another to cheat the drag model, but that's not my style. ...And I should add that while these laudably rigorous calculations are great for figuring out what works best for a given payload at Eve SL, actually ascending to orbit only happens in that regime for the first few seconds. Pretty soon you're in substantially thinner air, so a lot of this stuff doesn't matter so much anymore. For that reason (h/t @magnemoe), I have a SWERV as the core stage on my Eve 10 lander. Its decent TWR and far superior ISP make it the best choice IMO for the large dV push from being high in Eve's atmo to actually being in orbit.

I have a slightly better rig than even that, with 16 cores (Corei7, 11th gen), 64GB of system RAM, and 12GB of video RAM (RTX3060), and still anything approaching 300 parts becomes so painfully slow that it's just no fun to play anymore. Even worse, part counts in that range seem to break the VAB pretty regularly, which has recently caused me to lose hours of design work due to corrupted saves. This kind of stuff should be at the very top of their priority list right now IMO. Apropos of that, the reason I believe this should be their highest priority is that I don't see how we are going to get anywhere near those giant colony ships that we've seen sneak peeks of until they resolve this issue. They are going to need roughly an order of magnitude in performance improvement before any of this stuff is even worth talking about seriously. My experience trying to dock together two ~250-part assembles in the current game (for an Eve 10 mission), something I can do very easily with lower part-count craft, tried my patience to the point where I really just lost my appetite to keep playing. How are we ever going to have 1000-part colony ships if that's what we're up against? Everybody except a handful of diehards with extraordinarily performant computers is just going to lose interest if they don't deal with this first.

Yes, that's about right AIUI.

Yeah, I had those on all my general-purpose robotic probes and they all turned out to be "blocked" as well, even though there was no obvious reason why they should have been. Lots of lucrative science out the window! As I detailed above however, other issues were more problematic for me than that.

I must agree that fixing these things is way more important right now than having them fully implement the Comnet feature the way it worked in KSP1. In fact, I think that trying to implement it now, while there are still all these play hindrances due to bugs, would just degrade the experience further rather than enhance it. I've spent a good number of hours recently simultaneously working on three things in the game that are relevant to the above bug issues. One is my Eve 10 lander, which has three large orbitally docked modules, consisting of a big nuclear orbital tug with the crew re-entry vessel, the lander proper, and an intermediate sky crane stage to facilitate my Eve atmospheric entry. The second is a swarm of 5 remote probes, each of which is targeting a different body in the Jool system, all arriving in more or less the same timeframe, and the third is my Mohole mission, which I am gradually spiraling inwards towards Moho with a series of carefully timed gravity assists and DSMs. Trying to manage all these missions concurrently has raised a number of issues for me that seem like they should be quite high on the Fix or Implement Better Right Now list. For me, in order of priority, those would be: 1) What gives with the comically self-censoring pop-up windows when you want to see the info about when a given craft will reach a specific AP/PE? The default, information-less designator, e.g. "Jool PE", is always right in front of the critical information telling you when you will arrive at that spot when you click on it. D'ooh! And I mean, how hard can that possibly be to fix? All you need to do is change the default arrangement of those windows in the display, or enable the user to bring the desired window to the front by clicking on it. It's absolutely maddening if you've got 5 different flights making maneuvers in the same time frame! 2) About half the time, when I'm on an escape trajectory within some SOI, especially when I have just put myself on one, I have to play this ridiculous cat-and-mouse game with the pop-up window for maneuver nodes, because every time I click on the orbit to open the window and try to push the "Make maneuver plan" button, the window disappears before I can click on it. If you were actually trying to design a bug to drive players crazy, I'm not sure you could do better than that. 3) On the same subject, the display of patched conics and the placement of maneuver nodes is just not sufficient for anybody who is trying to plan things out into the future. I need to be able to place nodes in my next SOI, and I need to see where I'm going further into the future! Playing Jool Pinball with 5 simultaneous craft in-system is hard enough even if that all works well, and this system makes it well-nigh impossible. 4) When the part count gets really high, even if most of those parts are stuff like batteries, the frame rate still gets so low that play becomes next to impossible. Docking up my Eve lander module to the other two was just an excruciating process because the frame rate was so low. It seemed there was a significant improvement to this in the two last updates, but it appears they still have a long way to go. Anyway, for my part I'd really, really prefer that they fix stuff like this before they start trying to implement any new features. You can't keep making the building taller if the foundation still needs major work!

I must say that if anything, I find some of the marquee missions in KSP2 harder than most of what you had to do in KSP1 to get through the tech tree. The Mun and Minmus monument missions were pretty trivial, but the Stargazer Point and Duna monument missions were tough! The large amount of steep terrain surrounding those objectives required either a pinpoint landing right next to the target or an epic cross--country trip using a well-designed rover -- neither of which I would call easy even though I played endless amounts of KSP1. I'd also say that getting a probe into Jool's atmo intact and landing at the bottom of the Mohole aren't exactly trivial either, especially since the dV indicator in the VAB is completely Borked, so unless you have a rocket equation spreadsheet handy you never really know if you packed enough boom to get the job done. I'm also making the Mohole mission harder for myself deliberately, by not bringing the massive amount of dV required to do it the straightforward way. If you know how to set up the right Eve gravity assist, you can actually reach Moho's orbit and do almost the whole plane change for just a little over the price of a transfer to Eve's SOI. From there, you can set up a series of Moho assists and DSMs that will get you a lot of the way to capture for a whole lot less dV than doing the straight injection burn. The record I remember from the KSP1 challenge forum was 1800 m/s from LKO to low Moho orbit, pretty impressive when you consider the regular way costs 6640 m/s! And then of course there's ten Kerbals to the surface of Eve and back, which is really quite difficult when you've only got half the tech tree unlocked, at least for 95% of KSP1 players. So challenging? Yes, I think so! New? Not so much, but I hold out a lot of hope that this will be remedied by future updates that add both new features and new content to explore for the existing ones.

Well if that's what it really is, then I'm fine with it. I said as much upthread. They just need to know in no uncertain terms that they have to make this feature work better ultimately, and not leave it in the lousy state it's in now. "Working as intended" does not communicate that so well. It should really be something more like "Not fully implemented yet" or "Still under development". That way we won't think they just hate us and want the game to fail so they can move on to the next thing.

I actually have 5 probes currently inbound at Jool, and I found it extremely annoying that I could not place nodes in the Jool SOI for these probes while they were still in the Kerbol SOI. If for no other reason, I want those nodes there so that I am reminded in the tracking station to attend to those craft at the right time, which becomes quite complex when you've got 10 missions going at the same time as I do now. As it is now, the tracking station doesn't even show you your future nodes for a given mission when you when you click on it, which makes juggling multiple interplanetary missions much harder.

Reading through the comments so far I know I'm just piling on, but truly there are not enough rotten tomatoes in the world to provide sufficient feedback about this being an intentional feature. What gives? Why do you hate us so much? In KSP1, I would often plan three maneuvers ahead, all in different SOI's. Losing that functionality is a major pain in the end that should not point towards space, and while I can be patient about waiting for somebody to create it, the idea that it might never be possible is demoralizing.

Good to know, and thanks for saving me the guesswork! The engines weren't so easy to make out behind the heat shields in the pic you posted, but I can now see that's indeed what they are. I've been noodling around with my own eventual 10-seat Eve lander, and I'm pretty sure it will end up looking a lot like yours. I figured I'd use it to do the Chonker and Husky missions before actually sending it to Eve, since it will be a good testing opportunity for all the complicated sub-systems, and besides, what other practical reason is there in this version of the game to make a 300+ ton lander?

like what you did with the heat shields there! I was scratching my head about what to do for those, since I don't have the super-convenient inflatable version yet. In KSP1, I did something like that using hinges mounted to radial decouplers, so that I could stow the shields more aerodynamically for takeoff, but of course we don't have those in KSP2. Must have been fun taking off with that rig! I like the stageable chutes and stageable trusses for landing legs too. Anything to shed weight and drag for the flight back to orbit! Lastly, I'm kind of surprised by the choice of the Mammoth over the Vector for your ascent engine. I had thought that the Mammoth's worse ISP curve would have rendered it impracticable despite its better inherent TWR, but I guess I was mistaken!

That really depends on the direction from which you are entering Jool's SOI. For a typical Hohman transfer, that will likely be from more or less Jool prograde, so you'll want to be encountering Tylo when it's somewhere near its closest point to Kerbol and moving in a more or less Jool-retrograde direction. And yes, your trajectory would be at roughly 90 degrees to the Jool-Tylo vector no matter what direction you came from, but always going in the same direction as Tylo.

Pro tip -- There is no game rule that says you can't use the Gumball as a lander can! I actually landed 4 Kerbals on that mission as well, because I had a VAB-generated stowaway on my Duna Monument mission. When the Ike mission popped up while that mission was still in system, I ended up landing my Gumball transfer stage on Ike while it was still docked to my 1-seat Duna lander, which was supposed to have been discarded but was now needed as a lifeboat.

My usual Jool system MO, regardless of my ultimate destination, is to set it up so that I have a same-direction Tylo encounter on a near-tangent orbit as soon as I arrive in system. That will reliably get you Jool-captured for free, and from there you can easily set up further Laythe/Tylo encounters to get you cheaply captured by whatever moon you're ultimately headed to. For Laythe, it's usually Tylo-Laythe-Laythe, because I'm generally coming in too hot on my first Laythe encounter, even after swinging by Tylo first, to aerobrake successfully.

Aha! I knew there was something about staging in the middle of a burn that threw it off. Well done!

...So what I've come up with to help me plan efficient multi-kick burns is the following: 1) Put a bare bones probe, with very high (>=3) initial TWR and enough dV to reach any intercept in the Kerbolar system, on a circular 100km parking orbit. 2) Use this probe, of which my version can do a 2500 m/s burn in 44 seconds, as a tester to plot the whole orbital transfer as if it were a KSP1 node, since at that high TWR it's essentially equivalent to one. 3) Place your long-range mission with its pokey transfer stage on the same parking orbit as the tester craft. 4) Start planning the real maneuver by placing the node for your first PE kick at the spot where the midpoint of the high TWR test burn would have been. 5) Pull on the prograde handle at that spot until you have a short (<15s) burn set up, then drag your node backwards along the orbit to place the midpoint of that burn where its origin had been before. 6) Execute that short burn. Your resulting periapsis will now be at a good approximation of where your ideal periapsis for a near-instantaneous burn would have been. 7) For subsequent, longer PE kicks, start your node half of the desired burn length before your PE, then drag on the prograde handle until your burn is bisected by your current PE. 8) From that position, you will see that your projected new PE is closer to your node than your current PE is. Drag on the radial inward handle of your node until your new PE is again on top of the old one. 9) Execute the burn from there, which should leave your PE in the same spot it was in before, and then just go back to step 7 for all subsequent burns. This series of steps worked very well for me going to Jool with a transfer stage that had a TWR of 0.3, resulting in a total dV expenditure of only 50-70 m/s more than the nominal 1,989 m/s dV required for the ideal burn as plotted here: https://alexmoon.github.io/ksp/#/Kerbin/100/Jool/100/true/optimalPlaneChange/false/1/1. Not bad! I can definitely live with that.

I'd call that an alternate order rather than an alternate path, since the missions are still the same, but indeed if you know what's coming you can definitely be more efficient with time and missions. I didn't have the benefit of that knowledge, but I was still able to save a lot of time by sending multiple missions and/or overbuilding my missions to Duna and Eve . That allowed me to knock off a couple of things that popped up after the first mission was completed without having to wait for the next transfer window. I actually sent five separate probes to the Jool system, even though one would have been enough to do both of the two missions that pop up initially, on the assumption that new missions for Jool will appear after the first two are done. The probes start with something like 17,000 m/s of dV on LKO, so they can reach just about anywhere, and have a universal lander module that can land on any body and also return from most of them. I'm basically sending at least two of those to every planet now as the transfer windows happen, and not waiting for any directive from Mission Control.

What would be great IMO is if the Mission Control code could adapt to what tech nodes you have already unlocked and what kind of missions you have flown previously, to create alternative high-reward paths to unlock the tech tree, and perhaps also alternative trails of Easter eggs that all ultimately lead to acquiring some special alien interstellar tech that enables the late game. For example, I was always a plane enthusiast in KSP1, and flew all sorts of missions to faraway places using SSTO planes, but KSP2 Mission Control has never offered me ANY kind of mission that involves flying, even though I have unlocked multiple nodes of the aviation tech tree. Where is the "take off from the runway with an airplane, attain an altitude of at least 4000 meters, and land again safely" mission? IMO, it should be right there next to the "Launch a rocket" mission at the beginning of the game, or at least as soon as you've unlocked enough aviation-related nodes to build one. As it stands now, I'm already being offered some of the most difficult challenges in the whole game wrt rocketry with only about half of the tech tree unlocked and no access to any space plane-capable jet engines yet. Ditto probe cores, although it seems like while planes have been left out in the cold entirely, probes are just inside the room but have to stand in the corner quietly until (infrequently) called on. Again, I think there should be some kind of probe-specific mission available just as soon as you unlock the capability to make them. You could even think of these three branches of exploration -- aviation, robotic, and crewed, as three separate victory paths ala Civ, each of which you can freely choose to pursue to the extent you see fit. Thus, if you have separate tech trees for those three things, as we sort of do now, you can also add separate mission trees for those three things, each of which ultimately leads to the same place through a different series of steps. I think that something like that would offer the best possible mix of both replayability and playstyle flexibility for the campaign, while still maintaining science points as a fungible resource. Lastly, in addition to what techs/missions you choose, the game could look at your success/failure rate on specific early missions and adjust the rate at which the difficulty ramps up based on that. I dunno, maybe it already does that? That might explain how I'm getting such extremely difficult things served to me so early on, which is fine for me but seems like it would be pretty off-putting to a beginner.

I think a good portion of the fun of the game for me is improvising when things go wrong or don't quite work like they should. I often don't see it that way going in, but after I've managed to get out of some kind of unexpected trouble or solved some gameplay problem like this for myself, I usually feel a lot of satisfaction.

The only real reasons to get so in depth are if you're trying to reach some distant destination for as little dV as possible, or have to lob some truly ginormous thing into deep space with as little additional mass as possible. I did a whole lot of the former in KSP1, so I spent a great deal of time twiddling nodes to get the best efficiency and comparing notes with others on the forum who were far better astrogators than I. The new game OTOH looks like there's going to be a whole lot of the latter to get through the career tech tree, enough said about that. In any case, for my own purposes I'm implementing a workaround, which is to put a way-overpowered craft with no payload other than an OKTO into a 100km equatorial parking orbit as a test maneuver planner. It starts with a TWR of 3 and goes rapidly up from there, being able to do a 2500 m/s burn in around 44 seconds. Placing a node in KSP2 with that craft is essentially the same as placing one in KSP1, so I can use that craft to plan maneuvers for other, much pokier craft on the same parking orbit. Once I figure out where to center my PE kicks with that ship, I can plan maneuvers with the real missions for maximum efficiency.

For my part, I don't think it's really fair to level a lot of criticism at the KSP2 science system at this point because it's pretty obviously not finished yet. I too felt that the absence of actual readouts of temperature, pressure etc. made the experience of doing science less rewarding somehow, and also that the apparent paucity of mission options and alternative paths forward to unlock the tech tree are pretty restrictive. But I also can't believe that's all there will be to it. This is just the foundation of the building. After all, we have whole new tiers of parts that don't exist yet that will need to be unlocked somehow. And I actually like the idea of using a series of Easter egg hunts as a means of getting to some goal in terms of new alien techs and interstellar capability, which is where it looks like they might be going to me. I actually lobbied for that idea long ago in the KSP1 forum, because so many of the science missions in that game seemed totally pointless to me. I get that this might hamper the replayability of the primary campaign as such, at least if they don't implement some alternate paths to unlocking the essential capabilities, but with so much new content and so many whole new modes of play on the horizon, I have to believe there will be new campaigns that become available once the whole initial tech tree has been unlocked, and more still after that in the form of new star systems as DLC. Anyway, I think what we have now is still basically just a stub.

You just don't seem to get it, but whatever! I guess some of us just like to spend our time telling other people how they should feel about the game rather than playing it themselves.

All that would be great, but for my part, all I would really need to make the new system work as well or even better for me than the old one would be for it to allow me to specify an arbitrary TWR when placing the node. That way, I could set it to 100 (so that it works like the KSP1 node) while I'm finding the spot on which to center my periapsis kicks, and then change to whatever it really will be when I plot my actual first burn around that spot. Once you know the length of your burn, it's actually not so hard to pull radial inward on the gizmo until your projected trajectory defines a secant that intersects your orbit exactly at the beginning and end of it.

The point is that there is no way to eject from a circular orbit with maximum efficiency if you are pointed directly prograde when you start your burn and remain in that attitude the whole way through, unless you have infinite thrust. For maximum efficiency, you should be pointed directly prograde at the midpoint of your burn, but some amount inward of prograde at the outset, and somewhat outside of prograde at the end. Why else would people be setting up all these sequential periapsis kicks when they're using a low TWR transfer stage?