K^2

It might be actually be ice. Or some chute packing materials, maybe? I don't think this is indicative of any problem. Ultimate strength of steel can be about 50% higher than that of carbon fiber composite. This is approximate, because "steel" varies a lot, and so does carbon fiber. In contrast, density of steel is 4-5 times higher. So by weight, you need about a third of carbon fiber that you do steel. Again, roughly, depending on the exact materials you use and properties you're looking for. But it's very clear that while it helps close the price gap a little bit, it's still many times more expensive to build out of carbon fiber than steel.

Like, 95% joke, 5% "Wouldn't it be cool, though?" And I seriously think it would be a better startup than Spinlaunch. At least, it aims to do something you can't do with another method better already.

Sort of? But without need for maintenance. Not much of a fountain if you just yeet one piece of infrastructure per launch.

That's it. This is how we do it. A solid or hybrid motor rocket takes off as normal, and we fire fuel for its second burn out of a cannon timed for them to meet at some point during ascent. You get "gentle" acceleration for the cargo, making it potentially viable for human launches, and you still get to avoid building a massive first stage.

The only reason I can think of that this might be slightly problematic is if you want to start keeping track of resources required to adjust orientation. If we are happy with a fiat that the ship at this point has enough authority to adjust and maintain orientation with vectored thrust or what have you, then it's no harder to integrate e.g. prograde hold than a fixed orientation. So long as the direction of acceleration doesn't change much from one time step to another, it's fine.

As pointed out, that's the plan, but I also wanted to chime in to mention that this is actually a very hard problem, which is part of why KSP limited physics warp so drastically. To start with, each craft is a simulated object. Applying thrust can cause parts to flex, changing orientation of the engines, potentially, altering the net force if there are multiple engines working in concert. Even with a good simulation and optimizations, running this at 100,000x might be problematic to put it mildly. If the simulation still runs on PhysX, it's flat impossible. Of course, there are ways to work around that. Likely we'll see craft simulation "frozen" once it settles down and you can then increase the warp to a high factor. In a similar vein, orientation of the craft matters. If your craft is tumbling at a few revolutions per minute, well, your effective time step can't be larger than a few seconds. Again, if you're trying to run simulation at 100,000x for long transfers, this will be a problem. This is another place where we'll probably see orientation frozen, just like it gets frozen under time warp in KSP. Will this lead to players cheating and time-warping ships with unbalanced thrust? Maybe. Though, perhaps, a similar solution will be employed where your ship has to remain in fixed orientation for a bit before you can warp. Then we get into problems that are harder to work around. First, gravity is inherently a hard problem to integrate. Standard methods, even ones that are a touch fancy, like RK4, introduce fairly large integration errors. Even without thrust, an object you are simply integrating as it orbits a planet will be gaining energy. There are very clever methods, like ones used by JPL in their Solar System simulations, that do much better, but it gets computationally heavy and complex. For a game, you can get away with just making sure your time steps aren't too large. And it helps that this is more of a problem when you're close to a massive body, where you usually have a lower warp. Next we have SoI transitions. This one's a bit of a nightmare, as a glancing pass through one can give you wildly different results depending on where exactly you entered the SoI, and if your integration step was too large, you're going to miss it. Worse, as your integration step changes as you adjust warp, your predicted trajectory will jump. It also means that SoI checks are part of your integration routine, and while not terribly expensive, it's significantly more math than each integration step would have been otherwise. So it's going to be a significant CPU hit both in terms of computation complexity and reduced time step to preserve accuracy. Finally, the part that wouldn't be so bad on its own, but which can be a huge pain in the rear if you take all of the above into consideration. What happens if you are flying multiple missions in warp? Even in single player, ability to switch between several probes that are accelerating under thrust would be desirable, so you want to be able to time-warp multiple ships at once. In multiplayer this is absolutely a must. But does that mean you can't go to higher warp on your current probe if another is flying too close to a planet? What if the one you're currently piloting gets very close to something causing everything to drop out of warp entirely? What happens to all the other probes currently under thrust? Does their physics simulation remain frozen? If not, how do you fix any that might become unstable? This is one of these problems that becomes more complex the more detail you consider. And it has to be solved right in order for the game to be playable. So we'll just have to see what happens with all of this. I suspect, we'll have some hilariously broken exploits at the release that will get patched out as the game matures. Hopefully, nothing that will prevent people from having a good time with the game from the start, though.

