hatterson

The patented Matt Lowne lazy method. You can end up with some rotational/lateral movement as they close, but the magnets in the docking ports are strong enough in KSP to overcome it. It's a completely unrealistic method of docking, but it works like a dream in game and is fine for a game like KSP.

@The Space Peacock This appears to be related to the deployment status issue I identified in the bug report linked below. The part does not properly reach deploy status and thus when it is duplicated or when a save is loaded with one extended, the "heat shield extended" button seems to be out of sync with the part and thus won't let it retract (due to the part already thinking it's retracting but not moving) Unsure if you can link them or otherwise note it easily, but the root cause appears to be that the heat shield never fully extends and when it's copied or the save is loaded with it extended the button gets desynced and doesn't work. My comment is here:

More Detailed Information Adding some testing I've done while looking at the JSON. To ensure nothing else silly was going on I created a brand new sandbox save. I then made a simple craft. A pod with a giant truss out the top and a square connector on top of that. On each side of the square connector I placed an HS-I Deluxe inflatable heat shield ("heatshield_v2_inflatable"). I did this manually each time without using symmetry so that I could control each one individually. With the one attached to the "front" node of the square connector I clicked the extend button in the VAB one time to have it extended. The status in the VAB read "moving" despite being open. With the one attached to the "left" node of the square connector I clicked the extend button in the VAB twice to extend it and then retract it. The status in the VAB still read "moving" even after being fully closed. I left the other two alone. I launched the flight and made a save to check the json The heatshield attached to the "front" node listed it's in game status as "Moving" and the status in the json was "Retracting" (PartModulesState.ModuleData.DataObject.CurrentDeployState.storedValue) The heatshield attached to the "left" node listed it's in game status as "Extended" and the status in the json was "Retracting" Both the heatshields attached to the "back" and "right" nodes stated their in game status as "" and the json status was "Retracted" I then manually inflated the part attached to the "back" node and waited roughly 30 seconds after the animation was finished to ensure it had fully done it's thing. I then did a save again to confirm the json: Unsurprisingly the heatshields on the front, left and right nodes remained unchanged. The heatshield attached to the "back" node listed its in game status as "Moving" and the json status was "Extending" I then wanted to test the heat shield itself so I made a new craft. An Mk3-L "Wanderer" pod, the HS-I Deluxe inflatable heat shield below it, a TD-25 decoupler below the heat shield, an X200-16 fuel tank and an RE-L10 "Poodle" engine. I launched and then teleported into the minimum Kerbin orbit, 86,750x86750. I burned retrograde to lower my PE until my orbit was reentering Kerbin then staged leaving me with final orbit values of AP 86,741 and PE 56,691, a very shallow reentry. I made a save here and checked the json. As expected the heatshield had its deployment state as "Retracted" I then went in game and, without deploying the heat shield, warped to atmospheric re-entry. I set SAS on surface retrograde and let it go hands off. On the way down I received a heat bar for a short time between roughly 35000m and 20000m on the heat shield, but eventually slowed to a couple hundred m/s (no parachute so would have crashed, but that's not the point) prior to it even reaching the flashing point, much less exploding. I then reloaded the save I had and repeated this undeployed re-entry 2 additional times. On each of those times however my command pod had a heat warning starting at roughly 66000m and it exploded at roughly 61000m. (Edit to note: The differing behaviors between is documented here: I then did 3 tests where I deployed the heat shield prior to atmospheric entry. The status of the heat shield in game remained "Moving" with the json status at "" In all three of these tests the heatshield gave a temperature warning at roughly 64,500m and exploded at roughly 60-61,000m Additionally I noticed that the "Heat Shield Extended" toggle was marked off in game and clicking the button would do nothing leaving my unable to retract it NOTE: This is related to this bug report For my third test I modified the json on the part so that the deploy state of the heatshield was set at "Extended" and marked "IsExtended" to true and "IsExtending" to false. These values match how deployable legs change in the json, so I assume they're correct although without a functioning inflatable heat shield I obviously can't confirm if there's not some other setting still off. Once doing this the issue above where the "Heat Shield Extended" toggle being marked as false was resolved. However, unfortunately despite the heat shield actually being marked as "extended" it still exploded with the same parameters as above. Conclusions There is a bug with the inflatable heat shield that causes the deployment status to not fully switch. This causes issues with it remaining "moving" in game and desyncing the toggle button with the state of the heat shield at times Even if you manually correct this in the json and mark it as extended, the heat shield still blows up on even extremely shallow Kerbin re-entries and ends up exploding at similar positions when deployed or extended and similar positions to a raw pod as if it doesn't actually have any heat resistance. These are re-entries that ablative heat shields survive with absolutely zero issues.

On my testing above I was pointed surface retrograde for re-entry which was only a few degrees away from orbital retrograde and was still experiencing significant heating in the very upper atmosphere compared to the lower atmosphere.

Making it even more annoying is that the UI animation goes at a constant speed. So if you're going around at 4x time warp trying to make it go faster, you actually are losing more surface area to the animation. This is also related to this bug/known issue: https://forum.kerbalspaceprogram.com/topic/221681-non-biome-specific-experiments-are-behaving-as-though-they-were-biome-specific-making-it-near-impossible-to-collect-science/

To run some tests I put together a simple craft to test, An mk3 pod with the inflatable heat shield below and dropped it on a very thin pass into Kerbin's atmosphere. AP = 86752, PE=55,662. I was entering the atmosphere at ~2105 m/s surface speed. I did a quick save before entering so I could repeat it over and over again. On repeated tests, the heat bar would start showing up around 64-65km and the shield would blow up around 60-60.5km. I then tried a *much* steeper profile. AP = 300km, PE = -80.5km. This one repeated decelerated totally fine with zero heat bars. I was entering the atmosphere at ~2200 m/s surface speed. I performed test 1 again with an ablative heat shield and it performed totally fine, although it did ablate a total of .25 T out of the 2 T of ablator which seems like a lot. By comparison a very aggressive Mun re-entry (AP = 15,000KM which is past the Mun, PE = -51462m aka inside Kerbin's surface), entering Kerbin's atmo at ~3k m/s only ablated 0.06 of the 2 T before slowing to a nominal speed. I did get a heat bar on this, but it survived. So in conclusion, the inflatable heat shield appears to be messed up and upper atmosphere is doing weird things. Pancaking into Kerbin from the Mun should absolutely be a more significant re-entry event than barely grazing the upper atmosphere from LKO.

