K^2

Possibly since Monday, and likely until at least a few days into January. Given that release date has seriously slipped twice already, I suspect they will hold off on exact date until they're pretty sure about it. So we might not know exact date until well into the summer. Though, I'm sure we'll get at least an estimate at E3.

Alternatively, apply for a job at Intercept, if qualified. I guarantee you, everyone on the team is testing the game. That aside, open alpha tests are almost never a thing anymore. There are times when small focus groups are invited when decisions need to be made, but especially for smaller games, it's usually just internal testing. (Early access scenarios notwithstanding.) Beta tests are more common, but even then, for KSP2, I don't think there will be a public beta test unless it's a pre-order bonus. In which case, you'd be getting it two-four months before release, so it's not really worth it. Might as well just wait for the full release. Realistically, your best bet for getting to play the game early is if Intercept will have a booth at a game show event. E3 is a possibility. Gamescom and PAX Prime are also good options if the game is targeting late fall or early winter release.

The mass defect of a battery is exactly by the mass of matter/antimatter required to produce said energy, since this is literally just equivalence principle at work. (Technically, chemical batteries can also exchange gases with environment, which is a much bigger factor in battery mass in the real world, but that's a separate issue.) So yeah, if there was no other limit on storage, the best you could do is m = E/c2 or about 90TJ/gram. Of course, with any known storage method, you aren't going to get anywhere close to that ratio. The best we have a working theory for that works remotely like an actual battery is nuclear isomer batteries. The hafnium-178 isomer 178m2Hf can hold about 1.3GJ/gram. Sure, that's almost 10,000 times worse than antimatter, but it's also more than a million times better than Lithium Ion batteries, which top out under 1kJ/gram. This particular nuclear isomer has surprisingly good shelf life, with half-life over 30 years, making it an ideal candidate for batteries. Unfortunately, getting it to liberate that energy on demand has proven to be rather complicated, and the only known way to charge it is to chuck it into a particle accelerator, which is not ideal in too many ways to count. There was some optimism about it a decade or two ago, which even led to some research getting classified for the fear that somebody could weaponize it, but that fizzled out, and research has seen been released to the public. The conclusion has been that if there is an efficient way to store and release energy from this isotope, we lack technology to do so at present. But if you're looking for a "nearly magical" battery for your science fiction setting, you can do a lot worse than hafnium nuclear isomer batteries.

Honestly, not really? I don't want to make it sound completely trivial, but most of the work is done by the game's physics system. The inputs we are sending to the robotic parts are pretty much exactly what Unity's joints are designed to work with. And they are driven by animation curves that are basically built into the game as well and, at least in KSP case, are the same animation curves as are used for engine thrust/ISP scaling with pressure and speed. So it's almost as easy as making art for the parts and hooking up the necessary UI. Obviously, then there's some tuning, debugging, QA, just like there would be for any other feature. So it's not free. But it is definitely a low hanging fruit. That said, yeah, there are definitely higher priorities, and I'm not going to cry over robotic parts not being in the base game at release either, but it would be a nice touch, and I do hope Intercepts finds time for them at some point. Havin them stock would be way better for compatibility than having these as mods.

On one hand, fair. On another, I've only encountered two kinds of players. These who watched a how-to tutorial first, and these whose first encounter with Duna left a crater. It's very hard to guage the correct parachute setup based on info you have at that point, and Duna is different enough from Mars to only be a rough indication that it requires special prep. I suspect, Duna with wind will mostly trip up returning players. I think, that would actually be interesting to see. Of course, Duna landing might also come with extensive tutorial. I'm not saying the game should lead you by the hand to this point, but there could be a lot of value to new players if getting ready to land on certain bodies for the first time would trigger an optional tutorial. Duna's a good candidate.

Even with KSP aerodynamics model, I honestly have no idea how we are meant to do this without some sort of a landing planner. I'm sure, many of us can write a script, or at least do some estimate number crunching by hand, but that's not exactly a friendly experience. There are two ways I can see this going. First is taking the simple, "Anywhere on the planet is fine," kind of similar to how recovery works on Kerbin in KSP, with reasonable penalties for distance. It's not ideal, but it'd be better than requiring pinpoint precision with no assistance. The second option is providing a suite of tools for precise landing. That would include trajectory indicators that take aerodynamics and wind into account, showing, say, 90% probability impact area on the planet, and nav aids during landing that can help you stay on that trajectory as you approach. Even with aids, it will require some practice to perform precise landings, but I don't think any of us have managed docking on the first try without watching a tutorial. If the tools are good, I think it's a reasonable ask. If not, then precision requirements will have to be relaxed. Wind adds a layer of complexity, and that's part of why I think it should be a difficulty option, but it doesn't drastically change the situation with colony supply runs.

In KSP, generally, if you're landing powered, you're in (near) vacuum, and wind wouldn't matter anyways. And in places where wind can be a factor, you currently just wait for the craft to finally settle down with zero input. With wind, it would mean either being a bit more selective about landing spot or bringing in something you can steer and flare. And there are a lot of options here. You can bring a space plane, a capsule with deployable paraglider wing, a deployable autogyro rotor, or even go with hybrid approach of switching to powered landing before touchdown by cutting the chutes. There are plenty of options, and none of them are terribly complicated to work with. In case of Kerbin, you often don't even care about specific landing spot and can just splash down to avoid any of this complexity. So I don't think it creates unwarranted hurdles in most places. Duna might make for an interesting exception, where the atmosphere is thin enough to prevent parachute landing and thick enough for wind to matter during landing. Now, whether Duna is the right place for that kind of a crank in difficulty is a fair question, but I think some planets with this difficulty should exist. And the wind speeds and atmosphere density on Duna can probably be tuned for it not to be too bad there, making it a good training ground for other planets in other systems that are much harder. Personally, I don't think making every planet easily accessible should be a goal. There should be enough interesting planets to go to and explore with moderate challenge. So long as that's true, a few planets that are an absolute nightmare to land and/or take off from is perfectly fine. And wind can be just one of the challenges for such a planet.

I like the idea of wind having an effect on craft being a difficulty setting. It shouldn't be hard to model - you just need to subtract wind velocity from part velocity during any aerodynamics computations, and if it's an optional toggle, it'd keep most players satisfied. Having to do cross-wind landings would be fun, IMO, but I also get why some people don't want it.

If you're going for fewest satellites, two in highly elliptical orbit will do the trick. If they are placed about half of the orbit apart, one of them will already have a good overhead coverage of the polar region while going up as the other one is going down. There might be some choices that have to be made about specific eccentricity and inclination to make sure orbital precession keeps the satellites where you want them, but it shouldn't be too hard to find something suitable.

Look on the bright side. Elden Ring comes out in February, and you won't have to pick which one to play.

Even if they're officially in alpha, I still think even summer would be optimistic for release. There is a lot of work from alpha to beta to release candidate to actual release.

I genuinely hope that KSP2 multiplayer never gets monetized, and I doubt there will be anything but co-op in vanilla, making cheating entirely pointless. Of course, I would have told you exact same thing about Minecraft circa 2009-2010. It's hard to imagine exactly where community will go with this one, and maybe we'll have some serious community-run RP/competitive servers for KSP2 out there. Of course, these will inherently require mods. So disabling mods to prevent cheating in multiplayer that's only competitive because of mods would be totally pointless. So in any case, I don't think there is any incentive to block mods because of multiplayer. The only reason T2 might create pressure to crack down on modding of KSP2 is if mods start cutting into DLC sales. Which isn't impossible, but I don't think it's high risk right now.

Technically, you can get all that science from KSC, by using the fact that various facilities and individual buildings, and in some cases their upgraded variants, count as unique biomes. So if you focus on getting all the scientific equipment first, do the upgrades, then collect all the science again, you can get a very significant chunk of the tech tree unlocked. It's slow, it's annoying, and it has nothing to do with the game, and yet, it's the path of least resistance to gather the science you need to have fun with the game. Yeah, that system definitely needs changes.

So the sad thing is that even despite coming from physics background and working on multiple titles, I used to think that PhysX and (now old) Havok is as good as these systems get, and you just have to eat the instability problems if you want dynamic joints. By "dynamic joints" I mean, something that's entirely defined by the constraints equations that can change - be they contact points, ragdoll joints, wheels, etc. But then I've worked on an engine that actually handles it properly, and now I'm just bemused that PhysX still hasn't fixed their stuff. Interestingly, I can trace pretty much all of the major changes in how people do physics engine to Erin Catto's work on Box2D and at Crystal Dynamics. Following that, I can point out at least Havok, Roblox, and Epic's Chaos as engines that have implemented similar approach and now have good joint simulation that doesn't suffer from nearly the level of stability problems that PhysX does. I'm guessing Blizzard's Overwatch engine is also benefiting from that, since Erin worked on it, but I don't know how much use they're getting out of constraints. Erin has done a lot of work to improve their dynamic BVH, though. In general, if you're interested in game physics, I'd definitely look up his talks at various game dev conferences. Tangent aside, if PhysX got their stuff together and implemented proper constraint solver, even with using basic Unity welds, the KSP simulation would be way, way more stable. Alternatively, if KSP2 was to take a different route and use Havok physics for their components, but my understanding is that they initially wanted to recycle some of the KSP work in addition to Unity ECS, which is a requirement, being still kind of raw when KSP2 development started. So I think we missed that particular train.

The problem is user discovery. If you only play with random people, it's not too much of a problem. You just need a simple name server for that. But if you want ability to play with friends, you need a system in place. So if I'm making a game available on Steam and consoles, my options are to roll my own user registration, user search, friend list, request/approval for said friend list, all of the UI that goes with it, some place in database to store all of the information and then a facility to report potential abuses and give users ability to manage and delete their accounts (GDPR!)... Or I can just hook into Steam/Sony/Microsoft API and have you play with anyone you have as a friend on that platform, including built-in ability to send chat messages to invite said friend to a game. Yes, each platform has a slightly different API with slightly different limitations, which means some of this you'll have to implement in triplicate (or more), but this is usually implemented through a thin wrapper, meaning UI and game logic is only implemented once, so you still end up with an order of magnitude less work than building your own system from scratch. And because a lot of games are taking that latter approach, they are inherently locked out from cross-play, not because there is a platform incompatibility, but because you just don't have facilities to invite players from other platforms into a game. Of course, this is something that can be expanded after the release. And at least with Steam/Windows you have an option of adding Windows Live API to have access to your friends on XBox. So there are definitely ways to work around it. But it might not be something you have out of the box on any given project.

I think @sevenperforce meant that the gap in cost between SRB and liquid is much smaller IRL than in KSP. Not that solids are necessarily more expensive. I'm pretty sure it's still cheaper to build a solid booster than a liquid one for the same thrust and total impulse. I don't have full confidence, though. Also, if you factor in reusable stages, this balance will easily swing in favor of liquid engines all together. SRB fuel, both the raw materials and the process to make it into boosters, is rather expensive. And there's a lot of that fuel, so it does add up. If it doesn't quite add up to a cost of liquid fuel engine on one launch, it certainly will over multiple.

Yeah, there was a shot of a rocket firing engines relatively recently. Nowhere near as much bouncing as in early shots, but definitely some flex. Let me see if I can find the footage I'm thinking of. Edit: Ok, "recently" might have been a stretch. I'm definitely thinking of the outro sequence of Next Gen Astronauts. You can see the boosters react to change in acceleration. There is also a much easier to miss example in another part of this video, at 9:17 you can see two ships collide, with boosters on smaller one shaking as a result. Of course, collisions might be treated differently. Also, notably, all the flexing we've seen here is at separators. So it is possible that separators are still treated as PhysX joints, while the solid welds between components aren't. That would be an interesting choice for optimization and one I'd be in support of. But we also see parts breaking apart in the collision video, meaning that either there is stress limits evaluation as described above in this thread, or the welds are treated as joints at least during the collisions. Both of these are plausible, but so is the possibility that everything is joints, just like in KSP, and they are just too stiff for us to see any flexing in these examples.

Not at all. You still have to do collision detection, extract contact points, and solve the constraints for remaining joints and contact points. All of that is still handled by PhysX. The only thing the custom implementation for RB does is take the constraint forces produced by PhysX and multiplies them by a pre-computed matrix to get the forces on the internal joints of the RB which you then test against strength limits. It's a tiny fraction of the full solver. This is a bit of an understatement. Less than a year ago, at a former job, I have been involved in evaluating Unreal's new Chaos solver against our in-house engine that I was a lead engineer on. We have found problems. Now, UE5 was not released yet, and this was advertised to us as WIP, and the bugs and issues were being rapidly fixed, and I'm sure it's in way better shape now. So I'm not trying to talk crap about UE5 here. But this was a physics engine years in the making with Epic's resources behind it and it was still in need of work. A good physics solver is a huge project. Now, Chaos does a lot of things for a lot of different kinds of games. You don't need all of that for a game like KSP, obviously. You can cut a lot of corners and simplify a lot of things. Basic BVH-accelerated collision detection and a constraints solver are reasonably sized problems. And if you were clever about how Jacobians for your constraints are generated, adding special constraints to handle wheels and landing gear isn't a huge amount of work. But it's still a good amount of work, and if you consider that Intercept has only about a dozen engineers to make the entire game, only one of whom is a physics engineer, making a custom solver does not seem feasible. I agree with that part. I think going with wobbly rockets was a mistake from the start, and they should have treated the entire structure as a rigid body. Early versions probably didn't even need stress limits simulation, especially not with the way old aerodynamics worked. It could have been added in later versions, causing rockets to simply fall apart, rather than start bending. The end effect would have been exactly the same. You could still have rockets undergo RUD due to aerodynamic forces if you lost control at high speeds or simply due to impact with terrain, but you wouldn't have to fight Kraken just to get your large rocket to orbit. This is the kind of thing that's challenging, but isn't fun. But it seems that we're stuck with it. All of the footage we've seen of rockets under any kind of stress still show deformation consistent with PhysX weld joints. So it seems that this is still the design choice for KSP2.

As mentioned previously, the optimization that can be done is combining multiple parts into a single rigid body. If you don't care about flex between the parts, combining multiple moment of inertia tensor into one is a rather simple procedure. You also don't have to sacrifice ability to model joint strength limits, as for a rigid body, constraint matrix never changes, so you only ever have to invert it once. Combined with ability to build a reduced LoD collision model for the complex, a collection of welded parts can be as cheap to simulate in PhysX as a single part precisely because from PhysX perpsective it's a single part. It sounds like something like this is, or at least was, in the works for KSP2. And yeah, the non-PhysX portions of the simulation will mostly benefit from better ability to spread the work between the cores. Between these two optimizations, it should be possible to have a drastically higher part count and/or create breathing room for other systems.

That doesn't really matter to a game like KSP2 or just about any Unity game. The CPU difference hardly matters when you're running CIL code on a CLR. There could be some minor incompatibilities due to new CLR being written to support the new Macs, but that's more in the realm of bugs, really. Either way, it should have no impact on how the multiplayer functions. There is certain degree of challenge to actually get the game to run well on the Mac, but once you have that, making PC/Linux/Mac cross-play is going to be just as easy with M1 Macs as it would be with x86/64. That said, we haven't really had confirmation that KSP2 will be natively supported on Linux and Mac. Valve's Proton might actually end up being the best way to play KSP2 on Linux if nothing changes, since they are getting pretty good at supporting Unity games, and if Steam Deck does well, I suspect that will only improve. I don't think it will ever quite match native, but it could get close enough to where you don't mind. And, of course, if your best option to play KSP2 on Linux will be via Proton, you'll get cross-play automatically, as you'd be running the same exact version on both platforms. In contrast, I don't think there are particularly great options for Mac right now. With Vulkan dropped and OpenGL getting deprecated, options for running Windows games on Mac are getting thinner. It is possible to take a Windows Unity game, partially decompile it, and then build a native Mac project from it, which people have done successfully with some other games, but also, if something doesn't work, there aren't a lot of good options to fix it. So I would say there's a bit of a question mark on KSP2 on Mac at the moment, at least until we hear a confirmation of native support. And yeah, as people have pointed out, with consoles, there is very rarely a tech reason not to support cross-play. There can be some little things, like tying your match-making too much to the game services, which could make matching players on different platforms difficult, but there are always ways to work around that. So the reason is almost universally in contracts that developers have with console companies. Usually, at least one of the two will have a clause that makes it impossible or very costly to develop cross-play games. It does sound like these restrictions might be loosened at the moment, as there are a lot more games showing up with cross-play, but it's very hard to say if it's anything Intercept can count on.

These are not directly related. Simply having regions of negative energy density doesn't let you send signals at FTL speeds. The way Alcubierre warp works is that you start out by crafting a space-time metric that gives you FTL transfer. You do so by simply writing out a metric that remains "at rest" with respect to the bubble as it accelerates and decelerates. Alcubierre chose to make metric both inside and outside of the bubble flat. The interior metric being flat isn't really critical - it's just a simplification. The exterior metric must be flat, because otherwise, the bubble will radiate gravity waves as it accelerates and worse, will produce something similar to Cherenkov radiation if it goes FTL, collapsing the bubble. This is why the net energy of the ship under warp must be zero. There are other ways to demonstrate it from conserved current as well. Now, this immediately tells you that some regions of negative energy must exist in the bubble walls. In Alcubierre's paper, the interior of the bubble is empty, and if you do the math, you do, indeed, find that the total energy of the bubble is zero, allowing it to be superluminal. Crucially, it's the bubble that carries the contents in Alcubierre metric. So you have to have an ability to accelerate the bubble itself to superluminal speeds. Because Casimir effect is related to cavities in a conductor, in order for the bubble to accelerate, the conductor body must accelerate as well. And the negative energy generated is laughably small compared to the mass energy of the conductor. Meaning you can't possibly use Casimir effect for FTL travel via Alcubierre mechanism. There is no way to generate enough negative energy to compensate for the mass of the drive with Casimir effect alone. There are some other suggestions that might allow use of Casimir effect for FTL. For example, negative energy density is necessary to create a traversable wormhole, including the kind that allow for time travel. In that case, the throat of the wormhole does not have to be traveling at superluminal speeds, and can, therefore, be stabilized by Casimir effect. Maybe. Nobody has ever worked out the correct configuration to confirm that it can actually be done. However, stabilizing the throat is just one part of the problem with wormholes. A wormhole is a topological construct, not just geometrical one, and we have neither found a way to alter topology of space-time, nor discovered any naturally existing wormholes that we could "shape" into a traversable one. So this remains deeply hypothetical. But more importantly, none of these other ideas relate at all to this paper. All this paper has found is that Casimir effect may create a negative energy distribution that happens to be similar in shape to that required for Alcubierre drive, without matching any of the other requirements, nor having a possibility to match these requirements. It's also worth noting that there are assumptions going into the computation that have not been verified. The very idea that Casimir effect creates regions of negative energy density is still being debated, and to date, no experiment has confirmed negative energy densities directly. This paper might pave the way to a confirmation, if we can, for example, design an interferometry experiment that confirms predictions of the computations being used in this paper. But this is still work that needs to be done, and whether it is a step towards FTL or any kind of propulsion remains unknown.

We already know that it won't behave like a warp bubble as necessary for FTL because that requires the net energy of the bubble + contents to be zero. While Casimir effect may allow for creation of negative energy density regions, it is heavily energy-positive overall. There could be some other interesting uses for this effect, but in that case, similarities to Alcubierre metric are purely incidental. Of course, confirming negative energy density at all would be a great step forward, and the fact that simulations are being done to make predictions which can hopefully be turned into testable predictions in the future is all a good thing. This just isn't the breakthrough the article tries to present it as.

Trademark law in US is ugly. Big companies definitely need to play softer with this, because it comes off as bullying and can actually cause great damage to smaller companies; and T2 is one of the notable offenders. (Bethesda is another one I'd call out.) But also they are technically required by law to attack other companies over anything that can be remotely perceived as a trademark infringement. The problem is that unlike copyright, which you just own regardless, you can lose trademark if you don't demonstrate that you are taking steps to protect it. So hypothetically speaking, if I was to release a game and slap Take Two logo on it and T2 rightfully sues me for it, I could go and demonstrate a bunch of examples of previous "trademark violations" that T2 hasn't responded to, and argue that as they have not defended the trademark, that trademark is no longer valid. And what's really stupid is that this has been done and upheld by courts, meaning this is basically de facto law that you have to attack anything that even remotely looks like an infringement. Now, when this is done in a civilized manner, some sort of an agreement is immediately struck with the other company. The problem is that when it's done in a ham-fisted way, the damage might already be done. The cases like Mojang's Scrolls are particularly notable. But critically, the discussion should be about how the dispute was handled, and not over the fact that there was a dispute in the first place. Yes, it sounds absolutely stupid. I think it actually is stupid. But that doesn't change the fact that existing law forces these disputes to exist over something that should be entirely a non-issue.

They show a lot of teasers and trailers for upcoming games during Games Awards as well. If time was right to start marketing, it wouldn't be that wild of an idea to have something shown at the Game Awards, but it really is a bit early for that. If we are looking at late '22 release, I think the most likely time for the next big trailer is E3. It would also be symbolic, seeing how announcement trailer was originally shown at E3 as well. We might see something before then, of course, but this is when I'd expect anything major.

Yes, but capture inherently can only give us net zero. We're so far behind the curve that we have to be developing net negative approaches as well that can be deployed worldwide. We basically have to do all of the above. Replace emitting processes with non-emitting, especially in energy production, have mandatory capture anywhere greenhouse gasses are produced, and develop methods for carbon capture that can be used elsewhere. Part of the problem is that global average temperature increase leads to all kinds of additional outgassing, mostly from melting glaciers, but also from reduction in permafrost, heating up of old bogs, etc. This means that even if we reduce our CO2 production, we still have more net CO2 released in atmosphere than can be naturally absorbed, meaning, the CO2 will continue climbing, and we don't know for sure whether the process is a complete runaway or will simply lead to an equilibrium at higher temperature. Either one's bad for us, though. We have to start taking CO2 out of the atmosphere in addition to cutting production to as close to zero as we can manage.