KSP 1.1 Wheel Blocked: Yes

[Angelo Kerman]

I've been tearing my hair out trying to sort through the new wheel system and ran into a situation where wheels were not working. @Gristle generously provided me with some screenshots and it's clear that the new wheels are very claustrophobic when it comes to having things around them. If you have parts that are too near the wheel, they'll claim they're blocked. I've found a workaround, however. As you can see from the picture below, the wheels on the right are blocked while the wheels on the left aren't:

How did I manage this? I cheated! I rebuilt the inflatable module on the left by setting all of its colliders to layer 26, WheelCollidersIgnore. The inflatable module on the right has not been rebuilt yet so the right side wheels are still blocked. Once I set the colliders to layer 26, the wheels decided that they weren't blocked.

I've no problems rebuilding my parts to set their layer to 26, but I'm wondering if @nli2work or another modder has come up with a better way to unblock wheels.

Edited April 22, 2016 by Angel-125

[nli2work]

no idea. haven't touched wheels on 1.1 actual yet. It would suck having to set all non-wheel colliders to layer 26 especially for the large part packs out there. It's hard to say without knowing where the actual colliders are for all those parts and the wheel. I assume the hab module blocks the wheel when fully inflated, the collider scale? What if you didn't change any colliders but just reduced the wheel radius in the config? There might be some collider adjustments needed but for the most part I say it's a matter players have to contend with. The wheels are working as designed really.. setting all other colliders to 26 would permit some really absurd builds.

Edited April 22, 2016 by nli2work

[Angelo Kerman]

27 minutes ago, nli2work said:

no idea. haven't touched wheels on 1.1 actual yet. It would suck having to set all non-wheel colliders to layer 26 especially for the large part packs out there. It's hard to say without knowing where the actual colliders are for all those parts and the wheel. I assume the hab module blocks the wheel when fully inflated, the collider scale? What if you didn't change any colliders but just reduced the wheel radius in the config? There might be some collider adjustments needed but for the most part I say it's a matter players have to contend with. The wheels are working as designed really.. setting all other colliders to 26 would permit some really absurd builds.

Actually the wheels are blocked when the module is deflated, and the colliders scale. I have tried reducing the wheel radius for my custom wheels, but that had mixed results. I do agree that players have to contend with ensuring that there's enough space for the wheel, but at the same time I would expect certain designs to work where there's clearly enough space. In the example above, the wheels are scraping the inflatable modules. Here's a situation where they clearly don't:

In this case, KSP thinks the wheels were blocked. For reference, the wheel collider is sized to be right at the size of the wheel meshes. For me, changing the colliders resolved the wheel blocking issue.

And yes, changing all the part colliders to layer 26 would not be enjoyable. That's why I'm hoping there's a better way. If wheel radius is the issue, I really wish there was some debug option to show you the actual wheel collider as it is in game. That would help me design better wheels.

Thanks for your help.

[nli2work]

what is the default state of the hab when there's no animation? inflated or deflated? I don't mean the 1st frame of the animation clip, but the state of the model before animation is applied. maybe export the MU in deflated state as default and see if it blocks the wheels, if not, then add inflate animation. in other words the scale of collider is 1,1,1 in deflated state. instead of 1,1,1 in the inflated state.

Edited April 22, 2016 by nli2work

[Angelo Kerman]

1 hour ago, nli2work said:

what is the default state of the hab when there's no animation? inflated or deflated? I don't mean the 1st frame of the animation clip, but the state of the model before animation is applied. maybe export the MU in deflated state as default and see if it blocks the wheels, if not, then add inflate animation. in other words the scale of collider is 1,1,1 in deflated state. instead of 1,1,1 in the inflated state.

Good points. The default state of the hab without animation is deflated, so all the colliders are compressed down. Would wheel collider orientation make a difference? In Unity, my wheel collider is oriented so that the suspension height indicator points down towards the ground.

[nli2work]

