[Plugin] 747-Style Landing Gear (Advanced Animatronic Landing Gear plugin)

[OrbitusII]

Major breakthrough!

Unfortunately I can't recreate it (it seems to be a thing when loading the vessel from the Tracking Station directly after a restart of KSP), so there's that...

@lo-fi: It says your inbox here on the forums is full, so I can't send this to you in a message:

calling _wheel.enabled = true causes the issues with the wobbling AND the crash on revert, so I'm not using that bit of code. It doesn't seem to affect the operation at all besides screwing it up. I'll keep looking at it though.

[lo-fi]

Sorry, just cleared my inbox. Stupid limit!

Its sitting on the mesh collider on the wheels (remove). You're not going to get very far unless the wheelcolliders are enabled, crash or no I'm afraid.

Once the mesh collider is out of the way, its somehow sitting on the transforms of any gameobjects below the wheelcollider, CONTACT included, which is really bad news for your implementation. I have no idea how as those objects don't have colliders of any kind, but that's definitely what's going on :/

Edit. The wabbling was caused by grip settings: Usual Asymptote grip value is half Extremum grip - I got that one sorted early on.

Edited August 9, 2014 by lo-fi

[OrbitusII]

By experimenting some more I was able to determine that the launchpad and runway are the only two objects in the entire stock KSC that cause the issues. Something about them causes the brakes on the gear to go to infinity and screws with the suspension. I'm going to take a random guess that it's the physicsmaterials on those colliders, but unless I talk to the devs I can't be sure.

[lo-fi]

In all the reading I've done, Unity wheelcolliders ignore physics materials, which is why you have to script in changes in grip. Weird, weird behaviour! You're not calling anything stock that's wheel related either, which makes it even more weird. Having said that, your suspension code runs its own raycast. Add in a print(_wheel.rpm) line into OnUpdate and see what you get. If zero (or nullref) you're onto a false positive...

I'm just musing, be interested to see what that comes up with.

[OrbitusII]

Added the rpm printing in to see what it tells. Results:

-RPMs are only zero when the brakes are on, except when on the runway in which case random gear have their RPMs go to zero after the brakes are turned off.

-When on the runway with brakes off, no zero-RPM wheels, and the gear deployed the RPMs for random gear bounce between two values. The gear with the bouncing values are also the ones that twitch like insect legs. This happens consistently and starts spontaneously.

-Retracting the gear on the runway solves the twitching, but the vessel keeps floating as if it is still resting on the wheels. Wheels keep spinning which is ok.

[lo-fi]

Interesting results! OK, so it's definitely sitting some something other than what we want it to, which seemed to be those transforms. I can't currently see a good way around that, I have to admit.

[OrbitusII]

I'm testing it out with the collision enhancer disabled. I know it's required for stock wheels but here it might be superfluous. *fingers crossed*

Edit: Alas, removing the collision enhancer did not solve the problems. It even caused the game to crash on revert to SPH!

[lo-fi]

I'd abandon it entirely here, it's not needed here. None-the-less, it gets folded away when the retract happens, so it's not the collision enhancer it ends up sitting on...

[OrbitusII]

I'd abandon it entirely here, it's not needed here. None-the-less, it gets folded away when the retract happens, so it's not the collision enhancer it ends up sitting on...

Yeah, it turns out that reverting to SPH after loading a ship with these landing gear directly from the runway causes a crash, collision enhancer or not.

Edit: My bad, when testing I simply disabled the collision enhancer for export. Deleting it entirely actually made the game more stable (I just loaded back into the SPH after a load from runway)

Edited August 10, 2014 by OrbitusII

[lo-fi]

I found it would let me revert sometimes and not others, with no clear reason why or not. Log just shows CRASH!!

[OrbitusII]

I found it would let me revert sometimes and not others, with no clear reason why or not. Log just shows CRASH!!

Running through the error logs, it says that there was an access violation. It happens just after unloading a bunch of assets (during the Loading screen between scenes). Interesting? Yes. Helpful? No.

