lo-fi

IIRC, there was some disccussion about that a few pages ago, and the answer was simply "NO". I have no direct experience: I gave up messing with stock wheel modules back around .24.

Don't fee... Ah, whatever. Unity. KSP. Something. I've no idea. Ran out of steam for fighting with it, so have been doing other things for a while.

Not really, I'm afraid. With reference to mod comments, I'd suggest simply ignoring certain people, folks. Sadly @riocrokites post explaining that this was something you could do got deleted, but it's easy enough to figure out, and rather handy.

Thanks, that's certainly interesting. More testing on variations of the U5 rig fail to reproduce the problem now, after success earlier. It's quite infuriating! Maybe it's to do with ordering? I really don't know. I'll try again in game later this evening.

Now that's a great find. Can't use it, as we'd have to distribute as a binary blob with no source, which is against the rules for KSP mods. However, for $20 to get a look at the source... take my money! Interesting. My experience hasn't been good, though I've not tried in 1.2

Confirmed: Same behaviour of multiple wheels on one rigidbody in U5. My notes are clearly wrong, or I messed something in testing. Given that this IS a generic Unity problem, I'll incorporate the structural change within the wheel itself. Essentially, each wheel will create its own rigidbody and joint to the rigidbody the suspension joint would have been attached to anyway. This will actually simplify certain aspects of creating the suspension joint. Not sure about the performance hit, but I understand the new engine in U5 performs far better. Let's hope!

Sorry, I was out see Nitin Sawhney at the Albert Hall last night (was spectacular), so didn't get a chance to post up the latest KF. RL is more important! The Lo-Fi branch holds my latest working wheel code I suppose it is the Kerbal way... Interesting! Was this from a devnote, or have you been poking?

Thanks, that's a very interesting video I'd not seen before. I still can't tell what's wrong at this stage. More debugging and logging required, but my hunch is the serial nature of execution is causing problems, and thinking about it, I'm not sure of I properly replicated the KSP physics setup in the development environment. Repulsors are easiest, as they were "quirky" anyway, but I'm still a way away from where I'd be happy releasing anything, even to the testing team. So many unknowns at this stage.. I've got a few things to check out, but I'll pass what I've got over to @Shadowmage for investigation, if you can spare a few minutes.

Well.... First showstopper. Tracks with new colliders are just as crazy as with U5 colliders. I can't yet figure out why. Just get that familiar jittery stupidity. The annoying thing is, I'm sure that didn't happen in the U5 dev environment. I'll retest. Funny thing is, I can add as many wheels as I like to a vehicle, and it still behaves. This is smacking of something being up with multiple physics things interacting between two rigid bodies. There is the possibility of giving each wheel collider its own rigidbody and a joint to the part, but this is horribly heavy handed. The U5 colliders have a limit on the amount you can add to any given rigidbody, so maybe this is some kind of engine limitation, rather than a collider one, but I can't think what it might be. Thoughts?

I figured it must be something like that. Thanks

Hmmmm. Well here's an interesting thing... Even when my test rover is stationary, you can't swap away from flight, same as you can't when it's in motion.

Not really, as nothing in the game currently is coded for the new wheel colliders, other than the KF plugin code which is isn't anywhere near a state I'd wan to commit it, let alone let people loose with it. Ah, that's something in the new stock wheel module. Thankfully not in any way relevant to KF It will be possible to convert stock parts (and indeed other wheeled parts) to KF just in config with no model re-export needed. I have a little partmodule that takes the settings from colliders in the model, strips them off and adds the new colliders instead. I wouldn't be able to get PartTools to export the new colliders in a part anyway, so that seemed like a sane, easy way of doing things.

I already upped it from the default - the wheels were behaving like repulsors! I'm looking forward to trying out some different values this eve, and will report back. We have, for the dustfx stuff, a biome table that changes the dust colour depending where you are. This could be an excellent way of also changing the grip! I actually think the force based solution may be better long term, but that it'll take a lot more development to get right. The joints were a quick win apart from my little fubar with the anchor point code. If you're happy to do so, I think we ought to continue for force based solution as a side project, as it's definitely promising. This is indeed looking very good - thank you for all your efforts

