K^2

Languages and frameworks are your tools. Engines are more like construction kits. Some are more like Erector Set and others are more like Duplo. Unity falls somewhere in between. It's pretty flexible, but it can still be hard to build something if you don't have the right parts. If you have access to solver and can create custom joints, making good rail system is pretty straight forward. In Unity, I don't think I'd be able to make necessary changes to the constraints themselves. Instead, I would probably do something similar to how you'd set up a vehicle. You still rely on the engine for managing traction forces from contact points and use them to create hard kick if the suspension bottoms out, but you compute the suspension forces by doing ray casts to figure out wheel displacement. That sort of hybrid approach of relying on engine's physics and custom forces tends to work out pretty well. Unless you're making a high quality racing sim, at which point, you just don't make it in Unity. I would probably end up using similar approach to do rails. First assign collision materials to rail part and train carriage part so that they don't actually collide with each other. Other parts you use to build a train could still collide with rails, of course, but that's on player to build around that. Next, ignore the actual geometry of the rail and simply use the rails to generate a smooth spline to follow. Finally, generate forces on train carriage to follow the spine. This is where custom solver comes in. Ideally, you want a single solver so that all your forces are up to date, but with a custom solver at this stage, you're only one frame behind, so the only way this is likely to go horribly wrong is if the train already collided with something, generating a huge force spike, at which point it's probably ok to just derail.

Don't get me started. Part of my last job was evaluating Unreal physics for a project. Obviously, the olden PhysX setup is almost as bad as Unity's, but they managed to screw up Chaos as well. Seriously, Roblox engine has better physics than what Epic managed to get into U4/5. To be fair, they are still working on it, and it might still improve to the point where it's fully competitive with custom solutions, but it wasn't there last time I saw it, which was recently. And yeah, I have discussed it with Epic's engineers. I don't think they like me much anymore. Now, modern Unity does support Havok, which is the best of the bunch. It used to be a step above PhysX, but they have put in a lot of improvements recently. I have reasons to believe a lot of that was inspired by the work of Box2D's author, who is actually a go-to resource on modern game physics implementations. As far as I can tell, Epic is trying to do the same thing with Chaos, but Havok had an earlier start and did a better job. So as far as what you can get as middleware, that's your best option in my professional opinion. Unfortunately, unless there have been some major reworks, KSP2 is probably still going to be on PhysX, so we're probably not benefiting from that at all. All of that aside, implementing a good rail system for a modular game like KSP would suck on all of these. Havok would suck the least and Chaos would suck less than PhysX, but none of these solve all your problems out of the box. You would still have to write some clever custom systems to make it work.

With tachyons, at least we can show that if they do exist, under standard model, they don't interact with normal matter. So who cares? And usually, you can find these kinds of little gotchas that either make the result impossible or irrelevant. But there are also occasional edge cases where math says it's possible, but then we find zero evidence of it actually ever happening. Another good example from GR is torsion. We assume in GR that space-time can only stretch and bend and we set torsion term to zero. Why? Because theory works with torsion set to zero. But there is absolutely no known physical reason why it should always be zero, and despite a lot of effort, we haven't found any indications that we're missing anything. There is a whole another degree of freedom in General Relativity and we just pretend it doesn't exist. It's worth also adding that this isn't just an artifact of Differential Geometry, which is what Einstein used to derive GR. If you derive General Relativity as Mean Field Poincare Gauge Theory you end up with torsion as available degree of freedom. It's just apparently always zero - or the physics is somehow equivalent as if it was. Aforementioned (aforelinked?) Einstein-Cardan theory tries to work it into the rest of physics, but the very fact that it makes no measurable difference is telling in its own right. So yeah. There's math and there's physics, and while we use mathematics to describe the physics of the universe, sometimes we over-generalize and the real physics is just a subset of the mathematical model. And it often takes a very long time to figure out which parts are physical and which aren't.

Put a platform with thrusters in orbit. Tune thrusters to the TWR of 1 in Duna gravity, then land your lander on that platform. I mean, Duna does have some atmo, but for purpose of testing a lander, vacuum should be close enough.

