Rover Wheel problems, New fault finding info UNITY wheel build package

[SpannerMonkey(smce)]

Rover Wheels the black art.

So I've challenged myself to make at least one of every type of part, mostly because in a couple of years of modding KSP there are a couple of items that I fail on. The most annoying of which are rover wheels and landing gear, in fact any wheel has confounded me, and I've tried many times.

It seems that no real info on wheels exist apart from the stock rover wheel pic thats linked to every time this subject comes up and really for a complete noob it's not a lot of help.

Javascript is disabled. View full album

Important info that you need to know, most of the object in the hierarchy are colliders or bare named GameObject transforms, the rotation of the models transform/pivots is critical to a wheels functioning.

EDIT Much later still More info you need to know,

I was troubled by gaps in the suspension arms on one of my latest tests, so as usual i began tweaking and reloading. I have now discovered the suspensionTraverse, transform sets the apparent arc of the suspension, my trouble was due to the wheels having a large offset, that is that the dish and mounting face of the wheel was set way out toward the front face of the wheel on a wheel half a meter wide so placing the suspensionTraverse transform on the bottom bracket (see item bracket in labelled pic) had the effect of increasing the arc, spreading the suspension joints to far apart, the remedy is to move the suspensionTraverse transform closer to the center of the wheel. Experiments continue.......

NewEdit

Further hours past.... So it's been a productive week, i've got this wheel thing pretty much nailed now, now to experiment.

Notes on transforms

As mentioned earlier on in this post you need several game object transforms for various parenting jobs, my preferred method , now I've learned sumfin:P ,

Once you have your model in the scene and you have the wheel at 0,0,0 , and before you do anything else create the transforms you will need by selecting GameObject and selecting create empty, set this game object at 0'0'0 which should be the center of your wheel, if it's not find out why, rename that game object to suspensionNeutralPoint, steering, suspensionTraverse, trackSteering or whatever transform you need, and leave them outside the hierarchy until you need them. This way they all be done, they'll all have a 0,0,0 origin to start and trust me it'll make the whole job a lot quicker

NOTE, although these transforms all start at 0,0,0 you will move the trackSteering position after this to another location, but all the others stay at that point in space, note also that they will be moved into different parts of the hierarchy for use,

It seems all transforms are quite happy with the std rotation applied by unity except those parts named susp1-1, 1-2 etc these will need to be rotated so the the Z axis face each other along the component, this is due to the LOOKFX that is used to ensure the alignment of these parts

Before you combine these transforms with your GameObject make sure that the all all correctly rotated and scaled, scale should be 1,1,1, .

Once combined into the hierarchy it can be a real pain to sort out, and will make things very weird if the error makes it into game

Notes on Brakes and Braking speed

Hi all brake torque is one of those many things that will never be perfect for all occasions, ideally it would be adjustable for each rover you built. However watch this space, as in the near future the standard ksp rover will be rebuilt to use a very special and very clever custom wheel module, that makes the wheels behave so much better than the standard module that is controlling the wheels currently . In the meantime you can either (A) alter the brake speed and brake torque in the cfg, by altering the following

brakeTorque = 10
	brakeSpeed = 0.5

Brake torque is fairly obviously the amount of torque applied to stop the wheel rotating, and brake speed less obviously is the speed at which the braking torque goes from 0 to full on, tests have proved that altering the brake speed is a better adjustment than brake torque, as it still allows firstly for a decent stopping power, while creating the effect of heavier vehicles taking longer than light vehicles to come to a stop and a much nicer effect of adjust brake speed is that you can safely apply small amounts of braking in low g without taking off or flipping.

