ExtremeSquared

It would be nice if they would release the non-streamed high-quality stored footage from past landings.

That's the rub, I guess. I can't be bothered to keep track of this. I have definitely woken people up with 7am phone calls before because I knew they'd be up by 8am and they live in a place with spuriously changing timezones.

I'm American and can't be bothered to learn what EDT means. UDT is just easier all around. Unless you're in one of those 30 minute offset timezones. Then you need a calculator regardless.

19:37 UTC Not sure why EDT is used given it is unreliable to convert from.

Looks like they got the livestream start time wrong. Launch target is in an hour or so.

KSP was an unstable mess before 1.2 or so. It would crash-to-desktop regularly. If this happened while you were flying a plane, the whole crew would be KIA. I lost probably dozens of Kerbals to Unity.

I make sure Donner Kerman goes on all the extreme long-term missions.

Consider that aerobraking can give you 5-10g of deceleration. RCS would need a pretty large fraction of that to compete if the craft is aerodynamically unstable, and RCS TWR is usually an order of magnitude or two less than 1.0. Give it a big 'ol airplane tail instead. Detach the tail once it's safe to open drogue parachutes.

Aero surfaces on the leeward end of the craft are sometimes necessary with the inflatable shields. Like a dart. The inflatables are sort of a nightmare sometimes. I try to use overlapped regular heat shields when possible.

Assuming you won't be landing with it, you should compare it to a non-scaled Terrier if you want a real competition. I have regularly found the Wolfhound to be a poor choice for deltaV on deep-space engines. A poodle will even beat it on smaller 2.5m crafts.

This is absolutely the normal way to do things. This used to be common knowledge among people who use mods. Modded KSP really should always be played out of an isolated folder for minimum drama. Let's not forget that it's a good thing that less computer literate people and younger people are playing and modding -- KSP should be accessible for everyone -- and the issues arising from this will always congregate in the Kopernicus thread.

Not to go off on a tangent, but there's a VTC/VoIP article on the BBC News front page today that was so flagrantly wrong I un-bookmarked BBC News.

I wonder if there's much benefit in general to putting effort into supporting platform-locked libraries in a cross-platform product.

Not really that cut and dry. The whole point of starlink is ultra low satellite cost and losing a booster increases that whether it's this one or the next one.

Expensive disposable satellites given the non-recovered booster.

I like the slower Kopernicus release cadence. It seems like a great way to maximize the quality to effort ratio given a finite number of coding hours regardless of the number of contributors. Other mods update unreasonably often. And I can see being antsy in the pre-1.2 stage of KSP development, where the core game went from a crippled wreck to a slightly less crippled wreck every update. But now KSP is a mostly-working product sort of coasting through late development. You don't miss out on much at all being a couple KSP releases behind.

Complex transfers with gravity assists. The game's course plotting is flat-out wrong so much of the time and floating point errors eat up enough delta V in complex transfer schemes that a 10% delta V allowance sometimes ends in mission failure. It's not worth the "cool factor". I've done a few, and now I just brute-force all transfers with a 20% allowance minimum. Edit: And by the way, the trick to transfer to small bodies in very different planes like Moho or Dres is to transfer at ascending/descending node so that the nodes and ap/pe overlap. Then set up a burn at the orbit intercept point to achieve intercept on a second orbit. Optionally correct the planes at the ap. This allows near optimum transfer deltaV to Moho every time with basically no planning. If you really want to save more deltaV to Moho, combine the launch/transfer, and launch directly NE or SE just before Kerbin noon. This way you eat up plane change with the launch stages of your craft and get an Oberth effect boost by starting the transfer burn in atmosphere.

That hard starlink landing resulted in the use of the old deck jacks rather than the octograbber: Some more pics here: https://www.teslarati.com/spacex-rocket-booster-safe-port-return-hard-landing/

Crush cores should bottom out before engine contact.

I think the legs have crush cores and hard stops. If the hard stops are hit, I'd assume booster structure damage would occur before engine contact. Anyone have some schematics?

Sea conditions seemed below average. Not sure any landing code can be expected to deal with barge movement.

Looked like a somewhat hard landing? Haven't seen the legs collapse that much before.

Been trying to track down the problem where contract deadlines are smaller than Hohmann transfer times and failing completely. This is the nature of the contract system. I suspect transient sets of conditions happen in the randomized contract generation -- maybe hasty plus conglomerate modifiers -- which cause this issue. So it causes an unexpected problem a couple times in-game and then when actively seeking the issue, it becomes impossible to track down again. My vote is that best fix for this is just "be careful when accepting OPM contracts". Changing the base modifiers to increase contract deadline time would make it too easy the rest of the time. And near-impossible contracts popping up is nothing new to KSP.

I would have thought its terminal velocity was pretty high between 100km and 15km though. I guess it really must float down like a leaf.

In stream description: "Approximately 45 minutes after liftoff, SpaceX’s fairing recovery vessel, “Ms. Tree,” will attempt to recover a payload fairing half." Does this make sense? Are they trying to recover in the Gulf of Mexico after a full orbit?