K^2

Hm, that actually made me think, "Why isn't it possible to just keep symmetry as each satellite passes near the center?" And I think this might actually be a consequence of a theorem with the second funniest name in all of the mathematics. Hairy Ball Theorem. Topology, you win again!

The only thing that partially compensating mass with negative energy lets you do is get to higher fraction of c without expending more propellant. It's like a boost to your ISP. So, you know, still great if we ever figure out how to do it and might make a difference between being able to travel between stars and not, but it's not going to do anything nearly as dramatic as you describe.

Well, yeah. If you can make casing strong enough, even a nuke wouldn't explode. But extra casing strength is extra weight, so even when building something like SRB, it usually can't take a lot more pressure than what it's designed for. There's going to be a safety margin, but if the pressure differential is several times higher, it will rupture. There are ways to engineer around that - casing, fuel type, fuel mixture, oxidizer grain size, oxidizer to fuel ratio, bore diameter, bore shape, exhaust diameter... I'm sure you can build an SRB for Venus. I just think any that are built for operation on Earth will over-pressure and blow up. But in any case, you aren't going up from Venus on an SRB. Aerodynamic losses for conventional ascent on Venus are on the order of 20km/s. Given that you are unlikely to scrape up even 200s from SRBs in that environment, it's just not going to happen.

Hm. Interesting thought. Given that masses of satellites can be adjusted, I can take any projection with constant dimensions and give it the same moment of inertia as regular tetrahedron, so clearly, you can't have it work if the distances never change, but I take it that's not your intention? You are suggesting satellites that are in elliptical orbits but stay over projections of tetrahedron vertices at all times? I can't think of any way to prove that it's impossible off the top of my head, especially, if we don't require the center of tetrahedron to stay parked over the center of mass. But also, not coming up with any strategy of how to achieve anything like this configuration. Definitely worth further investigation. I'm starting to think about numerical methods one might deploy to try and find solutions like this. With strict symmetries in place, it's relatively easy to go over possibilities by hand, but once we allow altitudes to change out of sync, feasibility space is quite large, so I think this would require a computer to solve. Moment of inertia tensor is said to be degenerate if all of its eigen values are the same. That also means that you can use any three orthogonal axes as principal axes for the body and they will all have the same moment of inertia about them. For any given moment of inertia tensor, the angular momentum and angular velocity are related thusly, L = Iω. Because in general, moment of inertia about different axes can be different, L and ω don't have to point in the same direction. However, if all axes have the same moment of inertia, then multiplying by I is the same as multiplying by a scalar - it only adjusts the magnitude, but not the direction, and so L and ω are always in the same direction. This is crucial, because while L has to stay in the same direction due to conservation, ω in general doesn't. In the extreme case, this happens. This is called axis tumbling. If we were able to get our tetrahedron to tumble this way, there would be a lot more room to try and come up with motion that matches orbital motion of satellites for each vertex. However, all platonic solids exhibit high degree of symmetry, and from perspective of angular momentum, can be replaced by a sphere without any loss of generality. Once a platonic solid, or anything with the same symmetries, is set to spin about an axis, it will spin around that specific axis without tumbling. So the argument I laid out would also apply to trying to arrange satellites in a cube or regular octahedron, dodecahedron, or icosahedron. There are also some other semi-regular shapes that are symmetric enough to have the same restriction, but that's getting needlessly specific.

Didn't we all agree that an actual space kraken lives at the bottom of Puff's oceans?

Well, no, I've proven it to be impossible for regular tetrahedron. Might be possible with something kind of close, and probably not with anything that keeps distances consistent for the entire period.