What you have should be good, the raycast has to be pointed at the ground otherwise the wheel won't work. have you tried Sarbian's DebugStuff utility? it displays object names and collider shapes in KSP, very useful. It's hard to do any kind of tweaks without knowing how wheelmodule is determining whether it's blocked or not. 

The Wheel Blocked state is new in full 1.1 right? I don't remember seeing it in pre-1183

Edited April 22, 2016 by nli2work

[Gristle]

Saw this in the 1.1 change log and wondered if it might be the same issue being discussed here.

 

* Fix Unity bug that prevents us from ignoring collisions between wheel colliders and parts on the same vessel by disabling wheels that are within a certain range of other parts on a vessel. Where this sphere is and how large it is are configurable in the settings file.
...
* Re-exported all wheels with proper collision layers that ignore their own housing colliders, and other wheels.

 

[nli2work]

interesting. I'll have to dig into the part module tonight see if I can find this setting.

[nli2work]

closest thing I see are few new values in ModuleWheelBase, don't see any settings that change size of clipping sphere, maybe it's based on wheel radius?
blockedState = "No" 
clipObject = string.Empty
debugClipSphere = true/false

blockedState is probably just status display... clipObject might be important, maybe test it by assigning a tiny collider... debugClipSphere doesn't seem to do anything true/True/false/False

okay, clip sphere seems to be based on wheelRadius, maybe padded by suspensionDistance??, presumably centered on the wheelCollider. but shrinking wheel radius isn't best option in most circumstances. For stock wheels that maybe the only option, but limited by the collision enhancer size usually slightly smaller than wheel radius.

can't make any sense of what clipObject is supposed to do... it seems to work like the old Bounds collider. gets destroyed when vessel is launched... but that's rather pointless... Maybe it's a helper object for VAB/SPH?

recorded some video, will upload with annotations after I eat.

 

 

 

Edited April 23, 2016 by nli2work

[nli2work]

Clip sphere definitely looks to be based on wheel radius, with some padding, around 25%

[Angelo Kerman]

Very cool! Thank you for putting together that video, definitely helps understand what is going on.

[nli2work]

fixed the annotation, the first part has targetPosition at 1, not 0.5

just saw these values in settings.cfg...
WHEEL_CLIP_OFFSET = 0
WHEEL_CLIP_RANGE = 1
WHEEL_CLIP_MULTIPLIER = 1.05

I'm guessing offset is from wheelCollider center; 

Edited April 23, 2016 by nli2work

[nli2work]

Did a little testing, Increasing OFFSET seems to push clip detection in the direction of wheelCollider raycast, into the ground. Borderline cases where wheels are blocked but not visually can be solved by increasing offset just enough to clear the block. These setting doesn't allow actual clipping of wheels however. maybe except in the case where all other parts' colliders are set to layer 26.

[Angelo Kerman]

@nli2work My understanding is that KSP 1.1.1 has fixed a bunch of things with wheels. I wonder if they did anything with individual wheel OFFSET settings. I'm digging around as I write this..

Edited April 29, 2016 by Angel-125

[nli2work]

doesn't seem to be any changes in 1.1.1 on that front. no new settings in wheel Modules other than the substep values mentioned in the change logs. been messing around with a wheel part for the last couple days, overall handling seems a tad better, suspension seems better too. but I haven't touched the stock wheels much. One thing I did notice is TargetPosition seems to be inverted from Unity's convention. Unity has 1 at max compression; KSP has 0 at max compression. I don't think this is from 1.1.1 though.

Edited April 29, 2016 by nli2work

[Dr. Jet]

No changes in 1.1.2. Wheels on my mod rovers are still blocked.

Hm-m-m... setting colliders to layer 26... will it help?  

-----------------------------

Checked: Changed all MRR colliders to layer 26 and tested ingame.  

1. It "works". Wheels are not blocked and steer normally.
2. Any parts put on surface of rover close to bottom still DO block wheels despite being visually far from any part of wheel.
3. After "return to vab" colliders are nonfunctional, making any further surface attachments impossible .

