K^2

Given that my previous post stepped over some ToS/EULA bounds (sorry), the short version is that I severely doubt that this would be workable out of the box. But it might be possible with some extended modding. Whether that extent would be possible without violating EULA, and therefore, the ToS of the forum is a big question. But maybe we can get some sort of a sign-off from Private Division under an NDA to dig in the internals. There is precedent of this sort of thing happening in other games. It might also be possible to build a custom server under clean room conditions, therefore, not being in violation of EULA, but that's another level of challenge and time requirements. I've done that kind of work for Minecraft, but that's a much simpler game with much simpler server-client relationship, to put it mildly. A custom server would also need an access to all the stock parts, and whether extracting that data will be in line with KSP2 EULA is a big question. Some moddable games do come with EULA that allows this, so it remains to be seen what the case with KSP2 will be.

We've had a job posting in February of this year for a Mission Designer, which explicitly required knowledge of Lua. So we know that these experimental bindings turned into the way missions are done for the game at the very least. I have not personally seen where the confirmation of Lua for modding comes from, so just going along with what @GoldForest says. It would make perfect sense to allow Lua scripts on parts if there's already a support for it on the missions side, because that does expand what you can do with modding in multiplayer, but it'd be nice to see a link to an interview or an article that states that this was, indeed, implemented. For reference, here's the thread about the posting. Unfortunately, the posting itself is no longer available, and the only surviving bit seems to be the part I quoted about Lua. (Wayback machine was of now help, since this is a dynamic page.)

In the QA, yes, but it really doesn't matter nearly as much as what the devs are going to be actually working on. This is about the processes within an actual studio. It's about how we make games in the real world. In a perfect world, there are constant tests on the entire spectrum of target hardware, both done by humans and automated, any issues are promptly recorded, reported, and are scheduled to work on by both the engineering and content teams to rectify. In reality, I have not seen this happen in a single studio I've worked at, nor have I heard this perfect world scenario from any co-workers. And I've worked on everything from start-ups to decades old gaming giants, having shipped games with budgets well into 9 figures. The reality of what we do in the industry is that the game is tested on the hardware that sits on the developers' desks. This is why having everyone work with a console dev kit is a huge deal, even if you do expect the game to ship on PC first. I don't know if Intercept has a PS5 and/or XBSX on every dev's desk, but regardless, since the PS4/XB1 are out of the picture, the slowest drive the developers will have to deal with is going to be in their work desktop. And we really want to have the fastest SSDs available. Dev studios started switching to NVMe M.2 drives on dev machines basically as soon as they became reasonably priced for 512MB+. The reason is that we sometimes have to reload fifty times in a day. If the game takes a minute longer to load from a slower SSD, that's an hour of your work day wasted. A $1000 M.2 drive and compatible mobo is still cheaper than the engineering time lost in a year with a fast SATA SSD. Is this an ideal situation from perspective of reaching your markets? No, not at all. But if we were simply targeting the hardware people have, we'd still be making PS2 games. The reality of gaming business is that it's not just flashy tech sells. There is a vicious feedback loop where the engineers have to work on much better hardware than min spec, and because of that, the games end up running like garbage on min spec most of the time. No matter how much QA complains, there are usually higher priority problems, like performance hitches or outright crashes, and these have to be solved before we can work on optimizing performance for the min spec. So with every release, the plank for what's acceptable gets pushed further out, even if there was no hype from the gamers themselves to buy flashy new hardware. This cycle is a big part of why gaming hardware becomes obsolete, and right now is the time for mechanical drives to die. In truth, even the SATA SSD should have killed the mechanical HDD, but the part in all of this that might not be obvious is the relationship between game developers and console companies. If we want to ship on MS and Sony systems, we have to follow their license. And the license says that we have to support all of the "current gen" hardware. The exact SKUs change over time, and until recently it included at least all versions of PS4 Pro and XB1X. These still had mechanical HDDs on some SKUs, meaning we still had to support these. With gen 9 finally here, this requirement is dead. Game developers are no longer required to support HDDs. At all. There's going to be push-back from marketing, but it's going to be overwhelmed fast. By the way, if you're wondering, it's the same reason why ray tracing is gaining so much traction. The visual quality is not that much better, if at all, compared to a good light probes implementation. But the light probes can take hours to build. And you have to rebuild them any time you change level geometry. I can wait for that to go through the builder, or I can just disable the probes and run with ray tracing, which is instant. So any game that has RT support is getting more love and polish on RT than on probes, and this is only going to get worse. Yeah, it's expensive having all of these extra RT cores, but it saves us a ton of money making the game, so we're going to keep pushing this tech until everyone agrees that RT is just a standard requirement now and you have to have RT capable graphics card to play games. Even cheaply-made asset flips. So yeah, this is the direction things are going. Of course, we're still all going to use HDDs for bulk storage for years to come. But games will have to be installed on something a lot faster. And we're likely going to see a push to get better DMA hardware on mobos as well in the coming years, to get some of the same on-the-fly decompression features that we see on PS5 and XBSX. Sorry about the giant wall of text and a bit of a detour into game development in general. Hopefully, this isn't too off topic.

