K^2

I honestly don't know if it's relevant anymore. I know the site says it's coming to PC, PS4, and XBox One, but they haven't even updated it to include PS5 and Series S/X. This game is coming out mid to late '22 now, not early '20. Some of the terrain tech they've been showing off is pretty expensive. Not a huge factor for PS5, but I've recently worked on standing up something similar and we have been testing it on PS4. Which ran alright, I guess. But it was starting to eat into frame rate and this was on a custom in-house engine at a AAA studio, so it was actually pretty well optimized to do this work. KSP2 is supposed to run this with Unity. Even with as much shifted over to compute as possible, CPU is going to struggle a lot. Then we should talk about the core game. Yeah, they're optimizing it. But they are also adding new features. Continuous collisions are new. Time warp will have to support a lot more physics if we're going interstellar. Colonies. None of it has to get particularly expensive, but this is a small team making a big game. Not everything's getting optimized out of the box. I don't think PS4 being a target is realistic. PS4/XB1 are either getting dropped or back-ported with a lot of features cut. At which point, the development platform for KSP2 is going to be PS5. That's going to be the benchmark for "good enough" performance in a lot of QA. Which means, maybe they can optimized it a lot better, but there is high risk they don't, and PS5 CPU will represent a realistic minimum spec. That's not a guarantee, and it's entirely possible the min spec will end up lower, but if you want to forecast and buy something now that will be nearly guaranteed to run KSP2 well, that's your target. So as I explain above, it's not a guarantee. It might end up a lot lower, but PS5 will very likely be their benchmark, which means that optimizing the game for lower spec CPU is not going to be nearly as high of a priority. And it's not that wild on the CPU side. Prices on 3rd gen Ryzen and 10th gen iCore have come down significantly. Either of the CPUs I've listed is ~$300 in US right now and sales are frequent. Which is still expensive for a CPU, but it might not even end up the most expensive part of your build. The GPU you want to pair with this will start in $300 - $400 range and goes up from there. If you want to play other modern games, probably way up. This is an interesting opportunity to consider on-board graphics, though. AMD's APU design is actually quite beefy, and if you can find a way to purchase something like Ryzen 7 4700GE, that can almost certainly cut the mustard on graphics for KSP2. It's a lot weaker than PS5 GPU and is Vega 8 based, rather than RDNA2, but graphics are way easier to make tunable, and I'm fairly confident that Intercept will try to target lower tier GPUs. Now, the catch is that Ryzen APUs are an OEM part, meaning you are only supposed to be able to get them with pre-builds. There are some on the market that are reasonably priced, though, if that's what you're going for. Alternatively, I know people have been able to buy CPUs and boards meant for OEM at wholesale prices from less reputable sources. It's a risk, but if you're familiar with these markets, it might be a great option. I almost want to recommend the Intel's i10700K for the same reason, but I'm not nearly as confident that the onboard graphics there will do the job. It's also going to be inadequate in a lot of other games, so it's a very shaky proposition. I still like it as a gaming CPU, but running it without a dedicated graphics card is very meh. A 12th gen iCore CPU with integrated might actually be perfectly fine for playing KSP2, if rumors are to be trusted, but then we're back to the problem of trying to buy the latest and greatest, in this case, something that hasn't even been quite released yet. So you probably won't be able to save anything overall with this setup, sadly. And yeah, it might go way down from this target. I just don't think even anybody at Intercept knows at this point where it's going to land, so if you buy a CPU now and you go well bellow these specs, you're taking on a significant risk that you'll have to upgrade for KSP2.

We don't really have anything concrete, but I would aim for something circa capabilities of PS5 for CPU min spec. That would mean AMD Ryzen 7 3700X or Intel i7 10700K. There is every reason to expect that while KSP2 will be much better optimized, it will still, just like KSP, be very CPU hungry. So while I fully expect Intercept to make every effort to make the game run well on PS5, I have serious concerns about anything at lower spec. So I think that's the low bar to aim for and, if you can afford to, I would aim higher. On the graphics side, it's a lot harder to say. The GPU on PS5 is very close to AMD Radeon RX 6600 XT, but you will probably be able to scrape by on way lower spec graphics. You will definitely want something capable of DirectX 12, but something like GTX 1060 might actually be adequate, depending on how quality settings are set up. However, unless you absolutely must spend money on a new PC right now, I would wait. Both because we'll probably get better indication of what we need and because there's a huge shortage of anything silicon right now, so prices on CPUs and GPUs are kind of outrageous. It looks like it should start improving in the next few months, however, so probably hold off a bit.