Fuel is going to burn faster on Venus due to high pressure inside and exit slower than on Earth due to high pressure outside. That means the pressure differential between the inside and outside of SRB is going to be a lot higher on Venus than on Earth. Now, I am hand-waving a lot of stuff here. Maybe higher density of combustion products will actually allow for higher rate of outflow on Venus, which would allow to maintain a reasonable pressure differential, but I'm very dubious on this. The reason I'm dubious is because runaway pressure increase is one of the modes of failure for SRBs, and if pressure increase actually increased outflow sufficiently, they'd be self-regulating under all conditions, which clearly isn't the case. So I'm still leaning towards the ka-boom. But this might require a simulation to figure out properly. I'm also now thinking if I know anyone with pressure vessel that might let me set off a composite model rocket engine inside... Oh, it absolutely does. One of the key parameters when you are designing a solid fuel motor is the dependence of burn rate on pressure. It's often modeled as an exponent: r(P) = r0 exp(kP). You can some times find these parameters quoted for solid motor composites.

No. It's definitely not possible for circular orbits, and I was thinking that maybe there's a way to cheat with elliptical orbits and some odd rotation for resulting tetrahedron, but it's actually impossible. Here is the proof. Masses shouldn't matter, so we can take them to be equal without loss of generality. There is precisely one arrangement for four satellites that are equidistant from each other, that of a regular tetrahedron. Now, we can't use all the properties of rigid bodies, but because we are requiring that satellites maintain this formation, we do know that total angular momentum of this tetrahedron will be same as if it was a rigid body. We also know that moment of inertia tensor of a regular tetrahedron is fully degenerate. That means that angular velocity vector of this tetrahedron is co-linear with the angular momentum. Finally, each satellite is in its own orbit, so angular momentum is conserved for each one. That means the sum of angular momenta, and consequently the angular momentum of tetrahedron, are conserved. What does it mean? It means that axis of rotation for the tetrahedron cannot change. That means trajectory of every satellite must be a circle around that axis. But we also know that each satellite must be traveling in a plane that contains center of mass of the planet. There is only one plane that contains circles that are perpendicular to given axis and contains a given point. That means that all satellites must travel in the same plane to satisfy our conditions. Since tetrahedron is not contained in a plane, this arrangement is impossible. QED. Keep in mind, above assumes an absolutely perfect, regular tetrahedron. It might be possible to have an arrangement where distances change, and might not all be quite the same, but still gives you a good coverage and is stable over time. This would probably involve one sat in equatorial circular orbit and three others in elliptical orbits with high inclination whose ascending nodes are all 120° apart and whose arguments of periapsis are all the same. These would form one of the faces of the tetrahedron, which will rotate 360° for every orbit. It's not pretty, but if your goal is global coverage, it might be good enough.

The reason pressure inside SRB doesn't go higher is because there's an exhaust opening and pressure outside is close enough to zero. If you are to try that in the Venusian atmosphere, the pressure inside is still going to increase above ambient once the fuel starts to burn. That does, however, present a new problem. Rate of burn of the fuel in SRB depends on the pressure. As pressure increases, the fuel burns faster. High ambient temperature is going to accelerate the burn as well. Since you are already at exceptionally high pressure, and it's only growing higher as combustion products struggle to get out, the burn rate is going to end up much, much higher than on Earth, and so the pressure inside SRB is going to get many times higher than nominal. In short, my fear is that if you try to use a terrestrial SRB on Venus it'll just blow the bleep up. That said, I'm pretty sure that you can adjust the mixture and grain size for a burn rate that will work in Venusian atmosphere. The ISP won't be great, since you wouldn't really have a nozzle, but it should still be decent. Not that you'll end up going very fast or very far, given the density of the atmosphere. Edit: Ninja'd by paul_c.

Zero gravitational mass is what we care about here, but yeah, that's equivalent to zero relativistic mass. For which zero rest mass is a necessary condition, but not a sufficient one, as photons clearly demonstrate.

