lo-fi

Ah, I've spotted a problem with how the joints get configured when offset from the centre of the rigidbody they're attached to, which I think is going to be the issue with your single rigidbody setup. It'll require some fettling of the anchor point, which I'll work on fixing. For the time being, this will get you going: https://www.dropbox.com/s/jpd7gduvq5zy2ol/SM2pack.unitypackage?dl=0 EDIT: Confirmed: The problem with your rig stems from this line: susJoint.anchor = -wheel.transform.up * (suspensionLength + wheelRadius); This works fine for my rig, but if the rigidbody is offset from the GO the script is applied to, it simply puts the joint anchor suspensionLength + wheelRadius below the centre of the object with the rigidbody it finds. I'll need to figure out how to calculate the offset and set the anchor accordingly. Shouldn't be a big deal.

Of course, I'll sort that out shortly

Well I'm pretty sure we got the suspension and sticky friction nailed and Shadowmage's proof of concept for the grip models looked very good indeed. Merging it all together isn't looking too daunting either, so I'd say we're in good shape

I still can't believe we got such a pants update. On the flip-side, it's pushed us to make something that I think will end up being even better than the old U4 colliders. As discussed before, the grip model was truly horrible and directly responsible for many a flipped rover.

You should know that's how it works around here, Madrias Already developing in 5.3!

I couldn't quite figure out where you were going with the wrapper class. The collider didn't function without it, and it kinda did some stuff that a plugin or external script normally would. I changed just for the sake of convenience and simplicity really. I've implemented FixedUpdate() in a coroutine, which can be started and stopped externally, which made sense in the way I'm used to interracting with the original wheels colliders. Mostly just because it was simple, I could understand it that way, and it didn't end up replicating a load of stuff that's in the KF plugin anyway. the simplest way to disable sticky friction is to change susJoint.xMotion = ConfigurableJointMotion.Limited; to susJoint.xMotion = ConfigurableJointMotion.Free; Also, rather than simply turning it on or off, you can play with the spring and damper value of the jointdrive. Bingo. Not that I've seen so far! That may take some experimentation. Probably nothing sensible, so a correction factor is likely needed to convert to SI units. Plotting compression against spring value for a known mass ought to give us what we need. I'll keep an eye out this eve in case you need anything, and can sign into skype, googlechat or IRC. My current test rig is a large rectangle with rigidbody, four smaller ones placed as wheels with a fixed joint attaching them to to large one, GO's as children to each of them with the SLWheelCollider script applied. Kinda repliacetes a simple KSP vessel The script searches for ridigbody in parent, and seems pretty robust about setting itself up.

They always land the right side up....

This reminds me how much I'd like to change the grip level for different biomes with a bias for each type of part. The dust module already grabs the info needed. Would have been the type of thing Gaalidas loved to play with.

Some people always tryin' ice skate uphill

Details on how the skinned meshes are setup can be found here. As you can see, you rigidly have to define the relationships between the dummy objects that get manipulated in-game by code and the mesh that's deformed. Creating something that could be pieced together at runtime seems highly unlikely. Anything procedural that's been done in KSP has been mesh that's created real-time, gets manipulated, mapping co-ordinates generated, then stays static. It's a very,very different thing to tracks, skirts or whatever else with deform-able mesh.

I knew if anyone had tried this it would be you

Cool, I've got it fixed now. I know how you feel about going on holiday; I'm self employed, so going away is a complete nightmare. Commenting and formatting to follow - I just wanted to get a working copy committed. Will see if I can bodge the Unity scene into co-operating too, but basically treat my new class like the old wheel collider. Of particular note: "sticky friction" and suspension is controlled by the joint drives. specifically, lateral friction is controlled solely via the xDrive. This can simply be manipulated at any speed and need not be only for sticky friction. forward friction is controlled in the same manner by the zDrive. An interesting way to manipulate this might be simply pulling the contact object fore and aft. No attempt has been made to destroy the suspension joint when contact with the ground is left. It simply seamlessly transitions into becoming an ordinary kinematic joint and follows the wheel GO around gracefully. As there's nothing of the contact GO to interact with anything else, this seems to cause no problems. Bump stops are controlled by the linear joint limit. I've included no control inputs. I've just been using a script to "push" the craft around with a magic force, which seemed more appropriate when testing sticky friction. Punch-through performance can be improved by clever trickery with where the ray is cast from. It will only ever be as good as the cast used, however. Spheres are far better in this respect!! I don't see why not. You can effectively turn off the neutral steering by setting the steeringTorque curve to zero in the config, should you so desire. Sadly, I don't think procedural skinned meshes will ever be possible, which is what you'd need for the skirt

