K^2

The problem is precisely that the moment you add thrust, these "whoops, it missed the boundary," become, "whoops, the integration was complete garbage and now the ship is on trajectory drastically different than what was shown in the planner." It takes it from annoyance to completely unplayable. Granted, you could apply shorter time-step to ships under power and go for coarser steps for anything ballistic - and you can even do continuous collisions to avoid some of the problems from KSP, but this is all very far from trivial. Simply increasing time step under high warp is not going to be a good solution for KSP2. I'm not saying Intercept isn't going to throw in a towel and simply do that, but a good solution requires a lot more nuance, and I hope they at least attempt it.

Even during takeoff and landing there is enough authority to counteract rolling torques due to bad CoM. What you don't want is to have a lot of that torque already there in case of an engine failure, where you need extra authority to keep the single operating engine from flipping the plane over. So it's still very important to make sure your CoM is inside the envelope, but yeah, if people move side-to-side during cruise, it won't matter at all. Back-and-forward is a major problem even in cruise, not because you wouldn't have authority, but because you loose dynamic stability. In particular, CoM shifting too far back can easily be catastrophic. It creates a pitch-up tendency, which only grows if not immediately corrected. A plane with CoM too far aft once stalled cannot be recovered. I'm not aware of any passenger planes going down because of that, but cargo planes with unsecured cargo that shifted in flight absolutely have. Given the state of understanding of hypersonic flight at the time? Very doubtful. I mean, how early in the 50s? Sputnik 3 in '58 was already over a ton. That's more than enough for a manned flight to orbit. You just don't have the tonnage for an engine that brings you back. If we are talking about early 50s, there was tech for suborbital flights, but engines you needed for orbital flight were still in development. As much as V2 has demonstrated the potential, the fundamental design is not scalable to an orbital rocket. A lot of the components had to be completely reimagined, and that takes time. Getting from V2 in '45 to Sputnik in '57 was already very fast. Too many things lined up in the 60s tech-wise. Better understanding of hypersonic flows, better understanding of rocket engines, better materials, computers. Can't forget computers. Even if US didn't drag their feet early on and beaten USSR to first man in orbit, and even if Apollo 1 didn't go up in flames and luck was entirely on US side, it'd still be just a few years sooner.

Agreed! But there's a lot of room there. 0.42ly would still put nearest star at more than 50,000 the distance to Jool. As discussed at length, I think that's on the outer edge of playable with ~1G accelerations. On the other hand, anything less than 500x might not feel like there is a real vastness of space in between, requiring considerable change in tech to reach. But this still leaves a huge amount of room in between. And whether you want to go high or low on that range will depend on a number of factors we don't really know. What the tech tree progression will be like, how easy it is to get to 1G or above, and how exactly will time warp work.

It's not really a translation issue. It's purely historical. The 200th Brigade of the 14th Army Corps of the Russian Navy is part of the Coastal Troops arm of the Navy. That arm of the Navy has been formed relatively recently from parts of coastal defense artillery, motorized brigades, and naval infantry (marines), etc. Some of these forces traditionally belonged to the Red Army, including some of the motorized brigades, and so they have retained their Army organization style. Hence, the 200th Brigade is still included in an Army Corps.

It's a Unity game, and so it is written in C#. C# compiles to CIL which does a lot of dynamic linking, so it holds on to a lot more symbols than you'd think. A decompiler does a pretty good job of converting compiled C# back into source code. You lose a lot of local variable names that you have to guess the meanings of, but the function and class names are preserved, so it's not actually that hard most of the time to figure out what's going on. I've decompiled KSP a few years ago to look around. Mostly, looking at how forces are applied to the craft. Now, it's worth mentioning that, at least the time, the code was also obfuscated, but they used a standard, off-the-shelf obfuscator for which there was a good disobfuscation program out in the wild. Depending on what is used now, this might or might not still work. I mean, sure, but KSP struggled with 100k. We're talking doing everything KSP did across multiple star systems, potentially for a lot more objects, getting at least some form of colony update tick in there, and then also doing all the extra math for all the ships traveling under power. Sure, I expect KSP2 to be much better optimized overall, but even then, simply maintaining that 100k time warp as maximum is a challenge. There are also gameplay reasons why higher time warp might not be the solution you're looking for. Even in KSP it feels a bit odd to just skip years of time for a longer mission. Now we're talking decades, and in a game where a lot more is happening over time. Shouldn't you be collecting science, updating your tech, building colonies? Simply losing this much time on a warp doesn't feel great. While in time warp? Building a ship in VAB might actually be ok. You'd be sharing CPU resources, but VAB isn't too expensive to run. Anything else is problematic, though. How do you edit a colony that's being simulated at 100k warp? Intercept is likely going to need to implement special time step for that already, one that assumes that no parameters change for a long time. Now you start introducing changes. At best, it's hard to implement. At worst, a source of endless bugs. I wouldn't touch that. And of course, while you can launch new missions, you'll have to drop out of warp to do the actual launch, and then the time slices for that mission are likely to be so short that you won't be making progress on interstellar mission. Yes, I suspect some players will have a bunch of interstellar missions in flight at once with various alarms set, but this is turning from rocket game into ATC game. Some people will enjoy that and more power to them. You just can't rely on this to be solving your gameplay design challenges.

