K^2

The answer is "Colonization of Mars." There are enough good arguments for not going down another gravity well at all, but if we have to settle down somewhere, Venus is a much better place. The only thing Mars has going for it is solid ground under your feet, and that's overrated. Especially, when that ground is irradiated, chemically toxic, and abrasive for a good measure. Almost total lack of atmosphere and radiation protection means that the only possible living on Mars is in small, stuffy tunnels underground. Not sure what will limit your life span on Mars more, constant stress over maintaining all the air seals in confined space or the effects of low gravity. Venus gives you almost a full Earth gravity and temperatures just above freezing at altitudes where atmospheric pressure is close to Earth's. The atmosphere's not breathable and toxic if you inhale it directly, but it's there, meaning that even if you lost pressure, you could hold your breath and have a couple of minutes. And since the pressure in habitat is pretty much equal to outside pressure, you can build large clear domes out of plastic really easily. No need to be stuffed in a tiny tube with no windows. Plus, small leaks are effectively harmless. Mars has such thin atmosphere that CO2 capture is actually somewhat of a challenge there, especially given the fine dust that will damage and clog any turbines you build to compress it. And carbon is the easy part. Water is present pretty much only as ice, and you have to dig through aforementioned toxic dirt to get to it. Good luck getting nitrogen. All of this makes manufacturing on Mars actually very, very difficult. You are in luck with a lot of metals, but getting them out of soil is going to be a complex process requiring very significant infrastructure. Prospects of more conventional mining are unclear. Venusian atmosphere is basically giving you all the building blocks of hydrocarbons. The CO2 and nitrogen are readily available for capture. The atmosphere is often quoted as very dry, but that's because all the water is bound in sulfuric acid droplets. If you account for that, Venus is actually quote moist. At relevant altitudes, the sulfuric acid content can reach 0.1g/m3, which is comparable to typical moisture content of dense fog. The sulfuric acid is trivially decomposed into sulfur oxides and water vapor at temperatures of a few hundred Celsius. And because all of this is taking place at high altitude, you don't have to worry about solids damaging your condensers. The only disadvantage of Venus in terms of long term sustainability is access to heavy elements. Early on, any colony will have to be good at recycling. I would argue that recycling metals is a lot easier than recycling organics, making it easier to build an outpost on Venus that can be self-sustaining for years or decades. To make it properly lasting, you would have to come up with some sort of a scheme for mining. Whether it would involve dropping scoops on the surface or some other arrangement. This is entirely feasible if you have a healthy industry and large population. And the fact that the colony can grow with just minimal supplies of minerals from off world initially is already a huge advantage, which means we have an actual chance to expand a Venusian colony to self-sustaining levels, whereas a Martian colony would rely entirely on off world supplies for a very long time. At the end of the day, we might end up bothering with neither, sticking to building in space instead. But either way, trying to build a colony on Mars before Venus is entirely silly.

