Jump to content

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


lo-fi

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193


Recommended Posts

Good progress! I have the suspension working with spherecasts or raycasts and can now start to extract data to plug into a grip model. This is certainly and interesting journey, and I now understand why the original wheel collider is built the way it is as I'm coming to some of the same solutions (minus the craziness). Rather than apply forces for sideways grip, I'm leaning towards a full slip "angle" model, comparing the angle between the current contact point and the last to a calculated vector. Yey, more vector maths! Plugging in some velocities, load bearing and the grip coefficients as shadowmage has already made a good start on, then poking the dummy the suspension is attached to into the "correct" place and letting the joint work its magic. A solver will be needed to adjust the lateral grip if longitudinal slip is occurring, and vice versa - this is something also missing from the original wheel collider, and why you can never do donuts. I intend to correct this :wink:

There are two possible ways to deal with motor and brake forces. Either use the dummy and pull it fore and aft of the contact point, or adding a force as shadowmage has already started doing. Experimentation will show which is best :)

Link to comment
Share on other sites

6 hours ago, lo-fi said:

Good progress! I have the suspension working with spherecasts or raycasts and can now start to extract data to plug into a grip model. This is certainly and interesting journey, and I now understand why the original wheel collider is built the way it is as I'm coming to some of the same solutions (minus the craziness). Rather than apply forces for sideways grip, I'm leaning towards a full slip "angle" model, comparing the angle between the current contact point and the last to a calculated vector. Yey, more vector maths! Plugging in some velocities, load bearing and the grip coefficients as shadowmage has already made a good start on, then poking the dummy the suspension is attached to into the "correct" place and letting the joint work its magic. A solver will be needed to adjust the lateral grip if longitudinal slip is occurring, and vice versa - this is something also missing from the original wheel collider, and why you can never do donuts. I intend to correct this :wink:

There are two possible ways to deal with motor and brake forces. Either use the dummy and pull it fore and aft of the contact point, or adding a force as shadowmage has already started doing. Experimentation will show which is best :)

:)

I suppose it is fortuitous that I was already looking into writing a custom constraints solver to handle the friction stuff.  Probably won't get to start on it much until this weekend, but it sounds like we'll be needing it for nearly any solution to friction/torques.  Constraints/solvers are new to me, so going to be a bit of a learning process getting it put together.

Excited to see what you've come up with for the suspension and how we can potentially use similar solutions for some of the other problems we're encountering/going to encounter.  Sounds like the joint solution might even work out for the sticky friction component, though we'll have to come up with interesting methods to 'un-stick' it when needed.

Link to comment
Share on other sites

On 5/8/2016 at 11:37 AM, Kenobi McCormick said:

The Source engine, designed from the ground up to be a first person shooter, handles wheel physics better than KSP! Go play Gmod. There's no special module in that game to handle the interaction between something round and the surface upon which it rolls. The basic physics properties of the surface, of the wheel, handle all of that. How your car handles in Gmod is 90% how you set up the suspension constraints, 5% how you set up the controls, power system, and 5% hoping that you don't get constraint spazz when you run over a small prop left on the ground by the newbie spamming thrusters and soda cans.

 

 

I don't know if Unity supports that sort of level of physics, though.

Unity does. KSP doesn't include all the features of Unity engine yet, or if ever; probably big reason why there are so many different plugins to enable stuff that's built into Unity but not used in KSP. Reflections for example (see Lilleman's plugin thread; and TextureReplacer Reflection; and Starwaster's Reflection Plugin); Scatterer; list goes on and on. and lets not start a game engine apple juice squirt match.

Edited by nli2work
Link to comment
Share on other sites

1 hour ago, Shadowmage said:

:)

I suppose it is fortuitous that I was already looking into writing a custom constraints solver to handle the friction stuff.  Probably won't get to start on it much until this weekend, but it sounds like we'll be needing it for nearly any solution to friction/torques.  Constraints/solvers are new to me, so going to be a bit of a learning process getting it put together.