Short term, yeah. So in context, it might not matter, but on a slightly longer term, the rate at which SRB fuel burns depends on the internal pressure. As the pressure begins to drop, less fuel will burn, causing the pressure to drop further, causing an even slower burn, etc. In an extreme case of nozzle being completely removed, it can take the process down to a gentle burn with almost no thrust. Nozzle diameter on solids is actually a very delicate matter. There is a range at which pressure is self-stabilizing, but you make the nozzle too large, and pressure drops to nothing. Too small, and it's a runaway to an explosion. So depending on the nature of emergency. blowing out the nozzle can actually be a way to safely shut down the boosters almost completely. But it's not going to be instant.

It's not quite that simple. The shorter half-life means you get more decay events in the same concentration, but short half-life products also don't accumulate as much, because shorter half-life, so you don't usually get the same concentrations as the longer lived stuff. Not to mention that the kind of radiation matters. In waste, gamma and alpha might be nasty for handling the waste, but they aren't going to poison ground water, dust, or what might have you. Basically, neutron radiation is the only one you really have to be paranoid about long term, and the energy of the neutrons matters a lot. Particularly slow neutrons will just bounce around and decay to trace amounts of hydrogen gas. Very high energy neutrons tend to either not interact or convert whatever they hit into something very unstable, causing immediate collapse, and generally, safer products. But if you hit the energy sweet spot for a particular nucleus that a neutron might encounter, something entirely harmless might become radioactive with long enough half-life to get out there and cause harm, and that's the kind of radiation you really have to watch out for with radioactive waste. Radiation that makes other things radioactive. And some isotopes are a lot worse for that than others and it has nothing to do with their half-life. Now, reactors were never my jam, so I can't tell you off the top of my head how the waste is going to compare. There are complex decay chains for different isotopes of Uranium and Thorium all resulting in all kinds of candidates for bad neutrons, and it would take me entirely too long going through isotope table to sort it out. I'm sure people have done this work and there are probably some summaries out there on how the wastes of Uranium and Thorium reactors compares. The only point I'm trying to make here is that it's not as simple as "short-lived, therefore, nasty."

I can't say with certainty that EA doesn't operate on whole another level, as I have no insight into their internal marketing, but I highly doubt it. Places where I have had a good look at how the marketing is done from the inside don't operate on anywhere near that kind of forethought. Game marketing is entirely reactionary. And to be clear, this isn't a critique - at least, not in whole, They do what works, and trying to plan for the next successful strategy a decade ahead is absolutely not a thing that has been working for anyone. You invest in some number of smaller games that are trying new things, including new monetization tactics, most of which will fall flat, and then you invest the bulk of your effort into replicating what has worked before the demographic preferences change. And they'll do plenty of underhanded things, but horizon on this is measured in months, not years, unless it's something very generic that can be adapted to many different ways of marketing. You know, like match-making against pay-to-win players, because that's something you'll be able to milk no matter what you're actually selling. But loot boxes are too specific. By the time major companies went all in on the idea, the questions of ethicality and legality were already being raised. Current maneuvering reads to me like trying to suck all the profit they can from loot boxes before regulation clamps down, partially in disbelief that it hasn't happened already. Interestingly, a lot of companies are starting to learn that chasing hype with a game that has a six year development cycle doesn't actually work. It's something you ought to have been able to predict, but there is quite a bit of tunnel vision when you've been making games for decades following the same formula. Large studios will have to adjust to build more flexibility into their development cycle. And I do wonder if this is going to propagate into how games are monetized and marketed or if it's just going to create an even larger rift between developers and marketing teams.

And amazingly, tha almost worked. It's hard to abort docking after it is over, but Nauka gave its best and was very close to making it so. On a more serious note, I'm apalled that there are no safety checks on this. You don't write mission critical code that simply executes to completion if a particular routine got called. This is a known bad practice. Whoever's in charge of software needs to be fired and replaced with someone who knows how to write safe code.

I don't think it's meant to. It's meant to take a bite out of that market, sure, but it's clear from price point and capabilities that they aren't going after the whole market. Just taking a bit off the top. For me personally, if I'm carrying a backpack already, I can just put a full size laptop in it. I don't mind the extra weight. It's the extra bulk that I would like to avoid, and Deck does open up some options in that regard.