Getting 2km/s from the ground isn't a stupid idea. Combine it with a skyhook and you can do away with a rocket all together. Spinlaunch just happens to be the worst way to do it.

This is what I'm thinking. I could swear we've seen some publicity images that included only the PS5 and XBSX logos...

If they got along and worked together, which requires the greatest stretch of imagination so far.

There are more mainstream titles where this sort of thing does actually happen occasionally, but I have very little concern for this with KSP2. We might have some features dropped because they are considered too clunky for what KSP2 is trying to be, but it's not going to be a platform problem, but rather just general streamlining. And the attitude from Intercept on this is probably going to be, "This is mods territory." Which is fine, IMO. I'm also sure the bar for this is way, way higher than it would be for Call of Duty or something. When you're building a rocket, some amount of complexity is just part of the game, and everyone involved seems to be aware of it. In similar vein, I have encountered cases where we've had to make changes to content based on contracts with Sony/Microsoft in terms of what can and cannot be supported. For example, if you are releasing a game on PS4, in the past, you had to support all iterations of the console. You couldn't release features that were available on PS4 Pro but not on base model. This has been relaxed somewhat in the recent years, but this has caused cut features in the past. But these rules never included parity with PC. So again, no reason for concern. What parity engineers are usually responsible for is making sure all of the UI is accessible with controller/mouse, that performance is fine, etc. There's usually an entire laundry list of problems that have to be solved. And a lot of it is just having an engineer that works on the off-target platform and keeps track of things that are going in. Not if they only release on PS5/XBSX. The CPU on these is fine for now. Even with using these models as floor, there are going to be so many people whose PCs aren't nearly as powerful. We might actually be seeing the opposite, where the PC is the bottleneck. To be clear, that won't last, as the PC market is catching up really fast, but just now we're in good place for this. Of course, I'm making a huge assumption that PS4/XB1 support has been dropped at this point or will be a cut-up back-port, but not part of the core release. I could be wrong about this, in which case we're going to lose a lot of features from KSP2 to try and keep parity with old hardware, but that's precisely why I'm so confident that this won't happen and PS5/XBSX are going to be the only consoles with the full release of KSP2. Switch from Star Theory to Intercept gives them a PR excuse not to support the older consoles, and I think by '22 the PS5/XBSX are going to be common enough to where it makes financial sense as well.

You have a point, but solving fundamental physics problems tends to be an even less common occurrence than solving seemingly impossible business/process problems. Last instance which surpasses the challenges of spin launch is work by a certain patent clerk a century ago. Yeah, I'm that incredulous about the "engineering" challenges here. We do have a proven method for doing this with chemical propulsion linear acceleration (aka canon), though. With just the pipe of the same length as the spin launch facility diameter, you can have a lower average acceleration over just seconds to get to the same velocity. And you don't have to de-spin the rocket after firing it out of a canon. Plus, even if you have to evacuate the chamber, which might not even be necessary, it's a much smaller volume, so you'd be able to do several launches an hour instead of (maybe) one per day with spin launch.

It's running at a tiny fraction of what you need for ballistic launch. This doesn't scale at all. A cannon launch is cheaper and way more practical in absolutely every single way, including requiring a lower acceleration for a much shorter duration, and we're not even doing these. I'm absolutely flabbergasted that this farce has been going on for this long. I can't imagine any remotely competent engineer signing off on this as anything beyond, "marginally plausible at a stretch." This simply has got to be a scam.

