K^2

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.

Generally. Though, PhysX, at least the version used by Unity, is probably the worst offender on having issues with it. It all comes down to the solver and how that works. In technical terms, if you have two weld points between two parts, there is no longer a unique solution for constraint forces. You can always add more tension to one joint by relaxing tension on the other and compensating for torques. That means, the constraints matrix is inherently singular. If you do an "honest" analytic solution to such a matrix, you'll have a division by zero. A numerical solver might or might not encounter this as division by a very, very small number, resulting in large numerical error. This could be cause of a sudden Kraken in some configurations, honestly. If Intercept switched to Havok physics at some point, which we have no indication of so far, this might be a non-issue. The solver used by Havok is much better at handling cases like this. There are other reasons to do tree structure, however. Consider logic of separating ships, e.g., during staging. Right now KSP can guarantee that when a separation part fires, all of its descendant nodes become a new ship. No additional logic required. If you don't have a tree, and alternative connection points might still exist, you have to check whether you still have one ship or two ships. And that's a more complex problem. Not rocket science, of course - it's basically just an A* search, but we've seen that Squad made a mess of a similar problem doing fuel routing, so it's certainly an added complexity.

Yeah, we know that the early versions really struggled with framerate. They absolutely could not have had a live fast-forward in the version of the game they were showing at Pax West 2019. This fast-forwarding was done in post, and the "FF>>" label and the little VCR-style skip lines were clearly added after the capture. This is just video editing and nothing to do with gameplay. The footage itself from the presentation is neat. All of the commentary is either baseless speculation or provably wrong.

I honestly wouldn't mind some sort of simple, flocking fauna on the worlds where it makes sense. Something aquatic would be the simplest, but little fuzzballs scuttling on the surface of Kerbin, Laythe, or similar new world wouldn't be out of place, IMO. These can be implemented as 2D boids very cheaply, and if they treat any vehicles or structures as repulsors, causing them to scatter from these, you wouldn't have to implement any sort of complex interactions or network synchronization. For all intents and purposes, it'd be just another visual FX. (Which can then also be disabled in graphics if someone's running the game on a potato.) Edit: To maybe clarify the image a bit, I'm picturing these kind of like the Spirited Away soot sprites, but maybe without any limbs at all. Just little fuzzy things with eyes (optional) and maybe a bit more colorful, possibly even varying on the biome. Anything on the surface of Kerbin, yeah, but there's enough stuff scattered through the Kerbol system to add up to either an advanced ancient Kerbal civilization or aliens. Which, again, doesn't have to mean that the aliens have to be present and active. But finding more signs of ancient structures left behind by powerful alien civilizations is fully consistent with established KSP universe. I agree that making it front and center wouldn't fit the theme, but the space is big, and some very nifty things can absolutely be tucked away for players to find without breaking the theme of the game.

Some of the vusuals features we've seen are VRAM hungry, but hopefully, Intercept will give us an option to tune these down or disable them. I don't think there's a reason to go for 4GB min spec here.

None of the known solutions are stable, and there are some strong mathematical conjectures suggesting a stable solution isn't possible. That said, an unstable state can still be usable, so there are some interesting possibilities there. However, one should keep in mind that it's the sort of place where quantum gravity starts to play a role, and we do not have a mathematical framework for that which can be used in any practical sense. (We do, technically, have a governing equation for quantum gravity, but it's in a form where it's basically "infinity = infinity", which isn't terribly useful. And nobody so far has been able to figure out how to fix that.)

Totally get it from marketing perspective. It's just when some new info shows up only on Discord, fossils like me feel left out. But them's the times, I guess. People do post links here eventually. And I'll probably have to get on the Discord for mod API support anyways.

I don't know about a serious one, but it'd be a great setup for a horrible parody. "Yes, we found a suitable planet. Lets go back and let everyone on Earth know." - "Uh... Yeah, about that. We can only enter this space, not leave it." - "..." - "On retrospect, yes, a bad plan."

I knew a guy whose car got hit by a deer. As in, he was just driving on the highway, and his car got t-boned by a deer that jumped out from the forest. The passenger door got a huge dent and was permanently jammed. The deer ran away back into the forest. The most comical part was that the car was a Geo Metro, and so it getting hit by the deer instead of the other way around just makes sense somehow.

There will likely be differences, since the materials got more complex and likely will require some additional data attached to the mesh as well. But they might simply make a new version of the .mu to handle that.

I don't think performance is the problem. An absolute potato will not be able to run the game's physics at anything like a reasonable framerate, and since people tend to upgrade graphics before the CPU, and the type of procedural placement Intercept uses typically runs as a compute shader on the GPU, I can't imagine this being a problem. For a concrete example, we've been running large open world jungles on PS4 Pro with the view distance that would be totally fine for KSP2 without significant impact to the frame rate. I mean, it'd drop below 30 occasionally, but that was even before the final optimizations round. And we know the KSP isn't coming to 8th gen consoles, at least for now. So this just isn't the limiting factor. The problem is that building large worlds that look neither empty nor cluttered is hard work, and doing this for dozens of worlds, keeping all of them unique, is particularly taxing. The terrain tech we were seeing was still being tweaked half a year ago. This isn't leaving the artists a lot of time to really make these worlds work. I don't know how good the final product will be, but I don't think what we're seeing right now is that. And yeah, that does mean that worlds might end up feeling a bit barren during the early access and, honestly, possibly even a bit into the release. I don't think they're going to be anywhere near as bad as planets in KSP were, but you shouldn't expect AAA hand-crafted game levels of detail on every patch of land on every planet. That's just not possible to achieve. KSP2 will definitely fall somewhere in between, and hopefully high enough to keep exploration interesting. We'll have to just wait and see, though.