That's what people said about 3D gfx cards back in the late 90s, and then the devs jumped on them, and you just couldn't play any games without having one. Yeah, most games still had software rendering (for a while), but they ran terrible and looked horrible. So everyone sighed and bought graphics cards. At some point, if devs only bothered to implement a certain subset of hardware properly, there isn't much you can do but roll with it. If game streaming starts relying heavily on NVMe M.2 speeds, and that's the only configuration that gets properly tested throughout development, pointing out that a lot of people still have older hardware isn't going to help.

I mean, it depends on how much work you need done. If you have a few lines of script you need to make your component works, which is going to be most mods, I suspect, both the compile (loading) time and performance hit are going to be absolutely insignificant. If you have a huge complex library of stuff, yeah, you want a module, and keep any Lua interactions down to hooks if needed at all. Either way, I'm glad they're giving us both options. That's fantastic to hear.

Oh, good. But yeah, dev PCs would typically have SSDs regardless, and now people are shifting to M.2 drives on dev simply to speed up builds and reloading, even if consoles aren't a factor. The PS4/XB1 dev kit that sat on your desk was usually the place where you'd get to see how the game runs with older HDD. With these out of the picture, you really don't see mechanical HDD performance outside of QA tests, and that sort of thing tends to fall between the cracks. Obviously, I can't talk specifically for KSP2 development. They might be a lot better about testing on older drives, but M.2 or some future equivalent as min-spec is probably something we should all be preparing for in PC gaming in general. Can? Yes. But it's actually a pain in the butt to build and maintain. Any time you have two different branches depending on spec, one of these will almost never happen on dev machines. (We've typically had 64GB+ of RAM for builds, etc.) And when this happens, the unused path invariably breaks. A good example is a major optimization we've had on a certain MMO, where on the server, map assets could be shared between several instance. Each instance is its own process, but since RAM was a bigger limiting factor than CPU, a single server could run 4-5 dungeon instances so long as it shared "static" assets. Problem is, memory sharing had to be enabled (I don't know why this wasn't standard,) and so we'd CONSTANTLY get bugs where someone finally runs the code with shared memory enabled and everything crashes.

That's actually an interesting one. So if this was just a drag race from point A to point B over interplanetary distances, yeah, duration of the burn trumps a burst of power easily, and you're really just looking at getting as much impulse under your bell as you can. But if you have to hit multiple moving targets, now things get interesting. If you get up to 100km/s going to Jool, great, but your turn radius is now half a star system wide. How are you going to visit the moons? You'll have to slow down, then perform sharp turns and speed up again. That means high thrust for the turns. And you don't want to lug a chemical engine with you, unless this is your last stop. The only thing that's going to give you a lot of "thrust' over long enough duration for these turns is gravity assist. So now your race is less about the engines, because, yeah, you pretty much have to go with end-game interstellar to be competitive, but so much of the race duration is going to be about optimizing the route. I suspect we'll see some serious computational power thrown into analyzing the KSP2's Kerbol system, ideal departure times, and best gravity assist trajectories. These Grand Tour best times are going to be WILD.

