K^2

No. Complexity doesn't lead to uncertainty. If you can examine every little element and predict the outcome, then given enough time, you can go over everything and predict the outcome for the total system. Granted, it's a practical impossibility, which is why concept of chaos exists, but it doesn't make the system indeterminate. Between the chaos and quantum mechanics, though, I can be pretty bold about making claims about determinism of the universe, and still, I'm going to come up completely dry if you ask me about free will. I think, a lot of people conflate the two, but they are orthogonal concepts. Yes, in the grand scheme of things of all of the universe, none of your choices matter. But you can probably guess that without a degree in physics. On the other hand, you make decisions based on partial knowledge of the universe around you, and choices you make influence what changes you will observe in the universe. And that might sound like a bit of a solipsist view, but as you can't really experience universe from perspective of another person, that's all you really have to go on to judge your impact on the universe, and from that perspective, your actions and consequences are entirely a matter of your own choice. That's a far cry from definitive, "Yes, people have free will," but it's also a resounding "maybe" in a context of the universe as a whole being fully predetermined, and that's kind of amazing.

Nonsense. By that metric gravity is theology. You can't prove that there isn't a deity that's holding everyone to the ground and bends light as it passes stars, therefore, any claims that gravity is due to general relativity is religion! That's not how science works. We actually have a body of work on randomness of physics. We've tested the hidden variable theory and found it to be bogus. We've tested quantum mechanics and found it to be valid. We can draw conclusions based on it. And that's not how uncertainty principle works. It's not about inability of you to know the momentum and position, it's about the fact that you can't have electron in a state where both are eigen states of the respective operators. An electron in a certain position has a spectrum of momenta and vice versa. And that goes back to the fact that there are no hidden variabl.es. It's part of why quantum mechanics is fully deterministic.

Every test we've done shows physics to be entirely deterministic. Yes, even quantum events. Any time you observe a "random" outcome, it's just a side effect of you having partial knowledge about the system state. In case of classical "randomness," like a coin flip, that's an uncontroversial statement. In cases of quantum randomness, it requires a bit more interpretation, but the bottom line is that you need an observer with partial information and a system to observe before you get anything like "random" outcomes. If you describe that interaction as a complete system, all random outcomes go away, and you have a purely deterministic system. It's only when you start describing the observations an inherently limited observer is making that randomness comes into play. In ironic twist, perhaps, is that in classical theory, a random outcome is when you discover something you didn't previously know about the system. In quantum mechanics, you get a random outcome when you failed to learn something about the system. The net outcome is the same though. The universe is entirely deterministic and essentially a fixed structure in time. We're just too insignificant to appreciate it, looking at the most minute portion of the universe, and thinking that it seems kind of random.

Clocks aren't even half the story. The biggest bottleneck was cache performance. And while I haven't had hands-on with next gen yet, it sounds from specs like it might be a similar kind of story: CPU that's technically powerful enough to feed your GPU pipe from purely compute perspective, but starts to stutter the moment you are trying to do anything fancy. And, I mean, yeah, it's a definitely an improvement over Jaguars of the PS4/XBOne, but so was the Evolved Jaguar on PS4 Pro/XBOne X. Remember when these just came out, and it looked like it solved all the problems, because the numbers were better across the board and games built for the original systems ran pretty well on these? That didn't last long, though, as everyone expected better graphics on updated versions as well, and we quickly went back to the same problems we've always had. Worst of all, again, compared to compute capabilities, cache performance lagged dramatically. Meaning your pipeline is constantly starved.

I don't know if that's strictly a requirement, especially with Unity. You can easily catch up additional platforms to your leading one after the fact and then release in lockstep. The reason a lot of companies don't do this is because consoles and iOS require certification for any update. With iOS, there is some content you can push live, but if you update your game's code, you basically have to certify it just like you would with consoles. That requires some lead times before the updates are released, which can make QA a bit more of a challenge. And then, what happens if one of the versions fails cert? Do you delay everything? Or just the platform that failed? In contrast, PC release is a "free" opportunity to test the game. If there's a serious problem, you can release a patch within hours of discovering it. And because of similarity in hardware, most serious bugs are going to manifest across platforms. So if you catch all the bugs on PC release, you can have a much smoother release on consoles. But if you're doing that, consoles aren't even going into cert until well after the PC version of the patch released, and so you end up with significant difference in release windows.

