K^2

Helios makes their own He3. They can run the reactor in D-D mode that produces very little power output and spams neutrons, but produces a mix of hydrogen, helium-3, and tritium as its output, which are all easily separable. The tritium decays to He3 after a while, so they basically have their own supply. Their goal is to run the D-D cycle energy neutral on a separate machine with lower field strengths, and therefore, cheaper parts to replace once they start suffering damage from neutron bombardment. But even if they have to go complete energy deficit on that to go even simpler and cheaper on the components, the energy production on the D-He3 cycle is high enough to easily eat that cost. This also lets them split the production facilities from power generation facilities, which don't have a lot of infrastructure overlap besides storage, and would let them carry the He3 production in more industrial areas, while taking power production (which is now neutron-free, and therefore exceptionally safe) closer to residential areas where it's needed. Note that this means that the input fuel is just deuterium, which is by far the cheapest viable fuel, and since you don't rely on neutrons for energy production, you can capture them with much cheaper shielding material that can be designed to produce no long-living radioactive waste. Something that's just flat out impossible with Tokamaks. And while aneutronic, like proton-boron might be even cleaner and safer, it's not a fully proven concept, and boron-11 is way harder and more expensive to source as fuel than deuterium is, both because boron isn't nearly as abundant (though not scarce, which is nice) and because separating B10 from B11 is far more costly than purifying heavy water. They really thought this through to the point where the disadvantage of He3 requirement starts to look like a key advantage of the system. And I would be way more skeptical of this if it was still just an on-paper concept, but Trenta shows what can be done with this, so I'm very much looking forward to the Polaris and power production. This is the only fusion technology that has been shown to have a chance of being commercially viable by the end of the decade, meaning it's the only one we have right now that's actually positioned to make a difference in the fight against the climate change.

I'm sure you're aware, but in case someone needs to hear this, when going for a high end CPU like that with plans to utilize it to the full, make sure you pay very close attention to the motherboard specs and cooling. Either find a water block that is designed to cover both your CPU and the power distribution on that specific mobo or get separate blocks for your power MOSFET banks. Among the worst experiences in custom PC building is giving a Pikachu stare to your 50°C CPU that's thermal throttling, because your stock MOSFET heat sink is hot enough to boil water. Also, I'm really curious what sort of performance you'll get with that OC (I presume?) 13900KF with KSP2. So keep us posted once you have that upgraded and set up.