I don't think that's going to cut it for either category. Game is quite CPU-hungry and gen 9 consoles (PS5, XBSX) have better CPU specs than what you have in "recommended" as far as what KSP will care about. I somewhat doubt we'll see any. Vaguely speaking, unless you go full RT, which nobody does, with hybrid approaches, there are three things you do with RT: soft shadows, global illumination (GI), and reflections. Shadows in space tend to be hard, because Sun is quite far away, and simulating it as a point source is usually good enough. Writing RT shaders for just the few cases where it isn't seems like a waste. We don't have enough interior environments for GI to be worth it either, and on planetary surfaces, good sky illumination shader does the trick just fine, and that will have to be written for non-RT cards anyways. Finally reflections. For planetside, combination of sky map and screen space (SSR) will cover pretty much every case where you'll see something reflected in the shiny. And in space, you already have starscape in the cube map. Just render nearby planets to the same cube map, and you basically have perfect reflections for free. KSP2 is just not a good use case for RT. In a few more years, I suspect there won't be enough non-RT cards left to bother with, and then it might make sense to make everything hybrid RT simply because some of the shaders are easier to write than non-RT versions, but right now you still have to do both. So if RT doesn't get you enough shiny you don't bother with it. That said, the framework for RT is there in Unity. So if some bored rendering engineer at intercept ends up implementing it, it might actually happen. That's how a lot of, "Not strictly necessary, but wouldn't it be cool?" features happen in games.

It's cutting holes in terrain that's a bit problematic. Plus anything you want to build purely subterranean would require some sort of a UI to show you that you're building it... and then you basically never get to see it again. I just don't think it's worth the hassle for, "Trust me, there's an entire colony down there." Now, if we had giant caves and lava tubes that were accessible, that'd be another matter, but that leads to so many additional tech challenges, including the aforementioned terrain holes, a robust system that works with large colliders that aren't heightmap terrain, camera, etc. Nah, way too much work. There are definitely more interesting things to implement that are higher up on the list. The floating/submerged colonies I like simply because between orbital and ground colonies, they should have most of the tech and assets already in place. It's a fairly small change that opens up a lot of cool new environments you couldn't explore before. That has gameplay impact.

Mods certainly make the bad situation worse, but part of the problem is with KSP itself. It's exceptionally bad at utilizing threads both at loading time and runtime. You are clearly not I/O bound on loading. I'm in the same boat, running KSP from an M.2 Samsung EVO, and it barely makes a dent over loading from HDD. I don't know for certain what it's actually doing, but it seems to be doing some CPU-intensive work while loading assets, it's all loaded upfront, and (nearly?) all the processing seems to happen on a single thread. Situation doesn't improve greatly when the game is running, as older versions of Unity KSP was based on aren't great at multithreading to begin with, and KSP hasn't really done anything to improve on that. So again, most of the workload tends to be on the main thread. Which, when you have a CPU with 20+ logical cores, just isn't a great use of hardware. It sounds like KSP2 should be in a better spot for all that. Newer versions of Unity do make better use of threads and also provide you with a job system that lets you push a lot of additional work out to threads. Given that gen 9 consoles are going to be running with 16 logical cores, I can't imagine Intercept getting away with not optimizing the game for multithreading this time around. Might still not be great at using all 24 logical cores of 5900X, but 2/3 utilization would be a good start. Mods will still be mods, though. Crashes will still happen and if there are memory leaks, a mod will eventually eat through any amount of RAM you're likely to throw at it. That said, impact on loading times can be greatly reduced. And with better performance, faster loading, cleaner API, and more features in core games, there are fewer reasons for modders to do anything unconventional, which should improve overall stability for a lot of mods. Hopefully. All in all, KSP2 should be a better experience if Intercept makes reasonable choices along the way.

Oh, yeah, totally. If you can delay, you should delay. CPU situation is bad - you can get Intel chips at reasonable prices, but you would be able to do a lot better with AMD if their latest CPUs were actually available at MSRP, and you really just can't get these at MSRP. GPU situation is just abysmal - between the RTX 30xx / RX 6xxx shortage and the new crypto boom, the prices on the GTX 10xx generation are a highway robbery, let alone anything newer. And the RAM situation, well, it's not the worst, but it's been better. Some other components have been going on sales due to the above, though. Like, you can get really good prices on AMD AM4 motherboards, so if you know you are going to pick up something like R7 5800X once the price comes down, you might be able to catch a great deal on the motherboard sometime before then while you're waiting. Likewise, PSUs and cases go on some great sales every once in a while. If you are planning a build, might as well set up some alerts for these. On the other hand, I do know that some work places are offering their employees money towards updating home offices while a lot of people are working remote, so it's possible that for some people right now is the time to build the new machine despite unfavorable market. And if you're getting even partial reimbursement, you can get a decent build for basically everything but GPU despite the shortages.