I've been doing a steeper ascent trajectory the later I've got into the tech tree because of upper atmosphere heating issues. Earlier in the tree this wasn't as much as issue since most rockets were topped by either command pods or probes which have decent heat tolerance. However with larger fairings I get weirder designs inside and sometimes the top parts have trash heat tolerance. Combine that with the fairing not properly doing its job and it means me wanting to get fully out of the atmosphere later even if it means a less efficient launch just to avoid stupid things blowing up for no reason. If upper atmo heating was more reasonable I'd do a more shallow ascent similar to what @Superfluous J described although usually stopping the orbit around 80km for most missions and only going higher if there's a real need. I generally picked that up from the KSP 1 gravity turn mod and just kinda kept it. I also usually throw a probe core on my launchers so that I can fully deliver the payload to orbit, detach, turn them around, and then deorbit them.

I would very much expect more stuff like that as the game matures. It's version 0.2 of early access. Guys like Just Jim do great work, but understandably right now the focus of development isn't going to be having witty banter sprinkled all through the game, it's going to be on providing something that works. As new released come, I'd be shocked if we didn't see more of that type of stuff added in mission briefs, science tooltips, tech nodes, etc.

And new players should start with (crazy idea here) "Cadet Orientation" on. It's enabled by default and you have to explicitly disable it if you don't want it. When a save is started that way you get the fun intro video narrated by discount Carl Sagan that cuts out half way through and gives you the feel that this is absolutely not a super serious rocket game but is instead intended to be a bit silly. p.a.i.g.e. then explicitly tells you about the training center and to head over there to learn the basics. Additionally, when you go into the VAB p.a.i.g.e. again mentions the training center and says how it goes over everything from how to build rockets and beyond. The game does not force you, even if you're brand new, to do training missions or stupid training wheels stuff, but it absolutely gives you more than enough hints that if you don't know what's going on you *can* do those things to learn.