I have no affiliation with Squad or Intercept, but you need very similar code for camera in a lot of games, and I have worked on that on a few projects. First of all, you need to know how your asset is set up. I'm also going to assume we're going for a 3D look, rather than a similar 2D display used on some aircraft, so you have an actual 3D model, which is a sphere with all of the graphics textured onto it. For the sake of an example, lets say we're working in Unity and you want the compass model to be level with horizon and pointing North in its Identity orientation. That means you'll have 'S' painted on the +Z direction of the model (since you're looking at a sphere from -Z in its identity state), 'W' on the +X direction, and Y will be the up for the model. You can work with any other convention, of course, but I'm going to assume this one with the vector math below. Your second point of reference is your craft. Again, there need to be a set of orientations. This will be different depending on how the capsule or probe core is oriented, so it doesn't really matter how that aligns with craft's XYZ. What's important, is that there will be a strictly defined Forward axis, which I'll denote as F, and an Up axis - U. We can also always get the side axis, which in a left-handed coordinate system (Unity) will be in the S = U x F direction. Finally, you need to know where the craft is. Internally, KSP stores this in cartesian coordinates r = (x, y, z) and while this can be converted into polar coordinates with some trig, you really don't have to to make the compass work. So now we can define the problem. You can picture the compass as being a physical object at craft's location. It floats in an imaginary fluid such that its Y direction points away from the planet's center and Z points North. We can define these directions. First, observe that radial direction R = r/||r|| - so just normalize craft's position. In KSP you don't have to worry about ||r|| = 0, but you might in some other games. So keep in mind that you'll need to handle this. Second, the North direction is parallel to the surface (so perpendicular to R) and in the direction of planet's axis (by astronomical convention). Call planet's axis A. Then the north direction N = A - R(A*R) / ||A - R(A * R)||. That is, we take A, subtract component of A along R (so that the resulting vector is perpendicular to R) and then normalize it. Note, again, that you might be dividing by zero if R and A are parallel. This happens at the North or South poles and you have to figure out what that means in your game, just like for the ordinary compass. At this point, we basically have orientation of our imaginary compass in the world coordinates. I'm going to denote these with primes, so Y' = R = r/||r||, Z' = N = A - R(A*R) / ||A - R(A * R)||, and because X' has to be perpendicular to both of these and give us a left-handed coordinate system, X' = Z' x Y'. If you wanted to draw the compass inside the cockpit of this spacecraft, you'd be done, because these are body axes in the world coordinates, meaning the world rotation matrix for your compass would be (X', Y', Z')T in row major notation. Or, in other words, X', Y', and Z' are your rotation matrix columns. But if you want to show this on HUD, there's an extra step. Instead of rotation relative to the world, we need rotation relative to the craft. Namely, we want to know the rotation whose inverse will take Z' to F, Y' to U, and X' to S of the craft coordinates. The simplest way to get this is also with matrices. You can take the matrix (S, U, F)T, which might actually be just the rotation matrix of whichever component you're using for "Control from here" on that craft at the moment (or it might need some adjustments, depending on the conventions the game uses - it's always worth to check to see if the Forward/Up are indeed defined this way.) In either case, what we're looking for a transformation matrix M that satisfies (X', Y', Z')T = (S, U, F)TM. The logic here is that if we transform our compass relative to the screen, then transform the screen to align with the craft, the compass on our HUD will match orientation with compass in the cockpit, which is the left hand side of that equation. Multiply both sides by inverse of (S, U, F)T on both sides, and keeping in mind that for an orthogonal matrix the inverse is just a transpose, we get M = (S, U, F)(X', Y', Z')T, and that's the rotation matrix you need to set up on HUD compass for it to have the correct orientation. The precise math above makes assumptions that we're dealing with a game where you're always in one SoI or another, meaning there's a precisely defined "up" direction and "north" direction. This might not always be the case for some other games, and then you'll have to do a bit more work to figure out what exactly that means for your compass or any other world navigation display, but the logic is the same. See where the "up" and "forward" orientation of each relevant object is, make matrices out of these, and then multiply/divide these matrices until happy. It's good to work this out on paper to see if you see any optimizations or potentials for division by zero. Otherwise, though, the logic is always going to be roughly this.

You definitely want to be in alpha at least a couple of months before going Early Access. Technically, you can still be in alpha during EA, but you should be at least progressing into beta. I briefly got excited about the flashing lights, thinking it implied scripting, but we've had anticollision strobes with customizable colors in KSP, didn't we? It's probably just that then. And looks great. Really shows off what you can do with new pain customization. Love it.

If your temperature is high enough for atoms to come apart into protons and neutrons, we're not talking plasma anymore.

There are dynamically quasi-stable orbits near L1-L3. That's good enough for a lot of tasks.

The only thing you can do with neutrons is absorb them. I think, the goal here will be mostly to try and reduce the hazardous waste. The energy lost to neutrons isn't that high compared to Tokamaks, where that's the main energy output. So absorbing them safely without making secondary radioactive waste is the priority. I'm sure there will still be a good amount of heat produced, and there are definitely industrial uses for this. There are a lot of places in the world that still use the hot water from power plants (or even server farms these days) to heat residential areas. But even if helium production is going to be purely at a loss, that's still a lot of energy produced on the working reactor.

Helion just told NIF to hold their beer. Wow. If they can actually get power generation from Polaris in 2024, that's going to change the landscape of nuclear fusion completely. There are definitely big unanswered questions, but between what Trenta demonstrates and what they have planned for Polaris, this is closer to a commercially viable generator than absolutely anything that has been attempted or even seriously suggested in the past. It's also noteworthy that it's one of the very few generator types that aren't just a steam turbine with a fancy heater. That has huge implications in miniaturization if we can get stronger field strengths with faster coils, perhaps with hybrid magnets. This is all very exciting.

Whether or not gravitational constant changed is kind of debatable, because it's really not relevant to how the game works. The factor that the developers have explicitly set for the planets is the gravitational parameter, and that was just tuned to make surface gravity whatever it needs to be. Whether you want to think of Kerbin as ten times denser than Earth or if the gravitational constant is ten times higher is entirely arbitrary. For KSP, the former was chosen as convention, simply because we need a convention, but there is no reason why it can't be the latter for the KSP2. But also, gravitational constant and speed of light can scale independently. You can think of the two as linked from the gravitomagnetic perspective, but then you have a gravitomagnetic permeability to play with as a free parameter. So in either case, you can set the speed of light to whatever you want independently from the gravitational constant. The only difference this will make to physics is on how the gravity waves interact with matter and things like frame dragging, where relative velocities of exceptionally massive objects play a role. Since KSP2 certainly isn't going to do any GR effects, the connection is irrelevant. These are basically two independent constants. So I don't see any strong reason to assume that KSP2 speed of light is c, let alone whether we're using Earth year or Kerbin year for a light year as a distance measurement. Both 3x107 and 3x108 m/s would feel right to me, and I would be leaning towards Kerbin years for light years, which gives us a significant range to play with. With Kerbin year being about 1/3 the duration of Earth year, this could mean light years being as much as a 30th of what we have in the real world. Which puts quite a spread on what could be meant by "4 light years," and while talking about what we'd prefer to see in the game is an entirely valid discussion, I don't know if trying to guess the actual interpretation is worth it. We'll just have to wait until we have some more info, or at least another clue to compare with this one.

A custom loop is also fun to build. There's nothing wrong with making your computer be a little extra, even when you might not be pushing it to the kind of limits where it's absolutely necessary.

I have a feeling we're getting something greatly simplified for the Rask and Rusk system. (Aside, can we all just agree to call it the Risk system? I'm just going to do that.) A very simple way to handle a system like that is to have an SoI with a custom attractor in the planets' SoI overlap and at the opposing outer boundaries acting as L1-L3. That would let you place things in halo orbit, do low-energy transfers and captures, etc, without breaking the underlying assumptions the game has to make about everything being on-rails. You'd have to be a bit cheating about the attractors themselves, but a cylindrical symmetry with harmonic attractor in the radial direction and a very weak harmonic repulser in the radial direction is probably close enough. That way there is still an analytical solution to the trajectories in the Ln SoIs that would let you set up a quasi-stable halo orbit, and the capture trajectories passing through these will have the characteristic "spiraling in" movement. It's simple. It works with everything else in the game. It's good enough for Risk system. I would imagine something like this is what Intercept has gone with.