I believe it's still a UDMH+N2O4 fuel. So theoretically, it is hypergolic and can self-ignite if the valves were opened, but you'd have to have both fuel and oxidizer valves happen to fail simultaneously and in a way that still feeds the propellant through the turbopumps. So I don't think this can be anything other than an error in the control systems. Something had to actually command both valves to open for the engine to kick on.

There's a pretty big difference between the kind of design that's hard for a computer to fly and one that's hard for human to fly. There's an overlap, of course, but it's not a one-to-one. Generally, computer control is good at fast corrections, which allows aircraft with unstable static equilibria to fly true. Think of balancing a broom on its end. Humans can do it pretty well when the dynamics is slow, such as with a long broom, but try the same trick with a pencil - this is where computer can take over and have no problem keeping things balanced. On the other hand, a lot of rockets in KSP end up with dynamic instability. The kind of setup where if you don't mess with it, it seems stable, but if you start making adjustments, there is a tendency to over-correct, and the rocket starts building up oscillations. You know, the sort of thing that you have to fly with SAS off? Humans can usually work with this type of instability. It's not great, but manageable. A computer, unless it's very carefully designed to handle this specific kind of problem, is going to be worse than just letting go of controls entirely. Of course, there are also design problems that are fixable. Asymmetric thrust is a good example. It's super easy to correct for it, especially, if you allow the control system to individually control thrust of the engines. In fact, making this work and having a stock system that can provide stability is actually a pretty good argument for having an assist. I also think there's a lot of ground for a compromise. Nobody thinks SAS is bad, even though it clearly assists in flying the craft. I would try to build on top of that and come up with something that helps like an assistant for complex craft that need it rather than a replacement for human pilot.

They as much as confirmed some of this. Yeah, there will definitely be some unique functionality with Steam OS. I'm just not sure it's critical for most PC gamers. On the other hand, new people coming onto the platform might feel differently. So we'll just have to see how much of an impact that makes in OS selection. Yeah, it's hard to get a good ultra-portable made for US markets. They just never took off here like they did in Japan. If I can find a nice keyboard, or better yet, if someone makes a flip cover with a keyboard specifically designed for deck, I might try using it as an on-the-go PC. I was actually looking at GPD WIN 3 for this very reason, but Steam Deck completely surpasses it in every way except for on-board memory. And even with that, Valve has confirmed that they are using off-the-shelf M.2, so even if it's not designed to be user-replaced, it should be possible. It's a short form-factor, but 1TB modules in that size are available, and by the time Deck arrives, there might be 2TB versions already.

Rogozin, you forgot to switch accounts. I'm not sure if it makes me feel better or worse overall. On one hand, problem exhausted itself. Great. On another, at no point did any of the systems decide that something's going horribly wrong and tried to shut down themselves. No safeties engaged, no cutoff triggered. It just went "%$#@ it, I'm all in!" If it had any more fuel to burn, it would happily rip ISS apart and keep going. That's terrifying.

Steam Deck might actually support Windows Unity games pretty well out of the box. It's mostly a question of how good the CLR emulation is going to be on Proton, and it sounds like Valve has been putting a significant amount of effort into it. Also, I'm not entirely sure that majority of gamers on Steam Deck aren't going to just pave over the Steam OS with W10/11 install instead. So long as AMD provides compatible graphics drivers, it shouldn't be a problem. So we might not see as much Linux gaming on Deck as people imagine right now. In either case, it makes more sense for Intercept to wait until Steam Deck is out in the wild and people are actually playing games on it before committing to it one way or another. But yeah, having more games come with good Linux support would be nice.

Mods! Honestly, I still hope we get some sort of a visual scripting system, kind of similar to how the mission builder works in Making History expansion, but with a bit more capability, and possibly being able to run custom scripts on specific ships - like maybe via a special part. That would let you build any ideas like the above into a series of custom scripts for whatever minigames you want. Making these an integral part of a game would also allow sharing scripts like that via workshop and then you wouldn't need to make sure everyone has particular mod installed before joining in. It can all be automatically shared from the server.

If you use the same trick he did for caching intermediate results and render it in a shader at a reasonable resolution, you can run it on a good GFX card. Lots of tricky math and good programming exercise, but very doable. Of course, if you want to be able to render a ship in transit, there is an additional challenge, since you can't just do an honest ray tracing of it. You'd have to utilize screen space information in a clever way. It won't be perfect, and you'll definitely have some distortions and smudges on the ship, but if it goes through quickly enough it should look ok. (If anyone is familiar with rendering screen space reflections - yeah, basically same problem.)