If you do the math, it takes about a year to get to 1c at 1g. (Which makes 1ly/yr a very convenient unit of acceleration!) If we ignore relativity, trip to Proxima Centauri takes just over 4 years at 1G. At 100k time warp, that would still be 21 minutes of real time. This is starting to get into territory of bad gameplay. This isn't a flight sim where you have to actually fly the plane and long voyages make sense. If you put a rocket into time warp and have to wait for 20 real life minutes, it's not a good experience. And i your acceleration drops to 0.1G, that goes up to over an hour of real time under maximum warp that was available in KSP. And this is the nearest star. This is just not practical. Distances between stars will absolutely have to be at least an order of magnitude smaller than in the real world. That would bring it to KSP scale. As mentioned earlier, that's still a 7 minute trip to the nearest star under 100k time warp and constant 1G acceleration. This is getting into playable territory, similar to outer planets of KSP, but it's still not great. Distances might have to be shrunk even further. Especially, if time warp with thrust will have to be at a lower multipliler. So yeah, 1G continuous seems like a lot when you're working on a scale of planets in the Solar System, but the moment you go into interstellar distances, it's still going to take a very long time to get anywhere.

Stars other than the Sun still provide a good amount of light. I don't know if you've ever been in the middle of absolute nowhere, with zero light pollution, on a clear moonless night. It's dark, but it's not pitch black. Once your eyes adjust properly, you can see environment around you and even pick up hints of color. Everything is very muted, and shapes do blend together, but they're there. Looking at the stuff we got to see in previews, I'm pretty sure KSP2 is being rendered with HDR in mind. That means you can adjust exposure, simulating eye adjustment to light levels, and even filter colors based on light intensity, giving everything that muted look. I don't know if that's how Intercept will chose to handle it, but it's certainly an option, and would make the game quite playable far from the Sun. That said, it will certainly be a good incentive to place some additional lights around your interstellar ships to illuminate anything you might need to interact with during the voyage.

Doesn't cost anything to try.

This was in reference to particles whose positions are recorded exactly. Their momentum is infinitely indeterminate, meaning their speed can be anywhere between 0 and c.

All of these things have to be checked for during every time step, however, as you are computing the trajectory. It doesn't matter that any of these conditions will simply end Warp, you have to check where it happens, and where you cross SoI boundaries depends on your trajectory computations. So you have to do a single time step of trajectory update, perform all of the SoI checks, adjust ship's mass for fuel spent, then go to the next step. So if trajectory computation is complex and requires more steps, you have to do SoI checks more frequently. And because SoIs move on their own rails, these checks aren't trivial. Fuel checks don't depend on trajectory, but at least the way KSP does these checks, aren't trivial either. Consider core stage + booster in KSP with shared plumbing. Main engine is burning fuel from core stage and the booster, while booster burns fuel from booster only. When the booster runs out of fuel depends on consumption on the main stage. If you are doing this check incrementally, you have to check your entire ship's plumbing on every single tick of the simulation. Yes, you can pre-solve fuel consumption and know at what time which engines will cut off, and it's something that should be done, but that does require special code to write, verify, and maintain. Since code for fuel checks during normal flight is designed to work on a request system, because it has to deal with variable thrust and ISP. And this is the point I'm trying to make, not that it can't be done, but that it's a complex problem with a lot of tricky edge cases and a lot of custom-written code just for the purpose of solving the warp-under-thrust. That's all we're doing here. Computing trajectory and verifying that the ship has resources to stay on said trajectory and hasn't encountered any obstacles. But you do have to do all these checks still and you do have to mix them in with trajectory updates, because fuel consumption affects the ship's mass, which affects the trajectory, which affects whether or not you cross SoI and if so, at what exact position. And trajectory computations here are about the most expensive kind you get in simple mechanics. Gravity and thrust don't mix well computationally. So you end up with very short time steps to get accurate trajectory. And if you have shorter time steps, you need to do more checks on fuel and SoI because, again, you need these for every step. And as a point of comparison, KSP had all the time-warped ships on rails. They just follow conic patches and check for SoI boundaries. No collision checks - you simply drop out of Warp if you get within certain distance of planets and moons, and no fuel checks, as the engines aren't running. And KSP still struggled at 100k warp with enough space junk floating about. In KSP2, this is so, so much worse. Of course, KSP's trajectory updates were very poorly optimized, so there are going to be a lot of wins right out of the gate by simply writing better code, but at the end of the day, it's still a hard problem for a tiny developer team. This isn't to call for concern, or anything. From the very inception of KSP2, this was one of the core problems that needed to be solved, and I don't think anyone on the team would underestimate that, so I'm sure the necessary work has been put into it. But some corners might have had to be cut. 100k might be a little too much to expect. And if the time warp is any less than 100k, you basically have to pull in the interstellar distances from the traditional 1:10th scale. Alternatively, there might be limits on how many ships we have in flight under power during warp, which will make trip planning a bit harder. Or any number of other potential limitations or sacrifices made to make this feature work.

