K^2

Yeah, but that's less than two months on 100k warp! Start a server, join in ever few days to check in and make course corrections. Piece of cake. P.S. Yes, I do really enjoy the sci-fi trope of the FTL civilization catching up to a cryosleep vessel that's been coasting for centuries, why do you ask?

Multiplayer and modding are a complex topic. The short of it is that it will be largely on mod developers to write mods with multiplayer in mind, and on whoever creates a server to make sure the mod list only includes mods that work well this way and also make sure that there aren't any performance issues. Joining a random server hosted by some random fellow KSP enjoyer might not always work out. There are also some aspects of it that Intercept need to get right, but it mostly involves exposing whatever they end up needing for networking the various game parts to the mod API.

Good riddance. I don't want to sound dismissive of players who play games on consoles and haven't updated the hardware yet, but developing for gen 8 consoles was a nightmare. The original models in particular, before the Pro/X versions, had some ridiculous CPU performance issues. Cache would invalidate when you looked at it funny, and sometimes it took the pipeline with it. Trying to get even the bare minimum 20FPS out of some games was an agony. I wouldn't consider any of the games made for these consoles as ethically sourced. People have suffered to make these games. Yes, I'm being a little dramatic, but it really was not a good experience, and I'm happy Intercept doesn't have to suffer through it for KSP2.

"Nerva?" says Jeb, as he straps himself into a command chair sitting on top of an SRB stack.

We sort of have this option now with orbital assembly. It's of limited use in current challenges, though. You could save a bit of weight by moving one of the descent engines to an ascent stage of a staged lander, for example, but often it's just easier to build a single-stage. Of course, being able to scrap parts back into resources and use these to make new parts would be rather a change. That might alter how people plan for the mission.

Yeah, they were trying to make me into the 3rd generation. But fortunately I was already quite capable with C++ and quickly found that GNU F77 compiler is binary-compatible with the GCC, so I was able to pull the Fortran numerical libraries into my C++ code as if I was importing C libraries. I also re-wrote a few simpler routines for Gauss quadrature, etc. And this is a big part of why I would never want to deal with something like Fortran for a mod even for a joke. There are funnier languages that don't hurt my soul half as much.

Grand Tour rules allow ships to refuel, that is, to harvest materials and refine them into something that adds to the ship. So naturally, should the ship be able to manufacture parts for repair, it would be strange for the rules not to allow building replacement parts from harvested materials. Skipping through the Ship of Theseus right to the point where we have a second ship made out of discarded parts and the question of which one is the original ship, we clearly have a path to making two ships out of one without ever deviating from the typical concessions of the Grand Tour rules. Also, I don't know about you, but as someone who self-replicated from a single cell, I would feel hypocritical to deny it to a vessel. On a slightly more serious note, yes, I do suspect there will have to be subcategories. I believe, "No refueling," is already a typical subcategory, so part fabrication would likely have to be a category split as well. Especially, if orbital yard components aren't available for ships in stock, requiring a mod to actually do any of this to begin with.

That would require some advanced scripting.

This got my gears turning - though, I'm sure other people considered it before. Presumably, an orbital shipyard can be in any valid orbit. So really, its distinction from a ship can't be all that much. So does it mean that we'd be able to use any orbital colony modules on a ship? And if not in vanilla, how hard would it be to enable that in a mod? In regards to the challenge, the interesting use case is an interstellar colony grand tour. Sending a massive ship that can break into individual colony seeders in a target system is definitely going to be the fastest way to do this in creative, but if you have to extract resources to build it in the home system first, that could be the bottle neck. So why not Von Newman this? Send a colony builder ship that can build replicas of itself to a target system, and use local resources and the power of exponential growth to get all the colonies seeded much faster!

I had to do Fortran in university, because a lot of the theoretical physics is done by people who never studied comp-sci and learned everything about code from their advisors, who learned to code in the 70s. What would you say is the exact opposite of the enthusiast? We still likely to need plugins for some mods, and these would still have the same limitations in terms of security as they do now, meaning we'll probably end up needing a 3rd party mod manager for them. But if Lua scripting for parts is included, and we can have a lot of mods running just through that, yeah, it's entirely possible that you'd be able to auto-download mods when joining the server, and if you want to add mods for your own local game, you can get them from Steam Workshop, for example.

