dmsilev

Honestly, the reaction of the community is going to depend on how well you live up to the "sharing more" part of this. I'm sure you've noticed the deep concerns that many here have expressed about the lack of communications from the dev team, so please, don't screw this up.

(a) Not sure what this has to do with mods (b) The Coriolis force is a fairly subtle effect and to see it with a rigid body falling straight down, you have to be awfully close to "straight down" with effectively zero starting velocity (otherwise you get swamped by your residual horizontal velocity). How are you testing? What exactly did you see?

For #20, let me chime in with feedback to say that this behavior should be changed to allow placing nodes in other SOIs. Sure, for some things (e.g. circularizing after arriving at a destination) it's no big deal to plop down a node after the ship has entered the SOI, but there are definitely times when you want to plan out a mission fully in advance (gravitational assists, for instance) and you can't do that if nodes are limited to the current SOI.

The devs haven't said yet. Which doesn't mean all that much; typically they don't give a huge amount of advance notice before the patch. Could be a week from now, could be a few weeks, could be longer... I think they've been averaging a patch every 6 or 7 weeks roughly, and 0.2.1 was right at the end of January, so if I'd have to guess I'd say another couple of weeks. Just a guess though.

Again I would urge you to do some background reading on the IRL history of astronomy. The first exoplanet to be discovered orbiting a main sequence star was 51 Pegasi b, which was found by a ground-based observatory. Quoting from that Wiki page, That’s just one example; there are a plethora of others. Yes, in many ways it’s better to use space-based platforms to search for and study exoplanets (see, for instance, the Kepler mission), but it’s absolutely incorrect to say that it can’t be done from the ground. Also, it should be noted that the devs have said no warp drives, wormholes, or similar will be in the stock game.

I’m not sure I understand what you’re getting at. The cost of a plane change is proportional to the orbital velocity of a craft, so for a given change of inclination, it’ll be cheaper to do it at high altitude than at low simply because the velocity of a high orbit is lower. The spin of the underlying body doesn’t have any effect. Put another way, consider a craft in an elliptical 90 degree inclination orbit, with PE and AP at the equator. The dv costs to switch to a 0 degree (aligned with spin) or a 180 degree (anti-aligned with spin) orbit are the same, but doing the change at periapsis costs more than at apoapsis.

Also worth noting that in IRL, serious astronomical instruments didn't get launched into space until well after we were sending probes to other planets. For the visible-light band, Hubble was just the second astronomical telescope and wasn't launched until 1990 (there were of course some serious telescopes in orbit that were pointed down towards Earth much earlier....). Frequency bands that can't be seen from the ground, x-rays and gammas and so forth, saw much earlier space-based instruments (late 60s or thereabouts), but nobody was looking for moons around Neptune with an X-ray detector. Moving from IRL to the game perspective, it might be reasonable to reduce the visible detail of topography of a given planet until the player sends a probe into the SOI or to orbit (or something more in-depth like ScanSAT in KSP1 and Orbital Survey in KSP2). But that's a far cry from saying that the orbital parameters can't be determined from the ground. (Wikipedia has a nice list: https://en.wikipedia.org/wiki/List_of_space_telescopes . Short version: First gamma detector was 1965, X-ray 1970, UV 1969, visible 1989, IR 1983, Microwave 1993. Of those, UV, visible, and IR would be potentially useful for studying in-system bodies)

Doesn't the "overlay survey image onto the regular map mode" function give you most of the functionality of the second request? I guess that doesn't give the legend identifying the different science regions, but other than that?

Yes, definitely agreed. I would frame the broader question of progression this way: Once the player has demonstrated the ability to do precision landings on both moons, what are the reasonable next steps? Two things come to mind: Either go further out in the system or build bigger things locally. For the former, a basic "get to the next nearest planet" mission is the obvious next step. The latter would be a mission sequence of rendezvous->docking->space station assembly. I think ideally both mission lines should be in the game, but it makes sense to prioritize the exploration line with the initial set of missions that we got with 0.2.x.

