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

[Madrias]

2 hours ago, lo-fi said:

Some people always tryin' ice skate uphill

And they're doing so on rollerblades.

[Tex]

3 hours ago, Mycroft said:

Here are the community rules: http://forum.kerbalspaceprogram.com/threads/30064-Community-Rules-October-27th-2013 
In Rule 2.3 section F, it lists among the forbidden posts "Messages that repeat inquiries about updates or content from modders." 

@Vonnmillard's post is in direct violation of this rule. If this action is repeated, I will be forced to notify the moderators. Please consider yourself warned.

Hey now. If you or any other forum user sees a post with negative intent or that violates the rules, don't hesitate to hit the report button the very first time. That's the primary way we see posts that require attention, and there's no need to wait until rule-breaking is "repeated." Report like there's no tomorrow 

(But only if the post actually goes against forum rules, don't just go reporting everything pls)

[lo-fi]

2 hours ago, Madrias said:

And they're doing so on rollerblades.

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. 

Edited August 10, 2016 by lo-fi

[damerell]

It opens quite the can of worms - we know little from stock KSP about the surface of various worlds besides the colour and that Minmus may be made of frozen pudding (and in all candour I cannot claim to be an expert on the tractive properties of frozen pudding).

[Mycroft]

3 hours ago, Maximus97 said:

Hey now. If you or any other forum user sees a post with negative intent or that violates the rules, don't hesitate to hit the report button the very first time. That's the primary way we see posts that require attention, and there's no need to wait until rule-breaking is "repeated." Report like there's no tomorrow 

(But only if the post actually goes against forum rules, don't just go reporting everything pls)

It seemed apparent that @Vonnmillard had not read the forum rules, so I thought a warning was only decent. I didn't want to report him to breaking a rule he didn't know about.

Edited August 10, 2016 by Mycroft

[V8jester]

1 hour ago, lo-fi said:

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. 

That would actually be really cool! Add in a bit o difficulty. So you can't pull a 30 ton building with a golf cart at the poles. give you more indenture to use cats over wheels as you might get stuck.

[Mycroft]

Use cats over wheels?!?!? 

[lo-fi]

1 minute ago, Mycroft said:

Use cats over wheels?!?!? 

They always land the right side up....

[Mycroft]

5 minutes ago, lo-fi said:

They always land the right side up....

Ohhhhhh! NOW I get it!  I was picturing some weird thing where the poor cat was like a mud guard or something.

Edited August 10, 2016 by Mycroft

[Shadowmage]

16 hours ago, lo-fi said:

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!!

After a good look over the code last night, I should be able to get the friction stuff added back in fairly easily.  Had a few questions though:

1.) Is there a reason you changed the class to a MonoBehaviour (other than easier debugging)?  I had specicically left it as a standard class so that it could be wholly controlled externally (e.g. from the PartModule), to avoid all of the serialization issues that come with Unity, and allow for a single logical component/script to manage multiple wheels (rather than wheels manage themselves).  This is where the updateWheel() method came into play; it was intended to be called from the controlling class so that the controlling class had complete control over the updates (e.g. updateWheel() would be called from the PartModules' FixedUpdate() only when it was needed/ready).

Not a huge deal, and workable either way in the end, was just curious about it before I start bashing the code around for one way or the other.
 

2.) If I'm understanding it right... sticky friction is achieved through the constraint of the joints to their contact GO's, and turning it on/off can be achieved by enabling/disabling the JointDrives for the specific axis'?  Not really important for the friction implementation aside from knowing how to turn it off for testing   (dynamic force-based friction models needs no external interference for the actual friction; only needs to be able to turn on/off the sticky friction when it is needed).

3.) So, overall flow for these joint-based wheels is to use the contact GO as the constraint for the wheel, updating its position as needed when contact is detected (isKinematic=true), and letting the constraint update its position when no contact is detected (isKinematic=false, mass=0, gets drug around effortlessly).  Do any of the drives or constraints do odd stuff at high angular or linear velocities due to the constraints?

4.) In what unit of measure is the Unity spring value specified?  newtons-per-meter (nm), knm, nmm, other?  I could never figure out how the spring strength on Unity joints was specified, it never lined up to any other calculation using standard newtons-per-meter for linear compression.  Will need to know this in order to derive the down-force for friction usage;  in the end the value that is needed is the sprung mass or newtons of force exerted by the suspension.
 

 

Anyhow, I'll hopefully start playing with the code a bit later this evening.  Will likely just integrate the friction code into the existing MonoBehaviour based setup and we can figure out the actual componentization of it later.  Should be a fairly simple affair as long as the joints aren't interfering with the force-based friction setup; aside from needing the down-force for the friction, they should be able to operate as two separate systems.

 

[Kenobi McCormick]

1 hour ago, Mycroft said:

It seemed apparent that @Vonnmillard had not read the forum rules, so I thought a warning was only decent. I didn't want to report him to breaking a rule he didn't know about.

It's stickied in the main addons forum. Should be stickied here, either way it's not like it's hard to find that information.

 