I still think they'll try to get the game running on PS4 and XB1, at least the pro/X versions, but for good proxy to PC spec, I would look at the gen 9 consoles, PS5 and XBSX. Both of these have 8 core (16 logical core) Zen 2 CPUs. PS5 is a bit underclocked at 3.5GHz, while XBSX goes to 3.6GHz with SMT according to specs. There are some differences in cache, but otherwise, this is very close to the specs of Ryzen 7 3700X. On the Intel side, you get similar performance from something like Core i7 10700K. It does a little worse under multi-threaded load, but slightly better on single thread due to better turbo clocks, and overall performs similar, if just a hair better than the 3700X in most games. Both of these are well over $300, with Ryzen being the less expensive option at $330, so I really hope we're talking closer to recommended spec here, and you can get away with less for min spec. On the other hand, we still have a year and a half at the minimum until the game releases, so that might not look as intimidating by the time the game ships. Still, if you are building the computer right now and want to make sure you'll be in a good place when KSP2 comes out, I would look at these specs as a minimum you should shoot for.

Not really, though. You don't strictly speaking need the less-dense-than-liquid property to form snow. But it's true that the reason water ice makes flakes in the atmosphere is partially due to odd crystal structure of ice. You know how sometimes you get this frozen dusting of almost micro-hail instead of flakey snow? The kind that bites your skin as it strikes, because it's actually falling quite fast? I imagine, most compounds with simple molecular structure would have frozen precipitation be more like that than the flakey snow. But then, there are a lot of crystals that can form flakes despite the fact that the crystal form is still heavier than the liquid. So there are really three things going on. 1) Can other materials go from gaseous to solid state in the atmosphere and precipitate? - Yes. You can get some sort of solid precipitation from pretty much anything that has a solid state under given conditions. You can have iron "snow" technically. Probably wouldn't be pleasant. 2) Will that solid precipitation form flakes? - That one depends on conditions. Even water ice doesn't always do that. We get hail and other phenomena. But some materials will form flakes more readily than others, and some might not make it at all. Crystal structure of water is particularly good for making flakes, so that's why snow is common. With other substances, something that resembles might be rare or impossible. 3) Will the solid form float? - That one's super rare. I'm not actually aware of another example besides water. I'm absolutely sure that there are complex organic compounds that behave the same way, but as for simple inorganic compounds? Water might actually be unique. What makes it even more interesting is that water starts forming domains at temperatures above freezing, which leads to negative thermal expansion coefficients. And while I know that there are substances that give you negative thermal expansion coefficients in solid form, having a liquid do this is quite bizarre. Yet, that's what protects a lot of aquatic life in the winter, so it's a very useful property, and I'm not aware of another substance that does all of that.

That's sort of the general idea. It'd be more precise to say that the objective is to move a region of space without accelerating it, and all the compression/expanding stuff is just the fallout of the math involved. But the idea is that, yes, you create a bubble around the ship, you move that bubble somewhere else, and you drop the bubble. Since ship never accelerated, you didn't expend any propellant. But the math only works out if space-time outside the bubble is flat. So the mass of the ship + bubble still has to be exactly zero. And then you don't need to understand fancy GR math to understand why Alcubierre Drive can move without expending propellant. If net mass is zero, net momentum is zero no matter how fast the ship is moving, and so you can change your velocity without needing a reaction mass.

