K^2

There are a few places where you're asking which values for ISP to use, and some of these numbers are clearly meant to be in m/s and some in s. The easiest way to check which ones to use is plug it into formula and see if the units work out. If your dV didn't end up in m/s in the end, the input units were wrong, so you know to use the other convention. And the conversion factor is always 9.8m/s2. I strongly recommend keeping these in any computations as well. First of all, it's a simple way to check the results, and second, if any conversions have to be taken care of, they are plainly available.

Setting aside the question of whether that will be the only way to build fusion engines, I don't think even that's going to stop some players. I'm sure somebody's going to end up building these giants in orbit, then entering atmosphere to land at some suitable clearing to pick up cargo. Getting TWR for takeoff will be tough, but again, I'm sure somebody will figure it out. We've seen people do space planes powered by ions, after all.

You had to go and jinx it... v_v I don't think Intercept would be able to sell it directly. The publisher/developer relations are a lengthy topic, but tl;dr is that it would be exceptionally unorthodox for Intercept to be handling any sales directly. Private Division has a storefront, where I would fully expect KSP2 to show up once it's up for preorders, but that storefront simply redirects you to the Steam/XBox/Playstation/Nintendo stores as appropriate. So I suspect, the PC and possible Mac/Linux version(s) will be available through Steam only. Interestingly, KSP is up on PD store, and it does feature a DRM-free copy you can purchase from PD directly, but that must be an exception due to agreement with Squad during acquisition. I don't see this done for any newer games, so I highly doubt that this will be done for KSP2. But if there is ever a PC/Mac/Linux version that's sold directly without using an intermediate platform, like Steam, GoG, etc., that's where I'd expect it to show up.

@SciMan is correct, though. Procedural wings do not imply better aerodynamics or physics. They do encourage a sensible lift model, but even that would basically mean about the same quality as KSP is now. Which, honestly, I'm fine with. Some changes would be welcome, like transonic effects and lifting body forces, but there are more important things to get right in physics and simulation in general, IMO.

It was (and still is) a sort of RPG where all your powers are home-in-on-target and run on timers, so it's actually playable at 15FPS, just looks a bit crap. Obviously, everyone wanted a solid 30 or better, but this was landing on fire, we had a week before that version headed out to cert, which we were under contracts for, so 20 was good and 15 would have been acceptable. Also, XB1 was still new at the time, we were one of the very few F2P games on it, and in some regions the only one available, so the expectations and the bar were low. Of course, later, the XB1 version ended up doing really well and priorities shifted, but that's a different story. I don't really want to mention the game or studio by name in an open thread, but if you're curious about any of my work, feel free to DM me.

Having a physics engineer on board is a good sign. They're a bit green as far as formal experience with game physics goes, but good acafemic background and I'm sure a number of side projects. So hopefully, they'll do a good job. It sounds like KSP2 still runs GameObject system, rather than ECS, so we're stuck with PhysX as a base. That's the same physics engine as KSP, so some problems are likely to remain. However, it has been confirmed that we are getting continuous collisions, which helps a lot when two ships collide, and there has been talk of "physics LoD." We don't know exactly what this means, but likely, ability to simulate fewer joints by combining some parts into rigid bodies. If Intercept can manage to make that work without struts summoning the Kraken, it could easily improve performance and stability for larger rockets. So we're definitely getting some improvements, but how much difference these will make remains to be seen.

Depends on the stage of development. Early on, it's more about feature testing, since most of the bugs are kind of obvious. Later on, yeah, it turns more into data gathering on performance and bugs. But there's also the aspect of trying to keep the team motivated. People tend to do better work on a project when they understand the project as a whole and are invested. Having everyone try various builds of the game early is a good way to achieve that.

Keep in mind, there is some variation, because it's not like there is a committee that decides what you should call each stage of development, but generally speaking, there's pre-production, pre-alpha, alpha, beta, release candidates, and release/gold. With day-zero patches, that whole beta-RC-gold becomes a little blurry. Like, when you're playing a "beta", especially if it was a pre-order incentive, it's often actually the RC version. But then, yeah, most of the promo footage would get captured in beta, because people almost never do these captures at the last moment. And even if the promo footage is captured super late, you usually wouldn't use the release version, because you often rely on dev tools, and there might not even be a dev build of the release version. In which case, one of the RC builds is usually used. As for whether that will actually be called "beta footage," probably not. Devs aren't required to put that message there. That message exists when they know they're showing something unfinished that definitely will change. If there's beta footage that looks identical to shipped game, nobody's going to label it as beta footage. Edit: Eh, that doesn't have to be an indicator. We had all-hands play tests of games while ridiculously early in pre-alpha at one studio I worked at, and I've never been at a place where you can't just ask one of the engineers or designers for a build. Game studios generally encourage anyone on the team to play the games they're working on.

