LameLefty

Someone up-thread said they found something that looks like it in the game files but I have not tried to confirm.

This is the "canonical" web-based dV calculator you're likely already familiar with, especially if played KSP1 for a good while without using MechJeb. https://ksp.olex.biz/ That give us about 1,043 m/s for the optimal Hohmann transfer burn.

Again, I keep beating this dead horse, but go look at Nertea's Kerbal Atomics mods for KSP1. A lot of this stuff has been hammered on thoroughly by a lot of players over the years Nertea was developing and updating it periodically. His entire set of mods (including cryogenic tanks with boiloff rates to contend with, advanced oxidizer-injected NTR for "afterburners", tiny little RTG-powered nuclear probe engines, plus a full system of properly scaled radiators to handle the heat rejection, etc) is almost certainly the basis of what we are going to get in the basic nuclear rocketry tech tree when KSP2 is "done." We will have far more advanced technologies in the game, too, but for nukes, Kerbal Atomics is where you should go look for the roadmap, I believe.

I put dead-simple probe into orbit around Eve 10 days ago, then just for kicks (and since there's no reentry heating) tried to land it. Of course, without parachutes, landing legs or anything close to sufficient T/W ratio, it didn't end well. But an amusing assortment of debris survived the terminal velocity of about 30-odd m/s. I like the butterscotch flavored Dum Dums.

Go with a nuclear transfer stage. Your methalox boosters can't draw the LH2 even if they wanted to.

It sure would be nice if the Community Managers remembered that “community” includes this Forum, which has long-predated the existence of Discord.

Used to be a fun challenge early in KSP1 to launch a Kerbal to low Minmus orbit via jumping + EVA jet pack, and another challenge to land them again. That was before jet pack reaction gas mass was added though. I haven’t tried to see if it’s possible these days.

This. That said, the things Nate posted about (almost two weeks ago already!) will be welcome if truly fixed. Most of the UX/UI design-choice aspects that people don’t like can wait - right now, we need patched conics display back and trajectories that pass through SOI’s to be fixed; we need fixes for legs falling off landers and things falling through terrain; we need fixes for the burn progress bar resetting itself on change from Map to Flight modes and vice versa, or when hiding the UI for screenshots; we need a fix for the crossfeed bugs that put us in orbit around our target body but suddenly realizing our booster has used all our propellants; etc. With luck, hopefully all of these have been addressed in the five weeks since the ESA event. But if not, that fact it will have been five weeks WITHOUT these being fixed will be telling also.`

As noted above by others, the planets DO move in time warp but the current Tracking Station bug limits time warp available. I’ve done successful trips to Duna, Eve, Jool (several times) and Dres so far. The workaround of putting a dummy vessel onto a runway or a second launch pad, then going to the Tracking Station will allow you to warp faster as needed to get a launch window. However, there is a second bug potentially at play currently - right now, your plotted trajectory out of an SOI may be substantially different once your active vessel actually leaves that SOI. Last night I had a nice, near-optimal dV trajectory plotted back to Kerbin from Jool. As soon as my craft left the Jool SOI - making no maneuvers or even any attitude changes - the actual trajectory was wildly different. It required over 1,000 m/s in additional dV to achieve a poor intercept, which itself was so marginal I had to burn an additional 2K m/s to get a landing once back in the Kerbin SOI.

The game is broken as heck in some fundamental ways - hopefully the patch will focus not on some of the … questionable … UX decisions, but on core game-breaking things like trajectory projections being completely wrong when leaving an SOI (see the bug report I posted tonight for a good example); physics glitches like legs falling off and landers sinking into terrain and/or hopping around when changing focus to a Kerbal on EVA; staging glitches and parts failing to separate; etc. Yet, despite all that, Steam tonight tells me I have 60 hours of playtime already. Admittedly, I’d have had a lot more SATISFYING 60 hours minus all the bugs. But I’m still playing, so I guess there’s that.

I spent a LOT of time last night and tonight trying to get as close to the canonical "optimum" dV transfer from Jool back to Kerbin. This was the projected trajectory AFTER I had completed the Jool departure burn. Note the periapsis very close to Kerbin's orbital plane. However, immediately after leaving Jool's SOI, having made no maneuvers or any kind of trajectory adjustment, my vessel was tremendously far off the trajectory projected after the departure burn: The orbit after leaving Jool's SOI required almost 1,000 m/s to get anything close to a Kerbin encounter, and then a final mid-course burn of about 140 m/s to ensure it. And then once inside Kerbin's SOI, due to the inability to see the trajectory projections through the SOI, I was so far off I needed almost 2,400 m/s radially to get a Pe close enough to guarantee an atmospheric entry. Nearly all of the remediation efforts set forth above, however, can be attributed to the utterly WRONG trajectory that resulted at the exit from Jool's SOI. I was only able to salvage this return because I had a massively over-powered SWERV powered transfer stage with a good amount of dV left for the return, and a completely full Laythe methalox powered lander with 3,400 m/s dV available. (*) (*) I vastly mis-guesstimated the T/W ratio for Laythe so I just gave up on the lander and came home with full tanks. Had I not done so, these four Kerbals would be stranded in digital hell forever.

Take a look at Nertea’s Kerbal Atomics mod for KSP1, which I linked above. It has a complete line of much better-balanced (and thus more usable) nuclear engines in a variety of scales suitable for outer system light probes all the way up to SWERV-type gas-core rockets, each one thoughfully balanced as to mass, ISP, and placement on the Community Tech Tree to which he was a contributor. I think the NERV we have right now is either merely a carryover placeholder, or will later be supplemented by more advanced (lighter, better ISP) versions analogous to those from Nertea’s Kerbal Atomics. It’s also possible that by the devs are intentionally NOT going to fill out the lower end of the tech tree with better versions of existing tech (such as a sorely-missed Centaur-equivalent LH2/LOX engine) but instead focus on the far, high-tech end of the tree with those advanced plasma and fusion torch engines focused on interstellar tech.

If people want to know what to expect for later game content and in particular, nuclear engines, see Nertea’s longstanding (amazing) work with KSP1. In particular, I draw your attention to: The existing nuclear engines in the game are direct descendants on his work above, and I expect the thermal control system aspects will be as well, once worked into the game.

Not sure if this is affecting anyone else, but when I have this mod installed, when in the Map view, as soon as I zoom in with my mouse scroll wheel, the zoom level of the Map gets stuck fully zoomed-in, regardless of what I have the UI scale set to. As soon as I remove the mod and restart the game, my Map zoom works normally again.

Heat yes, radiation? I doubt it. If you’ve ever played with Nertea’s mods in KSP1, I think you’ll get a very good idea of how things are likely to end up in KSP2 (especially now that he is a KSP2 dev). Heat rejection/radiator mass will cut into the “OP-ness” of the SWERV but not to the extent that it’s unusable.

LH2 is what it is. It’s already as dense as hydrogen gets except for its metallic form, which requires truly intense pressures of the kind found deep inside gas giants like Jupiter. As a deep-cryogenic liquid, the tanks provided in game are pretty okay from a mass standpoint. Big Mylar-insulated Dewar containers like this are perfectly feasible. As for tech tree philosophies, that’s a subject for a dedicated thread once a tech tree gets added. Lord knows there was plenty of that in KSP1. Having said that, something like a SWERV and eventually Orion nuclear pulse, MHD plasma drives, etc. are truly order-of-magnitude more capable than earlier technologies and will definitely NOT be a “side-grade.”

Waaaay back in late March 2013, I found a tutorial video from someone that taught me how to do it. In KSP1 it was easier because when you create an intercept, you can see numerically how close you are going to pass, not just with big blobby UI icons. Aim for an intercept of about 5km or less for best results. Quick save after you make the burn just in case, lol. Then time warp until you’re a couple minutes from intercept. Take control of the active vessel and be sure you have the nav all speed set to Target velocity (again easier in KSP1 because the velocity is positive or negative to indicate departure or closing rate intuitively. In KSP2 it’s just a number with no sign - BAD UI, KSP2 DEVS!). Anyway, as you close on the target be sure to to set Control from Here for your docking port, and then point your engines generally toward the target. You should see your prograde marker somewhere near the target marker on the navball. Depending on how close your initial orbit was, your approach speed and closure rate will vary, but you will thrusting backwards to both slow your closure rate AND to nudge your velocity vector marker toward the target marker. You are effectively making your own current orbit match the target’s orbit. In practical nuts-and-bolt terms, you “pull” your prograde marker toward the target when you add thrust pointing at the target, and you are “pushing” the retrograde marker when you are facing backwards and adding thrust. The tricky part is, when you are “pulling” the maker by adding thrust, you’re speeding up your closure rate. So you have to flip back around and slow again while pushing the retrograde marker. It’s a lot harder to explain than to do after a time or two, and it’s VASTLY easier if you have slower relative velocities to work with. For practice, I’d suggest launching your target into something like a 200km circular obit, and your active vessel into a starting orbit of something like 170km or so. That way, you have plenty of time for each orbital period and the closure rate won’t be too high as you approach intercept.

SWERV is great! It’s only OP in the case of a pure sandbox, with all parts unlocked and usable from the get-go. In a true career-based campaign with an actual technology tree, you can be sure it’s going to be waaaay up there past the basic NERV, and require a lot of Science!(tm) to unlock for your late-game in-system bases, colonies and stations.

Excellent selection of tools here. I will note that Abrit’s Transfer Calculator gave me questionable results last night trying to return from Jool. From a medium Jool orbit (circular, between the orbits of Laythe and Vall), the tool suggested a desired phase angle of -409 degrees. LOLwhut? It’s unclear if that SHUOLD be -49 degrees (subtracting 360 from the absolute value of the phase angle displayed) or some other mathematical error. I have added an issue to the author’s GitHub repo so hopefully it will get addressed. EDIT: Mod author already responded to my GitHub issue post. For now, he said to add 360 to any result until you get an angle of greater than -180 degrees. So in my example above, adding 360 to -409 gives me a desired phase angle of -49 degrees. This comports nicely with the result from the long-standing web-based calculator https://ksp.olex.biz, which gave me -48.65 degrees. Close enough! He will have an update out soon.

The SWERV is awesome. I have a SWERV-powered transfer stage fed from a 50 ton LH2 tank, with a probe core, reaction wheels and some minimal RCS that can push itself out of LKO with 16,000 m/s dV available. With a 4-crew methalox lander as payload, it still has over 10K m/s dV available. Once you go nuke and figure out how to use it., you never go back. That said, to use an architecture like this efficiently, you have to be able to rendezvous and dock in both LKO and around wherever you leave your lander, and right now our tools to assist with this are quite limited.

In KSP1, I used MJ for docking exactly once, I think. It was terrible - spamming RCS all over the place, using up almost all my monoprop. As soon as @NavyFishcreated his amazing Docking Port Alignment Indicator, I adopted it right away and never, ever used anything else. But since we don't have that in KSP2, it's back to the old-fashioned method of getting a close intercept, then "pushing" and "pulling" the navball velocity vector markers onto the Target indicator (with the docking port of the passive vessel set as the "Target" once you get close enough). It works, but it requires a lot more patience than a nice close rendezvous setup with MJ's Rendezvous Planner and DPAI for the final 200m or so.

So, I'm of two minds about this. I don't want (nor have I ever used) a lot of the stuff some people LOVE about MJ (like Smart A.S.S., or automated docking for instance). But the stuff I do miss the most is the stuff that I REALLY miss - Ascent Guidance, Rendezvous Planner, and Maneuver Planner. I was also quite fond - especially in late-game situations - of the Transfer Window planner. Landing Guidance (especially for vacuum bodies or bodies with really thin atmospheres) was also pretty darn handy for my Mun and Minmus bases. After the first few thousand LKO launches and Duna transfers, there's only so much gravity-turn wrangling and manual maneuver node twiddling I find bearable.

The same “pass through” for control inputs occurs in the VAB when typing a capital M can bring you directly to the Map view, or in the Tracking Station when - if you had recently been controlling a vessel - renaming a vessel and hold SHIFT when typing in the new name will trigger the throttle of the vessel you were just controlling. So it appears to be a generalized UI bug where inputs are not isolated into text fields but still act as flight/mode controls for the game. (Also - you should edit the text formatting in your post - it appears as light gray-on-white, which is terrible for readability.)

So … let’s talk about this. Last nigh I landed a crew of four on Minmus as a basic functionality test of a new lander design. I got all four crew out and lined them up next to the flagpole (which rendered as the default KSP flag not my specific selection when starting the campaign, but I digress …) As I watched, they cycled between excitedly dancing in place, yawning, adjusting their helmets, but also scratching their rear ends and quite obviously either farting or peeing, presumably into their suit catheters. While the idea of idle animations as such is fine, I don’t really care awful much for some of the more infantilizing/middle school humor animations like butt scratching and farting. I miss the occasional “terrified Kerbal” trait - we should have animations of them looking around nervously or tentatively, staring up at nebula filled sky with dismay or even fright. We should have some more curiosity-themed animations too - looking down at the soil, pulling out a little widget and “scanning” the ground or the atmosphere with it, etc. In short, I don’t want my Kerbal to be green Minions. I want them to be Kerbals, like they’ve always been. What do YOU think?