Conclusion: this method is unsuitable, wheels are still broken.

P.S. Did anyone post this nuisance in a bugtracker? 

Edited May 2, 2016 by Dr. Jet

[nli2work]

it's a Unity issue, something Squad can only work around, which is the reason we have the clip detection. Till Unity fixes the problem or Squad switches to a Unity version where this is fixed, all we can do is adjust wheel/vehicle designs to minimize blocking.

There's a setting in ModuleWheelBase called clipObject = , point this to a mesh in the wheel part, a semi-transparent sphere centered on the wheel collider for example, to provide a guide for players. The clipObject is destroyed once wheelCollider hits the ground, after vessel is loaded. It's probably meant for debug uses, and looks kinda crappy when the vehicle first spawns, but better than nothing.

[Dr. Jet]

12 hours ago, nli2work said:

it's a Unity issue, something Squad can only work around, which is the reason we have the clip detection. Till Unity fixes the problem or Squad switches to a Unity version where this is fixed, all we can do is adjust wheel/vehicle designs to minimize blocking.

There's a setting in ModuleWheelBase called clipObject = , point this to a mesh in the wheel part, a semi-transparent sphere centered on the wheel collider for example, to provide a guide for players. The clipObject is destroyed once wheelCollider hits the ground, after vessel is loaded. It's probably meant for debug uses, and looks kinda crappy when the vehicle first spawns, but better than nothing.

Well, i don't have a trouble with MY wheels, as I didn't release any for 1.1.x. I have trouble with STOCK wheels.

From Blender/mu importer I'd say TR 2L wheel's two "wheel/collisionEnhancer"s (why they need TWO?) are badly misplaced. Spherical one is too "inside" and cylindrical one is too "outside", neither one matching with actual wheel mesh.

Edited May 3, 2016 by Dr. Jet
checked in blender/mu importer

[nli2work]

that's an odd one alright. might be part of the issue with that specific part. 

Edited June 4, 2016 by nli2work

[Fwiffo]

On 5/2/2016 at 9:31 PM, Dr. Jet said:

Well, i don't have a trouble with MY wheels, as I didn't release any for 1.1.x. I have trouble with STOCK wheels.

From Blender/mu importer I'd say TR 2L wheel's two "wheel/collisionEnhancer"s (why they need TWO?) are badly misplaced. Spherical one is too "inside" and cylindrical one is too "outside", neither one matching with actual wheel mesh.

Thanks for that excellent screenshot.  Holy smokes do those colliders ever look misplaced!  Maybe that explains why I have so much trouble placing the TR-2L's, and why they keep saying "Inoperative" even though there's lots of clearance around the wheels.  Has anyone released a fixed cfg / mu for the part?  (@Claw This sounds like a great thing for the Stock Bug Fix Modules mod).  Is there an issue opened with Squad?

 

[Dr. Jet]

13 hours ago, Fwiffo said:

Thanks for that excellent screenshot.  Holy smokes do those colliders ever look misplaced!  Maybe that explains why I have so much trouble placing the TR-2L's, and why they keep saying "Inoperative" even though there's lots of clearance around the wheels.  Has anyone released a fixed cfg / mu for the part?  (@Claw This sounds like a great thing for the Stock Bug Fix Modules mod).  Is there an issue opened with Squad?

 

It can't be fixed in config. And .mu... it belongs to Squad and Squad should fix it.

BTW, ingame proof that trouble do exist. Small addon shows physical colliders where they are.

Re-checked. Version 1.1.3 still has that sh*t for a wheel model. 

Edited July 14, 2016 by Dr. Jet

[Jon144]

This is the dumbest thing in the game. It is impossible to build anything that looks good without wheels being blocked. The old wheels were better because you could actually build cool things with them. Now 9/10 rover wheels just wont work.

[AmenRa]

I am very disappointed that the wheels no longer function in V1.1.3. Some or all are BLOCKED. When they do work and I restore the came - BLOCKED. Very aggravating.