[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.2.9

Adds dust effects, updated repulsor code, and a special module for ALG-style parts.  Should also be available on CKAN here in a few hours/day or so.  See link for full change-log and downloads.

Edited January 22, 2017 by Shadowmage

[Climberfx]

Hey Shadowmage. Loving your progress.

So, i have a question, is this damage control for mesh already implemented?

Am i doing it right?

Quote

    MODULE
    {
        name = KSPWheelDamage
        impactTolerance = 1
        wheelName = pneu_interno pneu_externo  // <-- i have two mesh parts for wheels, this two are the good ones.
        bustedWheelName = pneu_interno_crash pneu_externo_crash  // <-- and this two are the crash models.
    }

p.s: impact tolerance is 100, but i'm trying to crash it...

Edited January 22, 2017 by Climberfx

[SpannerMonkey(smce)]

28 minutes ago, Climberfx said:

Hey Shadowmage. Loving your progress.

So, i have a question, is this damage control for mesh already implemented?

Am i doing it right?

p.s: impact tolerance is 100, but i'm trying to crash it...

Hi if you make the second mesh a child of the first mesh  so for example tire/tyre/pneu,  would be a child of wheel,  then you only need to reference the parent, I don't think multiple names in that position will work,  

[Shadowmage]

35 minutes ago, Climberfx said:

Hey Shadowmage. Loving your progress.

So, i have a question, is this damage control for mesh already implemented?

Am i doing it right?

p.s: impact tolerance is 100, but i'm trying to crash it...

The 'impact tolerance' handling has been removed;  instead adjust the 'maxSpeed' and 'maxLoad' in the KSPWheelBase module.  'maxLoad' is used both for duration loading and absorbing impacts; setting it to a very low value should see the wheels break from low loads and impacts.

Multiple meshes are not currently supported (on the TODO list), but as @SpannerMonkey(smce) says, you can make both meshes a child of a single empty transform/object, and put that empty as the 'bustedWheelName' in the config.

[Climberfx]

Great, thanks both! Loving the smoke fx....

[Shadowmage]

1 minute ago, hippomormor said:

Is FAR support on the roadmap? Currently FAR is not working when I use ALG parts. It seems to simply not function at all.

Btw nice work!

...  https://github.com/shadowmage45/KSPWheel/issues/6

Feel free to add logs/etc to that issue.  Without more information I cannot fix the problem.

(I do not use FAR, and will not be installing it; so logs and more information is absolutely necessary if you want it fixed)

In the end though, it will likely come down to someone who actually uses FAR will need to submit the fixes.

[Haifi]

Hi Shadowmage

Sorry, I already posted this on KF.

The track steering lock seems not to be working. There's still force applied to the tracks when turning, with motor- and track steering lock active.

[Shadowmage]

15 minutes ago, Haifi said:

Hi Shadowmage

Sorry, I already posted this on KF.

The track steering lock seems not to be working. There's still force applied to the tracks when turning, with motor- and track steering lock active.

This should have been fixed in the release yesterday (I added code to the motor module to disable all input for tank steering if either 'lock motor' or 'lock steering' was enabled).

Have you updated to the most recent release, and is the problem still occurring?

Edit:  Apparently I never recompiled the .dll after adding that fix;  it was a last-minute fix that I did after seeing your post in the KF thread, and apparently it got missed in yesterdays update.  Should be fixed in dev versions ( https://github.com/shadowmage45/KSPWheel/blob/UI-Cleanup/GameData/KSPWheel/Plugin/KSPWheel.dll ), and will be available with the next release.  You can grab the .dll from that link, replace the one in your GameData/KSPWheel/plugin directory, and should be good to go.

Edited January 23, 2017 by Shadowmage

[Haifi]

Had KF updated yesterday, just to be sure I just downloaded and installed the KSPWheel plugin again. With motor lock and track steering lock ticked, the tracks have still force applied on turning. 

Btw. nice work on the DustFX really nice to have it back.

Edited January 23, 2017 by Haifi

[Akira_R]

Praises be to you @Shadowmage!!

Thank you so so so soooo much for supporting ALG, it's one of those mods that really changes the game when designing planes. Now hopefully we can get this FAR situation sorted out.

Again thank you!!

EDIT: woops just realized this is the KSPWheel thread not the new KF thread.... doh!!

Edited January 23, 2017 by Akira_R

[Haifi]

22 hours ago, Shadowmage said:

Apparently I never recompiled the .dll after adding that fix;  it was a last-minute fix that I did after seeing your post in the KF thread, and apparently it got missed in yesterdays update.  Should be fixed in dev versions ( https://github.com/shadowmage45/KSPWheel/blob/UI-Cleanup/GameData/KSPWheel/Plugin/KSPWheel.dll ), and will be available with the next release.  You can grab the .dll from that link, replace the one in your GameData/KSPWheel/plugin directory, and should be good to go.

Thx for the .dll, works like a charm now 

[Shadowmage]

Spent the last couple of days working on cleaning up the suspension auto-tuning functionality.  The current versions are using a basic form of PI controller, however the integral term introduces error in the suspension between symmetry parts depending upon how the craft is used/driven/manipulated -- driving the suspension into over-compression for a duration would result in the integral rising to bring up the suspension force; however when normal operation resumed this integral was still present, resulting in the previously over-compressed wheels having a stiffer spring than the rest.

Have reworked it into a more basic form of non-linear spring based on compression, and added a reduction term to bring the integral back to zero slowly after over-compression has subsided.

The largest remaining problem that I haven't been able to clean up is that adding more wheels to a craft will reduce the load -seen- by each wheel, but wont reduce the spring calculated by the auto-tuning system.  I'm really not sure if there is a simple way to solve this; the proper solution would involve analyzing the entire vessel, figuring out the load portion for each wheel based on vessel->ground orientation and what wheels would be in contact at a point in time, and feeding that into the spring auto-calc.  (This problem exists in the current implementation as well, as both implementations base the raw spring value from total vessel mass)

The other problem that I'm trying to solve is finding some way to allow for user-set ride-height and to accurately use that value for spring calculations.  Does not appear to be possible without the above problem being solved first -- I need to know the exact load that the wheel would be subject to in order to set the spring properly for a desired ride-height; without knowing the exact load/sprung-mass of the wheel it is impossible to calculate a spring for a desired ride height.  This is where the current 'Spring Rating' gui-setting is used; it adjusts the 'vessel mass' value that is fed into the current system, which does adjust the output ride-height, however it is not linked in any proportional fashion (increasing the spring-rating will increase ride height, but in a non-linear manner that depends on the number of wheel-colliders present on the craft that are currently supporting the load and how much of the craft load they are supporting).

I investigated using a PID controller for tuning of spring force, but that turned out to merely be a more error prone version of what I already had implemented.  Each wheel would arrive at a spring value sufficient to keep the wheel at the specified ride-height; however depending on how the craft was driven different wheels would end up with vastly varying spring values (example, the front left and rear-right wheels would end up supporting ~90% of the vehicle mass, and the front-right and rear-left would only share the remaining 10%; resulting in different handling characteristics if the craft were steered left vs. right).

Have not forgotten about the motor rework either.  I'm still working through figuring out the math needed to derive motor power from a config specified torque and efficiency value;  I can get the math to work, but only for specific power factors / no-load-power consumption values.  If I can find a power factor that I'm okay with as a default for all motors, I can finish writing up the rest of the power calculation code (I would like to find how to derive the efficiency even with different power factors, but unsure how long it will take me to figure the equations out).  The simplest would be to set the power factor to 0 (100% of power input goes towards 'work'), which gives a linear efficiency plot (0% at stall, ~100% of maximum efficiency at max-unloaded-rpm).

 

Have also done a bit of work/investigation/conversing regarding the FAR incompatibilities.  It looks like the cause is the bump-stop colliders that are added to the wheels at run-time;  from what I understand FAR does not handle disconnected colliders very well, and it is these that are causing it to fail (I believe FAR has special-case coding to work around this problem with the stock wheel modules/parts).

Not quite sure how to solve it; waiting to hear back from Ferram as to if there is a way to inform FAR to ignore specific meshes or colliders.  Alternatively... well.. I really don't have an alternative; the bump-stop colliders are necessary for proper functioning of the wheels (perhaps not exactly as I have it now, but some sort of collider is necessary; even the stock wheel use 'collisionEnhancer' colliders for this purpose).

[Akira_R]

@Shadowmage

Instead of trying to write code to automatically figure out how many wheels on a vessel couldn't you just add something to the right-click menu for the user to specify the number of wheels that they want and then the auton-tuner uses that info? 

I also just thought of a situation where things could really start breaking down, if you have a large cargo rover with a small rover docked inside it will the autotuner apply the same settings to all the wheels present?

Maybe a system that allows you to assign wheels to specific groups and for each group you can specify if you want the auto-tuner to use the vessel data or have the option to specify both mass and how many wheels. Plus if you implement a grouping system it could just see how many wheels have been assigned to the group and feed that info to the auto-tuner, this seems to me to be the most robust option for the end user, idk how difficult it will be to impliment though.

[Shadowmage]

5 minutes ago, Akira_R said:

@Shadowmage

Instead of trying to write code to automatically figure out how many wheels on a vessel couldn't you just add something to the right-click menu for the user to specify the number of wheels that they want and then the auton-tuner uses that info? 

I also just thought of a situation where things could really start breaking down, if you have a large cargo rover with a small rover docked inside it will the autotuner apply the same settings to all the wheels present?

Maybe a system that allows you to assign wheels to specific groups and for each group you can specify if you want the auto-tuner to use the vessel data or have the option to specify both mass and how many wheels. Plus if you implement a grouping system it could just see how many wheels have been assigned to the group and feed that info to the auto-tuner, this seems to me to be the most robust option for the end user, idk how difficult it will be to impliment though.

From your example -- rover docked inside a large craft -- WHEN they are docked together, they are one vessel, so yes, even the wheels on the rover will be set to support the weight of the entire vessel.  AS SOON AS they become undocked, the rover becomes its own craft and will only support the weight of the rover.  (Note that even trying to calculate based on # of wheels or % share and vessel mass would fail in this case, as both 'craft' are a single vessel; the -only- proper way in such a situation is to have discrete manual setting of the spring value or desired max load without any sort of auto-calculation involved)

 

What you suggest is pretty much the original 'manual' system -- You specify the % of craft weight that each wheel should support, and from there the auto-tuner can properly calculate the spring for each wheel based on that % and the total craft mass and the specified ride height.

The main problem is that mandating any user input is... well... problematic.  Too many people don't want to take the time to do the setup, or don't understand that it is mandatory, and then claim that the wheels 'don't work!!', when in reality they merely failed to set them up properly.  I'm just fine with it personally (having a technical mind I believe that taking time to do proper configuration is not only logical, but necessary), but the number of complaints and confused posts I had when the manual-spring system was in place lead me to believe that it is an unworkable solution for general public use (and dealing with the complaints/confused posts would cause me to stop modding in short order).

What really irks me about the problem is how unrealistic the expectations are compared to the reality of physics of spring systems.  Take for example the suspension on a standard passenger car;  it has been tuned for a specific ride quality at a pre-determined (and small) range of loading.  Try and put that same suspension system onto a vehicle that weighs 2x as much, or 1/2x as much, and it won't provide the same ride parameters.  Add too much weight and the suspension will bottom out.  Remove too much weight and the springs will be 'too stiff' for the new load.  If the original design parameters are violated during use (e.g. jumping a passenger car) the results are consistent with the original setup and intended use (said passenger car would bottom out and likely break some of the mechanics).

Now compare that to KSP.  Expectations are that the -exact same wheel- be able to support loads ranging from 5-500t all while giving a consistent ride across the entire range, as well as being usable for a wide range of purposes (sedate driving/roving, racing, stunts/jumps).  Absolutely absurd and impossible from a 'realism' standpoint using a single set of linear springs.  Why would someone expect the exact same physical wheel to be able to support such wide load ranges, or why would someone expect a single wheel to be tuned both for 'sedate passenger car use' and 'aggressive stunt use' at the same time?  (Rhetorical question; the answer has no basis in reality or physics: it is because it is a game and supposed to be 'fun')

Since scaling support is now a thing, I'm highly considering dropping the auto-tuning bit altogether (I'm really not a fan of it; even if it worked flawlessly it is still very unrealistic).  This would see wheels start with a single pre-set suspension spring value, being tuned for a single specific supported mass at their default scale.  The only options for adjustment would be 'ride height' (which would only be accurate at the current load rating for the wheel), damper ratio, and scale.  Need to support more mass than the wheel is tuned for?  Scale it up.  Need to support less? Scale it down.  Need to do a bit of investigation on how viable this would be, as well as examine some way to warn the user while in the editor that a wheel may need to have its size/scale adjusted (because launching a craft 5 times just to tune the suspension really isn't fun or rewarding).

(Rant not directed at anyone specific; merely sharing some of the difficulties that I'm encountering while trying to meet the often conflicting expectations on the UI/UX end of things with the wheels)

[Shadowmage]

Potentially good news on the FAR compatibility front -- I have tracked down the cause of the incompatibilities.  I have not yet found a solution though.

(cross-posting from the github-issue: https://github.com/ferram4/Ferram-Aerospace-Research/issues/165  )

After some quite lengthy investigation I have narrowed this down to being caused by one specific code-related action. (has nothing to do with the run-time added 'bump-stop' colliders as I had thought)

If I set the part.collider field to be null, voxelization fails.

Have a few ideas to look into for potential solutions and/or workarounds.  The particular problem code was itself a work-around to other problems in -stock- code, so the first thing to check is If the problems with the stock code have been fixed; that particular work-around might not even be needed anymore.

Hopefully will be able to come up with a solution for the next update, but no promises....

[Akira_R]

I see, I misunderstood the nature of the auto-tuning system, I thought it looked at vehicle mass etc only in the editor and assigned spring and damper settings to the wheels prior to launching and once launched those settings were "locked in" maybe with sliders in the right click menu in flight for additional manual adjustments.

Perhaps such a system could be the solution? It could keep the plug and play people satisfied by providing reasonable settings and usability out of the box for a narrow range of uses, essentially just four wheeled rovers. But any one building something more complex would need to do a bit of manual configuration. The first "level" of which could be the user providing manual inputs to the auto-tuner like number of wheels and vessel mass, or mass percent or whatever makes the most sense, and then another level of full manual adjustment of springs dampers etc.

But again I could be misunderstanding the system or the problem.

Also thank you very much for putting so much time into figuring out the issues with FAR, I have been following along on github and I know just enough about coding to undrstand conceptually what is going on and just little enough to be in awe of what you guys are doing lol.

[allmhuran]

First of all and most importantly, thank you for providing wheels that don't rely on forced autostruts! I've been away for a while and came back hoping updates to KSP would have made my mechs viable again, but wheelstruts were killing me. And if I don't have wheels on the feet, then the mechs can't  turn off the brakes and "skate" to higher speeds, nor can they turn on anything but "concrete". That's a new thing as far as I know, but the grass around the runway (and, I assume by extension, anything not "paved") now seems to have enormous anti-skid, which meant my SAS-powered-yaw form of steering no longer worked. Having something steerable on the toes allows SAS to "skid-yaw" the craft again.

For reference, this is what autostruts did to me:https://gfycat.com/CarelessColorlessBeardeddragon

From my experimentation (and a hint from your documentation) it appears to me that these new modules will only work if their parent part is not physicsless, is that right?

What I really want to do is create something like a castor... The wheels aren't there to really be wheels and I don't need motors, I just need a way to turn on grass and (preferably) be able to "skate" with brakes off. Still playing around with the various settings, I've been at it for a couple of hours and am making progress, albeit slow. My best efforts so far have suspension at zero, and alternating between full damping/no springs and no damping/no springs. Unfortunately both of those setups seem to create a constant "collision" noise coming from the wheel.

 

Edited January 26, 2017 by allmhuran

[allmhuran]

Learned some interesting things playing around some more.

Those wide footpads on my mech? They're physicsless. Physicsless parts have perfectly rigid joints and don't flop around on IR servos, so they have to be that way. Their mass is also really, really tiny at 0.001 in order to prevent the "swaying" of the leg mass from rocking the mech as it walks.

But the mech as a whole weighs ~15 tons, due to a dense resource I transfer between the feet as it walks, acting as a counterweight.

So, I have been putting a normal-physics part between the wheels and the feet. Just a small one, like a small girder. This is how I've been doing my experiments thus far, but I wondered what would happen if I simply gave the footpad its physics back. The result: The mech is flipped up into the air after it spawns in. This was with suspension 0, spring 0.05, and damping at any value.

It *looks* like the acceleration applied upwards by the wheels to the thing the wheels are supporting does not depend on the mass of the object as a whole, but only the mass of the immediate parent, which is interesting. I expect this is a KSP or unity thing, not a mod thing. But if this hypothesis is correct, it explains why wheels (and potentially a whole lot of other things) are so hard to get right.

 

Edited January 26, 2017 by allmhuran

[TGSAP]

I'd just like to add to what Akira_R said; a big thanks for your work on this mod in general and also in getting it compatible with FAR. I have experience with Unity development (and their godawful unusable wheel colliders), and I know exactly the scope of a project like this, and the difficulties involved, and it amazes me how fast you were able to get one working well (on a mod on which you weren't even planning to work that much in the first place). I also commend how well you have reacted to the feedback of players and how out of your way you have gone to accommodate them. Personally I like to set everything manually (like you, I imagine) and your patience and dedication in providing a workable solution to, let's say, "less dedicated" players astound me.

I have followed the situation on github as well, and it seems like a reasonably simple fix (to the extent such things can be simple) for the FAR situation, one I know is well within your capabilities. Again, thanks for the speed and the effort that you have spent in supporting a mod you don't even use. You can count on me to test this with FAR anytime.

[Shadowmage]

7 hours ago, allmhuran said:

First of all and most importantly, thank you for providing wheels that don't rely on forced autostruts! I've been away for a while and came back hoping updates to KSP would have made my mechs viable again, but wheelstruts were killing me. And if I don't have wheels on the feet, then the mechs can't  turn off the brakes and "skate" to higher speeds, nor can they turn on anything but "concrete". That's a new thing as far as I know, but the grass around the runway (and, I assume by extension, anything not "paved") now seems to have enormous anti-skid, which meant my SAS-powered-yaw form of steering no longer worked. Having something steerable on the toes allows SAS to "skid-yaw" the craft again.

For reference, this is what autostruts did to me:https://gfycat.com/CarelessColorlessBeardeddragon

From my experimentation (and a hint from your documentation) it appears to me that these new modules will only work if their parent part is not physicsless, is that right?

What I really want to do is create something like a castor... The wheels aren't there to really be wheels and I don't need motors, I just need a way to turn on grass and (preferably) be able to "skate" with brakes off. Still playing around with the various settings, I've been at it for a couple of hours and am making progress, albeit slow. My best efforts so far have suspension at zero, and alternating between full damping/no springs and no damping/no springs. Unfortunately both of those setups seem to create a constant "collision" noise coming from the wheel.

 

It seems you are misunderstanding the wheel system.

Zero-spring / zero-suspension setups will not work.  All friction forces are derived from the spring forces, which are determined by the amount of compression necessary to support the load.  No suspension = no spring = no forces.

Additionally, even trying to 'cheat' by setting the suspension to a very small value will not work due to the nature of stepped integration.  When there is enough force to support the load at 1/2 compression, you will get -double- that force at full compression.  If the difference in travel between 1/2 and full is not sufficient, the integration will 'step' from 1/2 to full in a single tick, and you'll find yourself launched into the air.  (you can see this on the wheels if you scale them down and put a very large load on them; the integration steps are too large for the simulation to handle in a stable fashion, and things start to jitter, bounce, or go flying)

Further additionally, the base 'spring-stiffness' for a given wheel is calculated from the vessel mass.  There is currently no in-game way to set it to zero spring stiffness, and even if there were it still would not work (see below).

The root of these problems is that something in KSP interferes with Unity's standard collision response and handling.  Stuff that works fine in the editor simply fails when used in KSP.  Particularly I should be able to set a collider to have zero friction, and it -should- work as a simple castor (sliding freely, but not being springy).  Works great in Unity editor, and even works okay on the runway in KSP, but as soon as you get off the runway, it 'snags' into the terrain and starts dragging.  This isn't dragging caused by friction, but caused by some sort of improper collision response (if I subscribe to OnCollisionEnter I can see that it thinks it is re-colliding every frame, when really it should have a single OnCollisionEnter and then OnCollisionStay for further frames).

 

Yes, wheels currently, by default, apply their suspension forces to their parent part.  This is the main reason why they don't need autostruts for regular use-cases, however, yes, it will have problems if you try and attach it to a physics-less part (which has no rigidbody, and thus nothing to apply forces to).

Edit:  This mod is not the solution you are looking for;  it is intended for spring-based wheels for standard vehicles.  Your only option would be to create the 'legs' of the walker as custom modeled parts that were themselves wheels and used the leg-bending as a response to the suspension compression.

6 hours ago, allmhuran said:

This was with suspension 0, spring 0.05, and damping at any value.

Heh, yeah, don't do that.

Edited January 26, 2017 by Shadowmage

[allmhuran]

That's all extremely helpful information, thanks very much! 

So my hypothesis about acceleration ins't correct, it's probably the step from half to full spring response you've just described that was causing the flipping. Interesting that it happens only when the feet have very low mass, though. Changing foot mass from 0.001 to 0.1 prevents it... even though the change to the mass of the craft as a whole, at ~15 tons, is totally negligible.

 

Quote

but as soon as you get off the runway, it 'snags' into the terrain and starts dragging

Yes, terrain other than the runway and other paved areas is super, super weird. This seems to be a recent thing.

I don't know if my own experiments will help you with your development at all, but it might. Let me describe exactly the problem I want to solve, and what I have found to work.

My mechs cannot "steer", since they can only walk straight ahead or straight back. Steering comes only from SAS yaw forces in the hips. I therefore give the hips a very large SAS yaw torque of 150ish (total craft mass, again, is only ~15)

With any configuration of physicsless contact patches: No steeering at all, the mech will only walk straight.

With flat bottomed, physics-enabled feet: On the runway, the provided yaw is enough such that if I put in full yaw, the mech will rotate around a vertical axis, both when stationary and when walking. But as soon as the mech walks onto the flat ground around the runway the mech cannot yaw at all, even with yaw force ramped up much higher.

With 4 small physics parts (structural girders) on the bottoms of each foot and high yaw torque: The mech can yaw very easily on the runway (too easily). It can just barely yaw while on the surrounding grass.

The solution I have found: I have made a custom part using the structural panel 1x1 and scaling it so that it is even thinner. I then put 4 of these parts onto each foot, on the front and rear toes so that the "edge" of the part runs from right to left across the toe. The obvious hope being that this would work kinda like an ice skate, with the sharp egde providing minimal resistance to movement in the direction of the long edge, but the wide, flat face providing high resistance to the orthogonal (mech forward/mech back) direcition. 

Amazingly, this actually works... even on the grass around the KSC, and even with yaw torque reduced And note: This is just a 1x1 structural panel that I have rescaled using a model{} block. It has no special modules or anything, and it has normal physics significance. If physics significance is set to 1, it no longer works.

So the friction value really does seem to depend upon the "contact patch" size and particularly the orientation relative to the direction of movement.

Of course, the downside of this solution is that I can't "turn off the brakes to skate". The mech is limited to walking speed.

Edited January 26, 2017 by allmhuran

[Shadowmage]

3 hours ago, allmhuran said:

So my hypothesis about acceleration ins't correct, it's probably the step from half to full spring response you've just described that was causing the flipping. Interesting that it happens only when the feet have very low mass, though. Changing foot mass from 0.001 to 0.1 prevents it... even though the change to the mass of the craft as a whole, at ~15 tons, is totally negligible.

This is due to Unity's internal limitations on joints.  They specify in their documentation that all rigidbodies that are linked by joints should be within one order of magnitude of mass.  So if the most massive part is 10t, the least massive one should be at least 1t.

If those rules are not followed the joint-constraint system starts to break down.

This is why if you attach a heavy part to a light part it will sag more.  Increase the mass of that light part and the sagging decreases.  Get the two parts to have the same mass and the sagging is at its minimum.

(Aren't Unity joints wonderful?.... wonderfully inconsistent....)

[allmhuran]

All this great information that I've never seen anyone mention in ~4 years of mucking around in KSP. You're a freaking goldmine. I first really explored the heavy/light mass joint problem about 18 months ago based on some discussion over in the infernal robotics threads, but nobody has ever mentioned anything as specific as what you've said here. Really interesting stuff.

In any case, this is why most of the parts on the mechs are physicsless - to prevent IR joints from being wobbly - so it solves the problem everywhere except for the contact patch with the ground.

Anyway, maybe the "ice skate" style ground physics will help with your skids, but it sure seems like you probably already know a lot more directly from unity than what I can find out by experimenting in KSP, even if the unity stuff is sometimes overridden by KSP behaviour.

[Shadowmage]

46 minutes ago, allmhuran said:

Anyway, maybe the "ice skate" style ground physics will help with your skids, but it sure seems like you probably already know a lot more directly from unity than what I can find out by experimenting in KSP, even if the unity stuff is sometimes overridden by KSP behaviour.

Interesting find; all of my experiments were using a cylinder or sphere collider, which should have a contact-patch size of a single point.... perhaps there is some additional funkiness going on regarding the contact size (although as I understand the back-end of unity physics, there is no 'contact patch' and all collisions are resolved as if it were a point-point collision, using the most-penentrating vertex of the intersecting geometry).

[V8jester]

Forgive me for the temporary derail.

@allmhuran Something I have recently discovered for mech feet is Tweakscaled KIS anchors. As long as your mech lifts its feet, you can change directions all you want. And climb hills. Not sure how much this helps this discussion at hand but.... Also try Tweakscaling a larger reaction wheel, then alt+click a copy. The smaller copy will have the same torque as its full scale counterpart. This mech has a single Reaction wheel on it's back.