Definitely not. Beta is "Finished game, some bugs." I don't think summer was ever realistic for KSP2, so if we're looking at a fall release, there are 6-8 months of work until release, so maybe 4-7 until RC submission. Depending on the kind of game we're talking about, maybe it should be well into alpha by this point, but for a game like KSP, the alpha phase is going to be pretty short. Alpha is feature complete, fully playable, but potentially with major bugs that prevent completion of the game start-to-finish. If you're making an open world RPG game, going from alpha to beta can easily take a year or longer. But for something like KSP2, once it's in alpha, it's a stone's throw away from beta. And beta is basically polish. Unless they're coming in hot, with a pile of bugs, beta might be the last couple of months before RC is submitted. So even if it really is still in pre-alpha, which we don't know - all of the footage we have is potentially months old - even then, there is time for a fall '22 release. Though, it is, potentially, starting to get tight. And if the game has already entered alpha, then it's well on schedule.

A lead is a team manager. They are very important in the long term, but a team can hobble along for a while without one if they have good leadership structure above and good production. It's a lot more work for the directors when they don't have good leads, but it's manageable short-term, so even if several leads leave the studio, things don't grind to a hold. The number of leads also depends on the number of IC roles. So if the teams have been growing through hire, the need for new leads might have only recently formed. And that's if the positions are vacant already. We know that Intercept has been working on spinning up a small team for a new project, and it's possible that these vacancies are to replace people who will be moving to a new project. That would mean that the leads are still on KSP2 until new people are hired and teams are rearranged. This is normal practice for studios that want to keep their lights on, as they are basically paid to make a game for the publisher and a big chunk of income disappears once the game actually ships. Intercept is owned by T2, so the pressure isn't as high, but generally, their budget is still subject to approval, and approval is subject to Intercept showing that they're working on another game. So all in all, this doesn't have to be an indicator of any sort of a problem.

I wonder if the rounder structures are craters, volcanos, or a mix of both.

Even in KSP, there are edge cases where this assumption breaks down, but in KSP2 this is completely unworkable. First of all, multiplayer. Anyone can take over any ship at any time. Second, some ships are going to be traveling under power for a long time. Again, there could be arbitrarily many of these. And crucially, if you are flying a long duration mission, you've set your thrust, you checked the trajectory, and then switched to a different craft, you can't have the trajectory change. Which means, it has to stick to the n-body. Since the game isn't clairvoyant in so far as what you want to use for your missions, that means that any part that came from any ship that has been flown should be considered still a part of the mission, and therefore be on n-body system. And that's basically everything in the game. So it's really an all or nothing. You can't swap between n-body and patched conics in KSP2 in any remotely reasonable way. It might be ok if you're just doing it to handle the Risk system, but not as a general solution.

This is one of the few things that would make me instantly pass on KSP2. There are good uses of cryptography and public ledgers in video games. But none of it needs to be distributed. Absolutely nothing in any video game has any business being attached to a blockchain. Which means, any time you see a game using a blockchain, at the absolute minimum, the developers have chosen an option that is explicitly harmful to environment for no gain other than using buzzwords. Potentially worse, there have been enough outright scams involving blockchain. So at best, it means the developers have no idea what they're doing, and possible implications only get worse from there. Either way, I want nothing to do with it and will not willingly contribute to any product going this route. And I sympathize with some smaller startup studios, because I get to deal with a CEO who's constantly exposed to dozens of crypto startups who got VC money to push blockchain as a product, and I have to keep explaining to said CEO why we don't need that technology, and why for every single "benefit" we can get the same exact functionality cheaper and without dumping literal tons of CO2 into the atmosphere. But "everyone's doing it," is a very bad reason to do things, and I am appalled that there CTOs and engineering VPs out there willing to go along with this either because of peer pressure or because they're literally getting payed to.

I'm having flashbacks to being tasked with bringing framerate in a certain RPG ported to XB1 to "playable" during an important raid. The demo file I was testing against would dip down to 3FPS. Following considerable amount of optimization, I had it running above 20 95% of the time. I was later told the studio would have been happy with 15. So "playable" FPS is definitely a stretchy subject.

