ShadowZone - What Kerbal Space Program 2 HAS TO Avoid

[Scarecrow71]

2 hours ago, Bej Kerman said:

Is this a problem? Surely recalculating it every time anything changes only helps prevent issues where the game might have done a bad calculation and needs to re-evaluate the dV.

I don't think you understand what I'm talking about.  In KSP, dV gets updated every time you change the craft, whether or not the change impacts a given stage.  If I have an engine in stage 1 that has 400 dV, but then add a part to stage 6 - which will be long gone at that point - why does dV in stage 1 get recalculated as if thus change impacts stage 1?

[MarcAbaddon]

What's the exact complaint here? That the program recalculates it at all (wasting a neglible amount of CPU time) or that the recalculation gives different results each time?

I could understand the second one would be an issue. Given that I usually run a pretty heavily modded setup and rely on engineer redux for this, I had to check in an unmodded KSP 1 instance if the Stage 1 values really change if you add something in Stage 6. They don't - at least in simple straightforward serial staging scenario. So I don't really see KSP 1 doing what you say  it does?

[Scarecrow71]

4 hours ago, MarcAbaddon said:

What's the exact complaint here? That the program recalculates it at all (wasting a neglible amount of CPU time) or that the recalculation gives different results each time?

I could understand the second one would be an issue. Given that I usually run a pretty heavily modded setup and rely on engineer redux for this, I had to check in an unmodded KSP 1 instance if the Stage 1 values really change if you add something in Stage 6. They don't - at least in simple straightforward serial staging scenario. So I don't really see KSP 1 doing what you say  it does?

So, I went into KSP this morning to get screen shots and show you exactly what I was talking about.  I have two installs of KSP on my machine  - 1.12.5, and 1.8.3.  And for the life of me, everything I tried in 1.12.5 didn't have this issue.  dV calculations stayed where they were for the stage they were in, so nothing I did to other stages below a stage mattered.  Which means that this is a non-issue (whether it happens in 1.8.3 doesn't matter any longer as, if it was an issue, it was corrected).  It's also entirely possible that I'm old and blind and saw something that didn't exist.  What I'm really trying to say here is...

[Pthigrivi]

7 minutes ago, Scarecrow71 said:

So, I went into KSP this morning to get screen shots and show you exactly what I was talking about.  I have two installs of KSP on my machine  - 1.12.5, and 1.8.3.  And for the life of me, everything I tried in 1.12.5 didn't have this issue.  dV calculations stayed where they were for the stage they were in, so nothing I did to other stages below a stage mattered.  Which means that this is a non-issue (whether it happens in 1.8.3 doesn't matter any longer as, if it was an issue, it was corrected).  It's also entirely possible that I'm old and blind and saw something that didn't exist.  What I'm really trying to say here is...

See I misunderstood and thought you meant an easier way to see dV for things like landers attached to the side of a mothership with docking ports. Since they’ve gone to a workspace model I would love a way to see dV for each subassembly even when its not connected to the main vessel. 

[The Aziz]

Since you're launching only one craft from the workspace, you should see the stats for that chosen craft. To see others, just switch the active one.

Build a lander, see its stats, put it on the side, build a lifter vehicle, see its stats, connect the two. As long as the lander staging is above the lifter, you should see correct stats for lifter with lander attached.

Now the problem lies with stats for the lander now attached, maybe in a weird way, to the lifter, but it shouldn't matter what it says on the pad or anywhere, because it will tell the correct number once you undock.

[snkiz]

On 2/10/2023 at 7:49 PM, K^2 said:

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.

I'm not singling you out, However this is a common sentiment.

The wheels are worse than they have been in the past, sure. But I would argue, that it's mostly the default settings that are bad. The wheels are really bad at adjusting to conditions or load. this is compounded when people test rovers on Kerbin, with Kerbins's gravity, and expect it work the same on another body with much less gravity. That isn't how friction works. In the real world this is a simple concept. In the gaming world, it's not expected behaviour. KSP did a really bad job anticipating players expectations regarding wheels, areo, really anything that wasn't more or less directly related to orbital mechanics. A lot KSP's faults can just be boiled down to that narrow scope. That's not to bad mouth it, it was 2011,  they only had so much to work with, so the primary focus was on the main gameplay mechanic.

[Bej Kerman]

10 hours ago, Scarecrow71 said:

13 hours ago, Bej Kerman said:

Is this a problem? Surely recalculating it every time anything changes only helps prevent issues where the game might have done a bad calculation and needs to re-evaluate the dV.