Yeah. The advantage of going with Lua (or some other properly sandboxed language) over native modules is that it's much safer to make them portable. So hopefully, there won't be any problems joining a MP game where a host is using a custom part with a Lua script attached, as the script can be safely downloaded. Or have the scripted parts and missions available on the Workshop. Though, have we had a specific confirmation that we'll be able to use Lua for modding? When it was first mentioned, it was only confirmed for missions, but that was a while ago, and I'm sure I could have missed additional info.

We're honestly moving away from the assumption that the primary storage is going to be a mechanical HDD. Most modern games are developed with consoles as a primary platform, as they tend to be the cause of performance bottlenecks, and gen 9 consoles are absolute monsters as far as streaming data from SSD to RAM goes. On top of that, most studios will have very fast SSDs on dev machines to speed up the workflows, so with gen 9 development, even if somebody is testing their builds on PC, there is no longer a point in the development cycle where you're going to be streaming from a slow HDD. There's a bit of a time lag until these kinds of studio changes start impacting the actual games, but we should be just about entering a generation of games that are developed entirely with the, "Oops, we forgot to test the streaming performance with HDD before going into beta. Oh well," kind of attitude. Because of that, I fully expect M.2 to start showing up as part of the system requirements on the new games. Will this impact KSP2? I don't know. The PS4 and XB1 are still listed as targets, but with the release having been delayed as much as it was, and with these consoles having such major CPU bottlenecks, I am not fully confident that Intercept has been doing a lot of tests on these. My honest expectation is that we'll probably see at least the planets shifted to streaming. There's so much more data for the terrain in KSP2 compared to KSP, that I'm having hard time believing that the team would opt to keep this in memory. On top of that, they seem to be using a lot of techniques common to open world games, which are heavily relying on streaming. So planets should be covered. But that does still leave ships with custom parts, and that might still have to be resident in RAM, and part mods might still have just as much RAM impact as they do to day. More, actually, since there will be more material textures.

Indeed. You have to make sure you make use of the instancing, which both the Unity and the PS4/XB1 era console support, but then you can get away with pretty dense vegetation. We've been able to run a dense jungle with procedural vegetation using a technique very similar to what KSP2 is using, down to the middleware used for trees, and we had stable 30 on PS4 Pro. Custom engine, etc., but we weren't doing anything Unity shouldn't be capable of. The limiting factor for gen 8 consoles is going to be the CPU, honestly. And you have to be a bit clever about how you do culling and clustering for the instancing to make sure the CPU isn't busy generating draw calls, but Unity mostly does that for you. I'm still very much concerned about KSP2 running on gen 8, but that's purely because of all the things that the game's doing that are unique to KSP - resource management, aerodynamics, trajectory updates, etc., especially if any kind of warp is involved. In the original KSP, this was not very well managed. It sounds like Intercept has put in a ton of work to make that better for KSP2, which makes me more optimistic about performance in general, but I do expect gen 8 to struggle with the game regardless of the vegetation and scatter on the planets.

If US simply didn't get their hands on it, the mere existence of V2 and Soviet interest in it would have been enough to get the spies working, and I'm pretty sure the time lost would be minimal. Maybe a year or two at worst. If German research didn't exist at all, it's not clear how long it'd take for everyone to realize the potential. Still, I don't think it'd be a lot more than a decade lost even in that case, since the jet propulsion programs existed outside of Germany, and the rising nuclear threat would push both the US and the Soviets to look at the ways to chuck nukes longer distance. It's very easy to imagine that without the V2, nobody would think that building rockets to push conventional bombs would be worth the expense. With nukes, even if the rocket is very expensive, ability to launch something hundreds of kilometers and drop it from altitudes that prevents any sort of intercept with these day's technologies would make it an absolute must-have technology for any nuclear power. Which means something like V2 would get worked on, developed into longer range ballistic missiles to try and push them intercontinental, and that naturally leads into space flight.