Excited to see what you've come up with for the suspension and how we can potentially use similar solutions for some of the other problems we're encountering/going to encounter.  Sounds like the joint solution might even work out for the sticky friction component, though we'll have to come up with interesting methods to 'un-stick' it when needed.

Great, I'm literally just commenting and tidying the code for a commit. Not a lot more I can do until we can run some calculations for grip and torque, but I think that's more your area of expertise than mine. I have some ideas which I'll explore, but I won't muddy the waters with them until you've worked your own magic.

I've already covered the unsticking :) When the raycast hits nothing (it's set to the suspension distance as per the original WC), the dummy object is simply put at the end of the suspension travel. It seems pretty foolproof so far! 

 

EDIT: There you go. Apply to an empty GO with Rigidbody applied. For the moment, I've not gone to the lengths of searching up the parents to find a rigidbody like the orignal WC's do, so apply rb to each of the GO's you assign the script to. Same applies, suspension travel is in y-. It should do the rest for you. Current suspension settings are about right for supporting a "vessel" mass of 200. It seems quite stable when changed.

A little script I used to push it around the floor - might come in handy. Feel free to use, abuse or ignore:

 

 

	using UnityEngine;
	using System.Collections;
	public class force : MonoBehaviour {
	    public float forceX;
	    public float forceY;
	    public float forceZ;
	    public float pokeForce;
	    public Rigidbody rb;
	    // Use this for initialization
	    void Start () {
	    
	    }
	    
	    // Update is called once per frame
	    void Update () {
	        if (Input.GetKey(KeyCode.A))
	        {
	            forceX = pokeForce;
	        }
	        else if (Input.GetKey(KeyCode.D))
	        {
	            forceX = -pokeForce;
	        }
	        else
	            forceX = 0;
	        if (Input.GetKey(KeyCode.W))
	        {
	            forceY = pokeForce;
	        }
	        else if (Input.GetKey(KeyCode.S))
	        {
	            forceY = -pokeForce;
	        }
	        else
	            forceY = 0;
	        if (Input.GetKey(KeyCode.Q))
	        {
	            forceZ = pokeForce;
	        }
	        else if (Input.GetKey(KeyCode.E))
	        {
	            forceZ = -pokeForce;
	        }
	        else
	            forceZ = 0;
	    }
	    void FixedUpdate()
	    {
	        rb.AddForce(rb.transform.right * forceX);
	        rb.AddForce(rb.transform.up * forceY);
	        rb.AddForce(rb.transform.forward * forceZ);
	    }
	}

 

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

I really, really want one of those! Would be really cool for Kerbals, wouldn't it. Thanks, by the way. So much focus on writing a wheel collider; I have a head full or vector code, edge and corner cases I need to handle, and I'd forgotten what fun it is to have people come up with cool suggestions for things to create for the game. I was just thinking way back to when someone suggested the screw drive and prompted me to go make it! Thank you, that's a lovely reminder of the end goal :D 

I'll make it if you can texture it :wink: Seems like ages since I worked on any stuff in 3ds max.

Link to comment
Share on other sites

23 hours ago, lo-fi said:

Most of the mods would probably not exist were it not for Unity being so commonly used and understood. I certainly wouldn't have managed were it not for forums full of info. 

Oh, I'm not saying Unity is the worst game engine ever, I'm just saying that I think Squad could've done better.  I do agree with Kenobi McCormick that Source is superior to Unity in pretty much every way.  Every game that I play that uses the Source engine plays more smoothly, is less resource-intensive, and just overall seems to run better than other games that use different physics engines.  I absolutely refuse to purchase any more games that use the Unreal engine after wasting money on 2 or 3 games that use it, it looks awful and just sucks in my opinion.  It doesn't crash a lot on my system, but it's just fugly.

So, anyway, I'm sure Unity has its strengths, but if that's the case then Squad doesn't seem to be doing a very good job at utilizing it to its full potential, IMO.  :) 

Link to comment
Share on other sites

3 minutes ago, Neutrinovore said:

Oh, I'm not saying Unity is the worst game engine ever, I'm just saying that I think Squad could've done better.  I do agree with Kenobi McCormick that Source is superior to Unity in pretty much every way.  Every game that I play that uses the Source engine plays more smoothly, is less resource-intensive, and just overall seems to run better than other games that use different physics engines.  I absolutely refuse to purchase any more games that use the Unreal engine after wasting money on 2 or 3 games that use it, it looks awful and just sucks in my opinion.  It doesn't crash a lot on my system, but it's just fugly.

So, anyway, I'm sure Unity has its strengths, but if that's the case then Squad doesn't seem to be doing a very good job at utilizing it to its full potential, IMO.  :) 

Unity's strengths are basically around portability.  No real work to make it buildable for Windows, Linux, Mac, IOS, Droid, and various console flavours.  Of course with KSP, it'd crash the hell out of just about any mobile, and requires a lot of rethink for consoles, so that advantage is maybe not as useful as it may have sounded at the beginning.  But it's also (excluding crazy physics) pretty good for modders, as the full editor is available free if you're not making money (above a threshold, which also makes it good for start-ups) from it and don't need collaboration features.

Not that I've checked out the Source engine.  I can't mod KSP in Source.  ;-)

Link to comment
Share on other sites

23 minutes ago, TiktaalikDreaming said:

Unity's strengths are basically around portability.  No real work to make it buildable for Windows, Linux, Mac, IOS, Droid, and various console flavours.  Of course with KSP, it'd crash the hell out of just about any mobile, and requires a lot of rethink for consoles, so that advantage is maybe not as useful as it may have sounded at the beginning.  But it's also (excluding crazy physics) pretty good for modders, as the full editor is available free if you're not making money (above a threshold, which also makes it good for start-ups) from it and don't need collaboration features.

Not that I've checked out the Source engine.  I can't mod KSP in Source.  ;-)

Yeah, well, you're still way ahead of me on this whole thing, lol.  I may be good at some things (well, maybe a few...), but I certainly don't know all the particulars of game design, or all the pros and/or cons of every single game engine out there.  All I know is what I've observed, and as it happens the majority of PC games I've played have used either the Source Engine (anything from Valve, such as the Half-Life franchise, Portal 1 & 2, the Left4Deads, etc.) or CryEngine, specifically the first Far Cry and the Crysis games... well, I can't play Crysis 3 on my system, my video card isn't beefy enough... but like I said before, the few games I've had the misfortune to purchase and play that used the Unreal engine just made me feel... unclean, somehow... after playing them for just a few minutes.  Anyway, as far as I know the only game I've played that uses Unity is KSP, so I'll freely admit that I'm working with a sample size of 1. But based on this experience, and while I really do love KSP despite all my comments seemingly to the contrary, I would honestly have a bit of a think before knowingly buying another game that uses Unity. 

Link to comment
Share on other sites

5 hours ago, Neutrinovore said:

Oh, I'm not saying Unity is the worst game engine ever, I'm just saying that I think Squad could've done better.  I do agree with Kenobi McCormick that Source is superior to Unity in pretty much every way.  Every game that I play that uses the Source engine plays more smoothly, is less resource-intensive, and just overall seems to run better than other games that use different physics engines.  I absolutely refuse to purchase any more games that use the Unreal engine after wasting money on 2 or 3 games that use it, it looks awful and just sucks in my opinion.  It doesn't crash a lot on my system, but it's just fugly.

So, anyway, I'm sure Unity has its strengths, but if that's the case then Squad doesn't seem to be doing a very good job at utilizing it to its full potential, IMO.  :) 

Eh, Source has its flaws as well. For starters, the fastest any object can move through a Source map without some hacking is about 115MPH. There's a hard cap built in, never a problem in any of Valve's games but it very quickly became one in Gmod once we figured out how to get our cars moving that fast. A plugin mod exists to remove this cap, using that makes the game rather prone to crashing from time to time. There's also an angular velocity speed cap, which when met, will cause wheels to spaz out/do really bizarre crap. Ever see a car suddenly fly up and hard left because it crested 74MPH? I've had it happen to mine before, hit angvel cap on the wheels and physics just broke down. Constraints behave in silly ways, the map system is of course wholly unsuitable for KSP...and modding it is not easy. Unity is most certainly more modder friendly than Source, no doubt, and honestly I'd use it for KSP before I used Source.