I don't think you understand what I'm talking about.  In KSP, dV gets updated every time you change the craft, whether or not the change impacts a given stage.  If I have an engine in stage 1 that has 400 dV, but then add a part to stage 6 - which will be long gone at that point - why does dV in stage 1 get recalculated as if thus change impacts stage 1?

Yes. I understood that. My point still stands. Recalculating it every time anything changes, whether or not there's a real impact, only helps prevent issues where the game might have done a bad calculation and needs to re-evaluate the dV.

[The Aziz]

58 minutes ago, snkiz said:

That isn't how friction works.

Trouble is: all the planets are made of ice or smooth rock. There's nothing for the wheels to get the grip on. No sand, no regolith.

 

 

LRV weighted a few hundred kilos and didn't slide all over the place and could actually move.

Traction settings in KSP1 are just a workaround for smooth wheels on smooth ground with 0/1 inputs. Even level ground should eventually stop a vehicle with any trace of tread on the wheels, but let go of W in KSP1 and you'll cover miles.

That's why I posted a suggestion thread a long time ago about different surfaces on planets, so the experience is different on every body, not just powersliding madness. If KSP2 can simulate that (not saying about visual representation of bumps and dust but just the behavior you'd expect on a surface made of certain material), I'd be very glad.

Edited February 12, 2023 by The Aziz
Filling this textbox is completely optional but I would very much like to test how long can I type until it ends, well let's go, 12 years ago I found out about Kerbal Space Program in a youtube video, it was very early alpha, aro I think this is the limit

[Bej Kerman]

2 minutes ago, The Aziz said:

Trouble is: all the planets are made of ice or smooth rock. There's nothing for the wheels to get the grip on. No sand, no regolith.

Even smooth rock should work. Friction isn't just misconfigured, it's completely broken.

[JoeSchmuckatelli]

My main concern with KSP 's implementation was how unpredictable the wheels would be.  I would spend time in the VAB or SPH building a rover and configuring the wheels (especially after noticing that using symmetry made wheels that were supposed to go in the same direction actually spin in opposite directions), configuring brakes and trying to anticipate what would work best at the destination... Only to have the wheels go bonkers every single time I loaded into the SOI.  Just to drive I would have to reconfigure each wheel - and then as @ShadowZonepoints out when the Kerbal got back on the wheels would be bonkers again.

The legs sliding thing happened to me as well - but not often. 

The weirdest one was when I had a 'fuel depot' built (a long, cylindrical tank laid on its side with landing legs  set to the Rover height and docking ports on the ends) and a plan of shutting fuel from the mining rig to the depot and from there to orbit via another craft... I returned to the SOI to find my fuel depot floating about 4 Kerbal heights above the surface.  Nothing I ever did stopped it - although in one save the thing did wander off into space after my Kerbal banged into it too hard with RCS. 

But the thing I appreciated in his video was the reminder of how frustrating it was to get an encounter and have it disappear later.  Some people have an education that lets them figure out how to fix it (or mods that allow small corrections) but when your knowledge of orbital mechanics is entirely garnered by playing KSP? 

Edited February 12, 2023 by JoeSchmuckatelli

[snkiz]

44 minutes ago, The Aziz said:

Traction settings in KSP1 are just a workaround for smooth wheels on smooth ground with 0/1 inputs. Even level ground should eventually stop a vehicle with any trace of tread on the wheels, but let go of W in KSP1 and you'll cover miles.

Not a workaround, just a simplified model. Racing  games operate with the same restrictions, the appearance of the same laws of physics. But you aren't using assetto Corsa to get to orbit, not on purpose anyway. The physics only goes so far as the focus of the game requires.

I'm not saying that simple model isn't a problem, I'm saying it's compound by the unintuitive nature of anything that isn't launching a rocket. m/s doesn't convey how fast you are going on land very well at all. Most games have consistent tracion everywhere, unless the is some obvious visual indication that it shouldn't be that way. Percy traveled what 200 m in a month?

Edited February 12, 2023 by snkiz
You know how you walk away from a conversation and then, I should have said... That's what this is.

[The Aziz]

In racing game I can see and feel a difference when I drive on tarmac or dirt.

In KSP I should feel a difference in driving on the runway or on the grass next to it or on the snow covered north pole or on the desert. Not much, since it's the same planet, but enough. Most grip on the runway, less on the grass and sand, the least on ice/snow.

I should have better grip on the Mun (regolith) that I would on Vall (ice) despite the latter having a bit stronger gravity.

It's just logical. If Minmus is now ceramic, it should be as smooth as ceramic. At the same time Bop should be a piece of cake to drive in comparison. Aside from being uphill in all directions everywhere, but you get the point.