@Shadowmage please ignore the latest commit, I've got my GitHub in a pickle

Does a save/reload after undocking fix it? Can you change height using RCM? It'll be some interesting little gotcha like that I've missed. The repulsors will 100% be back. In fact, they'll be the first things to come out of the foundry before wheels, tracks or anything else. They rely on the same tech as wheels, but, of course, need none of the grip stuff to work. Hovercraft skirts would actually be quite possible, it's just something I never got around to modelling.

Finally fixed the darn bump stops!! For those of you not familiar with the term: suspension compression limits. Many, many hours of head scratching went into that one. Why the Unity documentation is so poor, I don't know. Sorry for the delay, @Shadowmage, it was not easy to find. Pointless handing it over with that rather fundamental aspect broken though. Code tidy and comment, then I'll hand over. Neutral steering. Yes, of course, I'd forgotten that term. As already pointed out, yes it is supported. I'm hoping to improve the steering in the next version of the plugin too

Not sure what you mean?

Hehe. The mole tracks are a fun oddity that came from the original tracks mod. I'm glad at least someone got the reference I've been away over the weekend, so not much progress I'm afraid. I do have the suspension working, but have somehow broken the bump stop limits due to placement of the ray origin. It needs some tinkering then ought to be in a fit state to commit.

Looks like you're new here, so a few words on how this all works. From a forum point of view, posting "please make this for me. Please" doesn't tend to be well received. "I'd like to make an M1 hull. Where do I start" or "would love an M1 hull. Anyone got any suggestions? " will get you much further. Modding is a lot of work; please respect that we do this for free, and that making any kind of part is a fair undertaking. On a personal note: I've never done requests. Certainly not for replicating real stuff. It's too much work, everyone's a critic, and I find it uncreative and rather boring. Not that I'm getting at or dissing anyone who likes that sort of thing - there's some stunning replica real stuff out there - it just isn't my bag. Inspiration from real things is a different thing. Taking a look at something, turning it upside down and coming up with something new that kind of resembles it; that's my cup of tea. And, of course, nobody can tell you it "doesn't look right". If there's something you really want, the tools are free and the processes are well documented so go get creating! I'm sure if you were to make a decent M1 hull, it would be quite popular.

What would we do without you? I'd missed that; what an absolute godsend! Thank you, yet again!

Thanks, I'm kind of dreading that bit! I wish the loader wasn't so damn slow. I always run with a totally stripped down dev install, and even then it's frustrating.

I did, but got stuck with persistence/reloading. Because KSP is... KSP. Besides, I could do it far better with what I know now!

Indeed. It really is a labour of love developing anything in KSP... For what we're doing, the Unity editor provides a much more streamlined environment. Looking forward to seeing that SSTO. My very favourite thing about this whole modding experience has always been seeing what people do with the KF parts.

No no!!!! That's ancient, may have been 0.90. I wish I was that far along... At the moment, we're confined to a sandbox in the Unity 5 editor, developing there because it takes so damn long to reboot KSP after every code change. I could have spent weeks waiting for KSP to boot if I was developing this in game.

I will update soon, now I'm not quite so ashamed of what I've done Something like this:

The problem before was that U4 (and 5, I think) wheel colliders wouldn't accept a change in spring strength without either leaving contact with the floor or being disabled for a physics step, which made adaptive suspension impossible. We're no longer constrained by such silliness, and yes, it'll work real-time. Seems like one to work on, as it's win-win for everything. My only concern is making a stable adaptation system that doesn't fight itself with many multiple wheels in use, but we'll cross that bridge as we come to it. I love it when a plan comes together. A little update: Ray and sphere casts are working, sticky grip is functioning perfectly, and I think I've figured out a perfect way to do steering. Plugging dynamic friction code back in will take a little discussion with Shadowmage, then a whole lot of experimentation.