Eh. That's what mods are for. Ten internet points from my personal reserves to anyone who manages to implement realistic wormhole rendering in KSP2 mod, such as example shown by Scott Manley in the 360 Wormhole video.

Not with Unity. It doesn't scale like that. Even if you grab some exotic enthusiast grade CPU with absurd thread count on high performance cores, you aren't going to be able to leverage full performance of it, and there is no real way to distribute the load between multiple game servers without a major re-write to the core loop. If the game is well written, there isn't some silly cap on resources, and players don't build anything complex, something in health double digits might be doable. But I have a strong suspicion that you'll run into some bottleneck you can't solve with more expensive hardware before you're half way to 100 concurrent players. Now if the game handles ships that are landed or in good "parking" orbit elegantly, maybe you can have a few hundred players have their ships and bases in the game, but you'll still only be able to have a small fraction of them logged in and actively playing at the same time. Could still be interesting from perspective of player economies if there's a good system in place. There is a world where community writes custom infrastructure for this. The most mad lads thing would be a complete custom server written in a civilized language, like C++ or Rust. Problem is that you'd have to port every component, every behavior, every feature of every planetary body, make sure everything's simulated just so... Depending on how server-client is handled that can range from legendary challenge to impossible. But there is a more realistic scenario. Say you wrote a custom server that just handles open space in ballistic trajectories. So long as networking isn't too obfuscated, that might be a weekend project. Next, you make sure that while flying solo you can still interact with your craft and update server. If the game's client-authoritative on forces applied to piloted rockets, this might be a freebie. Otherwise, a bit of work is needed. At this point, this custom server can already handle a silly number of people - tens of thousands wouldn't be a stretch running in the cloud - who are all flying in the same shared space, but can't physically interact with each other. So the hard part is solving this interaction. And you do this by running Intercept's stand-alone server for every player hub. The easy version is to have pre-determined locations where players can meet up. Say, every planet and every moon gets a server. Maybe some specific orbits of some specific bodies as well for orbital stations. Only a fixed number of players would be allowed to gather at one of these at any given time, but you could absolutely instance it. So, like, if you are on Kerbin, you're playing on a version of Kerbin that has up to 8, maybe 16 players on it. But once you depart Kerbin and go build a colony on Lathe, or something, you could be meeting players from another version of Kerbin server visiting you there. Hence one big shared world for thousands of players. At that point, some sort of player economy would make sense, but it'd be basically up to whatever community builds all of that.

Correct me if I'm wrong, but I don't think there's anything concrete in that thread. Here's what I know. Intercept's LinkedIn page lists fewer than 30 people. Of them 10 have engineering roles, including one manager and one build engineer. There is no infrastructure, as far as I can tell, and only one engineer working specifically on multiplayer. Now not everybody is going to have a public LinkedIn profile, so we might not be seeing everyone, but this is a good starting point. Another point of information is that this is a Unity game. There are two general ways to build a real time multiplayer game in Unity. 1) You build it a lot like single-player game using Unity's native capabilities, making sure you specify what game state needs to be synchronized across network. If desired, this can be built as a stand-alone headless server for dedicated server deployment. 2) You write core game systems from scratch in whatever makes you happy. You then run the core either as a stand-alone server or as part of the game client, piping relevant information to game objects. Unity itself acts as basically a 3D animation player to render what's happening in the core. Option 2 is scalable and theoretically lets you stand up as many instances on your server farm as needed to support large number of players. It also requires a lot more engineering support. It only really makes sense if you're building your own infrastructure and focusing heavily on multiplayer. We don't see any of that at Intercept. This isn't something you can hide. So it is Option 1. With that first option, you are limited to two possibilities for core loop. You can have one of the players host a game and have other players join a game running on host's PC or console. Or you can run a dedicated server and have everyone join. Because it is a Unity server, don't expect miracles. It won't scale any better than running the game on your own PC. Which means the player cap is going to have to be pretty restrictive. They might not have a strict limit for number of people joining, but things will digress rapidly as more than a few players join. There are games out there that takes sort of a hybrid approach, where core game loop works via very limited co-op or PVP with just 2-4 concurrent players, but there's a larger metagame that's much more social. Unfortunately, even if someone was to come up with what that looks like for KSP2, even that would require more people working on infrastructure and networking, and we'd see evidence of it on LinkedIn in some way. So it doesn't sound like Intercept is even going to run their own servers. There might be something light for registration and user authentication and they might end up partnering with some cloud hosting service that will make purchasing server instances easy, but my guess is that if you'll want a dedicated server, it will be up to community or individual players to organize. So just based on the tech, that's really all that's left. Either you run your own game and invite a few people to join you across the network or you run a persistent dedicated server somewhere that allows several people to play on it concurrently. Think Minecraft multiplayer as a good example of what that might look like - you can have a lot of registered accounts, but not so many people playing at the same time before it starts struggling. There is still a lot you can do in terms of game design with that, but you have to stay within these technical limitations. Large multiplayer worlds just aren't going to be possible with what they have to work with.

