K^2

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.

The numbers look great. I just don't know how much difference it will make on KSP1. That game's really badly optimized to use multiple cores. It basically runs as fast as the fastest thread you can give it, so I don't think 12th gen will make a lot of difference. Though, one thing I have to say is that the fact that E cores can take on any of the background tasks means that you should see full turbo speeds on your P cores while running KSP1, so you'll really be giving it the fastest core you possibly can. That's on top of 12900K being a little faster thread-for-thread than 10700K to begin with. So I'm sure you'll see an improvement. It just won't be as much improvement as it can make for other games. Hopefully, including KSP2.

To be fair, I can see a world where it has a problem running KSP2 under Windows 10. Gen 9 consoles run 8/0/16 (P/E/T) core config, and 12600K is a 6/4/16. A game optimized for a gen 9 console will have workload spread across 14 performance threads of the 7 cores that are usually available to the game. So on 12600K, that means at least two threads ending up on efficiency cores, which can royally screw up frame timing if they aren't scheduled properly. And scheduler that can properly distribute work between P and E cores is a Windows 11 feature. So some games that are well-optimized and still push PS5 processor to the limit can struggle on 12600K under Windows 10 simply due to scheduling issues. This might get addressed with a future Windows 10 patch, or maybe 12xxx owners will just have to accept the awful UI of Windows 11. That said, KSP2 is a Unity title, so I highly doubt the core load is going to be anything remotely that even. So long as your main and physics end up on P cores, which it really should even with W10, I think you'll be fine even if some game threads end up on E cores. In which case W10 or W11 shouldn't make a difference, and 12600K will do just fine either way. So it's probably a moot point anyways. And yeah, if 12600K can't run KSP2 well, then neither can the consoles. So we really ought to hope. We've seen examples of some techniques that are generally VRAM hungry. This is why I specifically call out volumetrics, like clouds and such, and procedural vegetation. Vegetation placement, for example, looks a lot like technique used by Horizon Zero Dawn, in which case, it's a GPU placement based on multiple additional density maps that have to be in VRAM. And any sort of volume rendering techniques take up a lot of memory. And this is on top of the planet surfaces, which will require LoDs for absolutely everything. And I wonder if Intercept will end up using virtual textures to optimize that, which will eat up even more VRAM. I haven't seen anything to absolutely confirm the latte, mind, but it would be a good idea, and it is something recent versions of Unity support. What might allow KSP2 to run on a lot less VRAM is if some of these features can be disabled or allowed to run at much lower resolution. E.g., the shadow map cascades look way higher resolution in KSP2 than KSP, but also, it is something you can, at least in theory, tune to the capabilities of a particular graphics cards, and you'll simply have slightly worse-looking shadows. I honestly don't think that's happening anymore. They'd have to do a full back-port, potentially cutting a lot of features. By late 2022, I'm not entirely sure it will be worth the effort. Yes, I know there will still be a lot of PS4 and XB1 players out there, but given that KSP2 isn't going to be sold as many copies as some more popular title, I don't think it will be enough to offset the costs of back-porting. I fully expect KSP2 to ship as a gen 9 title. Even XB Series S support is a big question.

Core i5 has been around for over a decade, so there are a lot of CPUs in that category. A 2011 Core i5-2500 will certainly not run KSP2. On the other hand, the latest entry in that series, Core i5-12600K, outperforms CPU in PS5, so I would hope it will have no trouble running KSP2. In between, there is some gray area. Similar situation in graphics, except 1GB is not a lot of VRAM. I actually suspect KSP2 will want more than 2GB due to planet textures, atmospherics, and procedural vegetation. But also, it will almost certainly want DirectX 12 features. So a lot of older GPUs are going to be out just on that. A good starting point is to look at gen 9 consoles. PS5 has a CPU very similar to Ryzen 7 3700X and a GPU somewhere between Radeon RX 6600 XT and 6700XT. It also has 16GB of RAM, but that's shared between CPU and GPU. So a system with 8GB of system RAM and 8GB of VRAM on, say, RX 6600 XT should be very close to what you get on PS5. I wouldn't recommend this as an actual build for this game, but it's a good place to start the conversation. Of course, KSP2 is likely to be much more forgiving of graphics than CPU, so you can definitely get away with an older graphics card. It's hard to say where the cutoff is going to be, but if we go with DX12 feature set, you are looking at GeForce 600 series or Radeon 7000 series as hard cutoff. But these came with little VRAM and are rather slow by modern standards. Depending on how much you can tune down the settings, the lowest I can imagine it going is GeForce GTX 960 or Radeon R9 380, both of these at 4GB of VRAM. On the CPU side, I think developers will be coming close to the wire on console specs, with PS5 being the bottleneck. In that case, you don't want to go far bellow PS5 caps. That would mean aforementioned Ryzen 7 3700X or Intel Core i7-10700K. There is a bit more room to breathe with newer chips. As I said in the opening paragraph, Intel's 12600K should do just fine, and so will Ryzen 5600X. Both of these are at a lower price point now than the older alternatives mentioned. That said, these are still mid-high CPUs, so I do hope the game runs on lower spec or it might leave a lot of people unhappy.