[Gaalidas]

Daaang... and I thought passing algebra was hard. while I understood everything that's been discussed on the last few pages, I really do not have the mental capacity to make any sense of it. Why do I torture myself by reading it still? The world may never know...

[OrbitusII]

Don't worry, when we figure it out (and if we determine what the underlying problem was) I'll explain it as simply as possible. On the subject of math, I think Calculus is a lot easier than Algebra once you get a handle on the basics, so keep working through those classes and know that even in programming mods for KSP math plays a pretty key role. Real world applications are not hard to find if you look.

[lo-fi]

So I had an idea myself for how to implement this, took me a few hours last night:

Don't mean to tread on your toes, just thought I'd share. This is using part of my forthcoming open-source ModuleWheel (just normal stuff to map the suspension movement to the mesh, rotate wheels, steering etc.), what you might call a 'standard' KSP wheel or landing gear hierarchy in Unity (well understood and very easy IMHO) and an FXModuleLookAtConstraint called in the .cfg. No animations were used in the making of this production (though one is still needed to animate the retract process as usual).

I've not actually bothered to make the wheelmesh rotate for the demo, but this is trivial. The tyres will even spin up when each individual set hits the ground, and the swing arm will also follow changes in the angle of the aircraft against the runway

Apologies for abusing the mesh, CK! Rigging the actual main gear model this way would now be incredibly simple. Nose gear is working too.

Thoughts?

[CaptainKipard]

Apologies for abusing the mesh, CK!