You mean inter-player? Because I would appreciate it if people didn't build research stations inside of me. (intra- vs inter-) For comprehensive inter-player economies, you might need mods. Given the current team composition, I would guess that it's way beyond the scope of what Intercept is planning for multiplayer. But it is well within what you should be able to achieve with mods.

Though, if there is a dedicated server, I'm sure there will be mods that will let you play the game in a similar way.

I highly doubt that majority multiplayer will be anything other than inviting other players into your save game, effectively. Think Multiplayer in something like Terraria. So long as you can trust people you invite, it shouldn't be a problem. But hey, maybe have a backup of that saved game just in case. Now, hopefully, dedicated servers will be a thing at some point, and people will be able to host community servers. That stuff will take moderation. If you make it open, people will grief. If you don't ban people for grieffing, it will get out of control. But it's not really a new problem. Minecraft servers are kind of in that category, and so long as there are good community moderation tools or if you are a bit more selective about people you invite it should be fine.

That depends on nature of NDA and relationship between influencer and company. There are definitely examples of companies going exceptionally heavy-handed on this, but there are also examples of high-caliber influencers pushing back on that. The purpose of an NDA between a publisher and influencer is to make sure critical information that's meant to be revealed in due time isn't shared early. An NDA that prevents an influencer from actually sharing their opinion of the game is garbage, and it's not even an NDA at that point.

Depends on a lot of factors. Our best tool for measuring how fast stars are moving is still going to be red shift. That means that you have to be able to detect spectral lines. If you are looking at a star in our own galaxy, you can resolve individual star with Hubble and then you just have the spectrum which you can use to measure the movement speed precisely enough that you can tell what kind of planets are orbiting the stars by the wobble in speed. The precision of measurement can be as good as a few m/s. When looking at stars in another galaxy, you aren't going to be able to resolve individual stars, but so long as there are a few particularly bright stars in a "pixel" of the image to give you clean spectral lines, it's good enough. So for "nearby" galaxies at least, so long as their plane of rotation causes stars to move towards and away from us, we can do very good measurements on velocity distribution around the disk. These are precise enough for us to tell how much dark matter there is in the galaxy, for example, and we've been able to corroborate it with gravitational lensing in some cases. There is also obviously a limit to this. As you are looking further out, the stars are going to all blur together, and at some point, you're lucky if you can get an average speed for the galaxy. There is a way to put some theoretical limits on this using the size of the Hubble's main mirror, but I have a feeling that the instruments capable of spectral analysis aren't going to be able to have the same resolving power as the main cameras, so I don't know if that would be a useful estimate. Orientation of the galaxy will also matter. If we are looking more along axis of rotation, there is less red shift for us to measure. All of this combined, I don't really know at what distance the above methods are actually effective using Hubble.