KSP handles fuel cross-feed in a very stupid way. To the point where it can be the main reason for abysmal performance of ships with very high part count. I haven't heard anything, but we're hoping Intercept fixed that in KSP2. There are also things that are genuinely challenging, like the ship physics. There are optimizations that KSP didn't take, and we know that Intercept at least considered some of these at some points. So the expectation is that things will be better. There are additional optimizations that can be taken by switching from PhysX to Havok physics in Unity, but I've heard no indication that this has been done. There are good reasons to believe the game started out oh PhysX, and it would be a significant undertaking to convert the components to work with Havok instead, but it could have happened I suppose.

We had some major planet quality overhauls since .90 and the part count and fidelity exploded. These things should be close to final in KSP2 early access. The only part that's going to be big, new, and add a lot of additional resources will probably be colonies and space stations. I'm a bit concerned about these too. The part that makes me somewhat optimistic is that this shouldn't be a surprise for anyone, so hopefully, it's something the team thought about a lot and has a plan to make sure there is no (significant) performance impact. Colonies can probably be folded into the terrain tech, for example. I've never had to make an engine support a full planet with player ability to build a base anywhere they want, but I have had to support an engine that supports dozens of square kilometers of complex terrain with various environments and a team of artists who might decide to add some buildings anywhere they want. And in my experience, treating terrain, buildings, and randomly placed objects (trees, bushes, rocks...) as part of the whole at the high level, assigning them to LoD tiles, etc, and then taking specific low level optimizations where you can (like terrain being a height map gives you some neat shortcuts) only once you have the high level taken care of. If that's the approach taken, I don't think colonies should present any overwhelming obstacles to keeping the load times down. Stations are a bit trickier. In a lot of ways they're like colonies, but you're much more likely to be zipping past one at 5km/s. And while that's obviously a problem with KSP stations already, these have always been small enough to where you can gloss over that. (E.g., collision usually doesn't even work, as it's only checked once per frame in KSP) With KSP2, stations can get much larger, so you can't just pretend they're not there if they haven't had time to load yet... So I don't really know what the plan is. One way to address it is to expand the LoD approach to space as well, with the space divided into some form of sectors. SoI are a good starting point, but you'd need to further subdivide these, and then start loading things in advance as you're sort of moving from sector to sector... *shrug* Hopefully, people who have been thinking about it for a few years, rather than five minutes, have better solutions. Ah, right, almost forgot: Interstellar. Yeah, there are additional challenges with that one as well. But it really comes down to all the same problems you have to deal with when you have one star system. If you manage to load your resources without a CPU overhead and your planets stream, well, you don't have anything to worry about. If you already have some loading hitches in Kerbol, they'll get roughly twice as bad when you add Deb Deb. Fingers crossed!

Personally, I think the best design would be go with minimalist set, kind of like KSP - where I think even xenon might have been an overkill, but then instead of hard-coding the game for resources X, Y, and Z, have a table of them somewhere that mods can add to, and have the relevant parts tagged with the relevant fuel type. If you want to make a mod that adds Unobtanium as a new fuel type and add Unobtanium tanks, engines, and cross-feed rules, it's just a resource config file + matching tags in the mod part configs. That way, an average player is not overwhelmed, and the modding community will be on it to make "Realistic Fuels Overhaul" mod within weeks. That will probably keep everyone happy.