It's actually easier at low pressures. I know it sounds unintuitive, but there are two ways a gas molecule (atom, ion...) can lose thermal energy. It either emits a photon or it bumps into something. If the density is low enough, the collisions are going to be very rare. So we're looking primarily at losses to radiation, and the thing to keep in mind is that at frequencies where emission is high, so is absorption. If a photon is likely to be emitted, it's likely to be absorbed again, meaning the energy didn't leave the cloud. So despite potentially being fairly transparent in some wavelengths, the cloud has to be fairly opaque in wavelengths where it can lose energy to radiation, and so it's mostly going to be radiating from the surface. This is where the square-cube principle comes in, and it's a LOT of volume that has to lose heat from just the surface. So it shouldn't surprise you that it takes a very long time for any trapped heat to exit. Vacuum is a great insulator, after all. We tend to think of that as a feature of something like a thermos bottle, but it's effectively the same principle for a giant cloud of gas in space, except stretched to interstellar distances.

Models themselves should be fine. People might have to re-export with tangents built, but that's about it. Textures on the other hand, yeah. There are different ways to set up PBR shaders, but typically you'll end up with at least one extra map containing things like metalicity and roughness of materials. So that'd have to be made from scratch for every model. Supporting thrust during time warp is going to be a big deal. You'll also care way more about integration stability, so I'm pretty sure @GoldForest is right here, and it's pretty much a clean re-write. But I haven't looked at the Principia code, so maybe they already set it up in a way that'd make it a lot more straight forward.

PhysX isn't used for orbital calculations. It's not what it's for. The trajectory computation is custom. That said, numerical integration of gravitational interactions is notoriously unstable. You either have to make the time step very small even with RK4, or have to rely on very collocation methods. Either one brings its own limitations. Now, technically, since KSP2 will allow us to time warp with engines lit, you have to do this anyways - you can't just keep the ship on conic section rails if its engines are firing, but if the engineer Intercept hired to do physics really knows his stuff, he might have implemented a perturbation based approach, which allows you to basically run a step as if its on rails, then make corrections for external force. If that external force is a constant within the time step, as engine's thrust basically is, you can get wonderful precision with RK4 or even a velocity Verlet method. The math for it is a bit fancy, but that engineer has a background in finite element analysis, IIRC, so I'm cautiously optimistic. If this is, indeed, what's being done to improve the precision of trajectory computation while time-warping with engines on, then it's a fantastic reason to stick with patched conics. N-body is fun and all, but if that limits the time warp to a value so low the interstellar is basically unplayable, then it's not worth it.

You can run the game without the launcher. KSP_x64.exe from the game's directory runs just fine. For convenience, you can create a shortcut to it or even add it to Steam under Games->Add a non-Steam game... option. It seems to work just fine this way. A bit crap that PD is trying to push this, but so long as the game keeps working without the launcher, I consider it a minor annoyance rather than a barrier.

Unlikely, but any functional component has some state variables. Antenna being retracted or extended being just one of however many the devs thought they needed for the full intended functionality. Depending on the exact implementation, it is possible for these to end up in an inconsistent state, resulting in a bug that persists, but is hard to replicate. For a simple illustration, imagine that you have two light switches controlling two lights in a room. Your intention is to have both lights on or both off, so you flip both light switches at the same time. Now imagine that for some reason, at some point, just one switch got flipped, but you continue flipping both switches when you want to turn the lights on/off. From this state, you'll always have one light on and one off - a bad state that you can't exit without a change to the algorithm. I don't feel like decompiling the game (again) to take a look at exactly how that part of the code works, but my first guess would be that there's a flag saying that the antenna's extended, and a separate one that says it's ready to transmit, and the two don't trip at exactly the same time, because animation takes some time to finish, but both are simple toggles. So we're looking for a possibility that these two flags become inconsistent. If I was trying to reproduce this bug, I would try things that can disrupt the process during the animation. Quick-saving and re-loadng while antenna is extending/retracting, switching vehicles, going into time warp, etc. If that, indeed, reproduces the bug with a newly launched antenna, then repeating the process may fix it. Of course, the bug could be way more convoluted as well, and in either case, the correct fix is going to be in the game's code.