@Maximus97: See if you can get that sticky mirrored over here as well.

[lo-fi]

43 minutes ago, Shadowmage said:

1.) Is there a reason you changed the class to a MonoBehaviour (other than easier debugging)?  I had specicically left it as a standard class so that it could be wholly controlled externally (e.g. from the PartModule), to avoid all of the serialization issues that come with Unity, and allow for a single logical component/script to manage multiple wheels (rather than wheels manage themselves).  This is where the updateWheel() method came into play; it was intended to be called from the controlling class so that the controlling class had complete control over the updates (e.g. updateWheel() would be called from the PartModules' FixedUpdate() only when it was needed/ready).

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.

 

49 minutes ago, Shadowmage said:

2.) If I'm understanding it right... sticky friction is achieved through the constraint of the joints to their contact GO's, and turning it on/off can be achieved by enabling/disabling the JointDrives for the specific axis'?  Not really important for the friction implementation aside from knowing how to turn it off for testing   (dynamic force-based friction models needs no external interference for the actual friction; only needs to be able to turn on/off the sticky friction when it is needed).

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.

53 minutes ago, Shadowmage said:

3.) So, overall flow for these joint-based wheels is to use the contact GO as the constraint for the wheel, updating its position as needed when contact is detected (isKinematic=true), and letting the constraint update its position when no contact is detected (isKinematic=false, mass=0, gets drug around effortlessly).  Do any of the drives or constraints do odd stuff at high angular or linear velocities due to the constraints?

Bingo. Not that I've seen so far!

53 minutes ago, Shadowmage said:

4.) In what unit of measure is the Unity spring value specified?  newtons-per-meter (nm), knm, nmm, other?  I could never figure out how the spring strength on Unity joints was specified, it never lined up to any other calculation using standard newtons-per-meter for linear compression.  Will need to know this in order to derive the down-force for friction usage;  in the end the value that is needed is the sprung mass or newtons of force exerted by the suspension.

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.

[Tex]

@Kenobi McCormick, I'm not entirely sure which "sticky" thread you're referring to. However, if it's the Forum Rules you mean, then it's available at all times: Simply mouse over the Forums tab in the top left of the webpage, then click "Guidelines."

But enough discussions of rules and things. I was never here, a shadow on the thread... Discuss your mods now 

[Madrias]

5 hours ago, lo-fi said:

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. 

How did... Never mind.  An off-the-wall comment made when I was dead tired inspired an idea.  I'm not even sure I want to take credit for making driving places even harder than it already is...  Well, maybe if, and this is a really big if, we get some high-grip wheels/tracks to counteract the lack of traction later on, I'd accept some credit for the accidental idea.  Obviously, the big focus is repairing the wheel colliders before anyone even thinks of grip adjustments and tracks/wheels with extra grip (like little spikes on old-school snow tires) to counter the slicker surfaces.  Though I can think of a perfect balance for using high-grip tracks or wheels: They're 50% slower.  Which one becomes more important when exploring an unknown world:  Speed, or Grip?

And before anyone goes to slap me with a fish, I know that the repairs to the wheel colliders come first.  And I've got a mean swing and a shark to hit back with.

[OrbitalBuzzsaw]

@lo-fi I'd suggest gearing up for Unity 5.3, 'cause the 1.2 Hype Train is building steam!

[lo-fi]

You should know that's how it works around here, Madrias

Already developing in 5.3!

[V8jester]

18 minutes ago, lo-fi said:

You should know that's how it works around here, Madrias

Already developing in 5.3!

Yeah I'm pretty sure you were about to put your computer on the curb with a big free sign when 1.1.x dropped. I still can't bring myself to actually build anything in 1.1.3 just hasn't been the same till KF and Adjustable Landing Gear are up to speed. What point is there building anything when you can neither land or drive it?

[lo-fi]

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. 

[OrbitalBuzzsaw]

Good to hear.

[lo-fi]

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

[Kenobi McCormick]

Party in the tank~! \o/

[Shadowmage]

56 minutes ago, lo-fi said:

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

Nah, merging it together won't be too hard.  About all I need to do now is calculate the spring force from the compression and feed that into the friction calculator, and find the best time to enable/disable the sticky friction.

One problem I'm running into though is that my test-vehicle doesn't want to work with this joint based setup for some reason; it insists on flipping into the air regardless of spring/damper settings.  This is the standard car model I have shown in the previews, with all wheels parented under a single ridibody for the body (not jointed).  So I haven't been able to start testing the integration yet.

@lo-fi Any way I could get a copy/zip of your Unity project that you were using for testing?  I have a feeling that there is a difference in vehicle setup needed for these, or else there are some other settings that I've simply not configured properly.

[lo-fi]

Of course, I'll sort that out shortly 

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

Edited August 11, 2016 by lo-fi

[Vonnmillard]

18 hours ago, Mycroft said:

It seemed apparent that @Vonnmillard had not read the forum rules, so I thought a warning was only decent. I didn't want to report him to breaking a rule he didn't know about.

I acknowledged the warning...