I'm sure there will be mods for it. Adding influences of additional bodies might actually be very straight forward, as engine thrust under time warp is a thing in KSP2, apparently. If that's handled in a clever way, you might just add gravity of relevant bodies as "thrust", and let the game's simulation deal with it. Hopefully, the game handles thrust as a change to orbital parameters directly, rather than converting to Cartesian, applying forces, and converting back, which is what KSP did, and which is why there's so much jank around stability. Small errors in Cartesian can result in orbital elements bouncing all over the place. Whereas, if you compute the deltas for orbital elements directly, then small errors remain small. If KSP2 does the latter, this might work out of the box. Otherwise, precision will suffer greatly once you go beyond something simple like Kerbin-Mun transit or switch to high time warp. The problem is that either way this won't work at all with game's trajectory planning without some heavy modding there as well. So it will be consistently very wrong if you just hack in n-body physics. Whether it'd be possible to apply the same fix to the planning is hard to say, because we don't know how it's going to be handled and how the mod API will work with that. tl;dr: I don't know how good a mod like this will be for general play, but I'm sure there will be something for people to play with Kerbin/Mun Lagrange points if they want.

Agreed. The trouble is that even integration around a single body is nontrivial. The moment you go off conic rails, things get complicated. You either have to do perturbation, which is very mathy, or get exceptionally fancy with integration methods - also mathy and computationally expensive. There are definitely ways to make this happen, but it's a whole lot of work.

The mechanical properties of fiberglass composites are very temperature sensitive. It's the main reason why the use cases for that material in aerospace industry are limited.