Edited by Kenobi McCormick
Link to comment
Share on other sites

3 hours ago, Virtualgenius said:

You always had the best stuff lo-fi

Thanks, it was always fun making it :) When this is done I'll have a go at finishing some of the bits I never got around to before, like the magnetic handler/loader. That was possibly one of my favourite projects.

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

17 hours ago, Kenobi McCormick said:

Ever see a car suddenly fly up and hard left because it crested 74MPH? I've had it happen to mine before...

Honestly, that sounds like just about every fast rover I ever made in KSP... except swap out miles for meters, and hours for seconds, but otherwise... yup, hit a certain speed and suddenly the entire thing goes WHACKO!


I have a feeling it's not for the same reasons though...

Link to comment
Share on other sites

Exciting news! I got lateral grip working. It turned out to be the most stupid, simple thing. One of those beautiful, elegant solutions that just looks right! This is just a basic mechanism upon which to build a "proper" grip model into, so don't get too excited just yet. I know there are a lot of people itching to see some progress though, so here's a little clip of my U5 development rig in action:

The rig is so simple I've just got keys bound which add a "poking" force to push it around, but you'll get the idea. I start by shoving it side to side, then back and forward over the "hills", then giving a bigger shove side to side. You can see how it resists, rolls and slips when shoved sideways, and how naturally it behaves. I'm going to implement steering, then set up a crude driving mechanism to really test the dynamics out before we add the more complicated bits that really make it shine. None of he usual stuff you see with "wheels" is present, of course.

 A lot of work still to do.

Link to comment
Share on other sites

15 minutes ago, lo-fi said:

Exciting news! I got lateral grip working. [...]

Very nice :)

I should have some time over this weekend and would gladly help get the rest of the stuff in order if you would like.  As long as github is up to date I'll be taking a look over code a bit later tonight and see what I can do towards working on a basic/generic PartModule front-end for it; probably something intended to be used as MM-patchable replacement for stock wheel module.  Or if there is anything specific you would like a hand with, just let me know :wink:

Link to comment
Share on other sites

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

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!

Link to comment
Share on other sites

I don't know much about the ground based side of modding but I do know that antigravity works more like space than surface so can you please just release a repulsors and rover body only version of the mod while we wait for wheels and tracks? I feel like that would be a good decision because people would be more invested in the mod and remember that it's still a thing

Link to comment
Share on other sites

On Friday, May 13, 2016 at 6:28 PM, lo-fi said:

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

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!

Had some unforseen ...'obligations'... pop up that took up a bit of my time this weekend, but I've synced up my repo and have started looking into what you've done so far.  Should hopefully have an understanding of all that later today and be able to start working on the rest of the missing bits.  Might have something to show for it sometime tomorrow :)    (have tomorrow off from work and should be able to devote a fair chunk of time to wheel dev work)

Link to comment
Share on other sites

1 hour ago, Fireheart318 said:

I don't know much about the ground based side of modding but I do know that antigravity works more like space than surface so can you please just release a repulsors and rover body only version of the mod while we wait for wheels and tracks? I feel like that would be a good decision because people would be more invested in the mod and remember that it's still a thing

If only it was that simple, the repulsors too are (or were) a wheel collider based system, and so just as messed up as wheels

Link to comment
Share on other sites

Just now, SpannerMonkey(smce) said:

If only it was that simple, the repulsors too are (or were) a wheel collider based system, and so just as messed up as wheels

*Almost cries*. Okay ): I just love hovercrafts! So much fun!

Link to comment
Share on other sites

I have absolutely zero understanding of most of the technical talk on this most current page of the thread, and most of the old secondary thread.  but i am always thrilled to read through it and know that you guys are hammering away at it.

Anywhoo.  i'm just here with nothing to add to the conversation other than "keep up the good work, we're here ready and waiting, and glad you're doing it!"

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...