K^2

In theory, yeah, you could come up with a whip-launcher. But if you can build a megastructure like that, there are easier ways to launch something. If you have an "anchor point" and a tether long enough and strong enough attached to it, just use a magnetic linear drive to accelerate the cargo along the tether. It will be more energy efficient, you can get away with both a shorter and a thinner tether, and you won't be putting the tether under that much stress.

You now that x < 100 + 500 y(y + 1)/2. Treat it as equality, solve for y, then take the floor. Fix some sign nonsense, and you get this: y = floor(sqrt(abs(2 x-75) / 500 + 1/2)

There will definitely be some way of running the game on Linux and possibly even OSX even if there is no official support. I'll be getting the game day one for playing on my Windows machine, but I have a Steam Deck, which I don't think will run the game well, but should at least be a good way to see how the Proton manages it. So I can at least give you all a heads up on "starts/doesn't start" right away.

You generally shouldn't preorder games. It's one of these things that only helps corporate numbers, pretty much never impacts what the developers are getting out of it, and can actually harm development, because it results in the marketing for the game happening early, and a lot of developers are pulled from their work to provide footage and screenshots for marketing in the best case or working on preorder bonuses or even early beta when the developers should really be polishing the game and creating good day-one experience. As a game dev, I would much rather see people wait for day one to buy the games. If I'm getting a bonus from sales, a day one sale is as good as a pre-order, and if nobody preorders, I can spend more time making the game better for that first day. There's not going to be a shortage when the game releases if you're getting it digital. And you can even have a short window for a refund if it's bad. (At least, on Steam.) Get the game day one, keep it if it's as good as you expected, and don't participate in corporate's charade.

I've shipped multiple titles on XB1 and XB1X, and I even have an unfortunate experience of porting a PC game to run on XB1 back in 2014-2015. Most games are GPU-bound. That's why you can take an XBSX game and port it down to XB1X by just stripping down the graphics. But games that are CPU-bound? It's an absolute nightmare. The CPU on the 8th gen consoles was garbage. A steaming pile of contaminated manure in a plastic casing that we were all conned into treating like a processor. If it will be an eternity until I have to deal with the Jaguar's cache issues again, it will be too soon. KSP is a very CPU-demanding game. It already runs on the 8th gen consoles like it just woke up three hours before normal and haven't had its coffee yet. While we expect KSP2 to be far better optimized, it also has way more to do on the CPU. We're getting physics improvements, improved physics warp, more resource systems, colonies, extra load in multiplayer that can't be discounted in this discussion... I expect that systems that struggled running KSP due to CPU limitations will manage a slide show at best with KSP2. It's very likely that XB1X or PS4 Pro aren't getting KSP2 at all. Theoretically, even if the team can spend an extra year optimizing every system to perfection, cutting all the unnecessary bells and whistles, and getting it to run on these systems well enough for a release, it probably won't be relevant anymore. Not in terms of sales it could generate in proportion to effort expended. I don't think Private Division is going to invest in such a task.

Very different kind of wheel simulation.

Anti-satellite weapon has a huge relative velocity on impact and full orbital speeds in absolute terms. A skyhook docking happens at relative speeds in tens of meters per second, allowing for terminal maneuvering, and the absolute speeds you are dealing with can be nearly half an order of magnitude lower. These two problems aren't even close. You're on. Stock parts, airbreather jet plus 100m/s or so of orbital for maneuvering and docking sounds good enough? And I'll be using straight up save file hacks to create a skyhook I can actually dock with and probably some mods to extend the physics range. I'm anticipating about 1km/s in suborbital just above Kerbin's atmosphere where I'm meeting the hook, and that's going to require a 200km arm to give me that 2g difference. On release, I should have escape from Kerbin plus about 400m/s, which is enough for a number of interplanetary missions. Manual flight, using only stability assists available in the game, but I reserve the right to have some external calculator tools running to make quick estimates for corrections I'm going to need both for the rendezvous and the actual docking. It'd make for a tight departure window and some precise flying, but so long as I have a list of known checkpoints along the route, not harder than other missions I've flown before. Edit: I'm realizing that modding a sky hook into KSP is not going to be this straight forward. Even with extended physics ranges, 200km+ is going to be troublesome for a physics object. I'm trying to make a fake "planet" for it with Kopernicus, but that has issues too, since I don't want to alter gravity in the area, and trying to make the hook be a landed part far outside the SoI is not going well. I might have to find another way to fake this. If anyone has ideas, I'm open to suggestions. All I need is a docking port in the correct trajectory that I can actually interact with.

The margin is nowhere near that tight. You still have maneuvering engines to get into position and dock, no different than when you're docking with a station. You can't adjust your intercept by going to higher/lower orbit, so you have to be within a few hundred meters, but that's fairly reasonable. There's also a bit of an urgency to dock because the suborbital craft is being pulled down with nearly the full gravity, and the docking port of the skyhook is accelerating up at whatever the centripetal acceleration is. So you might be trying to, effectively, dock to a craft that's accelerating away from you at something like two gravities. That's obviously trickier, and you want to get through it fast so as not to burn too much fuel, but it's basically an identical problem, logistically, as trying to land on a small platform on a world with similar gravity - you are effectively performing the same maneuvers. Under real world conditions, the fact that this leads to a very narrow margin for error is what makes the timing requirements so much more strict and leads to a need for precise automation. But that's a matter of safety. In KSP, if you fail on the first attempt, you reload a quick save. People do far more reckless landings in the game than what this would require.

The problem with these, from perspective of replicating them in KSP, is that the more velocity you want to gain from it, the larger the arm has to be, since you want to avoid extreme centrifugal stress in the structure. There are some small moons in KSP for which this is viable, but they have no atmosphere. And if there is no atmosphere, you're better off building a catapult - and people have done that. The benefit of the skyhook is that it stays above the atmosphere and can boost a suborbital craft to orbital. And for that to make sense in KSP you'd need an arm many kilometers in length, which you can't dock with due to the loading range limits even if you could build one. You could, potentially, mod the loading and physics ranges in KSP to make this work, but building multi-kilometer megastructures comes with all kinds of other problems there. For KSP2, that's a more interesting question. We haven't really heard much about physics since a blog from a while back, and I don't think there was anything there that would address this particular kind of megastructure. We ought to be able to build things that are much bigger, but I don't know if we'd be able to build something this big, and whether it'd work as expected. Other than that, though, so long as you can build a ship that's many kilometers long, get it spinning fast enough, and manage to dock with it, the principle is solid enough to work. Best part is that unlike the real world, you don't have to deal with tidal forces, so you don't have to worry about any kind of weird oscillations building up. It's really just a question of how big of a ship KSP2 can handle. It'd be an interesting thing to try out as soon as some form of orbital construction becomes viable in the game.

There is absolutely an internal roadmap somewhere at Intercept that shows the milestone dates associated with the public roadmap, as well as some planned release dates for them, but I can't imagine them sharing it. Hopefully, we'll get some hints to approximate timeline closer to or soon after the early access goes live.

Or you can build a system that is fairly realistic - more so than the present system, requires absolutely no player understanding, doesn't cause as many unexpected problems for the players, and is generally more fun to play. Your argument on the basis of, "Well, this doesn't bother me, so it's not a problem," is, at a minimum, poor approach to game design. Clearly, it spoils gameplay for a lot of people. This can be fixed and made strictly better with no downsides resulting in everyone enjoying rovers more. Not doing that if you have ability to is unequivocally a bad decision.

If the Reynolds numbers are similar, I don't see why it shouldn't be. Of course, that would mean the technique is only efficient for a given size ranges at given altitude ranges. You'd also have to eat the complexity of the mechanism, which might or might not be worth it over conventional prop.

There are a bunch of problems with KSP wheels that point to underlying errors in how the wheel friction is simulated. Without taking the code for it apart, it's hard for me to be very specific, but the way the traction is done is just not a good way to do traction. As for different worlds, it's still a problem with the person setting it up not knowing what they're doing - and I'm not trying to be mean here, it's not exactly something you're taught in any class, and if you haven't had experience working with this, there's no reason why you'd just know this. I'm going to use suspension as an example, because it's the easiest one, and to be fair, I think KSP got it reasonably well. If you look at what you're simulating, it's just a damped harmonic oscillator. The equation for it that you learn in school would be something like this: mx'' + cx' + k(x - x0) = mg Here, x is the displacement of the spring, primes denote time derivatives, and m is the effective mass of whatever's on the other end. For the purpose of the discussion, you can think of m as the fraction of the mass supported by a given suspension spring. The parameters c, k, and x0 are yours to tune, and they correspond to viscosity, stiffness, and neutral displacement for the spring. The common mistake is to give each one of these a slider. And let me tell you from experience of making that mistake in some of the games I've worked with, even if you don't let players touch it, and you have experienced designers and tech artists setting up your vehicles, they will screw this up. They'll try to guess what these three numbers should be, and they will guess wrong, and they'll try to tune it until it feels "right", and it will be wonky forever more. Don't give designers, let alone players a reason to make mistakes. Factor that stuff out. That x0 is a garbage parameter. mx'' + cx' + kx = (mg + kx0) We know that this needs to be balanced when the displacement is zero from whatever the neutral resting ride of the vehicle is. We don't want to have the player keep adjusting that if the rover got heavier. Yeet this out. mx'' + cx' + kx = 0 Better. Now you no longer have to worry about a rover tuned for Minmus from bottoming out on Kerbin, because gravity is literally not a factor anymore. Lets keep making it better. Consider the form of this equation you'd learn in a differential equations class. x'' + 2zwx' + w2x = 0 Here, w is the natural angular frequency of the oscillator. It's just a measure of how quickly the vehicle bounces on the suspension. Guess what, if we have designers set that, the mass of the vehicle no longer matters. You can find parameters you like, add a bunch of weight to the rover, and it will ride exactly the same. So we just have to figure out z now. And that one's the simplest of them all. You want your suspension critically damped. Always. There is no reason why you'd ever want your suspension bouncing like a silly spring or take an hour to respond to anything. You want it to be smooth and fast, and that means setting z = 1. x'' + 2wx' + w2x = 0 Look, we're down to a SINGLE parameter that doesn't depend on vehicle configuration, mass, or gravity of the planet. If you build and test your rover on Kerbin with empty cargo bins, and then have it haul twice its weight of ore on the Mun, the suspension will ride exactly the same with zero effort from the player, all while still having customization. Set high w for a sportier, stiffer suspension, and low for more of an off road feel. And that's it. One slider that you don't have to re-adjust for different environments. Of course, under the hood, the programmers have to do a bit more work. We actually need to know the c, k, and x0, but these are trivial to reconstruct now. k = mw2, c = 2mw, x0 = -mg/k. We know g from whatever planet we're on, and we can compute m by doing a bit of linear algebra to solve for balanced suspension. You can literally update these parameters for every simulation frame, so you never have to adjust anything beyond selecting w that you're happy with for your rover. Same work can be done with friction. Yeah, gravity and surface materials matter, but these can be made dimensionless by scaling by velocity. The traction is effectively mu*g, where mu is the friction coefficient of the surface you're on with respect to the types of wheels you're using, and g is the gravity of where you're at. Your turn radius is (mu*g)/v2. If loose regolith on the Mun has traction of say half that of grass field, and gravity on the Mun is 1/6th, then you expect a rover on the Mun handle the same going 10m/s as it would on Kerbin going 34m/s. And yeah, these are some high speeds, and I do expect some tweaking done to allow traversing surfaces at higher speeds, but you don't expect the difference between worlds to be that dramatic. You go a little faster or slower depending on what the conditions allow. That's about it.

I mean, this is how we used to do rotors in stock before the robotics update. Anybody else remembers making bearings out of stayputnik cores?

In theory, you can use power kites at different altitudes to generate net thrust in different directions, including against the wind. Think of a boat sailing against the wind, using a speed differential between the water and air, and the fin and the sail as two airfoils working in these two mediums. If you have different speeds or directions of wind at different altitudes, you can do exactly the same thing with kites. However, I have never seen this put into practice, nor is there any indication of anything remotely like that on the photographs of these particular balloons. I think @magnemoe nailed it, that all they do is adjust altitude, and they simply have a much greater range to work with than conventional hot air balloons, which might give them a lot of options, depending on the weather.

Wheels is one of these things that everyone keeps getting wrong, even though it's not actually that complicated. Just a bit unintuitive in places. Get someone who knows what they're doing to implement your game's wheels. Intercept, if you're looking for somebody, I can do a contract. :p Seriously, don't just hand it to someone enthusiastic but clueless and tell them to figure it out.

The page lists predicted re-entry on the 7th, and this was on the 9th. I'm not seeing anything on the list that's a better match, either. I don't know if it's more likely that it was something that wasn't being tracked on this list or just a meteor that happened to look exactly like an upper stage re-entry. I mean, it was moving much slower than a meteor typically does, traversed enough of the sky before disintegrating to suggest a shallow angle (so the apparent speed should have been indicative of actual) and the track looked (entirely judged by eye) to be about 140°-150° heading, which is about right for a re-entry for a Russian/Chinese/ISS launch in a 50°+ inclination after you account for Earth's rotation. Plus, the way it flared up in a different hue after separating into several pieces suggest variation in composition very similar to what you see when interior tanks start burning on stage re-entry.

Just watched something break up on atmospheric entry off the coast of California at 2:46am Pacific, 10:46UTC. The flare and disintegration didn't look like a rock to me. Were we expecting a spacecraft re-entry? I can't think of anything that matches, but it really looked like something artificial coming back and fairly large, like an upper stage. Thoughts?

Is there any downside of creating a non-official page (maybe eventually semi-official) on something like Fandom and doing community maintenance there? I'm seeing that done with a lot of games, and it's fairly straight forward to set up.

Early access will be PC only either way. Closer to the full release, we should have a better idea as to what systems the game will be playable on, including min spec fir PC.

This is why I'm talking about Dress potentially forming in the Jool system, or being captured by Jool, colliding with one of the moons there, and then getting ejected. Alternatively, it could be a rogue capture, formed who knows where. I mean, even without the ring system, Dress doesn't look like it belongs in its current orbit unless it migrated there from somewhere else, whether within the Kerbol system or starting its life in a different system entirely. Point is, we have plausible scenarios that could explain Dress' gravity not being spherically symmetrical, which would explain narrow rings. These things happen, even if the exact sequence that can lead to Dress existing in Kerbol system being somewhat of a rarity. There are trillions of galaxies of hundreds of billions of stars out there. Kerbol system can be pretty weird, and you'd still find a real life analog somewhere out there, which, I think, is the point. KSP's home system is allowed to be unusual and interesting, because if you're picking a place to set your game and you have more stars in the universe than there are grains of sand on Earth, you might as well pick an interesting one.

Anything with a gravitational field that is cylindrically, but not spherically symmetrical has the necessary conditions form rings. While a gas giant is almost guaranteed to have the right conditions, there are a number of ways a rocky body can gain that sort of symmetry as well. Consider Earth's own Moon that has a very "lumpy" gravitational field. A body formed under similar circumstance but with more angular momentum, not becoming tidally locked as quickly, could gain the required symmetry. If we imagine that Dress formed as one of the moons of Jool and was later ejected, it could be the right gravitational "shape" to host rings.

The key requirement for this is that each molecule of said gas has to have a strong magnetic moment. Such molecules like to stick to each other. To prevent that, you'll have to give them a lot of kinetic energy, at which point, it's not a cold gas anymore. Iron is actually a perfect candidate for this. Has great magnetic moment, which is why it's good for magnets, and is nice and dense. You just have to vaporize it, and then you can drive it with a magnetic field. Problem is, that takes a ton of energy, at which point, it's by far more efficient to just strip an electron, turn your gas into a plasma, and now you can have electric fields doing the work, which can be done with much more reasonable field strengths. And, of course, we're back to just building an ion drive.

I have no idea how KSP handles it. For general information, there are three typical ways this is handled, and I've personally implemented each type for different games, and there are pros and cons to each strategy. Have the physics engine take care of everything. You can literally build out a wheel and suspension system and just apply torques to wheels. Traction on different materials can still work, because you need both restitution and sliding friction for physics objects in contact with the ground anyways, and there are usually material checks during collision, which can both influence friction forces and be used for any additional FX. That's usually used for things like impact sounds which can vary with material, but you can also use these for applying tire track decals. The biggest downside is that the wheel ends up being a rigid body, which means it will bounce a lot at high speeds reducing effective traction, and this has to be accounted for. But there are games where this hardly comes up, making it the easiest way to add vehicles. Custom system. This can be very simple or extremely sophisticated. This is the approach where you compute the tire-ground contact points, do all of the math on the dynamics of suspension and wheels, and then apply net forces to the vehicle body at the suspension contact points - that can be done directly through impulses or by creating virtual joints. The most sophisticated of such systems will compute tire deformation and how much rubber is being scraped off by the asphalt. They will update the tire and suspension physics at about 1kHz, and sync it with the rest of the physics on something more manageable, like 60Hz or even just during frame updates. This is very precise, but computationally expensive and is hard work to implement. Hybrid. You do a ray or shape cast to the ground to find wheel contact points. These become joints with custom constraints which provide side-to-side stability, engine torque and braking forces for forward movement, and a hard limit for the suspension bottoming out. You then compute suspension forces for the given displacement of the wheels and apply it to the vehicle body as impulses. Unless the suspension bottoms out, the "wheel" joints only constrain motion along the surface with the suspension impulses giving the vehicle a smooth ride over whatever surface. With this setup, you get all of your basic handling properties, you can handle both rough terrain and asphalt, and you can even do fancier things like drifting without having to fake it, while still utilizing engine's native solver for everything but suspension (which doesn't need one, because we handle bottoming out separately) and you can usually tune it to feel like whatever type of car that you want to within a limit where a casual player won't know it's not precise. My personal preference is to use that last approach for anything that isn't a hard racing sim. If you create a vehicle in Unreal using built-in vehicle class, that's the approach used there as well. I have complaints about how they handle traction, but it's acceptable overall and is fine for most games that need basic vehicles. This can be implemented in Unity, and it's what I would recommend for wheeled vehicles for KSP/KSP2.

For physics, not really. It seems like early versions of KSP had very different tuning parameters for struts, but that seems to have been improved with some updates to either how all the other joints are tuned or maybe there was an engine update that helped with it. I'm fuzzy on the details. But you still can have problems in KSP if you keep adding struts all over the place, and the same would apply here. There are limits to what you can do if there is an inherent problem with the solver. (Again, might be a non-issue if a different solver is being used.) In terms of connection logic, though, there are still challenges. When you do a stage separation in KSP, every descendant node is marked as new ship. All you have to do now is go through all the struts and see if they connect the old ship to the new one, and if so, disconnect that strut. If you have multiple attachment points, that no longer works. In the screenshot in the OP, what happens if you detach only the bottom decoupler, but not the top? The logical thing would probably be to do a full walk from decoupler's parent parts to child parts to see if they are all still connected. If they are, do nothing? Do you still apply the ejection force in this case? It's not unsolvable, but it's a non-trivial complication.