Unlike some people (and if you're reading this, you know who you are) I'm happy to have my work used for something constructive.

Actually I'm seriously considering releasing all the source files for my mods. I'm not sure yet, but I'm leaning there.

[lo-fi]

Unlike some people (and if you're reading this, you know who you are) I'm happy to have my work used for something constructive.

Actually I'm seriously considering releasing all the source files for my mods. I'm not sure yet, but I'm leaning there.

Thank you, I appreciate it Is your main gear model available please? I'll have my gear module working this afternoon, would be cool to test with the actual models and I'll package it all up to pass back.

I'm going to open source everything once I've got to full release phase with my parts and I'll be encouraging more people to do the same! We've got some really good knowledge sharing going on at the moment, I want to keep that going.

[OrbitusII]

Don't worry about it, our techniques for achieving the functionality is different enough to be distinguishable, especially during part setup in Unity.

I do have to ask you what the wheels in your module are doing differently, or is there virtually no difference between our operation? Having some sort of idea about what might be different between my code and something that works might help solve that critical bug.

[lo-fi]

I've cheated a little bit, I use two wheelcolliders. One is placed directly at the end of the suspension strut and this governs the movement of the strut via a gameobject called (by convention) SuspensionTraverse.

There is a second wheelcollider that's placed behind the first, with double the suspension travel and above by half that travel. This has a SuspensionTraverse2 object that's moved by the code as usual, except this one moves no mesh directly. It moves the swingarm via a lookat to SuspensionTraverse2.

The first collider governs the rotation of the front wheels mesh, the second the rear. The rear collider has much lighter springing than the primary, as the weight should be carried by the central collider, which is simulating all the wheels being on the ground, and thus compressing the suspension proper.

I figured if we both attack it from different angles the least we gain is a better understanding. Code is in my dev repo (did I give you access already?), though being updated fast with wheel rotation, steering, animation etc. and I'll pass back rigged models when I've finished messing about. I've learned a lot doing this, I have piles of notes to put in my advanced rigging tutorial, as well as some stuff I can use to improve my existing modules

I removed most of the superfluous mesh for clarity, will bung back in when I'm done testing.

Edit: to answer your question about what's different with the colliders: Nothing, except I have no transforms below them. Testing with your module revealed a few things:

The colliders calculate rotation, even if it's not them holding the model off the ground (or they're not actually enabled). The clues are: Brakes. Call the braketorque to the log and you'll see the brakes are not being applied even when the model seems glued to the runway.

Rotating the wheelcolliders away from the floor leaves the part firmly planted on the floor (though now appearing to float). This is a dead give-away, which lead me to messing with transform placement in the model. I can get the colliders to do their job correctly so long as there are no transforms below their level in the part and they are enabled. I came to the firm conclusion that it's not a collider issue, but a topology issue I'm afraid. At very least, the tranform position of the master parts needs fixing (this is easy), but your CONTACT object also causes the issue and this seemed instrumental to your simulation working as it stands.

I'm puzzled why you've got a separate raycast when you can use the racast from the collider, though? This might be a potential solution as (I think) you could do away with your CONTACT object and all will be good in the world. I could well be missing something fundamental, though

Edited August 10, 2014 by lo-fi

[CaptainKipard]

Is your main gear model available please?

Not right this moment. If you want I can give it to you in the current state, just keep in mind it's modelled with a compressed shock absorber as default. I'll upload it as soon as I separate it into its components.

This would be a good moment to ask whether you want the axle beam hydraulics separate so that you can animate them dynamically in KSP. I hadn't planned on that but OrbitusII's plugin might make that possible.

[OrbitusII]

Pretty cool stuff there, lo-fi! So the wheel colliders are made unhappy by not being last in the hierarchy, huh? I'll check that out with my stuff.

Edit: I kinda expected it, but the hierarchy order isn't the problem. It's something about the runway and launchpad. Gonna start pulling code out of the plugin until I get it working fine

Edit 2: No idea what's going on. I'm removing every bit of code to see how it works as just a plain old wheel collider.

Edit 3: Aaaaaaand of course the wheels are still rooted to the runway. Removing every collider except for the wheel, Bounds, and a collider to allow for interfacing (although at this point I don't know why I bother)

Edited August 10, 2014 by OrbitusII

[OrbitusII]

Ok, at this point I am completely and utterly stuck with no hope of moving forward, much like the cursed landing gear. I'm going to contact Squad (probably Mu or HarvesteR themselves) and ask them what the heck is up with the runway compared to the terrain and other parts of KSC when their work week starts again tomorrow. I've stripped down my code to the bone, even removed it from the config file to let the wheel roll around without any code messing with it and still no success. Until I can get this figured out I'm going to leave the code alone.

This does not mean that I am abandoning the project, I am only going to take a break from it because without more info, no progress can be made. I'll post a link to the current part, .dll, and source code in the OP shortly so that anyone can take a look at it to see what the problem could be.

[lo-fi]

Not right this moment. If you want I can give it to you in the current state, just keep in mind it's modelled with a compressed shock absorber as default. I'll upload it as soon as I separate it into its components.

This would be a good moment to ask whether you want the axle beam hydraulics separate so that you can animate them dynamically in KSP. I hadn't planned on that but OrbitusII's plugin might make that possible.

Feel free to send me a link as-is, be good to have something to work with. I can probably set up either way though, so you might as well model up in your preferred layout even if you send that later on and I re-rig it Suspension compressed is always the best way to start with it in Unity anyway, so that's a bonus.

I'll continue in your Skylon thread to save cluttering Orbitus' with something that's not directly related.

Pretty cool stuff there, lo-fi! So the wheel colliders are made unhappy by not being last in the hierarchy, huh? I'll check that out with my stuff.

Edit: I kinda expected it, but the hierarchy order isn't the problem. It's something about the runway and launchpad. Gonna start pulling code out of the plugin until I get it working fine

Edit 2: No idea what's going on. I'm removing every bit of code to see how it works as just a plain old wheel collider.

Edit 3: Aaaaaaand of course the wheels are still rooted to the runway. Removing every collider except for the wheel, Bounds, and a collider to allow for interfacing (although at this point I don't know why I bother)

Haha. Yes, it made them sad Sorry, I may not have explained very clearly: It's not the wheelcolliders that are the problem, or their hierarchical position. You'll find if you remove the wheelcolliders you will still have the same issue(!). The problem you've got is caused by positions of GameObjects (or tranaforms as you like) in the part, not their hierarchy or anything going on in your code. When I say underneath, I mean below in the Y axis! That's what's getting stuck on the runway. And thanks We've got some good momentum going at the moment with the wheel research, even if it's insanely frustrating at times!

Ok, at this point I am completely and utterly stuck with no hope of moving forward, much like the cursed landing gear. I'm going to contact Squad (probably Mu or HarvesteR themselves) and ask them what the heck is up with the runway compared to the terrain and other parts of KSC when their work week starts again tomorrow. I've stripped down my code to the bone, even removed it from the config file to let the wheel roll around without any code messing with it and still no success. Until I can get this figured out I'm going to leave the code alone.

This does not mean that I am abandoning the project, I am only going to take a break from it because without more info, no progress can be made. I'll post a link to the current part, .dll, and source code in the OP shortly so that anyone can take a look at it to see what the problem could be.

See above. I've identified the problem, I'm just not sure I can fix it without stripping it right back to the start. The runway seems to have a different physics material (which wheelcolliders ignore anyway - another clue). Off the runway, the troublesome GO's drop through the terrain and the part is left supported on the good-old mesh colliders in the legs (or the wheel mesh if you left that in). I spent hours playing about last night before I had the idea for my alternative method, and I've been through a lot of this with the rover wheels - though some of this is new and very interesting information, much as it's causing you severe aggravation!!

[OrbitusII]

Feel free to send me a link as-is, be good to have something to work with. I can probably set up either way though, so you might as well model up in your preferred layout even if you send that later on and I re-rig it Suspension compressed is always the best way to start with it in Unity anyway, so that's a bonus.

I'll continue in your Skylon thread to save cluttering Orbitus' with something that's not directly related.

Haha. Yes, it made them sad Sorry, I may not have explained very clearly: It's not the wheelcolliders that are the problem, or their hierarchical position. You'll find if you remove the wheelcolliders you will still have the same issue(!). The problem you've got is caused by positions of GameObjects (or tranaforms as you like) in the part, not their hierarchy or anything going on in your code. When I say underneath, I mean below in the Y axis! That's what's getting stuck on the runway. And thanks We've got some good momentum going at the moment with the wheel research, even if it's insanely frustrating at times!

See above. I've identified the problem, I'm just not sure I can fix it without stripping it right back to the start. The runway seems to have a different physics material (which wheelcolliders ignore anyway - another clue). Off the runway, the troublesome GO's drop through the terrain and the part is left supported on the good-old mesh colliders in the legs (or the wheel mesh if you left that in). I spent hours playing about last night before I had the idea for my alternative method, and I've been through a lot of this with the rover wheels - though some of this is new and very interesting information, much as it's causing you severe aggravation!!

That's really strange... In any case, I'm at least done working on it for today. It's caused me a lot of stress over the past 2 days so I'd like to take a break from it for at least 24 hours before I mess with it again.

[lo-fi]

I don't blame you! I did the same myself before tackling the animation stuff - I went out to the workshop and overhauled a carburetor this afternoon.

I hope my research at least gets you heading in the right direction

Such is the way with ambitious projects, but it wouldn't be fun if it was easy, would it

[OrbitusII]

I don't blame you! I did the same myself before tackling the animation stuff - I went out to the workshop and overhauled a carburetor this afternoon.

I hope my research at least gets you heading in the right direction

Such is the way with ambitious projects, but it wouldn't be fun if it was easy, would it

Of course not! I'm already enjoying my break and experimenting with ambient occlusion for texturing models. Never idle, this one.

What I cranked out over about an hour is on page two of this thread. Needs more detail on it but I'm liking it so far. I don't know if I'll ever make it an actual, complete mod pack but I can work really fast if I care to.