The answer to "Can this be done in Unity if it can be done in a custom engine?" is always yes. But, of course, the real question is "Is it possible with the time and resources?" And that's, of course, a much more relative question. I have not analyzed how the KSP loading works in a while. I'm mostly going off the fact that the current loading is still CPU-bound, not IO-bound, so I don't expect much changed from the early days. One thing that used to take up a lot of loading time was the part config parsing. This is absolutely something you can fix in Unity if you're prepared to make some sacrifices. The standard C# way is to make sure that your classes holding your configs are public POD classes marked as serializable, and you can then dump their contents to the file, or read these contents back. The sacrifice is having to build assets for every platform and every version from scratch and if there's a major change from version to version, like a new field in one of your configs, you may end up with an offset change that will result in a large patch size. Still, even if some patches have to contain the entire binary dump of the configs, it's not the worst thing in the world, and you're probably doing clean builds of your project for every platform and version anyways. At least, you really ought to be doing that. Similar techniques can be applied to loading things like geometry and textures. Unity allows you to lock off relevant buffers for read/write operations, meaning you can go as far as grab the mesh you have in GPU RAM, dump it into a binary, and save it to disk. (You can also compile these yourself, which is a better option, but that's a tangent.) Then read just these binary blobs into memory when the game starts, and build the mesh for the scene when it becomes relevant by doing exactly the same operation in reverse: construct a blank mesh object in Unity, lock its buffers, copy relevant data from RAM, and unlock the buffers. I've done something similar to load 3rd party assets in 3rd party format that Unity doesn't know how to parse without needing a converter. It's not the most pleasant code and API to work with, but it's there, it works, and it is stable and performant if you write your loaders right. There might also be shortcuts in modern Unity that make this a little cleaner and require less engineering work. Finally, there's the question of time it takes to switch between different game screens, and I believe it's because they are actually different Unity scenes, and switching between scenes takes a while. If that's the reason, the standard solution is to not switch scenes. It shifts a lot of responsibility for managing the resources from Unity onto the developer, but this is precisely how most open world games used to solve this problem. You don't rely on Unity, and you do your own loading or streaming as necessary. Maybe recent versions of Unity provide for a better way to do this, but at least the option is on the table either way. How much of this can we reasonably expect in KSP2? I think serializable configs should have been on everyone's mind, because you kind of use similar techniques for networking. You have to turn your classes holding the ship states and turn them into something you can send across the wire. There are different ways of doing it, but some kind of serialization is going to be a part of it anyways, and you might as well recycle the tech for resource loading. Looking at the planet tech, I can also say with certainty that Intercept has people that know how to make fast resource loading a thing. So the capability is definitely there, and we're just looking at whether they had the time to do it. My guess would be that delays on some other game systems and multiplayer will hit gameplay and multiplayer engineers a lot harder, giving some slack for the engine tech people to do some additional improvements. So hopefully, this is one of the things that made the cut. If they can stream planets, they ought to be able to stream ships. Finally, scene switching is probably the most painful part. It's not so bad if you designed the game that way from the start, but if Intercept already had the VAB/Hangar as its own scene separate from the rest of the game, it might be too time consuming to fix it once the game became big enough to start causing loading delays. It's very hard for me to say if it's something they'd be willing to spend time to optimize given the development timeline. And again, since I kind of expect the feature work during early access to fall on gameplay and multiplayer engineers, I fully expect additional engine work being targeted at performance, both runtime and loading. So what we get day one and what we get when the game gets its full release might be very different.

I wanted the suggestion to be sadistic, true, but I'm not a monster. There are limits.

No, you right. We shouldn't be arguing about it. Once the mod tools are available, we can just make a plugin that exports all of the mod API bindings to Common Lisp and then everyone will be happy.

And that can be greatly improved by packaging the assets differently. I really hope Intercept has done something about that.

Depends on how clean Intercept keeps their builds. My general experience, both as a developer and from my past as a modder and a dataminer, is that features get disabled in the most lazy way possible. I wouldn't be surprised if someone out there manages to get some early WIP version of multiplayer working in early access by making some config changes. In general, a lot can usually be learned about upcoming features from studying early access and beta builds, but I also expect that much of the relevant discussion will be against the forum rules, so we'll probably be learning about these finds through hearsay or other sources.

