lo-fi

Don't worry about this kinda stuff in the wheel collider component - anything application specific should be handled at the PartModule level IMHO. I'll pick that stuff up in the KF plugin

I'll have to have a look at the code. Is it up to date in Git?

There's only really one way to do this: Spring deflection against spring strength. I've given this a lot of thought. Any method that uses "vessel" mass is doomed to failure. Even finding all the "wheels", calculating their positions and orientations, then dividing that all up would be a huge task. OK for a "known" design, but in sandbox form we need a generic mode. Springs are usually measured in kg/mm deflection, so that ought to give you somewhere to work from. It won't be perfect, and there are some edge cases depending on how you've handled maximum deflection (bump stops), but it's the best and only shot you've got of handling this one.

Honestly, it's hard to say. Shadowmage is making incredible progress creating a simulation of a wheel (far better than the garbage Unity is currently shipping with), but there's a fair amount of testing and finessing to be done before putting it out into the wild. Progress has been rapid, so at this stage I think we're talking more weeks rather than months kind of timescale. Hehe. Sorry, Temeter, couldn't resist

It's technical. SoonTM

Cool, I was actually wondering if you were applying the traction forces according to the hit normal. I really should look at the code

I went into the project knowing a lot about wheel physics and nothing about writing code! Similarly a learning process the entire way. Do you use the . normal property of the ray/sphere hit? I haven't looked at the latest code. It might help, if you aren't already.

Awesome, that's exactly what I was hoping for with the sphere casts! I will get some time to start experimenting with your module - I'm afraid work and life in general has been mental the last few weeks.

Been discussed many times before. Not going to happen - please read the thread back a few pages. Squad's wheel issues no longer apply to us; sadly, I doubt they'll ever manage to fix them anyway.

If there's one thing I've learned, it's that you can't cover all the bases. Check the ray (or sphere) for rigidbody; if it's null or kinematic, ignore. Otherwise, apply one equal and opposite to the suspension. Job done. If people do stupid stuff, that's their problem. Granted, there's an annoying issue with skinny wheels and sphere casts, which I'll think on.

I'm not sure what the issue actually is here? Why do the wheels raycasts need to ignore the vessel? Surely if they're contacting bits of the vessel, it's simply bad design (user error). Is there something I'm missing?

Wow guys! I treat tracks as the sum of their wheels with the average rpm of the grounded wheels giving the track speed. No special consideration is needed for the wheel colliders, so Shadowmage's version will work perfectly well. Sprockets and idlers are treated as road wheels with no suspension travel.

I'd imagine they've changed how the engines work :/

I actually have no idea! I suspect probably yes, but it'll need investigating.

Surely just cast a ray or two at the start of flight, see what it hits, force all those colliders to WheelCollidersIgnore layer if they're in the same part? Agreed - checking every frame seems like a bad idea. All sounds good!

I've had no time to do much this week. Great progress, glad my work on the joints wasn't a total waste of time!

A few - think I can help with most of that. I'll get back to you when I've got a few minutes for a full reply

There were a lot of people who used KF fine in previous versions of KSP 64, so I see no reason why there should be an issue going forwards. I used to offer no support for X64 because squad didn't (and it was flaky at best), but made no effort to stop people using it. My own experience suggests that 1.1.X is about as stable as a 6' jello tower, whether 64 or 32, so mileage may vary.

I'm afraid everything was based around wheel colliders, which are what's been causing so many problems, so everything is broken in 1.1.X until further notice. We are working on a solution.

Yep, that's where the KF plugin comes in. Great work!

I think I know what happened there - it's a quirk of how my test rig is set up, and how my script doesn't handle many eventualities. Call it a difference of construction on your part, and an error on mine! Lovely work your end, it's looking great!

I might start testing the new wheel collider as a repulsor, see how it goes. They don't need grip, torque or anything like that, so probably an ideal part to start using them on. RL takes precedence

Making a plugin to do that is simple, and I've actually done so. What I found isn't simple is dealing with the jump between "on rails" and otherwise, and persistence issues on reload :/

Hey cool. I have made some BV202/206 tracks but never finished or released them. The biggest problem is that they're an asymmetric design, which of course doesn't play well with rotational symmetry. Luckily I have solution for that, but it's kinda complicated. You're very welcome to take what I've done and mess about with/finish it, if you like? Another challenge is the way the Haglunds things steer with the joint in the middle, of course.

Yep, should be up to date:) I guess we ought to be looking at how to marry up my joint model with your existing code, as you've done a lot of the work already for the grip model. I'm far too tired to think about much else now, though, so I'll get back to you with a fresh head tomorrow. Looking forward to a productive weekend I wouldn't worry too much about the KSP specifics just yet, I'd rather make sure it all works well in plain old Unity before heading that direction. I was thinking of a PartModule that looks for wheel colliders in a part, strips them off and replaces them with an instance of our version on each GO that had one applied. The rest is just a case of modifying KFModuleWheel to look for our colliders, and everything will work as before in those modules, provided we've exposed the same stuff. You have to strip off the buggy U5 wheel colliders because they will activate regardless of whether any other components of scripts are even aware of them! They are useful for a placeholder for "hey, we need a wheel here", and can carry over some settings from them, like the suspension travel, wheel radius etc. for each individual wheel in a part. Setting all that up in a config file/MM patch would be hell with the lid off!! If the grip and torque can be on the way to getting implemented, I think we'll be doing well!