A probe core with an SRB strapped to it is absolutely not an engaging first flight experience for a new player. It's literally press a button and watch what happens. Instead of showing you that KSP is a dynamic game where you both build rockets *and* fly them, the first few experiences you're giving a player is that KSP is a game about designing rockets and then watching them fly. I'm a huge proponent of starting with probes, but only for *experienced* players. I played a *ton* of the Better Than Starting Manned mod back in the day, but it is absolutely not the type of experience you want to have if the goal is to bring new players to the game.

Also once we get colonies as theoretically if you wanted to put a surface colony on Duna, Eve, or Laythe, you'd want to land your stuff pretty close to attach it. I'd assume you'd need some sort of rover ability to move it around the surface a few hundred meters, but being able to land within 500m is a lot different than landing 20km away.

This was spread over about a week in real life, but year 13 of my space agency's life was a very exciting one with the following events happening: Day 85 - Moho lander launch (unmanned) - Eeloo lander launch (manned) - Dres lander launch (manned) - Tylo rescue/lander launch (sent out unmanned so there was space for the crew to come back) Day 104 - Moho mid course adjustment Day 125 - Dres mid course adjustment Day 159 - Eeloo Transfer Day 185 - Moho Encounter Day 186 - Moho Landing and shenanigans** Day 209 - Jool Transfer for Tylo rescue/lander Day 269 - Jool mid course adjustment to get Laythe gravity assist inbound into Tylo encounter Day 347 - Eeloo mid course adjustment Day 380 - Moho -> Kerbin Transfer I still believe I have a few things that will happen in this game year, but don't have those fully mapped out yet and they might bump into year 14. **Shenanigans description in spoilers After all that: Waited at Moho for my transfer back to Kerbin and was able to get a pretty rough encounter with Kerbin where I hit it right at the descending node after burning all but 100 m/s of my dV. That means that when I scream by Kerbin I'll likely be going close to 4k m/s and at something like a 60 degree inclination. I'll have all the data transferred at that point, but I want those juicy surface samples from two separate locations on Moho. So the plan will be to perform what is effectively an asteroid capture mission. I don't have access to the grabber unit (is it even in KSP 2 at this point?) and the lander doesn't have a docking port so it'll have to be a manned mission where the craft goes up, rendezvous with the returning craft, EVAs over to it, and manually removes the samples to bring them back. From what I've seen I don't believe vessel to vessel science transfer is currently possible in game without docking, so that may require some save file editing, but I think that's fine all things considered.

We obviously should be able to track which science we've already collected. It's already clearly marked in the json, there just needs to be a nice GUI in game to identify it for us. There should also be a sort of checklist to identify what science we've collected from *known* biomes. By default I don't think there should be a full list of potential science or biomes until some sort of scan is done to reveal that. For example, if I know that Duna has a lowlands biome I should be able to identify what science I have and haven't completed there. However if I don't have any experience with a Duna polar biome (I, right now, don't actually know the Duna biomes since I haven't done a polar orbiter) then I shouldn't know if it exists until I've collected science from it or done some sort or orbital survey in a scansat type way.

The counter point to "and finding something new" is that the act of getting to other places (LEO, the Moon, Mars, etc.) has given us very, very, very few actual hard scientific or engineering advances related to spaceflight and spacecraft design. And frankly, there are few true *scientific* advances required at all for humans to go to the moon. There are, however, a *ton* of engineering advances that were required and those problems, and all of the new tech that came out of them, were predominantly solved on Earth and with only knowledge we had on Earth. It's not as if NASA went to orbit and suddenly said "oh hey, we learned something fundamentally new that lets us build an F-1 engine." Obviously there was a ton of testing that required real world data to validate, but the big space program advances were much more along the lines of "spend a ton of time engineering a new solution and then go test if it works" as opposed to "go to the moon and suddenly we have a lot more knowledge" The counter point to that counter point is that KSP is a game where we launch little green men into space as they humorously scream. Abstracting the whole engineering and testing process into "go place and collect progress points" is a fine abstraction for the theme of the game. KSP stock never has been, and never will be, a realistic space program simulator, it's just not the DNA of the game.

@Urus28 Is that a large heat shield with smaller heat shields radially attached to it? Or do you have something like a large under the probe body and small ones under each wheel?