This is almost always a more complicated topic than just a matter of mods. Roughly speaking, it's usually a combination of the following. Licensing issues. Microsoft and Sony have in the past been placing very strict limits on the crossplay. It looks like that has warmed up a bit, but last time I've seen Sony's contract on this (a couple of years ago) it was entirely prohibitive for most game studios. It is generally worse if your game has microtransactions, but even with a single upfront purchase there can be complications. Version incompatibilities. It's pretty common for multiplatform games to not publish patches or updates to all platforms at the same time. We're already seeing that with KSP2 as the early access is PC-only. It can be very hard or simply impossible to get crossplay to work when different platforms are running different versions of the game. Market mismatch. This is unlikely to ever be a problem for KSP2, but in games with player economies, the market conditions tend to be very different across platforms requiring different approaches to balancing. You can, of course, balance the overall market, but it's a much harder problem. Game balance. Again, unlikely to matter for KSP2, but for competitive games, having players with mouse vs these with gamepad, for example, could give one group an unfair advantage over the other. Friend list. A lot of games rely on the platform's service to connect you to your friends to play with. Building a service that lets you find and invite players from other platforms is additional infrastructure that has to be developed for the game. None of these are insurmountable, except, possibly, for the licensing bit, but they do require work to address. For KSP2, the biggest chunk of it is going to be making sure that all players are running exactly the same version of the game, including any mods and patches. It's obviously solvable, but when multiplayer is already running behind, it's likely not to be a priority. If it's something Intercept considered from the start and already has working, that would be fantastic. But if it's not, I don't expect they'll be putting time into it any time soon.

There is a well known phenomenon of surname extinction. There is a random fluctuation of more or fewer people ending up with a given surname with every generation, but once a particular surname goes extinct, without someone just legally changing their name, it can't be brought back. Over time, fewer and fewer surnames remain. This process can be faster or slower depending on cultural norms associated with how surnames are passed to new generations, and it generally takes a really long time, but it is a process that exists. Can it be the cause of kerbals having the same surname? It's hard to tell. We can look at human civilizations for some examples. While most Western civilizations have relatively recent surnames, In China, surnames go about a thousand years back, and 22% of China's population share just 3 surnames. Here's a video that gives an overview. So how long would it take for all of us to have the same surname? Well, if we take the patrilinear tradition as an example, we don't actually have to guess. There is a concept in genetics of Y-chromosomal Adam, a patrilinear ancestor of absolutely every human on Earth. Whoever you are, you are a child of a son, of a son, of a son... of that person. And while it's hard to be precise, based on mutations on Y-chromosome across the population, it is estimated that the most recent such ancestor has lived as recently as 160,000 years ago or as late as 300,000 years ago. If humanity has invented a concept of surnames all the way back then, stuck to it, and has insisted on strictly passing surnames father to child, we'd all be guaranteed to have the same surname. This is partially the case because the population of humans has been very small, possibly as few as tends of thousands, at one point in time. That was way before any modern surnames existed, so it couldn't impact us, but if we imagine Kerbal civilization to be very ancient, and that they've had some sort of a global catastrophe at some point in the past where their population has been reduced, or if it never exploded in the first place for whatever reason, it is entirely possible that they had a natural extinction of all but one surnames as the result. And, of course, this is all assuming their naming traditions are anything like ours to begin with.

I've seen a number of various approaches to this over the years, from mods either specifically designed to do this or flexible enough to allow for it, like kOS, to really hacky things like simply timing a separatron to tilt the rocket at the right altitude. What I was looking for instead is ability to perform a gradual gravity turn in vanilla KSP, and while I've done some experiments with fins attached to servos, the results have not been very reliable. Recently, I got a thought, what if instead of trying to force the rocket to tilt over, we trick SAS into thinking it already has. So I slapped a probe core onto a servo part, added some curves and activations to a KAL unit, and, well, the results were actually really nice. This can still use a bit of polish, but the entire control unit fits in a single 1.25m service bay and can be tuned for whatever rocket you want to send to orbit. I have found some interesting gremlins while working on this. It looks like the engine gimbals don't want to play nice with SAS if the axis the engine is aligned with differs wildly from the orientation of the control-from point. This isn't causing any issues during the first stage operation, but I had to shut down the gimbal on second stage and rely on reaction wheels only, because if I didn't, the second stage would spin wildly out of control the moment it ignited. There are also problems inherent to SAS use, like the fact that the lock orientation can drift over time, and that is definitely the case here, and you have to compensate for it. However, all that really means is that there is a bit of a trial and error in programming the ascent, which is likely going to be the case for any practical use already. Also, just to see if it can be used for some missions played in first person, I've set this rocket up to have a pilot seat, and when the program finishes, it sets the control-from point back to the command module. So it's entirely possible to use this kind of setup to take you to orbit and let you perform the rest of the mission manually from there. All in all, I'm pretty happy with the result.