( build heavier rovers

or of course © put up with it for a little while

Below is my original post left here just in case somebody else runs into the same issues and by following the tips and steps above will soon achieve wheel nirvana

Now this is my problem I have created after many hours, working, steering etc all functions are there, rover wheels, the snag is the suspension seems way too soft, I ve tried, setting the wheel colliders spring rate to some stupid high figure but this just makes the wheel behave bizarrely, I've tried moving the models origin from the center of the mount being set on zero, setting the wheel center mount as zero, the bottom of the tire as zero and apart from more weirdness it's been very unproductive.

I'm fairly convinced that its something to do with the wheel transforms/pivots but can't work it out. My hierarchy differs only in the position of parts susp3-1 and 3-1 I changed this from the example as they did not move in the manner i wanted but that aside I have two other similar models that have exactly the same layout and behave in the same way.

You can see that in the pics of the wheels fitted to my spacecab that the vehicle seems to hover even though the wheels rotate , steer and propel the vehicle, even the brakes work. It's as if the suspensions 0 point is not where I think it should be and rather than extending the wheel collider suspension etc is contracting to place the wheel at zero, moving the model in max didnt help, could the bounds be still there ? is my hierarchy right? what am I missing???

PS yes the cab does have an IVA

EDIT.... sometime later YAY Fixed

Fixed it , turns out all my transforms are right and the wheels position really needs to be centered 0/zero, 0/zero, 0/zero, your life will be so much easier. What does matter though is how you generate the wheel collider and collision enhancer objects, I'd been using a sphere then deleting the mesh render and mesh filter, although this looks OK it turn out its not, for some reason unfathomable the radius of the sphere is listed as twice its actual size, so it's really showing the diameter.

Do this instead

duplicate your wheel and drag it out of the hierarchy, you must do this otherwise if you have already attached the part tools script ,unity may start throwing nre errors,

now depending what object you want, you rename your wheel to wheelCollider or collisionEnhancer, in the case of the former now select physics and wheel collider, now remove other colliders from the duplicated wheel, also remove the mesh render and mesh filter, and lo you now have a transform with a wheel collider attached and its in exactly the right position, for the collision enhancer just add a capsule collider and remove the mesh render and mesh filter as before.

Updated hierarchy and multiple wheel setup in my last post, I will get this tidied up once i get a moment

August 23 2014Adding unity wheel package

For all those looking for an easy in to making Rover Wheels I have created in UNITY3 a DIY wheel package using a Squad KSP TR 2L reworked to suit.

In the package you will find a complete ready to build project.

IMPORTANT

To use this package create a new project in unity version 3 upwards,

Once you have created an empty project access the menu at the ASSETS tab in select import package, then select custom package,

Having done this browse to the location of your downloaded and unzipped unity package and select it,

Unity will now import all thats needed for you to start understanding and building basic rover wheels.

Plus a full set of the transforms unused for reference.

AS always any questions I'm happy to help when I can.

The package is complete you will not need to add anything all Part Tools, models textures and scripts are already in place, all layers are set all tags are set, I have set all the layers I know, along with tags so this would make a starting project for anyone from novice to experienced.

The model that can be produced has been thoroughly tested in game and is suitable for 23.5 onwards

Possibly asked questions

Why unity 3 I use unity 4.x?

I made the package in unity 3 as it is a fairly common to creators version and unity 4 will open unity 3 packages without issues.

Why a TR 2L it's horrible?

Mainly because its the simplest most effective design to learn with , it has the basics of suspension and steering without the complication of added extras like torque arms and shock absorbers, and the quality of wheel function that you will produce with this package is far from the TR 2L's behavior and performance. The little yellow rover in the gif animation shown in the gallery above has very similar setup to this project

Will you make a package with a more funky suspension so I can see how that works?

Watch this space

THE Package

A tested in game version of the wheel with CFG that you can use in your project

And when you've worked it out you'll have a wheel that can do this

Fault finding information

Now that so many people are able to and actually are making wheels now, I thought a little section on how to find a fix common wheel faults.

Problem. Wheel sinks into the ground.

possible cause and most likely is that the actual wheelCollider is not l on the wheelCollider layer ( layer 27 ) , If that fails always check the transforms in unity and your cfg for correct names, they are case sensitive.

Problem. Wheel and suspension are slamming up and down at launch and whenever weight is taken off the wheel.

The primary and only known cause for this behavior is that the wheelCollider is interacting /hitting with another collider that is not on the wheelColidersIgnore layer (layer 26) simply sorting that will stop the cycle. Important to note that adding to this layer stops things interacting with wheelColliders, but also makes them invisible. In the case for example that one of your colliders on the base/mounting part of your model is being hit by the active wheelcollider, do not set the bases collider to the ignore layer, instead temove the base parts collider , create a GameObject in the correct location , name it base_Collider or something, and add a simple box collider to the transform, then set your base_Collider as a child of the base/mounting.

Problem. Wheel hover or gaps in the suspension arms or dampers.

This is simply because you have transforms, that the wheel requires to be in a certain way, set up incorrectly.

Or you have not allowed sufficient mesh in your model to allow for the unusual way in which stock suspension works. Unlike real world suspension which moves in an arc around it's mountings, stock KSP suspension simply moves up and down, which means the pivot points at full compression are very different to those at full extension, being much further away, the model should be built to allow this to happen.

There are plenty more I'm sure but they are the most common faults I am asked about.

A little soap box bit tl;dr here so tune out if you want.

Wheel building and Transform naming

I've read recently a lot of people asking if "X transform has to be called jellybeans and why can't it be called furball? "

You can obviously call it what you want as long as you set the appropriate values in cfg , so that the game knows where to look. But, it may be a personal but, you are just making your own life difficult.

I always use exactly the same set of transforms and part names every time I build a wheel, sounds dull maybe? But this is the but it means I know exactly what everything does, where it goes and that every wheel I do will be easy on the cfg, as the parts names dont change, only requiring small changes from cut an paste. and perhaps more importantly behaves in a predictable way . Also it makes finding glitches easier because you know the x transform is always called x it should not be called X in the cfg.

I can't exactly say how long it takes me to put a new wheel through unity and into game but it's minutes not hours, through no other reason that a routine has been developed that works, without having to dig around for info or reference images. So do yourself a favor get something you are happy with and stick with it and of course profit!

Happy rolling.

Edited September 10, 2014 by SpannerMonkey(smce)
Added diy unity package and download

[lo-fi]

Nice work, I've been doing similar myself

One comment, though. Make the collider mesh for the wheel smaller in diameter than the WheelCollider. Its only there for if the craft tips over and the WheelCollider is no longer effective, so it doesn't drop through the ground. If it's too large, it will 'catch' on the terrain horribly sometimes while driving, rather than letting the simulation do its work.

I've also worked out a neat trick to make the wheel move in an arc with the suspension joints, instead of straight up and down if you're interested?

[SpannerMonkey(smce)]

Nice work, I've been doing similar myself

I've also worked out a neat trick to make the wheel move in an arc with the suspension joints, instead of straight up and down if you're interested?

I think just putting that out therre like that is a bit off:sticktongue: , so share tell all, that'd make them move as they should, hopefully it resolves the push pull on the suspension arms that can create a gap between parts as well

[lo-fi]

Haha! Sorry, I shouldn't tease Just didn't want to hijack your thread. It needs quite a bit of explaining as it breaks the classic hierarchy and uses some tricks with dummy objects and position/rotation controllers, so I'll do a full write-up similar to yours this evening when I have a few hours clear

Just quickly, this is how it looks:

[SpannerMonkey(smce)]

Thats lovely articulation you've got there, very interested in your method of hierarchy stacking

[lo-fi]

Cheers All will be revealed Was going to do a write-up anyway, just been busy trying to get everything sorted for release. We need to keep sharing knowledge like this to save the next guys from reinventing the wheel (if you'll pardon the pun)!

[lo-fi]

Ok, so really quickly:

Ever notice the entries in wheel part.cfg's that read

MODULE{
    name = FXModuleConstrainPosition
    matchRotation = true
    matchPosition = false
    CONSTRAINFX
    {
        targetName = steering
        moversName = trackSteering
    }


}

Well, it caught may attention. Steering is a Gameobject which contains the WheelCollider. The rotation is changed when steering is activated, and the wheelcollider follows because it is a child of steering in the hierarchy. trackSteering is the container for the mesh parts - usually the axle and wheel. It is this that sets the steering axis and here is the important bit: it is told to follow the angles of the steering GameObject by this line in the .cfg. Notice well the lines

    matchRotation = true
    matchPosition = false

We also have

    name = FXModuleLookAtConstraint    CONSTRAINLOOKFX
    {
        targetName = MovedBySusTrav
        rotatorsName = WishBoneLower
    }

So we have two functions we can call via the .cfg that will rotate and move parts in different ways...

So, my solution is this:

by adding a few dummy objects - these have no mesh and no collision mesh. One, which I've named MovedBySusTrav is a child of suspensionTraverse. It gets moved by the WheelCollider suspension, so it I get the wishbone to look at this dummy object, it makes the arms move correctly. However, I now need to attach all the other stuff to the end of it... I have an object called Axle which the hub and wheel attach to. Here comes the clever bit:

Another dummy object is created called RodEnd. This is placed on the end of the lower suspension arm. Now, it moves in an arc with the end of the suspension arm, but if we place the hub, wheel and axle as a child, they will rotate as well, so we use:

MODULE{
    name = FXModuleConstrainPosition
    matchRotation = false
    matchPosition = true
    CONSTRAINFX
    {
        targetName = RodEnd
        moversName = Axle
    }

}

The script ties Axle's position to RodEnd but not its rotation!!! Great, we're half way there. You'll notice there is a dummy object called steeringDummy. the trackSteering GameObject is told to match its position using

MODULE{
    name = FXModuleConstrainPosition
    matchRotation = false
    matchPosition = true
    CONSTRAINFX
    {
        targetName = trackSteeringDummy
        moversName = trackSteering
    }

}

this is what ties all the mesh child objects beneath it to the arc of the suspension movement. The upper wishbone is moved by

    name = FXModuleConstrainPosition    matchRotation = true
    matchPosition = false
    CONSTRAINFX
    {
        targetName = steering
        moversName = trackSteering
    }


    CONSTRAINFX
    {
        targetName = WishBoneLower
        moversName = WishBoneUpper
    }

in the same way trackSteering follows Steering.

SuspB and SuspT should now be self explanatory!

Notice also:

The wheelCollider is not in the middle of the wheel, it is almost at the outside. For wide wheels, this gives greatest track width and greatest stability. Also, should it tip, it stops the collider mesh from hitting the floor until almost 90 degrees. Also, you'll see it is half the diameter of the WheelCollider setting. Again, this stops random collisions that plague the TR-2L etc.

I know it's not simple, and it takes some getting your head around. Full part.cfg is here:

PART{
name = KF_WheelLarge
module = Part
author = Squad


mesh = LargeWheel.mu
scale = 1
rescaleFactor = 1


node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0


TechRequired = advancedMotors
entryCost = 6000


cost = 580
category = Utility
subcategory = 0
title = KF-2L Large wheel for planetary operations
manufacturer = Kerbal Foundaries
description = Optimised for Kerbin straight out of its wooden crate - though tweakable for higher gravity - this wheel is designed for large, high-mobility planetary rovers. Criticised for being power-hungry, but never for being over powered!


attachRules = 0,1,0,1,0


mass = 0.5
dragModelType = default
maximum_drag = 0.3
minimum_drag = 0.2
angularDrag = 1


maxTemp = 3600 


crashTolerance =3000
breakingForce = 5000
breakingTorque = 5000


MODULE
{
    name = ModuleWheel
    hasMotor = true
    resourceName = ElectricCharge
        resourceConsumptionRate = 4.0
    canSteer = true
    controlAxisType = Forward
    steeringModeType = AutomaticSteer
    brakeTorque = 150
    brakeSpeed = 2.5
    impactTolerance = 3000
    overSpeedDamage = 60


    WHEEL
    {
        wheelName = wheel
        wheelColliderName = wheelCollider
        suspensionTransformName = suspensionTraverse
        suspensionNeutralPointName = suspensionNeutralPoint

        rotateX = 1
        rotateY = 0
        rotateZ = 0
    }


    steeringCurve
     {
        key = 0 27.5
     key = 15 17.5
       key = 40 7
     }


    torqueCurve
    {
      key = 0 275 0 0 
      key = 15 150 0 0
      key = 40 0 0 0
    }


}


MODULE
{
    name = FXModuleLookAtConstraint
    CONSTRAINLOOKFX
    {
        targetName = MovedBySusTrav
        rotatorsName = WishBoneLower
    }
    CONSTRAINLOOKFX
    {
        targetName = SuspT
        rotatorsName = SuspB
    }
    CONSTRAINLOOKFX
    {
        targetName = SuspB
        rotatorsName = SuspT
    }


}




MODULE
{
    name = FXModuleConstrainPosition
    matchRotation = true
    matchPosition = false
    CONSTRAINFX
    {
        targetName = steering
        moversName = trackSteering
    }


    CONSTRAINFX
    {
        targetName = WishBoneLower
        moversName = WishBoneUpper
    }

}
MODULE
{
    name = FXModuleConstrainPosition
    matchRotation = false
    matchPosition = true
    CONSTRAINFX
    {
        targetName = RodEnd
        moversName = Axle
    }

}




MODULE
{
    name = FXModuleConstrainPosition
    matchRotation = false
    matchPosition = true
    CONSTRAINFX
    {
        targetName = trackSteeringDummy
        moversName = trackSteering
    }

}


MODULE
{
    name = WheelTweaks
}


}

[lo-fi]

Anyway, I hope that helps! Apologies for the rambling, I'm short on time trying to get my wheels sorted for release. Do shout if I can clear anything up, I'll keep an eye on the thread.

[SpannerMonkey(smce)]

I like that , very neat, only really just discovered the LOOKFX stuff and although nice it all seemed a bit arbitary, your layout clears that vagueness of where the rigs pivots are and from your vid gives very realistic movement. I've got another set cooking in max at the moment and am definately gonna spend the time to get it done your way, after all it's only tricky till you've done it a couple of times, I'm on my fourth (working!!) std group now and have finally got the hierarchy written on the back of my eyeballs!!!.

Some great info there especially the wheel collider position as the edges of the wide wheels sinking below ground level was beginning to bug me a tad. Cheers

Spanner

[lo-fi]

Cheers, do shout if you want the rigged Unity scene. I just set it up for the new dimensions and bung fresh mesh in for a new design, saves a lot of bother.

Glad I was of some help, that knowledge was hard-won so worth sharing!

I have a plugin in development that allows you to tweak wheelcollider suspension settings in VAB/SPH. I was told this wasn't possible in KSP. You're welcome to test/use/distribute with your wheels when it's done, though all my stuff is pre-release I'm afraid, I've only been at this a few weeks!

Nice work, btw

[ZodiusInfuser]

Just a query, whats the simplest working wheel that can be created in KSP? I'm considering doing a few for my Infernal Robotics Model Rework, based on NASA designs and there's not much in the way of visible suspension. Essentially I would like to do all the wheels in this image:

Thanks, and appologies if this isn't the best place to ask

[lo-fi]

Funnily enough, I'm about to work on something like the wheels in the foreground. They can be as simple as you like, though there are a couple of caveats in terms of object names the wheel module code expects to see. You can just set the suspension to very little or no travel if you want and the models can be nothing more than a body and a wheel, should you wish. I've not yet tried multiple wheels on a part, though depends exactly what you've got in mind?

Love your work, btw!

[ZodiusInfuser]

They can be as simple as you like, though there are a couple of caveats in terms of object names the wheel module code expects to see.

I expected as much. Found the same when creating variants of the stock struts too.

You can just set the suspension to very little or no travel if you want and the models can be nothing more than a body and a wheel, should you wish. I've not yet tried multiple wheels on a part, though depends exactly what you've got in mind?

I don't mind giving the parts suspension but it would be purely a linear piston of some sort, rather than an off-to-the-side thing. I presume multiple wheels can be tricked by making a single wide wheel that looks like two in the mesh? The main thing I want to do with such wheels is add an IR Rework attachment point above the rotation axis, so that they can be used with Rotatrons and the like, maybe even allow for this:

Love your work, btw!

Thanks!

[lo-fi]

Yep, that should all work fine as far as I can see. My suspension arms are setup exactly as you suggest for the wheels - as two separate elements in a single mesh that sit fore and aft of the body. Keeps the lookat stuff easy having a central pivot, will work a treat for the wheel. Linear suspension is so easy to set up compared to arms too, you can just track suspensionTraverse and jobs done. Should be some pretty cool parts!

[nli2work]

Awesome post

what piece controls the wheel rolling animation? the WheelCollider?

[lo-fi]

The physics object wheelCollider controls that, yes. It calculates based on its diameter and the speed it's going. The lines in the config call code which ties the mesh rotation to the result of that calculation:

  
WHEEL
    {
        wheelName = wheel
        wheelColliderName = wheelCollider
        suspensionTransformName = suspensionTraverse
        suspensionNeutralPointName = suspensionNeutralPoint

        rotateX = 1
        rotateY = 0
        rotateZ = 0
    }

The visible mesh is called 'wheel'. Something to note is that in KSP the wheelcollider doesn't work if 'wheel' is not present or not in the same position as the other objects named in that code snippet. TrackSteering can be elsewhere.

Change the rotateX value to -1 in a wheel config and the wheel mesh will rotate the wrong way is an easy way to demonstrate

Useful for fixing that issue if it comes up, as it did in one of my models.

[lo-fi]

Further to earlier information:

If standard components named in ModuleWheel in the part.cfg are not present, the physical simulation may not work. The wheel will drop through the ground on launch and nothing else will happen. The object 'wheel' is a great example of this, though it does not have to be a mesh; an empty GameObject will do. This may also be true if transforms (pivots) of steering, wheelCollider, suspensionTraverse and suspensionNeutralPoint do not occupy the same position in the Unity model (the exception is trackSteering, this can be anywhere). Check everything in the hierarchy, it's easy to get thing screwed up if you've moved stuff around

FXModuleConstrainPosition with matchPosition enabled will move the targeted object to the position of the pivot of the mover. It does not tie them together maintaining the same relative positions the two objects start in. This is quite important!

FXModuleConstrainPosition with matchRotation enabled will leave the position of the targeted object unchanged and simply match rotation. Relative positions are preserved. This is how trackSteering works.

FXModuleLookAtConstraint points the local Z (blue) axis of the named object at the named target object. If you've assigned this to a part and wonder why it looks fine in Unity but everything is all over the place in-game, this is why.

Wheels surface mount at the pivot of the root GameObject. This is handy to know if you find your wheels are mounting too high on the side of the rover body. Move all child objects down in the Y axis will fix this.

To set up wheels for the correct orientation in the VAB/SPH, you model should have the mount point to the right and the wheel on the end of the suspension when viewed from the back in Unity. It is normal even for stock wheels to need a 90 degree turn to be the right way up in SPH.

That's it for the moment. If I think of anything more I'll add to the thread.

Edited June 19, 2014 by lo-fi

[nli2work]

steering, wheelCollider, suspensionTraverse and suspensionNeutralPoint do not occupy the same position in the model

by this you mean their transforms must be at the same position and have same orientation in Unity correct? They can be in different parts in the wheel hierarchy?

[lo-fi]

Yep, exactly. Not sure about orientation and I've not fully tested, but my experience is that things get weird if they aren't in the same position. Sorry, should have been clearer - I'll amend OP. Yes, they can be in different parts in the hierarchy.

Hoping to make a YouTube tutorial at some point.

[ZodiusInfuser]

Hoping to make a YouTube tutorial at some point.

A video going through the unity setup process would be extremely useful. There's things that just aren't captured in these pictures. A simple wheel with just vertical translational suspension and no steering would be perfect for me (see)

[SpannerMonkey(smce)]

For the awesome critter in that post you really need the alternate hierarchy that lo-fi posted early in this thread, especially if you want those legs to be nice and flexible ,should have nice organic qualty, not done an instructional vid of anything before, usually use teamviewer for showing people how to do things like this, but i'll give it a go over the weekend.

I'm currently experimenting with multiple wheels on a single part and the results are if at the moment so i dont know how you'll get on if that is a one part creature, not an issue if it's a normal multi pa

[ZodiusInfuser]

I'm currently experimenting with multiple wheels on a single part and the results are if at the moment so i dont know how you'll get on if that is a one part creature, not an issue if it's a normal multi pa

It's multi-part . Pretty much all of it is Infernal Robotics, which has an element of springyness to it anyway (maybe too much). The wheel itself is quite simple in comparision to what you guys have shown off so far, or at least it seems like it should be.

[lo-fi]

A video going through the unity setup process would be extremely useful. There's things that just aren't captured in these pictures. A simple wheel with just vertical translational suspension and no steering would be perfect for me (see)

I'll see what I can do, buddy. Never done any tutorials before, so I'm working out how to record and make everything properly visible, as well as some sort of script so I'm not rambling too much! I'd like to do a series; I really struggled when I first started modding a few weeks ago as a lot of info is out of date now and I had no experience with Unity. Be nice to pass on some of that hard-earned knowledge. Tiberian's tutorial was invaluable.

Another little gotcha with wheels is they stop working if you disable the steering (this is NOT the same as locking the steering in-game). Better to zero the curves in the part.cfg. ModuleWheel does some funny things and throws its toys right out of the pram if you change too much from the norm.

And That. Looks. Awesome!

I've just been playing with wheels like that, but I'm struggling with surface placement AND keeping them steering correctly in-flight. I'm guessing you're going to have attach nodes to marry up with the IR parts and steering with be with rotatatrons? Happy to help you set up in Unity - I rigged a scene this eve to test which would probably suit that design.

Edited June 20, 2014 by lo-fi

[lo-fi]

It's multi-part . Pretty much all of it is Infernal Robotics, which has an element of springyness to it anyway (maybe too much). The wheel itself is quite simple in comparision to what you guys have shown off so far, or at least it seems like it should be.

I made semi-flexible IR stuff by messing with the JointSpring line in the .cfg - worked like a charm Wouldn't be hard to add as a tweakable actually... What stage are you at with the wheels?

[ZodiusInfuser]

Another little gotcha with wheels is they stop working if you disable the steering (this is NOT the same as locking the steering in-game). Better to zero the curves in the part.cfg. ModuleWheel does some funny things and throws its toys right out of the pram if you change too much from the norm.

And That. Looks. Awesome!

I've just been playing with wheels like that, but I'm struggling with surface placement AND keeping them steering correctly in-flight. I'm guessing you're going to have attach nodes to marry up with the IR parts and steering with be with rotatatrons? Happy to help you set up in Unity - I rigged a scene this eve to test which would probably suit that design.

Ah ok. If I have to have them support some amount of steering then I'll model it in, however as you guessed, the main intention is for them to be controlled by rotatrons via the attachment node style I've adopted. I can imagine when IR supports KOS scripts this will become a really powerful feature as you could coordinate all the wheels to do some amazing motions . Surface attachment would also be allowed but not the main use case. Assistance with setting up the unity scene when I get to that stage would be most welcome

I made semi-flexible IR stuff by messing with the JointSpring line in the .cfg - worked like a charm Wouldn't be hard to add as a tweakable actually... What stage are you at with the wheels?

Ah yea, I remember that. Flexible suspension

Very early, i.e. modelled it from scratch a few hours ago, more to see the viability of the idea more than anything.