Yeah, farts are mostly air with some gases mixed in. Some of these are flammable, but it's a questionable mix at a questionable purity and low production. Farming methane-producing bacteria might be an ok way to make the fuel, which is kind of related to all of this above, but even so, I'm pretty sure abiotic synthesis is going to be more efficient and reliable for any colony.

Could be a good avenue for modding. Route planning between bases for various delivery rovers is an interesting problem that's kind of stand-alone from everything else the game is doing. So that could be made into its own system. Players would have to plan a rover around the AI a bit, which is a big part of why I don't think it'd be part of vanilla, but for a modded expansion that seems like a reasonable requirements. I don't know if it'd be viable with interplanetary routes, though. That has a few too many failure modes to make it work reliably.

@magnemoeYup. Hence the 'generally'. Mobile towers aren't likely to be present in quantities to alter the strategic situation, though. So I'm focusing on the prevalent case.

Yes, absolutely. Military uses satellite communication a lot, and civilian use of satellite internet and phones is becoming more common, but civilian use isn't at a point yet where it makes a strategic difference, I don't think. The most common use case for civilian use of satellite phones is for emergencies while far away from civilization, so that's people who live far away from any cities and occasionally some adventurous types who bring them on trips to the wilderness. Most of these will also have very limited data capabilities - it's there to call someone and request help if you're in a bind. For any other use, satellite phones are just too expensive. And the satellite internet is just starting to pick up, and it only makes sense to pay for it if that's basically your only option. So again, mostly places far from any major cities, very scarcely populated. The difference is pretty clear. If you are moving your forces through an area that has any sort of a population, the odds of somebody snapping a picture and posting it to Twitter, Telegram, Whatsapp, or whatever, is basically a certainty. Likewise, any sort of theft from civilian population by your military is going to result in some cell phones stolen and misused. Obviously, that latter bit will happen a lot less in a disciplined army, but I don't think you can get it to zero incidents with any military force. These are things that can still happen with satellite phones, but it's in the category of a limited risk. With cell phones, it's just going to happen, and you have to deal with it one way or another.

Satellites aren't generally used in cellular communication. It's a surface or a subsurface wire connecting the towers, so destroying the towers is your only option. Trouble is, large number of towers and redundancy is a key design feature of cellular networks, meaning destroying cellular infrastructure can get prohibitively expensive.

It apparently also makes an invading army's opsec absolute garbage, because making sure that at least some soldiers don't steal someone's phones to make a call home is nearly impossible, and as these thefts are reported frequently enough, these phones end up getting monitored by the defenders. And having a fix on a phone you are certain is in the hands of the enemy is as good as having the enemy disposition laser painted. Not to mention any leaks that can happen from the contents of the conversations themselves. You can (and probably should) use jammers, of course. And we're seeing these being deployed too, but a jammer itself is a hot target for an anti-radiation missile, so you have to be very careful about where you place them. The jammer is cheap enough to lose this way, but anything near it might not be. And because they tend to be fairly broad spectrum at high power to guarantee that they jam the cell frequencies reliably, they greatly reduce availability of channels and equipment you can use for your own communication. So even if you address the security problem of the phones, you do that at creating new disadvantages for your own forces. All in all, the prevalence of cell phones is a huge advantage to the defending side, and any major military that isn't currently thinking about efficient means of dealing with them in a larger scale conflict are likely to find themselves in a disadvantage should one happen.

That doesn't happen in practice with any sort of noteworthy frequency with modern AIOs. Not the sort of a leak where you'd have to worry about your system, at any rate. Small leaks causing loss of fluid over time do happen, which is one of the failure modes that can happen, typically after years of service. The other, as @Laikanautpoints out, is pump failure. But they'll still typically serve you for years without issues with proper installation and under moderate pump speeds. So the risk isn't really there, and once you get into the price point of AIOs, they usually outperform air coolers dollar-for-dollar. You can also better manage the heat flow. One of the common problems of air blowers is that its' hard not to make your CPU be eating at least some of the GPU heat. But there are a lot of variables there. For the specific niche where they make sense, sure. But it is a niche. So is the AIO, of course. All of this exists in this narrow sliver of space where a cheap cooler doesn't cut it anymore, but you're not at a point where you need to drive a custom loop through the monoblock to manage your thermals on the power delivery. The main point here is not that you shouldn't be spending money on a good cooler. Rather, if a $40 cooler isn't doing the job, and you're eying a $100 cooler, you really should be considering your options. With most configurations and given how most cases on the market are organized, AIO will probably give you the same or better performance for $60-$80.