The open 'u' by itself is pronounced as "you", which is actually two sounds, the vowel "oo" and a voiced palatal approximant (I did have to look up the name, yes). That has tendency to merge with a preceding consonant in ways that vary heavily on language and dialect. (Because it's a tiny variation in tongue position and the exact timing on voice.) In at least some variations, the way the "dy" merge together, they start making a "dj" sound (as that includes a palatal fricative), and so it gets quite close to "Junah" in the way it sounds. Another option is for palatalization of the consonant itself, which would make it sound like "D'unah", which is the way pretty much any Eastern European will pronounce it (e.g. Russian). But in US English it does seem far more common for that voiced palatal approximant to either stay separate ("Dyoonah") or disappear entirely ("Doonah").

The name very likely derives either from nickname of Arrakis, Dune, or the literal sand dunes. Either way, the pronunciation of "dune" as "d(y)oon" strongly implies that it is pronounced closer to "D(y)oo-nuh" than whatever the standard rules of English spelling would suggest. Edit: Actually, it's an open syllable either way, isn't it? It'd have to be "Dunna" to be pronounced differently.

Idk, the effort bar to get the main controls, at least, interactable is super low. I don't know if it'd be anything more than a gimmick even then, but making the whole mission flyable entirely in VR is not a lot of work.

There might be a shortcut I'm missing, but I've converted both coordinate systems into Cartesian and worked from there. The Z axis will run through the poles, and without loss of generality we can take the X axis to be passing through ascending node. Also, we really don't care what the longitude's going to be, so we can set 0° at ascending node as well just for simplicity. We will also be working with true anomaly, so we don't care about the actual radius, so I'm going to take R to be 1 for both planet and target orbit. This is correct to within oblateness, and that's a separate can of worms. For the same reason, we can take argument of periapsis to be 0°, so we'll be counting true anomaly from the ascending node. So the spherical coordinates are latitude and longitude: θ, φ. The orbit coordinates are true anomaly and inclination: ν, i. Conversion from polar coordinates to Cartesian: x = cos(θ) cos(φ) y = cos(θ) sin(φ) z = sin(θ) Conversion from orbital elements to Cartesian: x = cos(ν) y = sin(ν) cos(i) z = sin(ν) sin(i) So then you just have these 3 equations to work with. You really only need two of them, but it might be convenient to switch around which one you're using depending on what you're solving for. cos(θ) cos(φ) = cos(ν) cos(θ) sin(φ) = sin(ν) cos(i) sin(θ) = sin(ν) sin(i) If we are looking at situation where we know the desired inclination i, and the starting latitude θ, then you know cos/sin of these angles and you can work out what the ν and φ are going to be. Now, you shouldn't treat φ as actual longitude of the launch - rather, it tells you what the launch window should be to match your desired longitude of the ascending node. Finally, if you want the angle for the heading, you have to do a bit of calculus. If you treat orbit as a parametric curve parametrized by ν, you know that the tangent in polar coordinates will be given by ∂θ/∂ν and ∂φ/∂ν. ∂θ/∂ν = cos(ν) sin(i) / cos(θ) ∂φ/∂ν = cos(ν) cos(i) / (cos(θ) cos(φ)) So the heading angle will be given by arctan((∂φ/∂ν) / (∂θ/∂ν)). Keep in mind that this is true heading, and you need to do considerably more math to get ground heading from it.

The demo with plank and a "cart" made of rollers is all you really need to understand. If you understand why the cart can outrace the plank that's pushing it in that demo, you shouldn't have any trouble understanding why same works with the wind or any other fluid.

OP, you are confusing several different coordinate systems. Heading and pitch are relevant with respect to local horizon. Inclination is an orbital element. You shouldn't be mixing these together. And neither is inherently tied to your geographical location, which is yet another coordinate system. A rocket taking off from 20°N latitude will end up in an orbit with an inclination of no less than 20°. And to achieve exactly 20° the ascent will begin with rocket pitching over to head East, 90°. In general, the optimal ascent will always begin by heading directly East regardless of where you take off from and will put you in minimal possible inclination. The only time you might want to launch in a different direction is if you are targeting inclination greater than your latitude. In general, relationship between initial heading and final inclination is quite complex. For example, if you take off from 20°N and wish to establish an orbit that has inclination of 30°, the heading you should be aiming for is 108.6° or 71.4° (via considerable amount of trig). So roughly East by South East or East by North East, depending on how close to ascending node you want to be. You're still going mostly East, though.

JT works with telescoping as well. If you do the math, the relevant component is just a dot product between error and the direction the piston extends in. Again, you want to scale it to relevant velocity and then apply limits to avoid over-extension. But it works pretty well. JT actually works with arbitrary degrees of freedom. So long as you can take first derivative of your effector position with respect to your available DoF you can apply the method. For some DoF the math ends up very ugly, though. It's specifically translations and quaternion rotations that give you very clean, very easy to use results. Fortunately, that's also what you are usually dealing with in simple robotics and animation. If you have complex linkages, then, of course, you'll have to do additional work. But that tends to be the case with any IK method.

All good stuff. I like JT specifically of because how trivial it becomes in quaternions. You literally just take cross-product between the vectors to end effector and to target from given joint, multiply by a rate, and constrain to the joint limits. Apply iteratively and that's it. The only downside is that it's unstable with respect to starting conditions, so if you have to IK from animation on every frame, it doesn't work great. But it's fantastic for robotics. If you want stable solutions, it works best if you add energy cost to individual joints, and then do damped least squares, yeah! So long as your energy costs are sensible, small variations in starting positions will result in small variations in motion to target, which is great for animation work.

That's a pretty big leap. This comes from old footage - pre Intercept. The game has been pretty much re-written since then. There is no guarantee that this arm made it through to the current version. And I'm pretty sure we never have actually seen it move. Regardless, though, it could easily have very limited motion, similar to how we've had ramps before Breaking Ground, but you'd never consider it robotics. At best, we can say that at some point during game's development, components that would make sense with robotics have been considered. This isn't anywhere near "definitely there," as much as I'd like to hope so.

It's in the upper half, for sure, since you need NTR tech as a pre-req, but I have a feeling we'll have a lot of interesting tech up in that portion of the tree anyways. So by the time you get to that point in the game, a climb out of planet's gravity well is mostly just a chore, so making it easy with an engine like this isn't a bad thing. Of course, it depends a lot on how they balance out progression overall.

I don't think multiple skyboxes make sense. It'd be a pain to blend them as you travel from one star system to another. It seems far more likely that there would be a single sky box with "distant" stars/galaxies painted into it and any of the reachable stars, which are the only ones that would likely have appreciable parallax, be rendered directly - similar to how moons and planets are handled in KSP. There is, potentially, a world where skybox is generated procedurally by rendering all the stars from a database. That can be split between frames to keep cost to an absolute minimum while still providing realistic parallax and giving a bit more room to expanding the star systems in the future, but it seems unlikely that it'd be considered worth the trouble, so my money would still be on a single skybox texture. Other than that, so long as you keep your work in a lossless format, I don't think you'll have trouble converting it. Just make sure it has high enough resolution. Something that looks good in 4K at 60°FoV should be sufficient. So I would keep your source work for the cube map as six 4096x4096 textures, and if the actual cube map will end up a bit smaller in resolution, you'll be able to downsample to whatever the game actually expects.

I think that's much more reasonable with KSP2 than KSP, anyways. In KSP, you either had to squeeze all the biomes for science, including a bunch of KSC biomes, which always feels a bit like an exploit, to have half of the tree unlocked, or you need to go to the Mun without a lot of the tech that I'd consider "essential" for that sort of mission to not be a frustration. And if you did squeeze biomes for science, then by the time you'd be done with Kerbin system, you had most of the tech tree unlocked. A couple of flights to Duna and Eve and you were done with career mode. It's not a great balance either way you end up playing it. In KSP2, tech scales up a lot more. That LANTR engine they've shown of recently would make a lot of SSTO designs trivial, but then it can also be locked way on the far end of the tech tree. There's just so much more to unlock that you don't need for early interplanetary gameplay that it'd totally make sense to lock some of it away behind exploration of outer planets. I would even not be upset if there were multiple science "currencies". Like, you can get basic science from Kerbin system and inner planets, but you need some "advanced" science that you can only get from outer planets if you want to research the upper echelons of the tech tree. Alternatively, keep something like current science system in place, but add "achievements" that have to be met as part of the unlock condition. These could be recovering science from SOI or surface of certain objects, for example. So long as they give you a bit of flexibility on how you go about it, I don't think it's undue challenge to get a probe to any of the outer planets or moons. In a game where you have to go interstellar just to visit all the places, that doesn't seem like a big ask at all.

Steam does allow for creation of discount coupons that are automatically sent to owners of another title. It might be a nice gesture + a good marketing move to send out a small discount on KSP2 to KSP owners on Steam. I wouldn't expect more than 5%-10% discount with something like that, though. I have no idea if there is a similar mechanism on consoles. I know you can generate conditional discounts for SKUs, but I don't know if there's anything like a discount coupon. The neat advantage of the Steam's approach to this is that you do get a new "item" notification, which might generate more sales. Other than that, though, I wouldn't expect anything. It's a new game with completely new development cycle. Other than the IP and some overlap on devs, there isn't really a connection between the two games.

Would actually not be hard to make it work for user-built stuff. UI for setting up joints might get a little awkward, but something like Jacobian Transpose method is a breeze to write, works with arbitrary chains, and does alright with joint limits.

One of the designs in the original trailer looks a lot like it's inspired by beam core antimatter rocket proposals. Obviously doesn't have to mean anything, but makes it look like it was at least considered.

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.