They are identical for gameplay purpose. We aren't looking to fully simulate the dynamics - that would by the very definition require full N-body simulation. But it's also not what people are asking for. What people want is be able to place a replica or re-imagining of a real or proposed spacecraft that utilize these points. For gameplay purposes, you can place a spacecraft near the location where L3, L4, or L5 would be found in the real world and have it stay in general neighborhood of that point arbitrarily long. There are no perturbations or sources of external force, so having an equilibrium is all you need. Already addressed in the thread. In general, a 3 body problem, with 3rd body of negligible mass, produces a chaotic solution for that 3rd body. There can be closed form approximations for certain special cases. Some of them are well known. However, it does not cover the general case, which we need for the game, and approximations aren't always good enough even for cases where they are available. So while yes, there are things you can do to clean up the problem and use in things like mission planning, if you are simulating the game, you still have to rely on numerical integration, and the fact that the system exhibits chaos, would require very fine precision as you are integrating forward. This isn't impossible in principle, but given that even at 100k time warp, which is the limit in KSP, any sort of interstellar mission would take a while and there can easily be dozens to hundreds objects one has to simulate, this becomes a very hard numerical problem. Add to it the need to project orbits forward and all the shenanigans that come with multiplayer, then consider requirement of this whole thing running on a console and not even natively, but via C# compiled to CIL? All of these things you can work on. You could maybe discard debris a lot easier to keep number of simulations down. Maybe not project future trajectory as far forward or not worry about potential SoI intercpets as much. You can compile native code to run the integration more efficiently. You can do very fancy implicit integration methods to reduce errors. There is a lot of room for optimization here. Or you can just keep using patched conics and fake what you need for gameplay. Again, keeping in mind that we're more interested in supporting the mission profile than providing 100% accurate simulation.

Performance-wise, it should be fine. There will almost certainly be some "ultra" settings that this card will struggle with, but I would expect even "high" settings to be within reach. Rendering just isn't a likely bottleneck for KSP2, and I've seen the fancy vegetation and clouds similar to what we are seeing for KSP2 running on a PS4 Pro just fine. GTX 960 outperforms that by a good margin. The only thing that might be a slight concern is VRAM. Some of the techniques Intercept are going for are very VRAM hungry. GTX 960 came in a range of variants equipped with 2GB to 4GB of VRAM. I find it extremely unlikely that more than 4GB will be needed on high settings, because that's kind of a lot even for gen 9 consoles, but there's a chance that you'll need more than 2GB running everything on high. Specifically, you might have to bring in render distance for vegetation, and/or shadow and cloud quality down a notch, as these will take up the most VRAM. Still, I expect the game to look very good on GTX 960. I'll be surprised if you'll have to sacrifice a lot of quality with that card. Depends on the generation of that Ryzen 7. If it's at least a Zen 2 (gen 3 of Ryzen), then you'll be fine, because that's pretty much what PS5 and XBSX are running, and you should be able to boost your clock more than either of these systems. If it's an older R7, then it's harder to say. We don't really know what the requirements will be for the CPU, only that it will probably be on the high side, and that Intercept has to get good performance out of PS5, so it can't be higher than that. Bellow that, it's hard to say. Ryzen 3700X outperforms the 2700X by about 20-25%. It's a pretty significant gap going from Zen+ to Zen2. So if you have gen 3 or newer, you're fine. If it's older, we don't know yet.

We already know that they're trying to get early pre-production ball rolling on another project, which is normal for a studio that wants to keep everyone's paychecks coming after the current game is delivered on. And I don't see any significant changes with positions they have open for that. All in all, no real change in status from any of this information. KSP2 is still planned for sometime later this year, and since I wouldn't have expected the game before late summer anyways, the fact that it's fiscal '23 is as expected.

I find these instructions somewhat questionable. "We found no traces of stone fish venom. He must have mistaken something else for it." - "Wait, so what killed him?" - "The bends."

L3-L5 require no additional work. They are already equilibrium points in KSP. No, they aren't. The term "virtual" wouldn't even make sense in the context. They equilibrium points of the effective potential in the rotating frame of reference. If you want to make it sound like your argument is coming from some sort of academic principles, at least use the right terminology. Here's your system on n-body physics. Same system on patched conics with SoI boundary marked. The L3, L4, and L5 have merged into a continuous equilibrium band. They're unstable, but so was L3 to begin with, and L4 and L5 only have limited dynamic stability. They work for gameplay purposes either way. If you want to build a base in L3 in KSP, if you're careful about parking it, it will pretty much stay there. It requires very careful maneuvering and observation to even tell that the dynamic of craft near L3 in the top picture vs bottom picture is any different. For gameplay purposes, they are identical. L1 and L2, in contrast, are simply gone. They are not a feature on the bottom image. If you want to place an object where L1 or L2 would have been, it will drift away from there in a hurry. These points aren't just unstable, they aren't equilibria at all. The entire topic of discussion is, can we reasonably bring in an approximation of these into the game? And the answer is yes. If you build small plateaus in potential where you want the pseudo-L1 and L2 to be located, it will work. And for gameplay purposes, you will not be able to tell the difference between the picture on the top and the picture on the bottom, because I already had to tinker with contours and contrasts and apply logarithmic stretching just to make the two pictures look different for illustration purposes here. This whole talk about n-body somehow being critical for simulating Lagrange points is hot air. ^ There's the math.