The current sequence isn't quite "the easiest interplanetary mission". Not only do you have to get a craft to the Duna system, you have to land something on the surface. That landing has to be extraordinarily precise, or you have to design/land a rover or you need to spend however long it takes to walk a Kerbal to the (quite small) target zone. There really should be an intermediate mission, similar to the ones already in the sequence for Minmus and Jool, where the goal is just "get an orbiter to Duna with a good antenna". If, in a future update, there's some sort of planetary-imaging/mapping part, require that as well. That gets the player to learn about interstellar transfers and so forth. The craft itself isn't that much of a size/capability leap from something that can go to the moons; the hard part is in the mission planning. Once the player has managed that, the next step adds in the landing requirements. The interplanetary maneuvers are the same, just with a bigger craft, and then there's new stuff to do upon arriving at Duna.

You mean the sample arm? I had that unlocked before sending out the wave of probes; all of the landers I built had one. One-way missions using it don't have the same sort of rewards as an actual sample-return mission, but do yield some science. Haven't decided yet whether I want to do probe-based return missions or crew-based as a next step, but the point I'm making is that I'm not feeling limited by the tech tree and points availability, at least so far. Did find it odd that the medium-class SRB is located all the way at the exit node to Tier 2, so strap-on boosters are really really pointless for pretty much all of Tier 2, but other than that, seems ok to me.

I'm a "probe" guy, at least as far as getting started with interplanetary missions goes, and I'm not feeling "yikes" at all. I did the mission sequence as far as the Minmus Monument and hit the major biomes on both moons with crewed rockets, and then switched to probes. Tier 2 gear is enough to send orbiter probes pretty much everywhere, plus some landers; having orbited just a few planets (Duna and Moho so far, with probes en route to Jool and Dres) is enough to basically finish Tier 2 even without doing any sample-return missions. Once those are done, I'll think about crewed missions.

At least for moons, that can make sense. Consider going from Minmus to the Mun, or between moons in the Jool system. That's functionally the same as transferring between planets, and indeed in KSP1, the MechJeb transfer planning code handled the inter-moon case as well. Timescales are shorter since the relevant period is the month rather than the year, but that's about it.

That was a very nice presentation. The one thing which I think was missing given the "101"-level scope is more about the benefits of staging and why it works. It was mentioned, but only as a sort of "oh, by the way" at the end. Since you go through the math of the rocket equation, showing how staging changes that math isn't that much more of a leap to make, and it'd give that section the same level of depth as the rest of the presentation. Oh, and just for the sake of nitpicking, the correction needs correcting:, liquid helium is 4.2 K (and regular LOX is roughly 90 K, not the hundred and fifty or thereabouts mentioned in the vid). Both numbers the one-atmosphere boiling point.

A few degrees worth, so not a huge amount of dv. The real advantage was that the timing worked out to be able to use a Tylo flyby to take care of the vast majority of the cost of insertion into the Jool system.

Thanks for the testing. What I ended up doing was similar, time-warped to near the beginning of the window, use the 'as soon as possible' plus some manual tweaking, but didn’t worry about getting an actual intercept on the departure burn, but instead manually dropped a maneuver node at the ascending or descending node and did some manual tweaking there.

Saw some behavior I didn’t quite understand, maybe it’s me or maybe it’s a quirk of the system. I put a ship into LKO and asked for a node for a Jool transfer at the next available window. The universe time was around year 1 day 160-ish and external transfer-window calculators said that the next window was about 35 days later. The 'next transfer window' indicator field in FP said the same thing. However, when I clicked the make node button, I got a departure time that was in the window after that one, a year and change later. At least according to the external calculators, the later window is slightly cheaper in dv (by about 100 or so m/s), which I guess would explain why the solver preferred that solution, but in that case shouldn’t the indicator also show the later date? And, as a possible feature request in lieu of a full porkchop plot interface, could we be able to ask for 'best node in a specified date range' or similar?

You don't have to follow the mission tree to get science. Send some orbiters or landers to Duna and Eve and their moons. Visit Dres. All of that is doable with Tier 2 gear of the sort that you should have after doing the "mainline" Mun and Minmus missions. Once you've gotten some practice landing things on Duna, you can think about doing a precision-ish landing of a rover near the waypoint for the mission and doing that one. The Chonker is currently just a for-excrementss-and-giggles; the (science) return on investment is tiny.