0.5c* * To within ±0.5c.

And thrust can vary depending on availability of some resources (e.g. electricity for ions,) and some engines might cut out or switch modes as some of the resources are depleted, and the rate at which mass is consumed will vary with all of that... And that is if we decide to just forget about the rotation and keep orientation frozen, which is very exploitable, but might have to be done. And that's on top of gravity and possible SoI changes. This is a hard problem. It's solvable, but KSP struggles with it without any thrust at all, just keeping orbital junk on rails and doing SoI checks. KSP2 has to do all of that with, likely, more debris, and be able to do that with thrust applied to some of the objects. And having both central potential and thrust in the mix makes the numerical solutions to differential equations way less stable. There are ways to work around it, if either can be treated as perturbation, but that's pages and pages of math on top of algorithmic complexity. And either way, this is going to be a lot of computation. If this was my project, I'd start asking questions like, "Should we really be doing this in C#?" To be clear, I'm not saying that this can't be done, or even that it unlikely to be done by Intercept. It's just a lot of work, and it's not the only work that their physics engineer needs to get done. And we're still just talking about matching the 100k warp of KSP. Some corners somewhere might end up getting cut. Whether it's going to be simulation stability, ignoring some of the nuance of physics under warp, or simply smaller distances between stars remains to be seen.

Sure, in theory, but these numbers are considerably larger than what's reasonably necessary to assign every atom in the known universe a unique identifier and its coordinates with precision to within the Planck length. As for using floating point arithmetic specifically, this is handled with origin relocation and is already part of KSP code.

Yes, it'd have to be something like that, I think. But there is still a lot going on. Resource use has to be accounted for, and KSP had it set up in a way where it was a huge resource hog just to process fuel priorities. (I haven't looked at that code, but I suspect either a bug or bad algorithm. Performance of that system was terrible.) KSP2 should be better, but with a complex enough ship, it's still far from free. And then there is question of ship orientation. If you simulate torques, changes in orientation, and thrust applied in different directions, then not only do you have to reduce simulation time step to avoid errors, but you also have to consider how any stability/guidance systems will work. You could completely lock orientation, like regular time warp does now, of course, but then you basically don't have to think about thrust symmetry at all. Just slap engines wherever, and hit warp to prevent your ship from flipping. That's not great from gameplay perspective. You might want to have something in between. Perhaps, start with normal physics warp, and only if the ship remains stable, allow you to go into higher warp levels with engines still firing. So while it's clear that what you have to do is simplify simulation and increase the time step it can handle for this particular case, the devil's in the detail of how to actually achieve it. And it's a mix of engineering and design challenges. So it's not immediately clear to me what the correct solution is. Intercept has good game designers, though, and had more time to think on it, so hopefully, whatever they came up with will be fun to play.