Performance hit is a few extra constraints, so it shouldn't be bad. But if you just take raw prismatic constraint, it's going to cause problems when you're hitting transition from one rail section to another. You know how kerbals some times freak out when they transfer between ladder sections? Imagine that, but at high speed, and now instead of a single kerbal, you have an entire craft with all its physics riding on the rail. Yeah. Krakens galore. So you have to handle that somehow, and Unity/PhysX doesn't really provide you with a native way to do that, so you'd have to write your own sub-system for it. It's doable, but you might as well be writing a custom constraint solver at that point. Don't get me wrong. It'd be cool, and I think they can work it out given time. I just wouldn't hold my breath for it. I'd be shocked if that's something KSP2 can do at launch. But maybe in a DLC, like you said, once they get the core physics and multiplayer stuff sorted.

Yes. But also, rails in Unity? Ooof.

It's a feature of General Relativity that it extends into negative energy densities. But nobody knows if that extension is physical or purely an artifact of mathematics used to describe it. There are plenty of similar examples. We frequently use imaginary amplitudes in electrodynamics, but you can't point an electric field along an imaginary axis. These solutions are not physical, but they are allowed by the mathematics of electrodynamics and can actually be useful as part of computation due to the superposition principle. General Relativity is non-linear, however, so if the energy density solutions aren't physical something new and exciting is going on there, but we just don't know at this point.

It's a bit hand-wavey, but generally speaking, when you generate marketing, you want something actionable for target demographic to do. Like, with very early stuff, it might be something as trivial as, "Sign up for our mailing lists," but eventually, the goal is to get people to buy the game. Given how long the game's been known about and what marketing has already been done, my guess is that next big push is for pre-orders. It doesn't make a lot of sense to build up a hype for anything else at this stage. Also, given how things have gone so far, I don't think T2/Intercept will want to announce release date early, and I don't think they'll start taking pre-orders until at least the month of release is made public. I don't really expect the game to come out before early fall '22. In which case, they might even wait for next year's E3 to announce release date and open up pre-orders. They might start a little earlier, especially, if I'm pessimistic about the date, but I still wouldn't think they'd start in earnest until well into next year. That's not to say that they can't take some opportunities to generate additional marketing earlier. Especially if there are any events or conferences that will be well timed for it. Just nothing like an organized push.

That one isn't as much of a want for me, but it's certainly a nice QoL feature. In some cases, just taking a working design and swapping out the fuel in a particular tank might be worthwhile, and it's certainly easier to change it in tank's settings than to replace the part.

That. There are different kinds of neural nets, of course, but as far as pretty much anything related to Deep Learning goes, you have two distinct processes. You train the network first, which is slow and not necessarily deterministic. Once you are done with training, you use the network for evaluation. At that point, the weights are fixed and the process is fully deterministic. Generally, once you released a version of your product or feature, it will only be running in evaluation mode with all of the weights you generated during training supplied. That way, the neural net will produce the same output for all the users consistently. So yeah, as long as you use the same seed to generate the input, it should always produce the same output. The only place where you have to be careful is the edges of terrain tiles, where you have to make sure to provide a little bit of additional input data from neighboring tiles. But that's standard procedure for this kind of work.

I haven't, but yeah, that's roughly what I was picturing. Native support for multiple star systems should improve some of that dramatically. My biggest complaint is that surfaces of planets/moons look exactly what I'd picture procedural planets/moons to look like. If you are just taking random noise, filtering it down, and then peppering some features, which is all it seems to do, then you only have two possible outcomes. Either bland and featureless or noisy and cluttered. In the real world, there is structure to features. Terrain tends to be fractal-like, but details change with scale. You can't capture that with a simple generator. You have to do something extra. Some terrain generation tools try to fix this by simulating weathering effects from water and wind erosion and sometimes even some tectonics. But that's extremely computationally expensive and takes time to process even on small regions, let alone trying to replicate billions of years of changes on an entire planet. But that's where generative adversarial networks come in. There's a pretty good Two Minute Papers episode on one such example. It is possible to train the network so that instead of topographical guide, it would use output of a noise-based generator and spit out a complete elevation map that has erosion features, valleys, etc. It's a bit of work, but most of the heavy lifting has already been done in research and it's just a matter of getting enough training data.

Wings are confirmed, yeah. And I'm just guessing that there is no reason for fairings not to return. But we haven't heard or seen any indication of any other procedural parts so far. We're pretty sure engines et cetera won't be procedural - might even have confirmation on that - but there is still possibility of other parts, and as I've said above, I'm holding fingers crossed for fuel tanks. Even if they just snap to the same sizes we would have gotten in KSP by stacking different lengths of the same tank type, that'd still be an improvement.