For landing in a vacuum, the optimal approach is a "suicide burn", where you do a de-orbit burn, coast until you're almost at the ground, and then brake all at once, coming to an exact stop at exactly 0 meters above ground level. That's ...challenging to do by hand, though people have certainly done it, so a safer approach is to plan on coming to more or less a full stop 1 km or so above the terrain (set nav ball to surface retrograde, burn until velocity is nearly zero), then switch to Surface Up orientation, do a controlled fall, and bring the velocity down as you get close to surface. How slow you fall depends on how good a feel you have for your ship's acceleration when you ramp up the engine. Faster with a single sharp burn at the end is more efficient, but slower can be easier when you're first trying. For getting home, an elliptical orbit is fine. Just set the PE to be a reasonable depth within the atmosphere and you won't even need the retrograde burn. Doesn't hurt to burn off any remaining fuel to bleed off speed just before reentry, but it isn't necessary. Asparagus staging is definitely still a thing in KSP2. Set up a central core (tank and engine) with three radial decouplers. To each decoupler, add a fuel tank, an engine, a nose cone, and a fuel line going from the outer tank to the central one. Finally, under staging, have the first stage be all four engines, the second stage be the radial decouplers, and the third stage the central decoupler for dropping the central stage.

If you don't mind using a mod, the Science Arkive add-on lists all of the science regions for each body. Optionally (turned off by default) it lists the discoverables as well, though not their locations.

Thank you for this mod. KAC was a must-have in the first game and it’s great seeing someone carry the torch forward into the KSP2 era. I did run across a couple of bugs tonight, mostly minor annoyances rather than anything critical: The Timer and the Universe Time options both seem to do the same thing, create an alarm the specified distance relative to the current game time. As I understand it, UT should be absolute and T should be relative. Sometimes, when deleting alarms with the X icon next to the alarm, multiple alarms get deleted. 'Sometimes' is pretty vague I know; if I can find a definite pattern, I’ll update, but I definitely had it happen more than once. When typing in a custom name for a fixed-time alarm, keystrokes seem to both enter text and get passed through as flight commands. Mostly harmless, but pressing either shift or space is …not ideal. I ended up switching over to the VAB space to create alarms with custom names, rather than flight.

By the middle of the 19th century, we knew the masses of the planets precisely enough to realize that there was an inconsistency in the observed orbits that couldn’t be explained, most notably in the precession of the perihelion of Mercury. Mid to late 19th century astronomers tried to resolve this issue by looking for an additional planet even closer to the Sun, but by the end of that century observations and especially advances in photography had pretty much ruled out that possibility (or at least had set a fairly stringent upper bound on the possible size), and ultimately Einstein's development of General Relativity provided the answer. Point being, we knew a lot about the planets of the Solar System long before reaching the 'can send sounding rocket to edge of atmosphere' tech level of the game's starting point. A KSP2 starting-node rocket is in the rough ballpark of a V2, so if you want an equivalent to Earth, ask about the level of astronomical knowledge at the early 1940s.

The K2-D2 mod has a 'fly gravity turn' mode. I’ve only tried it with fairly simple craft, but for those it made orbit reasonably well. Compared to similar functionality in KSP1, I think both MechJeb and BetterGravityTurn were more efficient at launching, but it’s a matter of degree, not a huge difference.

The problem with mapping the process of real-world space science to a game is that the loop is inverted. In the real world, the process goes (roughly) identify scientific goals-> perform engineering research and development to build spacecraft/rovers/whatever that can carry it out -> launch ship and make the measurements. The gameplay progression step, of acquiring the new parts etc., happens before the flight, not after. Sure, the engineering experience of one flight can sometimes feed into others when there’s a direct sequence (e.g. the progression from Sojourner to Spirit and Opportunity and finally to Curiosity and Perseverance), but that has little to do with the experiments that are run and in any case learning about how to operate Mars rovers tells you very very little about how to design an unfolding sunshield for the JWST. How do you you translate that in any reasonable way into a gameplay loop, especially in an open-ended game? Sure, you could have some sort of budget-ish resource where missions are proposed or accepted, granting R&D points to enable the necessary techs , but what happens if the player chooses poorly or just decides to use the Duna lander budget to go visit Dres instead? If NASA tried that in the real world, there’d be a lot of people in a heap of trouble, but dragging the player off to jail for misappropriation of funds doesn’t seem like it’d fit the Kerbal Way.

I think some people have lost sight of the fact that the tutorial in question was the very very first one in the series. It covered yaw pitch and roll, and the keys to push to enable those actions. Things like that. Of course it comes off as very basic. That's the intent. Has anyone posted video of an in-game "go to orbit" tutorial yet? That'd be a better reflection of the level of audience that the tutorials are aiming at.