The distances involved are huge, don't get me wrong, but a lot of that is going to be absorbed into using torch drives. In KSP, we are currently dealing with typical relative speeds of a few kilometers per second. For interstellar, the speeds will have to be in thousands of kilometers per second, and that's going to cut into the distance gap dramatically. Using times for comparison is the right call, but we should also take into account the tech leap required to go interstellar. The efficient transfer from Kerbin to Jool takes a little over 1.5 Earth years of real time. The maximum time warp of 100k reduces that to about 8 minutes. Now, suppose you have a torch drive that can provide you with sustained 1g of acceleration. If we take the same 1/10th scale distance to Proxima Centauri, the trip there is a little under 1.3 Earth years of real time. Again, if we can get the same 100k time warp, we can be making a trip there in under 7 minutes. This is very reasonable. And in fact, interstellar trips taking a few minutes of real time is right there in the ballpark of what would probably be good gameplay. The real trick here is maintaining these 100k of simulation speed multiplier with engines running. You can push physics warp a little past what vanilla KSP lets you, but even if you mod the game to remove that cap, you aren't getting into anywhere near the numbers you need here. So it would have to work different. Crucially, however, not having some kind of warp that lets you run engines isn't an option. Times required to reach outer planets of KSP are already on the silly side. So Intercept is in a bit of a bind. They can't place other stars too close, because then you could get there with chemical rockets by just waiting a little longer, and they can't put the stars really far away without relying on something like physics warp, because nobody is going to wait for a real life month to get there. So it's a problem Intercept will have to solve, and we can assume that we will have ability to use torch ships with time warp. So where does this leave us with interstellar distances? Well, if Intercept can squeeze out the same 100k multiplier, the 1/10th scale is still very reasonable for interstellar distances. If not, how far can the distances be shrunk? The really icky part is that distance is quadratic in time under constant acceleration. So if we still want the trip to be under 7 minutes and we can only do 10k time warp, the distance would have to go down by a factor of 100, or be just 50 times further out than Jool. That would border on broken, because a rocket that can cross that distance in a few hours under warp can be built with tech we have in KSP, and that doesn't feel sufficiently interstellar. So the time warp in KSP2 can't fall much bellow the 100k we have in KSP while still supporting torch drives. And then we're fine with Kerbal-scale versions of real interstellar distances.

Technically correct, but I think this caveat is worth mentioning. They are completely identical if the expansion is uniform, but since universe is expanding at an accelerated rate, we can directly probe that acceleration. Of course, if all you are looking at is light, it's no help, but accelerated expansion will impact massive particles slightly differently. So if you could measure both from the same source, say light and a neutrino burst from the same event, and you knew initial energies for each, you could work out what the actual velocity of the source should be if it's only due to expansion and get motion relative to that. It'd be a very indirect measurement and rely on acceleration being uniform over relevant time frames, so not applicable to most distant objects, but it's a way to, at least in theory, distinguish between expansion and relative motion. In practice, I don't think we have means to do this quite yet. Also, the distinction here is a bit of an Occam's razor one. There is no true physical difference, and a contrived example can be made where you get fooled, but it's a bit like equivalence of gravity and acceleration. Sure, you can't really distinguish between the two, but if along with "gravity" you noted a rather strong Coriolis effect, you're probably sitting inside a centrifuge and not on a surface of a planet.

Interesting thought. The origin story of the Duna SSTV signal does involve a planet in the outskirts of the Kerbol system, far beyond anything that was added in KSP. If the teaser in KSP2 video really is a planet beyond Eeloo, it could, indeed, be inspired by that story, whether that planet's actually in KSP2 or if it's just an Easter egg. Of course, it could also be entirely coincidental or might not hint at a planet at all, but just a general idea of exploring beyond Kerbol system. Personally, I think it'd be great to see the idea of scavenger hunt sort of adventure to find a lost planet be realized in KSP2, but assembling necessary info from things like SSTV transmissions might be a bit much for average player.