On the tech side, it's not so bad, though, it would likely be a bit hacky with Unity/PhysX without having access to the source. The general outline for something like this is that you start by fully embracing the virtual textures for the terrain. That lets you render decals for both visual materials and the height maps at very low cost. If you do this, a crater can basically be just a decal you apply to the terrain. Next, you want tessellation. You can do small deformations with displacement mapping, but if you want a sizable crater from the impact, you need to alter the mesh. If you start with a low poly mesh based on the original height map, then tessellate using the virtual texture, you'll have geometry matching your newly formed terrain features. Finally, you need collisions to respect the deformations. You keep using PhysX scene to handle crashes, but you replace the line probes for landing legs, wheels, and kerbals with a compute shader that tests against virtual texture directly. What you get is something with almost no performance overhead, but so precise, that you can have large rovers leave tracks deep enough that kerbals would stumble over. This can also be baked into procedural feature generation so that small rocks, tree roots, or any other small features can be applied as decals instead of having to be geometry. This is a bit of work, of course. I can absolutely imagine Intercept not having people with necessary skills to spare on something like this right now. But yeah, maybe it's something we can get in a future update if KSP2 does well enough, and Intercept wants to put some extra shine before some major DLC or something.

Yes, even taking into account the energy required to sublime iodine into a gas, you get lower energy requirement to produce I2+ than Xe+ ions. But Iodine is still going to be molecular in an iodine thruster, so you are looking at about 30% loss of ISP when everything else is kept the same. If you're building something like a cube sat, the low cost of Iodine, the fact that it can be kept as a solid until needed, and lower ionization energy, are probably the deciding factor. And in fact, a lot of the simplest RF-based ions for cube sats are already Iodine based for this exact reason. On the other hand, if you are building something for a long duration interplanetary mission, ISP is generally a greater factor, meaning that you want to go with the lighter elements. And here, noble gasses give you a very significant advantage of being monoatomic. Basically, whatever your specs are, you can probably find a noble gas that matches the profile, but is much lighter than diatomic alternatives. Xenon, of course, being most directly comparable to Iodine, but same can be said about Krypton or Argon thrusters in their own respective categories.

Current openings for Intercept include two writers, two leads (design and SE), two SEII, an SEIII, and a UI/UX. Both of the lead positions appear to be for a next project after KSP2. One of the SEII is explicitly for console parity. So in terms of what they are looking for core, it's the writers, two SEs, and a UI/UX designer. Worst case scenario, if they have to go without engineers and the UI/UX person and outsource some of the writing, this adds up to a couple of months of delay. I don't see anything remotely worthy of concern.

There's a bit of a typical problem when developing environment assets where 3D artists need to have some idea for the layout before they can make good assets and environment artists need assets to create the layout. When making maps, usually, the map artists or designers will block out the environment first, for example, using very simple shapes. Then real assets are placed as needed. With vegetation, blocking things out doesn't work, so the workflow is usually using whatever you have that sort of looks right. Its's not unusual at all to see completely wrong biome plants in the first pass, with an artist responsible for vegetation coming in and using this first part as a starting point to begin making appropriate assets. I don't know if that's really the case here, but it's at least one reason why we might see very boring plants on "Lapat", with the intention being to create something more exotic later. Of course, it could also be just an unused prototype or a testing planet, or any number of other things. Including possibility of a yet another planet with boring green terrestrial-looking plants somewhere. But yeah, I also hope that if there is alien vegetation, it looks reasonably alien.

For hypersonic, you want to go high. At these speeds, nearly all of your engine thrust is fighting ram drag. If you go lower, yes, you get more air to feed your engines, but you need more thrust by the same proportion - and more fuel to go along with the air you're getting. By going high, you need smaller, lighter engines, and you consume less fuel on top of not picking up as much heat. There is no reason to go low, and the further into hypersonic you go, the higher you want to be. Of course, at some point, you might as well skip the atmosphere entirely and go suborbital, but there is a sweet spot at about Mach 5 and 30km of altitude that, at least on paper, looks like it would be fairly economical. There are some design projects for airliners that are meant to operate at these altitudes and speeds, but it's hard to say if they'll actually be commercially viable. On paper, Mach 2 at 20km is also a fantastic sweet spot, with fuel consumption per distance traveled actually quite comparable to modern airliners, but supersonic flight came and went, and it's hard to say if it will be back without some major paradigm shift. So I have hopes but little confidence for hypersonic passenger flight.