So has the current (past?) generation, just with severely underpowered CPUs. But that hasn't changed, so really, there's absolutely nothing different with next (current?) generation. Come to think of it, the only XBox that was ever not just a cheap PC was the 360. That one was a Mac. (Trust me, that joke would have been funny fifteen years ago.)

You can't exactly put something into orbit quietly, so overwhelming majority of objects in LEO are tracked. There's always a chance of some forgotten derelict or a spook sat that quietly moved to another orbit and nobody noticed, but there's also a chance of a random rock just flying by. Generally, whoever does the launch will try to pick an orbit that's less likely to collide with anything. But that's no guarantee. And every nation that does launches, and probably a few that don't, basically just try to watch everything and notify whomever it concerns if there's a likely collision. Sometimes, one or the other satellite can be moved. Sometimes they just get to cross their fingers and watch. And collisions still happen, but yeah, they're extremely rare. Even birthday paradox can only do so much when there's so much space even in just LEO. Edit: There might have actually only been the one satellite-satellite collision. Though, there have been debris strikes before. 2009 collision.

Fair! In that case, might even be possible to pull off a brief hover, and then the sample return can be entirely passive. (Edit: I mean, the part that returns to upper atmosphere from the lander.)

Earth's atmosphere is rotating significantly faster than Venus'. We just don't call that wind, because ground rotates at the same speed. Venus' atmosphere super-rotates, but due to high density and viscosity of lower layers, any effect from difference in rotation speed between ground and atmosphere is completely nullified a few kilometers off the surface. The ground might as well not be there as far as upper atmosphere is concerned, and so the absolute wind speed is completely irrelevant. On Earth, we're used to high turbulence, shear, and wind gusts to come with high wind speeds, because there is interaction with static terrain as well as temperature variations across it. Even on global weather scale, mountains and shapes of continents make an impact on how weather systems develop. You don't have any of that on Venus. The atmosphere is opaque, so the heat energy received by atmosphere is exceptionally uniform, and mountains are all lost in that thick, viscous part of the atmosphere, so they make absolutely no impact. The "weather" in upper Venusian atmosphere is exceptionally "calm". There is very little shear, turbulence, or gusts. Movement of atmosphere tends to be very uniform over large distances. There's still a huge challenge in docking at hypersonic speeds. And I don't know enough about hypersonic aerodynamics to say how doable that is. Naively, I want to say that if you're catching up from behind, you should be inside the shock cones, and so it shouldn't be fundamentally different from same maneuver at subsonic speeds, but I'm not certain. If that's not feasible, you'd have to drop speeds to subsonic and do docking the same way the in-air refueling is done. A slower start will mean extra fuel requirements, and then this might not work as an SSTO. I still think recovery vehicle should be a space plane even if it has to be staged, but it would certainly mean your recovery vehicle is larger and payload you can retrieve is smaller, which is a shame. But in any case, the absolute speed of wind with respect to terrain isn't going to matter. Conditions are going to be much better than they would have been on Earth at similar pressure altitude. The only thing that matters is how fast you're moving through local atmosphere during the docking.

There's definitely room for discussion here, and above is what popped into my head first, but I would still argue that sending a lander first by itself, and after the sample return portion ascends with balloon, do a fly-by to pick it up with a recovery vehicle is a better plan. The plan you outline has two main advantages. You can, potentially, send multiple probes down, as you've said, and you also don't need to do any high speed maneuvering to collect the samples before returning. Note that in your plan, the sample return will still have to chase the main rocket. Venus has very strong winds at high altitudes and basically none at ground level. Anything that goes down and then back up is going to fall very far behind. Near equator, it might even make sense to wait for a full revolution, as it takes upper atmosphere only 96 hours to revolve around the planet. Naturally, whether you wait for a round trip or try to catch up, making way back to the main ship is going to be a huge challenge for landers. In addition to that, you are still dealing with a giant zeppelin supporting the main rocket, which you need to deploy while descending through atmosphere within a very short window of atmospheric entry. It's far from the greatest challenge of the mission, but it's a non-trivial one, and will further reduce maneuverability of the main ship, requiring the sample return vehicles to do all the maneuvering for rendezvous. This is precisely why I recommended sending a recovery vehicle from orbit only after sample return has ascended to high atmosphere. You can be fairly precise when coming in from orbit on where you'll meet up with the sample return, and recovery vehicle can be effectively gliding at several times the speed of sound in its vicinity without requiring much in terms of additional hardware compared to what you'd need to enter the atmosphere. So all the sample return vehicle needs is a small rocket to get up to the same speed. And since now the recovery vehicle already has a decent starting speed in relatively thin atmosphere and in lighter gravity, you are very likely to be able to get away with a relatively simple SSTO. The downsides, of course, are that you'll very unlikely be able to collect more than a single sample return vehicle in a single pass, which almost certainly means that's the limit for the mission, and you do need to dock two vehicles traveling several times the speed of sound completely autonomously. On the plus side, the later sounds like a pure engineering challenge. So overall, this seems like the most doable thing with technology as is. Any practical jet used in propulsion is a thermal jet. But yes, I've addressed nuclear thermal.