Modern radar is very heavily processed, so it's not like you're looking for a funny smudge on a screen indicating an anomaly. That went away with WWII radar tech. It's all about whether the system is designed to find such anomalies and present them to operator. And as far as that goes, it depends very much on what you're looking for. Most ground-based radar stations aren't going to have a background to compare to, which is why stealth works. Unless you're running weather radar, the main reason to use radar at all is to not have to worry about clouds and such. So if you're just looking for an active radar return, you get the pitch black of open space as the backdrop. But you don't have to look for the return. There is plenty of static, and you can look for anomalies in that. That's what a passive radar does, and it can in theory pick out both types of anomalies. A plane will bounce off a lot of radio coming in from all sorts of sources, making it stand out, and you can look for that without attracting attention to your radar station. Likewise, a stealth plane will block out the background. But this is way, way harder to detect, primarily due to resolving power of your system. If you want to pick up a plane with active radar, you don't need to worry about resolving power almost at all. If you pump enough power into the ping, you'll get a bounce and know its direction to within resolution. It's the same reason you can see stars even though they are point sources of light for all that it matters to our eye. If you are looking for a bounce with passive radar, you need a larger dish or array, because the power you get back is inherently limited and now you actually need to resolve the return better. But it's still a bright "dot" over a darker background. That's not so bad. If you are looking for a dark spot, now you have to actually resolve it to at least a single "pixel" to be detectable. And unlike active radar, where you get to pick the frequency to work with, for passive radar, you get to use what's there. If we are relying on ground signals bouncing from ionosphere, you won't get a lot past 1GHz or so. That's 30cm. If you are trying to spot a plane 10km away that has a 50m wing span by the fact that it's blocking a 30cm background, you're going to need a radar array 60m across. You could look for anomalies in microwave background, which has much higher frequency, but then the intensity isn't there, and you're basically going to need a radio telescope anyways. If your radar is flying, there is more you can do. An active radar sweeping down, using ground as backdrop, can actually be very powerful. You get to pick the frequency range, pump a lot more power into the ping, and you can use time-of-flight to resolve the return instead of just angular resolution. If the stealth planes are trying to sneak by at low altitude, a high flying AWAC should be able to find them by the "hole" they're leaving in the ground return. Is that actually used? I have no idea, but I'd be surprised if nobody at least tried.

Don't know about using cell phone hardware directly, but microwave detectors are really simple and cheap. Wouldn't be a trouble to create a dongle for it. That said, microwaves are usually pretty sell shielded by human skin. If the power is sufficient to start cooking your brain, your skin will be getting burns. This is why microwaves have been researched as means of safe-ish crowd dispersal. You start feeling like you're being burned long before there is actual damage. You'd have to drop down to very long wavelengths before you can start doing more damage to the brain, and by that point you're pumping so much EMF into the room you'll be tripping breakers from induced current. That actually sounds way more plausible. Current theory on why head blows can cause unconsciousness is due to mechanoporation, and it's been long theorized that ultrasonic cavitation might lead to the same effect. The trouble is that with ultrasound, it's a very fine line between causing depolarization and doing tissue damage. No official medical research on something like this would ever be permitted. But off the books... The benefits are obvious. Any chemical agent causing unconsciousness will have a host of side-effects and is very easily detectable after the fact. If you could deliver equivalent of a blow to the head without any physical injury, well. Suppose, goal was to render diplomats unconscious for a brief period. The agency involved might have had success in the lab using ultrasound to induce unconsciousness on "volunteers". They try it in the field. Agents turn the system on, fumble with controls, get no results, increase power way beyond safe limits, and end up causing tissue damage. And the reason it failed could very well have been that real environment obstacles, like walls and windows, prevented delivering ultrasound the way it's meant to. If it was easy to apply in controlled manner, everyone would be doing it. That's wild speculation, of course, and entirely ad-hoc. It fits MO of Russian intelligence, Soviet research, and what little is public knowledge about the symptoms. But that's a long throw away from anything conclusive. I just wouldn't be surprised, lets say. But if that's it, it's going to be relatively easy for other countries' intelligence to collect evidence on it and come up with countermeasures or at least means of detection. Again, this takes quite a bit of power, so the only subtlety here is that it's not audible without special equipment.