You are dealing with low pressure, so it's much harder to generate lift. You then either have to greatly increase the wingspan - the U-2 route, or greatly increase speed - the SR-71 route. Traditional swept-wings are critical for flight in the transonic region. We're talking Mach 0.9-1.1 or so. Airliners dip into that region, so they have to incorporate the swept wing design. Having very long swept wings is impractical, however. So U-2 is limited to lower speeds, around Mach 0.7 in cruise, where straight wings work perfectly fine. In contrast, if your answer to the low density is more speed, then your biggest factor is heating. To reduce heating, aircraft are made long and slender, with sharp points on leading edges and anything else that might have to stick out. There are also considerations for where along the aircraft the sonic shocks form. A shock forming along the surface of the wing can lead to separation and loss of lift and control. I suspect this is a big part of the reason for where exactly the engines are placed on SR-71, but it's getting into nitty-gritty of supersonic physics where I'm not proficient. Not entirely. For one, you have to be more specific about what you mean by strength. If we're talking purely tensile, there's a strong correlation between melting point and tensile strength, but it's hardly 1:1. More crucially, however, materials with high tensile strength can get brittle. So if you're making something like armor, you actually get "stronger" armor by either going for alloys that actually lower tensile strength (and the melting point) or by going with a composite material, where you're going to have two or more different melting points for different components. So it really depends on application.

As much as I'd enjoy there being more to it, sometimes an Easter egg is just an Easter egg with no deeper rabbit hole hiding behind it. Given the new procedural placement for vegetation and scatter they've put together, I think the temptation to fill at least one other planet out there with vegetation is going to be too much. I would fully expect at least one planet with alien plants.

I haven't seen any focused studies either, but based on what we're seeing with volcanoes, etc, while the short-term effect of a global scale nuclear bombardment would be cooling, and idea of nuclear winter might not be far off, long terms is going to be contributing to heating and can easily tip us over into a runaway effect. Roughly, the mechanism is as follows. Normally, most of the sunlight reaches surface and some part of it is absorbed, heating the surface up. Surface cools by emitting infrared, some fraction of which is re-absorbed in upper atmosphere by high elevation clouds and greenhouse gasses. The portion that does not escape to space directly is re-emitted and re-absorbed heating the upper atmosphere somewhat. The surface and upper atmosphere are further in rough an adiabatic equilibrium due to convective currents. So energy trapped as IR in upper atmosphere eventually makes it back to the surface. Normally, heat wouldn't flow from cold upper atmosphere to warm surface, but air currents moving down are compressed by higher pressure, warming up enough to transfer heat to the surface. The effect is called "greenhouse effect," but the direct heating works more like a heat pump. And this is crucial to impact of ash clouds. I don't know if nukes are going to be exactly the same, but ash clouds from volcanoes typically occupy altitudes between 6 to 9 km or so, where temperatures are 40 to 60K lower than at the surface. So step the first, major eruption or series of nuclear explosions took place, placing ash and dust at these altitudes. At first, the impact is rather direct. Sunlight no longer reaches the surface in the same quantities. At the same time, surface continues to radiate the same amount of infrared. The ash cloud, now opaque both in visible and infrared, also radiates infrared, but because it is at least 40K cooler, it sends back a lot less energy. Between the IR from ash cloud and limited sunlight, the net flux to surface is now lower than net flux away from surface. Surface begins to rapidly cool. Depending on coverage, we can be talking about a drop of a few Kelvin, which might impact crop yields, to tens of degrees, which can lead to a global disaster. However, the thing to keep in mind is that equilibrium isn't reached yet. The ash cloud now receives direct heating from the Sun and the infrared heat from the surface, which is more energy than it can emit into space at its current temperature. It starts to heat up. The equilibrium temperature for it is still slightly bellow what normal equilibrium temperature for the surface is, as the ash cloud isn't impacted by greenhouse effect nearly as much, and can only get additional heating due to lower albedo, so if there was no air circulation, the final effect on the surface would still be net cooling, but as I've mentioned above, there is a heat pump effect. In the long term, temperature differential between surface and clouds is fully established by the pressure differential. So as the temperature of the ash cloud starts to rise, so does the temperature of the surface. In the most extreme case of a dense ash cloud with albedo of about 0.6, the equilibrium temperature at 9km will hit 300K. That will put surface temperature at 360K. Close to the boiling point of water. This sort of dense cover is not realistic, but it's a hell of an upper limit, and should give you an idea of the sort of catastrophe that's likely to follow. Climate change as we know it is absolute peanuts to what will happen if we dump enough ash into upper atmosphere to appreciably reduce the amount of sunlight that's coming through.