It varies a little from studio to studio, but vaguely speaking, alpha is feature-complete. That means, you can in principle do anything in pre-alpha that you'll be able to do in final game and all tech and parts are available. Some of it might still have unpolished or (rarely) even placeholder looks, but it's all there. Game might run horrible, it might crash, and getting to some of the content might require using dev menu or cheats. But it's all there. Beta has most of the polish and optimization in place. The game should play the way it will play when it ships. There could be some balancing changes, and there might still be bugs, but there shouldn't be any problems that completeliy prevent you from playing through the whole game. During beta, all you are doing is fixing problems that prevent you from releasing the game. Consequently, pre-alpha is the stage of game development that isn't feature complete. Things can be missing, including some very important parts of the game. Some content is entirely place-holder. So you shouldn't expect anything you see to be in its final state. People would also some times specifically call out pre-production. Production is kind of an umbrella term for pretty much every stage of development once the game is approved and resources, which is primarily people who will be making the game, are allocated to the project. So when you see somebody showing prototypes or concept art from pre-production, you need to understand that it's all made by skeleton crew and main purpose is to get the game approved for production, so it's really just a mock-up of what they intend the game to look like. When a game in pre-production is approved for production, it's said to have green light. Clear on the other side of the development cycle is release candidate (RC). When the developers say that they have a release candidate, they mean that they are done with beta stage of development and have what they think might be the final version of the game. The RC then undergoes rigorous testing as if it was a final game published across target platforms. If serious problems are found, they are fixed, and another RC version is released. Finally, once RC passes all the tests, it becomes the final version and is sometimes said to have gone gold. Each part of development would typically be broken up into milestones and vertical slices, both of which you can think of as sets of goals developers expect to achieve by certain time. Milestones are usually internal goals, while vertical slices are presented to the publishers in form of a playable early version of the game. These can happen during every stage of production, and there is usually a vertical slice corresponding to the game going from pre-alpha to alpha and from alpha to beta, subject to approval from both the studio leadership and publishing. Now, not every studio is going to have vertical slices, but it's becoming very common, and I think Private Division would expect its studios to follow this pattern. So the full cycle is something like this. Game concept enters pre-production when a few people are allocated on proving that concept. Often, the pre-production team is working towards the first vertical slice. That vertical slice is then a sort of a demo prototype of the game that can be played by studio heads and people from publishing to approve the game for production. If the game enters production, it is now in the pre-alpha stage working towards alpha. There can be a few more vertical slices along the way, which are used to make decisions on how the game is to be taking shape. Eventually, there is a vertical slice separating pre-alpha from alpha that goes through approval, and if everyone is satisfied with the feature set, the game is then in alpha. The difference between pre-alpha and post-alpha vertical slices is that pre-alpha slices just give you an idea of what the game will play like, while post-alpha slices should give you the full experience, albeit, within certain expectations for quality. At the final vertical slice of alpha, the game is to be approved for beta, and so that vertical slice is the first fully playable version of the game. From there on, there might be more vertical slices, but the team is generally working towards RC which you can almost think of as the very final vertical slice. So what we know about KSP2 is that it's in pre-alpha. We also know that it's in full production. Technically, the game left pre-production before the first teaser at E3, but I would argue that we should only count proper production from a few months after Intercept took over, because they had to basically re-do the road map, which seems to have been approved, and that's why we now have the official 2022 release plan. What this means is that the game is still missing a lot of its core features, but it's far past a prototype phase. Most of the content being made is intended to show up in final game and not just act as placeholder. Though, some amount of place-holder content is going to still be present until the game is ready to enter alpha stage. There are going to be parts of the game the devs will happily show us the progress on, like the new parts and some screenshots, but also a lot of the parts that are just not ready to be shown to anyone either because they aren't finished or because they don't work well at this point.

Subterranean is a tech nightmare. That's the reason I'd vote no on that. It's not as cool as other options to begin with, but would be a much bigger tech challenge and take a lot longer to implement than the other options on top of it. I can definitely see some structures being shown as only the small surface part, with it being implied that there is more underground, but that's different from actually having meaningful construction underground. Colonies floating in thick atmospheres of some worlds or in the liquid oceans should be relatively easy to add. I don't know if devs necessarily need to spend time on it, but I would like to see them in mods at least. All that I want to see from Intercept is not strictly requiring attachment to terrain for colonies. Which might already be the case due to how orbital construction is going to work. Building at the bottom of oceans should just work the same as building on an airless world. You basically have all the same requirements. (Other than structural, but that always gets hand-waved.) I would probably make solar collectors unavailable if submerged and change the look of heat exchangers for reactors, but everything else can just stay identical. Small amount of effort for a lot of variety. And we have heard that devs want to make submarine exploration more interesting, so hopefully being able to build bases is a part of it.