Betas can be good for shaking out problems with server load by increasing it incrementally rather than letting everyone in all at once for games where it's relevant. Doesn't always help, but it's one legitimate reason to crowd-source your testing with a beta release. Of course, I don't think that's at all relevant to anything Intercept is doing with KSP2. So yeah, there would be little to no value in beta test as far as getting player feedback goes.

There's still a digital E3, which might have limited turnout itself, but a bunch of big studios are doing their events around the same time. It's an important time point even if mostly by convention at this point. I don't know if T2/PD will have something as part of digital E3, or have their own show, or simply use that time of increased media attention to push a lot of marketing. They'll certainly be doing E3-adjacent marketing of their other properties. So either way, it'd be a good time to kick off KSP2 marketing, whether actually at E3, or just around that time. Not the only option, mind, but it's a high probability one given the release schedule. Only starting marketing push at Gamescom feels a little late, and there isn't really anything else going on that would have sufficient media attention. You'd be wasting free publicity, basically, if you don't start marketing at E3. But yeah, Gamescom and maybe PAX Prime is where I expect it turned to 11 and where we'll see booths, possibly playable demos, certainly some sort of fresh gameplay videos, etc.

Then counterweight is your reaction mass. That still has to be delivered to the centrifuge. If it makes sense to double the payload to centrifuge for this, then that's fine.

This has merit, but there are several things to consider. First, the centripetal acceleration. At 1km/s, to keep it down to 1g of acceleration, the radius of the arm would have to be over 100km long. And if you plan to have this structure be reusable, it will have to be able to absorb the shock of releasing the cargo, which will propagate as a wave through the structure. So it's not trivial to build something like this. It's a major project. Second, conservation of momentum is still a thing. If this arm is orbiting a planet, the recoil from launch is going to alter its orbit. You need to compensate for this somehow. The most practical use case is if something like this both sends and receives cargo. You can also just use it to de-orbit random rocks to absorb that momentum, but basically, if something goes up, equal amounts of something must come down. Finally, corrections will still have to be made, and something with that size and artificial gravity at the tips won't be possible to mill with sunlight. A sail of that size will not be able to withstand the rotation. So you'll have to expend reaction mass for correction and to initially spin up the structure.

It's hard for me to say if that's the correct call, since I don't do marketing, but it looks like PD isn't doing any marketing yet. Intercept is doing normal PR outreach, with a lot of what's being shared being prepared primarily for internal consumption. Clearly some editing work is done and promotion is happening, but just enough to keep us here. Real marketing from PD hasn't started yet. This is typical for a game not scheduled to release until late in the year. Marketing tends to ramp up quickly right before preorders open up, which you obviously can't do until the date is set. The only real conclusion is that we shouldn't expect a release in the summer, but that was everyone's assumption as is. E3 is probably where we'll see marketing kick off, and maybe a booth at Gamescom with a demo. This is assuming PD is marketing this like any other title with similar budget and sales expectations.

I must have looked at an old article. Even better. This is 5M people already familiar with KSP, meaning PD won't have to spend nearly as much marketing KSP2 as it would for an obscure game, and it makes RoI even more reliable here. So the fact that KSP2 is on an expensive side for a brand new studio is entirely justified here. It also doesn't look like they're squandering resources based on the progress the game is making. So again, I don't see a problem.