[K^2]

8 hours ago, snkiz said:

The wheels are worse than they have been in the past, sure. But I would argue, that it's mostly the default settings that are bad. The wheels are really bad at adjusting to conditions or load. this is compounded when people test rovers on Kerbin, with Kerbins's gravity, and expect it work the same on another body with much less gravity. That isn't how friction works. In the real world this is a simple concept. In the gaming world, it's not expected behaviour.

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 - x₀) = 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 x₀ 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 x₀ is a garbage parameter.

mx'' + cx' + kx = (mg + kx₀)

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' + w²x = 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' + w²x = 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 x₀, but these are trivial to reconstruct now. k = mw², c = 2mw, x₀ = -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)/v². 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.

[snkiz]

Just now, K^2 said:

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 gotta be honest you are way in the weeds there. I think the TLDR for that is what I already said, on overly simple model compounded by players not understanding (due to the game not conveying it) the forces they are subjecting their rovers to. I don't have any issues driving on minmus, 200 m per month is fast enough.

[mattinoz]

On 2/12/2023 at 12:27 PM, JoeSchmuckatelli said:

Please go back to 2019 and see if you can get them to listen. 

Rover wheels were possessed in KSP. 

Unless what you are trying to do is put the Kerbal back into orbit without a vehicle.

[MarcAbaddon]

How much of the KSP whackiness with wheels is due to homebrew KSP code vs the Unity engine anyway?

There are probably good games using Unity with don't have whacky wheels, but tbh the KSP setting if fairly unique with the rugged and roadless terrain, varying gravity (!) and varying weight. In other games you'd probably just need to fine-tune the wheel parameters once. 

If it's Unity, do we know if they have improved their wheels since the fairly old version that KSP is using?

[The Aziz]

Whenever was the wheel update, it was said they're now more dependent on unity wheel system.

Which didn't really work in the end for the variety of environments.

Again, trouble with traction is, even on auto settings, even carefully set up manually, that you end up with veeeery slow accelerating and braking vehicle. You know how using full throttle in a car uphill on icy road doesn't work? Easy on the gas pedal and you may be able to move. It's what traction settings do, limiting the motors on the wheels. If only there was something on the terrain and those high tech off-road wheels that would allow to get a little bit of grip.

I mean hell, look at that famous Parallax. The obstacles are still silky smooth despite them being rocks and stuff, you can't get a single bit of traction on them either.

[K^2]

9 hours ago, snkiz said:

I gotta be honest you are way in the weeds there. I think the TLDR for that is what I already said, on overly simple model compounded by players not understanding (due to the game not conveying it) the forces they are subjecting their rovers to. I don't have any issues driving on minmus, 200 m per month is fast enough.

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.

[pss88]

As I was saying 10 years ago, they should have just write their own physics engine and not use ANY of Unity's physics.

[snkiz]

4 hours ago, K^2 said:

Your argument on the basis of, "Well, this doesn't bother me, so it's not a problem,"

Don't put words in my mouth. I didn't say it isn't a problem in fact I called it one. I also said it's more complex than Arrr wheels bad. They must not know how to code. 

[Bej Kerman]

5 minutes ago, snkiz said:

Arrr wheels bad. They must not know how to code.

Then again, they had years to fix them.

[snkiz]

Just now, Bej Kerman said:

Then again, they had years to fix them.

And in a racing game that would have been unforgivable. KSP1 is an orbital mechanics "simulator" (that's a stretch I know). Everything else is almost bare minimum, and secondary to the goal. Given the blistering speeds real rovers achieve it's a little more forgivable.

[Bej Kerman]

Just now, snkiz said:

4 minutes ago, Bej Kerman said:

Then again, they had years to fix them.

And in a racing game that would have been unforgivable. KSP1 is an orbital mechanics "simulator" (that's a stretch I know). Everything else is almost bare minimum, and secondary to the goal. Given the blistering speeds real rovers achieve it's a little more forgivable.

FYI, 0.19 released back in 2013. That's a decade of opportunities to fix wheels. "it's a little more forgivable" isn't really saying much,

[snkiz]

My point is, even if they hired iracing devs to fix the wheels in KSP1 all of the other issues would still be present. People driving to fast in low g environments and then complaining it doesn't work like on Kerbin. That's a thing that Still happens. I never said it doesn't need to be better. I was and am judging KSP1 based on the  goals of it. Not the sequel, not any other games.

[Bej Kerman]

Just now, snkiz said:

People driving to fast in low g environments and then complaining it doesn't work like on Kerbin.

Nobody is complaining about this though.