Kerbin isn't an actual place either. There's a lot to be said about providing interesting mechanics in a game. There are a lot of features of real world orbital mechanics that lead to cool use cases, such as parking craft near Lagrange points, which would be interesting to replicate in a game. Saying, "That's not a feature of patched conics," is missing a point of all of this by a nautical mile. The entire goal of the simulation is to allow you to run a variety of mission profiles approximating real world cases while being able to run at 100k the real time speed across dozens of craft in multiple star systems and provide real-time trajectory predictions while doing so on console hardware. If you have a better idea how to achieve that, I'd love to see an implementation.

Fair point, but Series S runs on the same CPU as SX, just with a slower clock speed, which is still higher than PS5 clock speed, and the architectures of all 3 are very, very similar. There's a reason why Series S is popular, and not having a CPU that runs like it came from a cereal box is a big part of it. Series S might actually be a more reasonable comparison in terms of graphics hardware you'll need to run all the bells and whistles on high, but in terms of CPU benchmark, PS5 is still the bottom threshold. So we could revise the "Guaranteed No-Higher-Than" min spec to Ryzen R7 3700X with Radeon RX 6500 XT (down from 6600XT) and 8GB RAM. Though, I think it's still a given that you'd be able to go way lower on graphics hardware for min spec here. We just don't have any indication on where the cutoff is going to be, since we don't know how many of the new features we'll be able to disable.

I'm sure you could create an SoI with either no planet but still having an attractor, or putting in a fake planet with no collision or rendering to the same effect. The only problem is that you'll have a singularity dead-center, so you might need to actually use two SoIs, the inner, much smaller one having no gravity. As Intercept are still developing KPS2, they could, of course, side-step both of these problems and simply allow for SoI with arbitrary attractors. Code-wise, you'll still have to do designate inner and outer zones in SoI and do an additional boundary check on orbits passing through it, but instead of having a dead zone with gravity sharply cutting off, you could have a harmonic attractor, which will allow for much smoother orbits. Of course, this would also require information about these fake L-points to be somehow presented to the player, probably have tutorials about it... It's a pretty sizeable feature, if implemented properly, so I wouldn't hold it against Intercept for just passing on it. Might still be something that can be modded in, though. We'll have to see how easy they make it to modify the planetary systems.

Nah, that's not the problem. MRI machines actually need a very uniform magnetic field to produce images with minimal distortion and they are plenty strong enough. So we literally have magnets that would do just fine. The problem is that even if you had a way to magnetize blood, there's not that much of it compared to the total weight of the body. Total water content is a lot higher, but if we're talking about blood specifically, you'll have to pull on it with significantly more force than gravity does in order for the net force on the body to add up to a full normal weight. And blood already starts to pool in extremities with just a bit higher gravitational pull. I'm having hard time believing this would be healthy even if you only lye down flat. Trying to stand up would be instant unconsciousness. There might be some interesting use cases for the concept specifically in countering high accelerations, say, for fighter pilots. When your body is already supported by the chair, and your biggest limit on pulling g-forces is blood going where you don't want, being able to push the blood around with a magnet might let you go to higher accelerations briefly. But for sustained artificial gravity, you still want something more like a centrifuge.

That's just a general case of a tidal force. It goes down as a cube of the distance from source and grows linearly with the size of the system influenced by tidal forces. As size of the Solar System is pretty much negligible compared to the distance to Sag A*, the effect is, technically, there, but it's not significant at all.

Yeah, but it's also a bigger game with much more expensive physics and time warp calculations to enable multiplayer, so it's very hard to say where that's going to land. We know it has to run well on PS5, because otherwise they might as well cancel the whole thing, hence using that console as a benchmark. On the other hand, I'm pretty sure the min spec will end up higher than that for KSP, because I don't think all the optimizations Intercept are likely to put in are going to outweigh the game getting bigger. Somewhere between these two goal posts pretty much for sure, but it's a wide spread. I would guess that general case with all the bells and whistles will end up on the high end of that range. Primarily, because that's where the main financial pressure ends - if you can ship the game on modern consoles, you're going to bring in most of the money the title can collect. Spending more time optimizing sees diminishing returns. So usually, min spec optimization only goes as far as it needs to. But depending on how Intercept chose to handle some of the optimizations and quality settings, if you play single player (or at least, don't host) and tune some of the quality settings down, the requirements might be much lower. There's also a question of what breaks first if you are bellow min-spec. Based on limited info we have, my biggest concern would be time-warp in interstellar. So maybe if you're ok with things getting really slow and choppy when at max warp, and trips generally taking longer, maybe the game is still playable for you. So again, for anyone who absolutely must upgrade their system now (even though it's still kind of the bad time for it), the safe threshold is matching PS5 performance. But if your system is bellow that, don't despair yet. It's much too early for that. Wait and see.