Not even close. I'm not sure what gave you that idea. The only kind that might be even remotely viable is nuclear thermal, but you'll have a heck of a problem with waste heat. And you'll still get better TWR out of running a turbine to a prop. Jet propulsion makes sense if you are moving fast relative to the working fluid, and that's the last thing you want on Venus. You want slow turning props that generate high thrust to pull you out of that soup. The density you're dealing with is a lot closer to that of water than that of air. And high temperature actually makes gasses more viscous. You do not want anything moving rapidly relative to the atmosphere in these conditions or that's where all the energy will end up. Honestly, at just the intuitive level, if you are trying to come up with a plan for leaving Venusian surface, try to imagine leaving Earth, but you start inside of a vent of a volcano at the bottom of an ocean. That's a lot closer to the kinds of challenges you'll be dealing with in terms of hydrodynamics, temperature, and probably even chemical composition. The biggest difference is that there isn't a clean liquid/gas interface like you do get with the ocean, so any techniques you come up with for early ascent are going to start struggling before the techniques you'd use for late ascent become efficient. And that makes Venusian ascent extra, extra challenging.

That's a non-starter. First of all, in lower Venusian atmosphere, rockets are just a bad idea. If you want a plane to do initial climb, it will have to be propeller driven. And that can get you to altitudes with similar conditions to airliners, albeit, at lower speeds. And note that we don't launch rocket planes from these altitudes either. We go for regular old rockets. You just don't get much benefit from wings if your propulsion system is a rocket. Can you builds a prop plane that launches an orbit capable rocket on Venus? Maybe? But it seems like a very inefficient way to go about it. If our goal is something like sample return, I would propose one of two solutions. First option, we land a rocket on parachutes, then lift it with balloons into as thin atmosphere as we can, then do conventional launch. The downside is landing a rocket on Venus. Building tanks that will survive the landing is going to be extremely difficult. So would building electronics that can manage all of that and survive the temperatures. So while the mission profile here is simple, I'm worried it will stretch our material science to the limit. Or past it. The second option is rendezvous. You drop a dumb lander. It scoops up dirt and fires gas generator canisters that inflate balloons. This can all be done with zero circuitry if needed, using clockwork. Now the goal is to meet up with the rocket in upper atmosphere. You probably want to have a space plane re-enter but keep going at hypersonic speeds in really thin atmosphere, so your sample return will have to match speeds. That can be achieved with a simple solid state motor and a simple guidance system, though, leaving the job of precise maneuvering for pickup to the space plane. Once the payload is picked up, the main rocket is fired and the rest continues similar to launch from high altitude aircraft. This kind of mission will require good timing and very precise maneuvering, but it's something we know how to do. So I think it's the more plausible of the two. The only good news in all of this is that unlike Eve, Venus has a slightly lower gravity, so at least the orbital velocity you need to achieve isn't as high. But it's still something you have to get exceptionally creative with to have a chance to pull it off.

Sure, but that requires a collision scene rebuild and makes streaming terrain more awkward and expnsive. I can see it becoming prohibitive on consoles. And you are still limited to height map resolution, which isn't terribly high. With VTs, you unload work to GPU and can have resolution down to centimeters.

