Jump to content

[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks


What to work on next?  

1,271 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      449
    • Rover bodies
      238
    • Landing gear
      136
    • Landing legs
      108
    • Something completely different
      190


Recommended Posts

1 hour ago, Shadowmage said:

Indeed; the only place where raw vectors are used is:

https://github.com/shadowmage45/KSPWheel/blob/dev2/VSProject/KSPWheel/Component/KSPWheelCollider.cs#L230-L232

and I -think- that the anchors are setup in local space, where that is correct.


Unless you saw something I missed in there somewhere?

 

This are the values to define the local XY&Z. Have you tried <wheel.transform.forward> and <wheel.transform.left> ? That way Z should be tranfrorm.up and than It's defined a free joint.
 

Link to post
Share on other sites

I haven't given up quite yet... Thank you all for the intelligent discussion, it's given me a few new avenues to follow up. I'll reply more fully once I get back in front of the pc and I've done some testing :)

Thanks guys, couldn't keep going without your enthusiasm . 

Link to post
Share on other sites

Well, something like this does stand out:

susJoint.anchor = ITP + -wheel.transform.up * (length + radius); // using transform's world up to calculate local anchor position?
susJoint.axis = new Vector3(1, 0, 0); // local space axis
susJoint.autoConfigureConnectedAnchor = false;
susJoint.secondaryAxis = new Vector3(0, 1, 0); // also local space

 

Link to post
Share on other sites

That's reassuring, as it's exactly where I thought I'd start looking.

Yep, the anchor position needs to be where the contact point game object sits at fully extended suspension travel, so a calculated offset from the parts rigidybody to here. The anchor point is indeed defined in local coordinates of the game object of the rigidbody its applied to. I think all the funkyness is happening somewhere in here. I'll keep to confirm, but I think the root GO of the part has Part applied, as well as rigidbody. . . Which in my testing case shouldn't be the problem, as it's in the same orientation as the "wheel" GO where the wheel collider component is applied and references position from. Ultimately, I'll have to do some scalar products to determine the wheel orientation against the part and set the joint axis correctly, but for now I just have to figure out why it's all back to front when they're in the same orientation! 

The anchor object gets positioned correctly in Start(), but the moment the joints are connected to them, it all goes berserk and they get forced into the wrong place. 

 

Link to post
Share on other sites
1 hour ago, OrbitalBuzzsaw said:

@lo-fi you might want to change OP "1.1x notes" to "1.2x notes"

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

Edited by lo-fi
Link to post
Share on other sites

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.

Link to post
Share on other sites
25 minutes ago, lo-fi said:

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.

Every time I see this going forward still bring another smile to my face. Awesome! I dream in treads lol

Link to post
Share on other sites

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 :)

Link to post
Share on other sites
13 minutes ago, lo-fi said:

The light at the end of the tunnel just got a little brighter :)

Spanner >currently digging up the rails half a mile further on,  just in case it's actually a train :)

  Congrats must feel good to have some success after the past few weeks confusion and misery  , i feel good for you  anyway ,  Cheers

18 minutes ago, lo-fi said:

I have yet to test parts with more than one wheel collider in-game, though I don't believe this will be a problem.

oh and whoop! missed this first time around   I can't wait to have my toys working again whoop whoop

Spoiler

nT85zkK.jpg

 

Link to post
Share on other sites
10 minutes ago, SpannerMonkey(smce) said:

Spanner >currently digging up the rails half a mile further on,  just in case it's actually a train :)

  Congrats must feel good to have some success after the past few weeks confusion and misery  , i feel good for you  anyway ,  Cheers

oh and whoop! missed this first time around   I can't wait to have my toys working again whoop whoop

  Hide contents

nT85zkK.jpg

 

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.

Link to post
Share on other sites
14 hours ago, SpannerMonkey(smce) said:

Spanner >currently digging up the rails half a mile further on,  just in case it's actually a train :)

  Congrats must feel good to have some success after the past few weeks confusion and misery  , i feel good for you  anyway ,  Cheers

oh and whoop! missed this first time around   I can't wait to have my toys working again whoop whoop

  Hide contents

nT85zkK.jpg

 

My old friends :) I remember that wheel texture! The suspension is all new but the tires are still the same. That looks outstanding Spanner. And I agree. I'm glad you finally caught a break after all the walls you've been running into the last couple weeks. We are all rooting for you @lo-fi Just don't forget to enjoy playing the game after all this. Thanks for all your hard work. You too @Shadowmage and @xEvilReeperx we appreciate all you combined efforts on all this.

Edited by V8jester
Link to post
Share on other sites

@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. 

 

Link to post
Share on other sites

Hiding? Ohhhh, nothing :wink:

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. 

Link to post
Share on other sites
On 30/10/2016 at 1:27 AM, lo-fi said:

@ShadowmageIt 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.

How launch-y are we talking here? Vessel does a wheelie, or vessel fired into orbit? The former seems consistent with the idea that if you hit a bump at speed with the suspension bottomed out, bad things will happen.

Link to post
Share on other sites
  • Snark locked this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

guest_terms_bar_text_value