A low budget AIO can be cheaper than D15, by a good margin sometimes, without sacrificing performance, and because of the thermal mass, it's not going to have to spin up the fans/pump if there is a short spike of load, which happens quite often in a lot of usage cases, which means that AIO can be quieter than a comparable air blower. How much of a difference that makes for you particular case is up to you, and specifics will matter from build to build, but if you're going to drop $100 on cooling and don't at least consider liquid cooling instead, I have questions. In contrast, unless you do have a high end CPU and/or are overclocking, maybe go with a much cheaper air blower instead. Something in $20-$40 range will do for most people in most cases, so long as they have an otherwise good air flow into the chassis. A $100 air blower is kind of a niche choice.

Honestly, at that price point you can start looking at AIO liquid cooling. If your case has a place to drop in at least a 120x240 radiator, there are a lot of decent inexpensive options, and AIO is as easy to install as a conventional cooler.

Taking Sol verbatim would be a lot of work for just an Easter egg and would stick out a little too much if it's prominently placed among the other systems. I think a known exoplanetary system is a more interesting idea. The only problem is that our ability to detect exoplanets is kind of weak, so all these star systems look very barren in comparison to Sol. It's likely that many of them are filled with many more small planets and other objects, plus moon systems around the known planets, but we can't detect these things to make an accurate maps of them. However, astronomers have gotten pretty good at making simulations of star system formation that closely match the known features of a system so that the resulting simulation can be studied in far more details. Naturally, Sol is the main target of such research, but I'm sure there are simulations of other star systems. So if we wanted to have a system in KSP that's pretty much "This is a real system, best we can tell," I'd take a simulation of one of these star systems with known exoplanets and use it to fill in the gaps.

It is not an exaggeration. We don't have a solution. At the scale where you're supporting the country's grid, not having compact storage means you end up having to build megastructures to store the energy. That's not a huge improvement in cost. You basically have gravity storage on one end of the spectrum, LiPo on the other, and everything in between is some sort of a compromise. This is a grand unsolved problem. We do not have a fix for it. If you want to run numbers, be my guest. Chose your favorite method of storage, scale it up to provide several hours of uninterrupted power of some large European country (or US, if you want really scary numbers) and estimate the costs. Then compare them to the costs of nuclear for the same load. We can chase this problem back and forward, but it's really much more constructive if you just do the math once. (I can do this, but you'll just tell me I'm using the wrong energy storage, so I'm letting you pick.) Your own graphs show battery higher than peak gas, which is more expensive than nuclear. And that's before we take into account that the price shown is not scalable to a country size. You really should run these numbers yourself. No, we're very much not. That's why we need nuclear energy. We have to maintain the existing grid and build new capacity. There is no alternative that is currently viable, and there might not be an alternative in a decade. It'd be amazing if some breakthrough in batteries or fusion comes about in the next ten, even twenty years. That would literally save us. But we can't risk it. We have to do what we can with existing technologies. Not stuff that works in the lab. Not stuff we think we might figure out in the future. Our environment cannot withstand significantly more pressure than we are applying to it now. It's already collapsing under the current strain and is on borrowed time. We have to act now, and we have to act with technology we have. With current technologies, we can do 60-70% with wind and solar. The rest has to be geo, hydro, and nuclear, and the former two are situational. Countries that cannot do these, have to go nuclear. Leaving a gap of even 20% on fossils is not acceptable. It was twenty years ago, but we missed that train. If we reduce our energy production carbon to 20% of what we're releasing now, we're still screwed. It's like planning to close 80% of the holes on a sinking ship when it already took on too much water to stay on the surface for very much longer. Zero is the only acceptable target.