Instructor: "You know that thing we've practiced not hitting for the past few lessons?" Student: "Ground? Yes." Instructor: "I want you to hit it this time. But gently." Student: "Hit it? On purpose?" Instructor: "Yes. But gently."

I wasn't going to after the first one, but now I have to.

Also, if I do put engineering vessel into an unfortunate spin, I'd rather have to go hunting for one kerbal without an EVA pack than a dozen. Actually... Do engineers in External Command Seat allow EVA repairs and/or contribute to the assistance count? I haven't checked, and that might be a fairly convenient way to do orbital construction.

Oh, ladder forces got fixed? Great news. That was honestly by far my biggest problem. Sometimes, there is just no way to get around having to do construction from another ship, so you can move about with the storage in tow, but then the ladder force just made matching orbits impossible to any practical degree. For large construction, I prefer to keep old methods. Use docking ports in more places, then your engineers can always add RCS and probes to any large sections and you can move them under their own power and re-dock as needed. The great thing about EVA construction update is that now I don't have to pre-emptively put RCS and probes on everything and once things are attached, I can add struts and fuel lines. And that's honestly enough to get almost any orbital construction or retrofitting I might care to do. Though if they added a part that increases construction weight limit, that'd be neat. Like, a manipulator arm of some sort that you can attach to your engineering vessel or station used for orbital construction.

You are probably not correcting for inclination change. Park in circular around Kerbin, set Minmus as target, look for ascending/descending nodes. Put a maneuvering node on one of them and adjust the normal/anti-normal until the new ascending/descending node reads 0 degrees - it might move to a different place, that doesn't matter. You can adjust retrograde at the same time to keep orbit circular, or you can fix it later. After you execute that node, encounter with Minmus should be very easy. You can make it trivial by using KSP subway map. Minmus is 930m/s from 80km parking orbit around Kerbin. So if you put your ship into an 80km circular orbit with same inclination as Minmus, just create a new maneuvering node, dial in 930m/s for prograde, and then slide that node around orbit until you see an encounter. You can't miss it. This does cost some extra delta-V for inclination change, of course, and there are ways to save that fuel by making sure you are doing correction late in transfer. That requires waiting until Minmus is in a good place for such transfer, however. Another pro strategy is timing your launch and going for 6 degree inclination orbit that closely matches that of Minmus right away. Both of these are harder to execute but will save you a lot of delta-V on inclination change. Minmus doesn't require you to be terribly fuel-efficient, though, so you might as well go for simple and fix your inclination in parking orbit as described above. There are other planets/moons you can't time nearly as easily and have eccentric orbits on top of odd inclination, so if you haven't had trouble with them, you were lucky.

As someone who works on a team that shipped a major game during pandemic, the impact wasn't all that high. There was definitely loss of efficiency, it was harder to test builds, and we straight up lost a couple of weeks in transition to working from home, and some companies lost closer to a month, but it still adds up to a few months, not years of delay. Educated guess, based on information released, is that the original plan for KSP2 was basically a face lift. A prettier version of KSP on newer version of Unity. Basically, a glorified DLC with some rework to make better use of updates the engine's been through and ensure smooth release on next gen of consoles. Interstellar and colonies are a pretty big addition, but the way it was presented initially, can still be looked at as a couple of DLC packs. This matches up against timeline, the early press releases, and the fact that the game was given to Star Theory - a tiny little studio with no experience in making large games. They were supposed to take KSP, update the rendering, add some new rocket parts for interstellar, and ability to build modules on planets, plus add another star system to explore - probably just the one. A reasonable scope and timeline for Star Theory. I'm guessing, this changed after response to E3 video in 2019. I don't think Take 2 / Private Division expected such favorable feedback to announcement. Game started growing in scope, probably with Nate Simpson as primary driving force with a node from someone at Private Division. Colonies becoming central element of gameplay progression and interstellar expansion, multiplayer that was just mused about became a core feature. Larger ships, more star systems to explore. Much, much bigger game. Somewhere in the process of negotiations for that scope expansion, Private Division and Star Theory came to an impasse, and Take 2 authorized creation of Intercept Games. Pandemic hit just as development was ramping up in a new studio. The combination of much larger scope, new developers, and the pandemic does sound like the right amount of factors to delay the game into 2022. I doubt Intercept went into what can be qualified as full scale production until late spring to early summer of 2020, and you aren't going to make a game like this in less than two years. And while it's not exactly starting from scratch, given the scope change, it might as well have been. The only part I'm a little upset about is that they kept trying to make it look like they're trying to salvage original timeline with some delays when it was clear that wasn't going to happen. Announcement that game would be delayed to 2022 should have come out sooner. Other than that, this seems about right for the size of the project they're working on. As for announcing early, I really do think Take 2 honestly expected to ship KSP2 much sooner as a much smaller game. And on the net, I'm glad we're getting a proper sequel rather than just a remake. So I'm happy to wait.