Even at Kerbal Scale, you have to keep in mind that this is in 3D, so 500 systems would be a pitiful likeness of a galaxy. You might be able to get away with 3 digit numbers for some of the globular clusters, but for something that will just feel like a spiral galaxy at scale you have to be operating on 5-6 digit numbers at least. In contrast to the nine digit number of stars in our own galaxy. Now, naturally, if you were to go that route, you wouldn't be expected to visit even a meaningful fraction of the worlds, which means you can get away with considerable repetition, but at least everything a typical player visits needs to feel fresh. So even if that's just a dozen or so systems on average, to account for birthday paradox, you probably need something on the order of 100 hand-crafted systems which you can then vary a bit with procedural work so that everything feels sufficiently unique. Needless to say, that's a colossal amount of work. Maybe if Rockstar takes over KSP3... Another route is go full procedural on everything and hope you make it good enough. No Man's Sky ended up ok. Eventually. But it was no small effort and was designed to be procedural from the ground up. Plus, the creators were fine with it being very sci-fi, so some of it looking... unnatural was par for the course. KSP is a bit more grounded than that, which means that generating believable and yet diverse worlds would be even harder. I don't think Intercept has nearly enough resources for this either. Now, I will say that I would be very interested to see a modding attempt to build a procedural galaxy. With expectations for quality not being quite the same and some amount of repetitiveness being far more acceptable for a fan project, a talented group might be able to put together something that would be interesting. I don't think it'd overshadow stock systems as The Way To Play KSP2, but it might be good enough to sink some dozens of hours exploring all kinds of procedural star systems and worlds. Could be fun. But this is not for vanilla game. If somebody will want to give it a shot, I can pitch you some new ideas from the land of Deep Learning used to create believable landscapes. With a decent underlying generator for base relief of the planet based on classical methods that build up on Perlin noise, a DL algorithm can turn it into weathered mountains, river valleys, place biomes, and so on to form a fairly natural-looking world. I wouldn't use this for a gritty realistic game, but for a KSP-style planet, I think it can cut mustard.

I'm sure fairings will make a return. But yeah, I still want tanks. It'd be very easy to add and would make way more sense to have adjustable length of particular tank type than have separate parts that only differ by length.

But what if we do it... via the Penrose Process! Here is the idea. We drop the black hole we want to recycle into an even bigger black hole that is already rotating. The theoretical limit on how much angular momentum we can give it would actually convert 100% of the smaller black hole's mass into kinetic energy of the larger black hole. We can then use Penrose Process to extract that energy back from the ergosphere. Profit! Thor Odinson on a pogo stick, can't you ask something simpler? You're basically asking if a medium consisting of black holes can lase. I mean, yeah, technically, as far as our understanding of these things goes, I guess it's an inverted population state if you have a matrix of black holes in a vacuum. Somehow. But I'm not touching that bag of Plank gremlins with a Hubble length pole until somebody sorts out quantum gravity. Lasing is inherently quantum, and we haven't even figured out how Hawking radiation squares with quantum nature of vacuum near event horizon, because our math for vacuum disintegrates near event horizon. You wouldn't think that'd be possible, and yet, here we are. So I propose we stick to simple topics, like warp drives and black hole dynamos and leave Hawking lasers to better times.

That is not entirely correct. Or even mostly incorrect, depending on how you look at it. There is quite a bit to unpack, though, so please, bear with me. First of all, Intercept wouldn't need to port anything for the M1. It's up to Unity to make sure that their engine runs on that hardware. And Unity has been working with Apple even since before the official announcement, and by now do have a working Unity player version for OSX on M1. The caveat is that you do need to be on a fairly recent version of Unity to get that support. Normally, that would be a concern, but Intercept will have to have updated to a recent version to keep up with gen 9 consoles (PS5/XBSX), so I think they either already have M1 support or would only need a minor version bump to get it. This does, however, still leave a number of loose threads. The biggest is Metal renderer. This is an issue regardless of whether you're going for the new M1 hardware or the previous generation of Macs. Apple has been dropping OpenGL support for a while, and Unity straight up does not support it any longer under OSX. So you have to make sure that your game compiles and runs with Metal shaders. This might require some amount of tech art work to make sure that materials they've built for the game are compatible with Metal. It is a non-trivial amount of work in a lot of cases, but quite manageable overall. Especially, if your game already runs on PS4/PS5, which have their own rendering library entirely distinct from DX12 used on Windows and XBox versions. Generally speaking, if your game already runs on Windows and major consoles, you are in a good place for Metal and Vulkan, and that covers you with OSX and Linux. As a bonus, Unity takes care of differences in file system, audio interface, input, etc. So in most cases, if you've made a cross-platform games, adding OSX and Linux as extra targets is basically free. But... But you do have some edge cases. And most crucially, you have bugs and potential crashes. Modern games are complex enough that just because you can run on PC and consoles without seeing bugs, doesn't mean there aren't any bugs, and they might manifest on other platforms and only on other platforms. Which means that adding additional targets is never free. You have to constantly be making builds for all the targets and having QA capacity to go through all of them and check each one for bugs. tl;dr - Putting it all together, an OSX port would require Intercept to go to latest version of Unity, make sure all of their materials compile for Metal, and then add a lot of QA and support for OSX build of the game. But there is no special work needed for M1 specifically - that's taken care of by Unity.