I guess some of that might be possible as we've got a much greater degree of freedom than ever before. Shadowmage's purely force based suspension springs could be abused modified for quite a bit of repulsors craziness. I'm just happy this stuff is working, and most importantly better than what we had before, kinks and edge-cases aside. I'm also very pleased that the new collider has nothing KSP specific and might well benefit far more games than KSP. Still a lot of discovery, work and testing to do.

On the understanding that nobody even mentions the hype train, let alone boards it: I haven't even started to mess around with the grip, torque and suspension settings to really finesse the dynamics and they'll need a little more respect from the plugin and config parameters, but this is looking extremely promising. @Shadowmage's grip model worked beautifully from the first moment I pushed the W key, as nice wide powerslides are possible with no hint of tripping over and flipping. I almost can't quite believe how well and realistically they handle.

Cheers. I can tell you it's doing nothing bad so far I need to get the control input from the modified KF plugin going before I can really start testing the dynamics, but I'd say I'm quietly confident that it's going to be fine. I just need to find a neat, easy, robust way to delay everything starting up until rigidbody on the part is added, then I'll be able to really see what we've achieved! That's this evenings job, so I'll keep you updated. I ought to try the new colliders on a track unit too, before I get too carried away with the higher level stuff.

As launchy as a Kerbal launchy thing. To be expected when the bump stops have zero spring. Needs fixing, but makes total sense if you think about it.

Hiding? Ohhhh, nothing Actually, it's a fresh install of 1.2, and I've been too lazy to change it out of window mode yet! All I've been doing do far is running it up to check that my tidying and refactoring haven't broken it.

Right, that's a commit of my WIP code and about all my brain can handle today, much as it's been productive. Night all

Still works in 1.2 to auto load a save and go to the space center

@Shadowmage I'm just getting set up to update my branch of your repo. For a speedy hack, I ended up plonking the wheel code straight into the KF plugin rather than making a hard dependency, but I'm about to split off the working code, set up the reference and push it all back. Looks like you kept a copy of the libraries from KSP in the lib folder, so I'm going to update those to 1.2. Nothing seemed to want to work well in Unity 5.2/ KSP 1.1, so might as well target 1.2 as we discussed a while back. Just wanted to make sure we're all on the same page It's looking really good so far. I got the visual suspension stuff working with very little effort (actually much easier with our colliders), and I'm working on bashing the control input into working shortly, along with the wheel/track visual rotation code. One interesting little gotcha I think we both found is that you can't add the joints in until the rigidbody has been added to the part, which seems to be about three or four physics ticks in. This was why you always used to get the warning message "wheel collider requires an attached rigidbody to function" in the log. We'll have to have a little delay routine for the colliders and plugin, which I'm working on now.

Cheers fella. Now that looks awesome There are some potentially cool options for playing with other suspension rigs down the road with this setup. Actual swing arms, but just a visual cludge might be possible. That's a way off down the line, though.

Alright, I have the joint suspension working in game! A few notes: It works really well when the suspension isn't fully compressed against the bump stops ("active region", henceforth). When sat on the bump stops, any sharp change in terrain cause a big jump that launches the vessel. This can probably be 'massaged' into something more compliant by changing the limit springing. I'll investigate. We may be able to use this to calculate the load when on bump stop if we're careful With the above in mind, setting up "adaptive" suspension which tries to keep within the active region is increasingly looking like a good idea. Not sure whether this should be done at "wheel" component or KSP plug-in level, though. Sticky friction works well alongside @Shadowmage's dynamic friction. Still needs some finessing, but I don't think this will be difficult. I have yet to test parts with more than one wheel collider in-game, though I don't believe this will be a problem. Code will follow shortly after I've cleaned up the unholy mess I've made with debugging statements, commented and figured out what I'm doing with Github again. It's been a while! I've deliberately not taken video or screen shots, as that tends to stoke the hype train up far too much. The light at the end of the tunnel just got a little brighter

Right, I've found where it was all going wrong. @xEvilReeperx was spot on with the world axis. My code worked when the axis of the wheel objects aligned with the world (as in the test environment), but fell apart when it didn't at the equator. This affected the setting of the joint anchor offset, which caused all the problems. Of course, there are now a whole set of new problems to deal with, but at least things are ending up where they should, the craft isn't spinning out of control and the runway doesn't blow up. Happy days.

Done, and thanks. If that isn't plain enough, there's really nothing else one can do...