Yeah, but it's also used for jet engines, and the density doesn't make sense. FL-T200 holds 1T of fuel and oxidizer and has a maximum usable volume of about 1.5m3. There is no way to hold that much hydrogen in such a small volume. However, this is plenty for methalox or kerlox, both of which have an average density around 1T/m3, which allows for some usable volume loss to internal tank structure and plumbing. In principle, while kerosene would be an absolutely awful fuel for a NERVA, methane isn't quite as bad. You can get about 30% of ISP you'd get from hydrogen if you run with methane instead, assuming methane decomposes into carbon and H2 gas in the core. And while KSP's LV-N engine's impulse seems to be based on real life NERVA, theoretical maximum for NTR is closer to 2000 seconds for a gas core, which would bring us up to about 600s on methane. It's still a little lower than what we see in the game, but it's starting to get to a point where I'm prepared to accept, with a stretch, that maybe the liquid fluid is liquid methane. Of course, a very strong argument could be made that it's just kerosene, and we shouldn't be considering LV-N in this picture at all, because Squad is on the record that they didn't want to add yet another kind of liquid fuel.

Please attach a debugger to the actual native compiler in CLR, Mono, or any other bytecode interpreter with JIT capability. Not a single one of these will compile the entire bytecode at initialization, unless your program is literally the Hello World. The simplest of these will compile functions on first call. Modern implementations don't even always do that, and absolutely all of them have some capability to interpret bytecode directly, at a minimum, to discover entry points to functions that need to be compiled. That's literally the concept of JIT, and if you ever debugged a language runtime, you should know that.

There is not a single modern language that compiles to assembly. Lets get that out of the way first. It's just not done. You can ask some C++ compilers to dump assembly code, but even that, in practice, is usually achieved by disassembling output binary. Assembly is not a good choice for intermediate language, and so it is simply not used. JIT turns bytecode to machine code during runtime. That's literally it's job. Please consider reading up on JIT and how it's actually used. A compiled C# program is stored as CIL and does not turn into machine code until execution, and only as necessary. A typical JITed interpreter will still elect to run bytecode in pure interpreter mode until it becomes a performance penalty over spending time to JIT the code. This is a standard feature of CLR, Mono, V8, LuaJIT, JVM, and basically any serious JITed interpreter. I stand corrected on use of CLR. Older versions of Unity were relying on CLR on MS platforms, but yes, it looks like recent versions have switched to Mono entirely.

Galaxies are typically grouped into clusters, with galaxies roughly orbiting the center of mass of the cluster. That CoM might or might not contain a particularly massive galaxy - kind of similar to how the stars in galaxies orbit center of mass, which might or might not contain a particularly massive black hole. Clusters are typically grouped into superclusters, which are more loosely bound. Milky Way is part of the Local Group cluster, which itself is a part of the Lniakea Supercluster. The superclusters together form galaxy filaments, which all together form the known universe. At that scale, talking about orbiting is kind of silly, as the universe is expanding, stretching and tearing the filaments like cotton candy. The name of the filament we belong to is Pisces-Cetus Supercluster Complex.

They use a custom implementation of it. It started of as an off-the-shelf implementation, but they've since replaced it with an entirely custom Lua engine that does some very clever optimizations and JITing. Ok, there are a lot of misconceptions here. Lets start with C#. C# scripts for Unity components first get converted to Common Intermediate Language (CIL). There are three ways that can run. Unity provides a transpiler that takes CIL and converts it into C++ code (IL2CPP) that is then compiled to native code. That is your best performance. Still not as good as writing C++ code yourself, but very close. However, it's not always an option for plugins, as the C# code for IL2CPP has to be available when you build the game. If you're making your own plugin, you can absolutely just write all of your performance-critical code in C++ or have your code likewise transpiled into native, and then bind it from C# layer. But any C# code you ship with your parts is going to be interpreted from CIL directly. So that leads us into two other ways Unity runs C# code, and it's by using either .NET Common Language Runtime (CLR) or Mono. Former is available only on MS platforms, and the latter is available for the other platforms KSP2 is likely to ship on. Both will optimize CIL further and use JIT (Just in Time) compilation to run the code. This is slower, but not by a lot. Typically, you'll get about 20%-30% performance of native with CLR and a little bit worse with Mono. Next, Lua. Lua is compiled to Lua bytecode. There are ways to convert that to native code, but that completely defeats the purpose of using Lua in the first place. The only benefit of using Lua is running it in an interpreter sandbox. The typical way to run it is using Lua's own runtime, which is a pure bytecode interpreter. It is comparatively slow, about 10x slower than CLR and Mono on average. There are projects that are designed to bring in on-demand optimization and JIT to Lua, like the aforementioned Roblox runtime and the LuaJIT project. The latter is publicly available, but it's relatively new and I don't know how good their sandbox security guarantees are. Since the only reason to even entertain Lua code for KSP2 mods is safe portability of code, odds are, if we're getting Lua in KSP2 for mods, it's the slow, official version. Now, 20-50 times slower than native is still blazing fast in the absolute terms. Most mods I've seen that have custom code for custom parts does not need full native performance. A few percent of native is fine. If you want to write a custom IK solution for a Canadarm part mod that automatically moves modules on your station, Lua is plenty fast enough. If you want to run dynamic trajectory estimates, you'll want to be careful about how you write your code, but you can get away with Lua. The place where Lua will start struggling is anything to do with graphics. But I'm not sure we'll be able to do much with custom displays without C# anyways. See above. This is only the case if you specifically enable IL2CPP, which converts to C++ (which never becomes assembly in modern systems), and this only works for code that's available when you build your project. If you want to import things dynamically, best you can do is interpreting CIL or Lua bytecode, depending on the language. No. You use language reflection and it's automatic. You literally just have a line you paste in front of a function you want to be accessible from Lua. Of course there is. You simply don't allow a client to connect to a host unless the client already has all the plugins that the server is running. That's how it's done in literally every moddable multiplayer game. You both must have the mod installed.