Which is why it's doubly bad when publishers that can afford to ship a game still go for early access purely to reduce their fiscal risk. We need crowd funding to be available to games that wouldn't happen otherwise with conventional publishing. Not be spent on providing a safety padding for large publishing houses. KSP needed early access to happen. It's a game for a niche that hasn't properly existed until there was a game, and no publisher would take a risk on that until it's proven as a concept, and that requires someone to front the cash. Individuals, on the other hand, saw early demo and went, "I'd play the crap out of that!" And rightly so, in most cases. Sure, that sort of thing still flops more often than not, but it gives an opportunity for that variety. KSP2, on the other hand, is being published by Private Division, which is large in its own right, but is also a division of Take Two, one of the largest publishers out there. They can afford to make this game, and by now, they know they'll make their investment back. Expecting fans to pay up front for making of the game would be ludicrous.

Yeah, if your country's economy is in bad shape, you do what you need to do. In my personal opinion, games should never be a thing you don't get to play because you can't afford to. Obviously, we need support from gamers in form of sales to keep making games, so I would like to see anyone who can afford it to spend money on art forms they enjoy, but I also don't think it should ever be a wall. And yeah, with games, the hardware will always be a barrier to some degree, but at least, as far as games themselves go.

There are definitely things you can do with surface properties, but it's a bit of a can of worms. Like, if you want a muddy sort of surface, you probably want rovers to leave tracks in these. Now you need to do local terrain deformations, even if just for the visuals. There are several good ways to do this that aren't too expensive, and if this was a custom engine, it'd probably be a no-brainer, but under Unity it's a bit awkward. They are adding some features that should make it easier to do stuff like that, but I don't know the state of it and whether it'd be stable enough for Intercept to use with KSP2. Whether it's based on Unity's tech or they roll their own, though, I would very much like to see Intercept implement something like this. It goes beyond just tracks. There are a lot of ways you can greatly improve fidelity of terrain using these techniques. Especially, if Intercept implements virtual textures for terrain. Thin ice is one that I'd probably vote to scrap all together. One of the key assumptions that a lot of systems are going to make is that terrain height-mapped. So at any given point, there is one unique elevation that remains constant. If you have ice that breaks, you have two levels of terrain. Granted, ice can be a collision mesh instead, like the buildings at KSC, but this doesn't work too well over large distances, and breaking just section of ice introduces challenges with LoDs. But then things like low friction on thick ice? That's very doable with what Unity already does for you. You can get physics material from any collision surface and use that to adjust how stuff interacts with it. You can make surfaces that are "harder" or "softer" on impact as well as being more or less slippery very easily. So maybe things impacting snow and mud don't bounce as much and when you are driving on either of these surfaces you drift a lot. Intercept would need a way to assign materials, but what people usually do is associate it with texture. So anything with snow texture would get snow physics properties, etc.

Yes. Because mass difference is so high, high purity heavy water is available and has laboratory uses. You need fairly high fraction of your body water replaced with heavy water, but it's definitely possible if you only drink heavy water and don't get a lot of water with foods you eat.

My guess is that if we have any chance of something like this being stable w.r.t. vacuum, let alone gravitationally, it would have to be tiny enough to benefit from some sort of quantum weirdness. Since it'd have zero net energy and not enough gravitational distortion to detect indirectly, I have no idea how we'd go about detecting it. Otherwise, I'd probably we recommend looking for these on the off chance someone is already using them for long range communication.

You don't necessarily need more of it, but you need it earlier, when the game might not be in its final shape. So when we should be busy finalizing feature set, which is about the most sensitive period in game development, suddenly, marketing needs polished trailers. Which inevitably means that devs end up trying to put polish on something that was quickly stood up just for this marketing stunt instead of working on the actual game. Not only does it result in trailers that are far from representative of final game, but also you lose valuable time. Often features end up having to be dropped or land unpolished/broken because of it. The good outcome is that you end up delaying the game because of that, but you rarely have a delay without a rush and crunch to go along with it, and it's never good for the final product.