I don't know about the rest of the site, but the concept isn't entirely made up. Still, it's kind of in the vein of how scientist used to think that the metallic hydrogen might be a superfuel, but then we found that expectations of its metastability have been greatly inflated. We don't actually know if any of these exotic states of matter are metastable. We have no way to verify, and our ability to rely on theoretical results here is questionable at best. These kinds of densities push limits on how much we can decouple quantum mechanics from gravity, and that's on top of them being exceptionally hard problems in condensed matter physics in the first place. The only thing that might lead to some better clues about feasibility of it all in our lifetime is the dark matter search. If we actually detect dark matter and it turns out to be strange, charmed, or some other form of exotic quark matter, we'll have our answer. If it turns out to be something else and our estimates for quantity of whatever it is match quantity of dark matter in the universe, then these metastable states are much less likely to be real. One piece of evidence that makes me a bit skeptical of quark matter or any other compact object explanation for dark matter is the fact that we haven't found any evidence of primordial black holes. Same models that predict a lot of strange matter floating about predict a lot of primordial black holes floating about. Normally, sub-planetary mass black holes would be very hard to find, but there is a specific mass range that should be very obvious. Black holes that were created with just enough mass to evaporate over the age of the universe. We have looked for gamma ray bursts associated with the last moments of a black hole evaporation as it pops out of existence, and found absolutely nothing. That leaves us with three possible explanations. 1) Black holes of sufficient mass to survive until now weren't produced - that seems unlikely based on amount of dark matter we're trying to explain here, and given how easy it would be for black holes to merge during early expansion. 2) Black holes don't evaporate or evaporate at a much different rate - plausible, but then we understand bleep-all about quantum gravity, and our predictions about stability of strange matter or conditions for its formations aren't worth the paper they're printed on. 3) Sufficient density fluctuations were nowhere near as common as some of these models suggest. In which case, these things might still be around, but nowhere near the quantity to explain dark matter. I'm leaning towards that last option, which isn't definitive as far as stability of strange matter, but it takes away the biggest argument for its existence - that it explains dark matter. And without it, it's just a numerical curiosity of a particular model with no experimental evidence whatsoever. And either way, we can't make any, and if it's not common in the universe, we're not going to find some to use or experiment on.

That's basically the same thing. There are some models suggesting strange matter might be metastable, but we've never made nor observed any. If it exists, it can be used for many interesting things. That is, if you ever figure out how to contain it. Given that you'd need a considerable amount of it to be of any use, it would be exceptionally massive while still remaining exceptionally compact.

Thought crossed my mind, but it'd be an odd choice to propagate that as material cost to the build cost, given that you have other options for producing electricity. Usually, games will just tell you how much energy is needed, and it's up to you to figure out how to get that made. As a matter of fact, I would like to see more intermediate materials. Not too many - this shouldn't be turning into Factorio/Satisfactory type of game. But one additional, vaguely named layer, like, "Metal Construction Parts" and "Electronic Components" would be nice. Partially because some of these can have multiple production routes, electricity being the most obvious, but being able to make parts from scrap metal instead of ore, for example, could be good. But more crucially, it gives you a bit of flexibility on where to do your refining, and gives colonies a bit more purpose than just being ore extractors. If you take raw materials and turn them into components you need, you have less weight to lift to orbit to supply your orbital shipyard, etc. Finally, I do think some people might actually want this to be Factorio with rockets, and having rudimentary resource chains in vanilla game would make it much easier to make good mods for that kind of player. But this is all just musings based on very limited information. I guess we'll see it when we see it.

Yeah, I kind of thought aileron failure must've been part of it. The way it suddenly starts rolling like that, I suspect, the pilot was countering the engine on the opposite side, which couldn't be cut to lower throttle due to lack of altitude for a free glide. And asymmetrical thrust during critical engine failure does generate both yawing and rolling torques. At low speeds, you have to counter pretty close to limit of authority to keep the plane straight. The moment that aileron went, there wouldn't even be time to cut throttle, not that the outcome would likely be any different, given the aforementioned lack of altitude. I don't know if they mean that the fire actually spread, or just that the heat from the engine was cutting into the wing like a blow torch. You can do a lot of damage inside a plane with just really hot air being fed under pressure. Ideally there shouldn't be enough stuff to burn inside the wing to do anything other than electrical damage. Unless the fuel tanks rupture, of course, at which point you have a different sort of problem. And as far as I understand, the general idea is just to have enough fire suppression in the engine to kill the fire before it does any of the above, rendering the engine inert. I know airliners usually have additional fire extinguishers in crew cabin, cargo hold, and even sometimes on key electrical systems, but I've never heard of any just peppered throughout wings or anything like that.

I think I even remember people being confused about why uranium is needed to build a nose cone, and it's been clarified that these were just placeholders. I also don't think we've heard anything final on when you'd have to use materials instead of credits, and whether you'd be able to choose either when building at KSC or anywhere else, for that matter. It is the sort of thing that you can keep tuning pretty late, though, so we probably won't know exactly how that's meant to work in final until very close to the release.

This is based on all the previews we've already seen,, but it's a very good summary, and maybe some people missed some of this footage. I think it's good to see all of the individual new features in context of all the others, which this video does really well. You can also see the progression from rough ideas and prototypes to something that's starting to look like working implementation for a lot of these features.