The incentive is that if I make a mod with a native plugin, I can take full control of your computer if I'm a malicious type and convince you to downnload my mod. That means that if you join a multiplayer server, having the server share native mods with you is a huge security hole. This creates all sorts of complication. Lua runs in a sandbox. If properly set up and properly patched, there are no known ways to exploit it for an attack, meaning you can just download all the mods from the server when you join a multiplayer game. Likewise, for sharing modded parts, you can utilize things like Steam Workshop, have modders upload their mods there, and have zero risk when people download these. Lua is by far not the only way to do this, of course, but there is also no reason to add yet more complexity for this if Lua is already being used. You don't put it on a job requirement like this unless it's actually heavily used. So yes, it might be entirely internal, with no user-facing interface, but we know that Lua engine is in and it's heavily used by the game. Once you have that, creating bindings for a mod is actually very easy in C#. C# supports custom attributes. So any function you create for use with modding API can simply have something like [KSP_Lua_Function] attribute in front of it and it's now available in the Lua API. That's it. Last studio I've worked at, we did this for Python bindings in our dev tools. It was all internally facing, since we didn't ship our tools, but it made writing Python script for our tools and content validation a cakewalk. So again, this is hardly confirmation, but we know that the Lua engine is in the game, there was interest in and at least some work done to expose Lua to modders, the additional workload is trivial - as the modding API C# functions have to be written anyways, and the binding attributes have to exist for internal use already, and there is a strong incentive to make this available to modders to avoid security problems when sharing mods. At this point, my confidence in this being a feature usable in KSP2 modding is well past 50%, though still far from certainty until officially confirmed, of course.

It's a little bit more complex than this, because you build geo out of textures, and how you handle boundaries between LoD tiles gets a little involved. There are also non-trivialities about how textures are mapped, especially once you get into virtual texturing. As for procedural placement, the technique used in KSP2 is some sort of an evolution on Horizon Zero Dawn's approach. I've linked a couple of videos in a spoiler bellow if you're interested in a deeper dive. Collisions run on the server. Not only to stop players from cheating, but also because mob AI and movement runs on the server, and it can also be relevant to some power effects. So the entirety of the level geometry, nav beacons and meshes, various event scripts, FSMs for the AI... There are a lot of game assets the server needs access to. Obviously, without textures, animation, and audio, you get to cut a lot of the memory footprint compared to the client, but it's still a non-trivial amount of data. If you duplicate it across the multiple server processes running on the same physical server, it eats significantly into RAM you can use for game state, meaning you can run fewer game instances on the same physical server. When memory sharing lets you run 5 instances of a dungeon instead of 4 on the same machine for the same $$$, you spend the effort to implement memory sharing. There's also a bonus that spinning up new instances becomes a little faster. But that honestly wasn't the economic driving force behind maintaining this feature.