It doesn't need to be all THAT more complicated, but having docking "magnets" be optional might be nice.

Some sort of beamed power, at any rate, yeah. Again, I don't know if that'd be within scope of KSP2, but that's the sort of thing that I'd like to see in a mod, at least. Plausible with near-future tech. Very useful, as even the most basic implementation is like having a jet engine on your SSTO that requires no fuel while you're in atmosphere. And yet, it comes with significant limitation of requiring either a ground or orbital station to produce required power. It's just a perfect synergy with KSP2's base-building.

More like coilgun, but it's an electromagnetic linear drive of some sort either way, yeah. Same with startram/maglev. Main difference is that magnetic levitation of the later makes it a bit more viable for regenerative landings, not just launches. In both cases, atmo is a huge problem. There are proposals of building these at high altitudes, using vacuum tubes, etc, but I think that's all a bit too out there for KSP2. On the other hand, on the airless worlds/moons, you literally just need to build a really big electromagnetic accelerator to launch cargo into space. It's pretty straight forward, and given much higher g-tolerances of Kerbals, makes it viable as tech for colonies.

Visually, very easy to do, but the hard part is updating collision model. Whenever you are playing a game, you can picture it as two worlds co-existing at the same time on the screen. One is what gets rendered, which is purely visual and doesn't affect any gameplay or physics, and the other is the collision world, which defines all the boundaries, but remains entirely invisible. And they are handled completely differently. Rendering is done on the GPU fairly haphazardly, because it's more efficient to throw more shader cores at the problem than do any sort of complicated logic*. Collisions are handled by CPU, so all the collision geometry is neatly organized into hierarchies for quick access. If you want to render a crater, it's easier to just render terrain with a chunk of it set to transparent and then draw the crater model over transparent bits, and it will look to you like there is a crater in the terrain. You can't do that with collisions, because there is no way to just make a portion of collision geometry "transparent". So if you want to place a rock on the terrain, well, that's still going to require you to update the hierarchy, but otherwise, you just add more collision geometry. But if you need to make the hole in something? That's an adventure. The engine I'm responsible for, we have a way to disable some of the collision triangles on a mesh during build time. It's convenient specifically for cases where you want to make a crater or a tunnel through geometry that's already been designed. In principle, you could add some code to enable/disable individual triangles in the mesh at run-time. But it's not free - the collisions will take longer to compute if you do this, and it really has to be built into the physics engine. As far as I'm aware, that's not an option in Unity/PhysX. So if you want to be able to have craters in terrain, you have to go custom with your terrain collision system. I've described in a post above a good way to offload it to GPU, which isn't something you can do for general collisions*, but you can for terrain. It is a lot of extra work, however, and I don't think Intercept has resources to throw at this right now. * Worth nothing, I'm describing conventional GPUs with conventional rendering. Ray tracing uses "accelerators" which are very similar to how collision hierarchy is handled, so in theory, at least, RTX/RDNA2 graphics cards should be pretty good at running collision detection. But it's unlikely we'll see a lot of games utilizing that at least for a while.

Yeah, full opacity might be a bit complicated, depending on how they set up the shaders for decals, but alpha-cutout is always an option. And with some temporal AA, the edges should look smooth regardless.

You know? That'd be a good way to expand the AU formula. Say, you need to make sure you have a pilot and an engineer by the end of the game for a crew victory. You can try to guess what role each player has by the tasks they are doing. So now there's a reason for crew to fake their tasks as well and for impostors to pay attention to what tasks are being done. And a lot of, "You can't vote me out, I'm the last pilot left!" during discussion. Fun!