Certainly puts a new twist on doing things for the MEMes.

V Speeds - KSP Edition. VX - Best angle of climb. Take off at that speed to avoid structures, terrain, or tall trees at the end of the runway. VY - Best rate of climb. Take off at that speed if there are no obstacles and you just want to gain altitude as rapidly as possible. VZ - Best time to climb. Take off at that speed to pass between blades of the wind turbine at the end of the runway. (Note: Varies with departure time. Consult your terminal charts.)

That depends on your measure of efficiency. In terms of wind energy converted, sure. But if you're not even capturing most of the available wind, that's not a terribly useful metric. In a lot of contexts, what matters is efficiency per area of footprint, and vertical turbines can have a lot more wind cross section for the same footprint. Especially, when available space is limited. This is why you'll see a lot more vertical turbines in urban settings than conventional type. It also just makes sense for a game where you are building on a grid. You need to make a lot of room around a conventional wind turbine. For a vertical one, you just have to make room for the base. Would it really be the best choice for colony power generation? Probably not. But it really makes sense for a game like KSP.

Cost of launch is often comparable or even lower, these days, than the cost of building a probe. And highest risk to mission is usually on launch and/or defects inherent to design. It's better risk management to send your first payload, see how it does, then send a follow-up, possibly with some modifications. See Mars rover missions for some great uses of this strategy.

Based on the orbital construction clamp they've shown in most recent video, and given that we'll be able to build various craft on colonies, I can't imagine it would be too difficult to build your own dock wherever you like.

Yup. Too late for that. What it sounds like is that they'll have more hands on deck to fix and polish things, which, hopefully, means less crunch for Intercept and less chance that the release will slip further. Late Summer - Fall '22 is still the ETA based on everything I've seen. But I would now rate odds of it slipping into late Fall - holidays to be lower. It's not remotely that simple. We're getting a very different game than what was supposed to ship in early '20. Delivering scope of KSP2 we're actually getting on that time scale and with that size studio was flat out impossible. If I had to point a finger at one person, I'd probably "blame" Nate Simpson for the delay, but I also think we're getting a much better game as a result, so it was probably the right move. As for Star Theory not making that game, well, that one's harder to place. It was definitely about money and politics more than anything, and I don't know which side was ultimately unreasonable. T2 did handle communication on it horribly, though. Even if they were forced into a position, the response was crappy and I can guarantee impacted decisions of some smaller studios to work with T2/PD in the future. Somebody clearly was only thinking about cold tactical advantage and not how that's going to look from outside, which is always a mistake if you're running a public company. But from perspective of KSP2, fallout from rescoping the game would have been roughly the same. We might have had a bit less delay if things could be worked out with ST, but we're talking 6 month difference at the most - likely less. And that's under assumption that there weren't problems with how ST was managed to begin with, which is purely a benefit of the doubt at this point. It's entirely possible that ST leadership would have caused same amount of time lost following renegotiation. Bottom line, I don't think 2022 release was avoidable regardless. As soon as creative leadership on KSP2 and Take Two saw that they can make a much bigger game with better general appeal, this trajectory was set.

That might actually be the best way to address that. Throw in an option to start the game at a different launch site, and I'm sold!

Wind would add a lot of variety, though. I think I would prefer "wind affects craft" to be a setting when you start the game, and when enabled, work across all planets and moons with atmosphere. And to be clear, wind should always be there, because it can add to weather variety visually, but affecting the physics could be a toggle.

Sorry if I'm wrong, but it sounds like you might have missed this video. We know for a fact that there will be clouds in the game.