Sure, but also that's just how physics works. I don't think KSP should be a slave to realism or anything (at least stock), but there's a reason why every rocket humans have ever built is thin and tall, and it would be weird to have a physics based rocket launch game not disincentivize you from flying something that is 50m wide and 10m tall. There's maybe other things that KSP 2 could do to make landing a little easier like legs that unfold wider or fixing landing leg suspension stuff, but I'm not sure how it can realistically not punish building wide and maintain it's core of being a physics based rocket game. FWIW, once we have orbital construction, or at least constructions on vacuum (like Mun surface or whatever), then you can build as wide as you want. Obviously that's not an option now, but long term it will be.

I've had nothing but issues with the dV calculations in the VAB. Apparently the order you place parts affects it and can cause issues. The in flight ones seem a bit better, but they still seem to have some quirks when using asparagus staging. So far I've been building it non-asparagus first, see what it says for dV, and then moving it to asparagus and adding 10-30% dV depending on how close to mass/TWR limits I am. That's had some unfortunate consequences when my guesstimate is off (like the rescue mission I'm sending to Tylo right now), but it works alright as a workaround.

I think the biggest reason why is that those things are people slotted for future milestones. Specifically, things like maps and mapping missions are slated as part of either colonies or resources. I think something like research to take into account atmospheric drag isn't included simply due to the fact that it's a non-trivial problem and resources have been devoted elsewhere. As far as requiring an environmental survey before knowing things about the atmosphere or a planet, part of me thinks that's an intentional design choice to allow more streamlined missions. As a veteran player, I absolutely can understand and buy into the idea that I first need to send an automated probe to Duna before sending a manned mission, even if that means waiting literal years between missions for transfer windows to line up. I'm not sure that newer players will have that same type of understanding or buy in. I might be totally wrong with that, but it feels like that's the direction that many of the decision makers are taking with the game. Provide a more streamlined (if less realistic) experience that's more targeted at newer players and have tweakable options or rely on mods to ramp up the difficulty for veterans/more advanced players. Regarding the Kerbolopedia, I agree it's an excellent idea but, at this time, it would primarily be fun in game background/flavor text. I can't imagine that the long term plan for the game would be to have the player *have* to read a literal in game encyclopedic to do the missions, that's the antithesis of what stock KSP has always been. So as much fun as it would be to fill in that information and have background articles on all the anomalies, I think the reason it's not in the game now is because it doesn't have gameplay value. It might provide cool motivation for some players to go to a certain biome (either to be a completionist or get more background story), but as something that wouldn't actually be a core part of gameplay, it's understandable why it would be lower on the priority list. Based on everything I've seen and read about this release and the future roadmap, I think an important thing to keep in mind is that the version of science mode released in 0.2 is absolutely not expected to be the final version of science/career mode that is in the finished game. It will expand significantly in depth (more star systems) and breadth (colonies, resources, etc.). The idea does not appear to be that in KSP 2 1.0 you'd have sandbox mode, science mode, colonies mode, etc. but rather sandbox mode and career mode. Maybe two types of career modes or maybe just one with configurable settings. Current science mode is not meant to be the final version of science collection, but rather the bones of how science collection and points will work in the final career mode.

Like I said earlier, I think it's fine in general as long as it's clearly communicated to the player that it's designed as a optional and "lol this is absurd" mission. The name of LIL' CHONKER is a hint at that, but doesn't do enough to separate itself as clearly a joke inside the writing and humor style of the "serious" Kerbal attitude to clearly communicate that to the player.

Oh for sure. I meant comparing KSP 2 right now to KSP 1 right now both without mods. KSP 2 right now is better than KSP 1 was in early versions. Nostalgia covers over a lot, but in reality the early versions of KSP1 were *painful*

I've had more issues with the KSP 2 nodes than KSP 1 stock. It seems tougher to grab individual arrows when focusing on the target planet and the lack of "next orbit" buttons is an issue (I'm fairly certain that's stock KSP 1 now)

Yea it's pretty annoying without mods right now. Needs to be fixed (and they're planning on it) for even interplanetary burns, nevermind interstellar burns in the future.

Unfortunately these options appear to be missing currently.

Are you able to capture a video of this happening? Or a bunch of screenshots? I've done a ton of different burns and they complete on time and on target basically all the time.

I believe I planted a flag on Duna and Ike, but unfortunately I don't see a way in the UI to see where flags were planted to be able to confirm. I also don't see one on the mun or min and I definitely planted one there so I'm not really sure why they're not showing up.