Note the sin/cos flip on X/Y coordinates and the fact that 0° heading points along Y because of it. This allows it to be right-handed with Z-up while heading still runs clockwise. Effectively, the reflection across X=Y plane compensates for the reflection across the XZ plane that you get from heading running clockwise, which introduces the sign change for the Y component. Net result of these two reflections is a 90° rotation, so that heading of 0° ends up along Y instead of X. Which, I mean, Y might as well be North, right? So this is a bit unconventional in terms of notation, but perfectly serviceable.

z = sin(pitch) Also, keep in mind that this assumes that you are using the local XYZ coordinates with respect to which pitch and heading are given. It will mean that your Y axis points North, X points East, and Z points to Zenith. This is fine, if these are the coordinates required, but might need to be adjusted for a different convention. If your coordinates are relative to SoI, however, with Z or Y always pointing along the planetary axis, then you'll have to adjust the transformation based on where you are located. It's significantly more math to transform from local pitch and heading to SoI XYZ coordinates, so @Cannon if that's the conversion you need, please reply or mention, and I'll give you the steps. It's just too much to type out if it's not what you're looking for.

Unfortunately, this doesn't refine timing better than "Some time in '22," that we already know, but it is a good indication that T2 isn't foreseeing any further delays.

Everything that becomes a cloud of debris above the orbit of ISS will eventually be on the path of ISS as the orbit degrades. Orbital mechanics doesn't take bribes. This will put ISS in the hazard area within a few years. The debris cloud should disperse by then to make the odds of impact low, but there is absolutely zero way to predict or avoid this danger now.

If I present my comments in the language they are streaming from me right now, I'll get banned from the forum. *deep breath* This was among the most irresponsible things done in space in the recent history, maybe all of history, of space flight. Keep in mind that general vicinity of debris cloud from 500km impact is guaranteed to cross paths with ISS eventually as their orbits degrade. The odds of an actual impact are still on the low side, and since larger debris are tracked, ISS will likely be moved to avoid the highest risk areas, but the odds that ISS crew will have to deal with puncture holes in the hull in the next few years has gone up by orders of magnitude from this event alone.

Gravity is a phenomenon caused by curvature. If you stand inside a rotating room, it seems like there is a force pushing you out from a center. In fact, if you describe dynamics from perspective of coordinate system attached to the room, you actually have to add this term as an external force to make the math work. Likewise, if you are in an accelerating car, a similar kind of force pushes you into the car's seat. These are inertial forces, also known as fictitious forces. A bit of a terrible name, since they technically work the same way as absolutely any force, and therefore aren't any less real, but we're stuck with this historical terminology. Gravity is such an inertial force. The thing that makes gravity special is that no choice of coordinate system makes it go away. If you describe a rotating room from a non-rotating coordinate system, centrifugal force goes away. Instead, you have wall pressing into you to keep you going in circles. Likewise, a car's seat has to press into you to keep you accelerated along with the car. You can't make gravity disappear from your equations of motion in the same way. You can choose a coordinate system where gravity isn't experienced locally - like if you are free-falling, you don't experience gravity. But the fact that ground is rushing to meet you at an accelerated rate suggests that gravity is still there, plotting your demise on the global scale. This is because of the space-time curvature. In flat-space time, which, technically, only exists in school physics problems, we can choose an inertial coordinate system that makes all fictitious forces go away - no gravity. In curved space-time, in general, that is not possible, and we call the force that accounts for this curvature "gravity". The source of curvature is stress-energy tensor. That is a generalization of energy and momentum densities to arbitrary coordinate system. People often casually simplify it to just saying that energy causes gravity, but it's really energy, momentum, and how they flow that all together influence the curvature. In practice, though, unless you're dealing with something very exotic, like a neutron star or a black hole, or something very large, like clusters of galaxies, you really can reduce it to just how much energy there is. And if you want to get super technical, it's not even that the stress-energy is directly causing the curvature, but rather that the stress-energy is the conserved current of the Poincare symmetry, which is the extrinsic symmetry of the Lagrangian, and is therefore the source of the gauge field, which happens to be related to the metric tensor, which determines the differential curvature. But that's, like, some years of lectures in a sentence, so I hope previous paragraphs provide you with some intuitive sense for gravity and curvature.