I'm confident that nothing like this will be part of vanilla game at launch, but maybe we'll see mods. It'd certainly be an interesting experience.

Unless Intercept reiterated that, I wouldn't take much stock in it. While the core concept has remained the same, so many details about how KSP2 should look have changed when development moved to a new studio, that a lot of older concepts might very well have been abandoned. I would imagine many parts have been re-designed, replaced, or simply cut. I think, by now, the original reveal cinematic trailer might as well be considered fan art. I'm sure we'll see a lot of what's there in the final game, but by no means should the trailer be indicative of any final features.

This is now my favorite description of β+ decay and the best thing I've seen today. Thank you. The heavier the nucleus is, the easier it is for it to shed a nucleon. Nuclear matter soup is way more complicated than electron orbitals, but some of that applies here. Most evidently, if you have just two protons or just two neutrons, they can occupy the equivalent of the s0 orbital, which is exceptionally stable. This is why 4He is so stable. As you go to higher atomic numbers, things get progressively more complex. 12C, for example, is shockingly well described as three 4He nuclei bound to each other by atomic forces, which isn't something you'd expect if you were guided by the orbital shell model. But ultimately, Pauli exclusion is one thing you can rely on, and you simply cannot have all the protons and neutrons occupy the low energy states. Some nucleons have to have more energy than others, and that becomes more of a factor as you add more nucleons in. At some point, the easiest way to decay is to simply kick out one of the nucleons that already has a lot of energy. While 2He can decay the same way, the barrier is significant, and energy gain isn't. Again, if you want to know exact branching fractions, you have to do a lot of math, but you can get some sense for it by looking at masses of products. Figuring these out is also a lot of math, but people have done that math, so we can make use of it. 2He - 2.01589amu 1H - 1.00784amu 2H - 2.01410amu e+ - 0.00055amu So we can see that 2 1H is lighter than 2He, but only just. In contrast, 2H + e+ is lighter than either by a more substantial amount. That is, of course, not the whole story. There is also the question of the potential barrier to the decay. The decay to deuterium requires the emission of a W+ boson, because the whole process is actually p -> n + W+ then W+ -> e+ + ν. The energy cost of creating a neutrino is negligible, and the W+ is virtual, but because the mass of W+ is so comparatively high, it's still a relatively slow process. Not as slow as protons overcoming the attractive barrier, however. It is the same barrier that prevents two protons from coming together, and we know that's slow, because this is literal proton-proton fusion. In fact, you can think of p + p -> 2H+ + e+ + ν process to actually include the 2He2+ step, and then subtract the probability of the proton-proton decay from the overall rate. From perspective of underlying physics, the two processes are identical.

It's true that He-2 is not a stable isotope, but your reasoning for why would imply to He-3 and He-4. Adding a neutron does not magically cause repulsion to go away. If anything, it brings protons closer together, increasing repulsion. Moreover, decay mode for He-2, according to calculations, as it has never been created, would not be by flying apart into a pair of protons. He-2, were it to exist ever so briefly, would undergo beta+ decay, where one of the protons kicks out a positron and turns into a neutron. Rather than two protons, what you'll end up with is a single deuterium nucleus. Stability of isotopes is nowhere near this simple, and trying to imply intuition based on everyday experience is a sure way to think yourself into a corner. To actually figure out if something like He-2 is stable you have to take into account such bizarre things as virtual meson exchange. Lots of dense math, and absolutely none of it is intuitive.

We got to "play" with one back at school. I can confirm that they are sensitive enough to detect a difference between there being a student under a desk and not while the device sits on top of the desk. By moving one of these around the vessel, you can get a pretty good estimate not only for the mass, but mass distribution as well. Though, measuring the mass directly with load cells will still probably be more precise until you get to something the size of a naval vessel.