That's actually a great point. Yes, spending time actually providing better data to influencers is absolutely worth it. I still don't think a blog post linked from a forum is the right way to do this. A modern marketing effort should include direct outreach to influencers, and whoever's in charge of that, should be able to figure out what information is useful to provide to influencers. Fortunately, most influencers that actually reach high popularity know that having access to information is helpful to their career, and treat NDAs very diligently. So you can usually trust them with information about the game, knowing that they'll be able to build up hype without saying anything you ask them not to share too early. Yeah, and it's a factor, but it tends to work as a multiplier. Prior to game's release, the only place where overwhelming majority of word of mouth originates is still marketing material. Again, very few people will have special insight into how the game is made, so most of the people saying, "Wow, take a look at this game, it seems fun!" are going to be influenced primarily by trailers. So the fact that word of mouth helps the information spread doesn't change your marketing tactics. In practice, very few people do. Ability to refund certainly helps, and very public disasters like Cyberpunk release help to improve the landscape, but the numbers still show that trailers and marketing sell the games. Just because numbers on this ended up fairly public, number of pre-sales of Cyberpunk that were not refunded was enough to cover cost of development, despite it being the most refunded (in absolute quantity) game on record. Any sales they made on top of pre-sales are cherry on top. It's very important cherry, so fortunately, there is still an incentive to make a good game, but marketing is so much more important to game's sales. And I'm saying this as someone firmly on the dev side of making games, absolutely loathing the fact that good marketing sells more games than good production. But I'm also involved in enough meetings where marketing numbers are shared to know that this is absolutely the case. And almost all of the marketing return is from trailers. How these trailers are shown to people still matters a lot, but it starts with a sequence of pretty pictures. I should probably add that I'm mostly talking about the sort of things that game creators have control over. Sometimes a game blows up because it became popular with streamers, and sometimes it's purely on good game mechanics. Games like Among Us absolutely deserve it, but it's also not something anyone can possibly take as an example of doing things right. And sometimes something becomes popular just because it's a meme. Either way, it's not something that helps you figure out what information you should or shouldn't share about the game in development, unfortunately. The only rule of thumb that's been developed is that it's more damaging to share too much than too little. And in that light, I'm actually glad whenever developers take a bit of a risk and give us some early previews.

It's entirely possible that they just really wanted the background with rings, but the planet that was supposed to go in there wasn't anywhere near ready enough for a close-up shot, so they dropped in Duna instead. So this very well might be a Duna/Ovin hybrid or something like it. The terrain does look very Duna, though, so I doubt this is actually something new either way.

I'm not sure you've spent enough time in modding communities of either of the games you are quoting. Back in GTAIV days I was helping out a team trying to port San Andreas to IV engine by writing an air sim, since IV had no planes. The team fell apart, so this was never finished, but I had a working prototype. I've put a video in a spoiler. Aerodynamics ran as a custom component tick on vehicles, read in relevant parameters, computed aerodynamic forces, and applied them to vehicles. It also controlled animation on relevant control surfaces. The mods worked as injected C++ code and could control just about any aspect of any spawned entities or spawn new entities. With GTA V, the modding tools have only become more complete. I can say with confidence that it's easier to remake entire KSP in GTA V than it is to make anything like GTA in KSP. And this is based entirely on community-made tools. R* has never intended for their games to be moddable. Skyrim's only problem is a really bad, really outdated engine. There is absolutely no limit to what you can do with mods there other than just the engine sucking abysmally. There are complete overhauls of magic, combat, crafting, etc. If you look at what people have done with mods there, it's way more extensive than any other game out there. People have made entirely new games in Skyrim. Although, they do tend to stick to the theme, because if you're not sticking to it, then you might as well work with FO4, which also has plethora of complete overhauls. And, of course, you have to remember that real mudding started with id Tech games. I learned a whole lot about game programming by making Quake II mods. Later, I've messed with HL2, which is its own engine, but heavily inspired by design and style of id Tech. These were games made on in-house engines that were good enough that these engines ended up getting licensed out. But they were first-party engines first and foremost and they are practically responsible for us having expectations of mods that go beyond simple graphics replacements. The only thing Unity has going for it as far as mods is that there's already a huge community of people creating tools for modding any Unity game. Which means that even if Intercept isn't going to put in an effort into allowing mods, people will be able to mod KSP2. Which is great. But first party mod support is always better, especially early on. And it's actually easier to give people modding tools as a developer if you have full access to all aspects of the engine. Allowing for easy mod import in Unity requires adding side-loading capability, which is not something Unity is designed to handle gracefully. Unity expects all of your assets neatly packaged, and working around it actually means inventing back doors. You don't have to do that if you have your own engine. Games by Bethesda, id Software, and Valve that are designed to work with mods will specifically search directories for additional archives, scripts, and even dynamic libraries to load because they are designed to be moddable. Which means you can package new assets and game code in the way that engine actually expects it to be formatted making results far more consistent. Sure, but no explanation of early work is going to do anything for majority of people who might buy KSP2. The percentage of people who are going to read any kind of explanation on a forum is tiny. Most sales will be made on trailers and marketing that will be released in the last couple of months before release, and these will be tightly polished just to show the game from the best angles. None of it has anything to do with how the game might or might not run either now or in the future. It sucks, but games just aren't sold on facts. They're sold on pretty trailers.