lo-fi

Best guess is definitely repulsors hitting those launch clamps, particularly those at the rear. If power is an issue you'd get an entry in the F2 log saying retracting do to low power. This does happen of a joint breaks in the craft sometimes, so worth double checking Cool, please post us a link when you've got the gremlins ironed out Hmmm, I see...

I think this may be your answer, Trollkowski Also, try setting the hover height on the repulsors low for launch, then crank up via action group once it's all going nicely. I've got some fixes in the next version which will make it all a bit easier and smoother. Looks cool, though! Any plans for a video?

Here we go again Wings this time! Haha. Swing wings? I don't really see why the deflectionLiftCoeff and AoA drag in ModuleLiftingSurface couldn't be changed on the fly by a little plugin which also triggers the animation, though I may be missing something. You mean like a sort of Z joint? Sketchup doodle?

Actually, this is the first time I heard of it. It seems like a cool idea, I'll have to find out how to go about getting included.

It doesn't stop there... I'll have a demo thrashed out shortly if it all works out.

What I'm actually going to do is make separate steering components you can mount wheels or tracks to, the same as you're doing with IR. The difference will be no IR dependency and the steering will mimic the current method exactly for control input and proportionality. If what I'm testing currently works, it'll be a complete game changer for how attached parts behave in KSP, but it's early days yet. The joints are all new to me, and I have to learn how to use config nodes properly, so this will be a slow burn - I hope you're up for lots of testing, it's going to need it Cheers dude, I'm having a blast! I know it looks like I'm going way of scope sometimes, but the more I cover the more cool stuff I realise I can do. It's a pretty cool journey to be on. Thanks for sticking with it

That's cool, just thought I'd forewarn just in case. Haha! Yes, it kinda does. I'm off to make some Kerbalised T72 tracks...

All you can really say is 'wow'! Looking amazing, Spanner, will give it a whirl shortly You clearly had a lot of KF stuff scattered around a save, Gaalidas

Oh, I see! Hadn't quite understood what was going on there, that makes more sense. Thanks for the explanation

This seems so absurdly simple I'm almost embarrassed to suggest it (particularly given the amount of help you've given me with my code), but... will masterNode.RemoveNode(nList.ToString()); work? I don't know enough about confignodes to test it myself I'm afraid, I'm still a little baffled by them beyond grabbing stuff out of config files. Apologies if that's a complete waste of a post, it may have been so obvious you didn't mention having tried it

Revenge is sweet Originally, I wrote it purely to drive tracks.. Then I realised it would drive wheels just as well, learned some more C# tricks (I am a programming newbie, don't forget) and it just sort of carried on from there before I renamed it. I suppose I should have done so before the 1.7 release, but there's not a lot I can do about that now! Anyone tested the repulsors with the new water collider method, btw?

The latest dev commit will probably not break saves, but it will lose settings from saved craft and craft in flight. Sorry about that guys, a refactor which included the module names was long overdue. Seeing as I started the track modules now run wheels and the screws, it seemed a little odd being called ModuleTrack! Sadly as the module names no longer match those in the persistence file, the values will be discarded and defaults set. If you've got anything that matters in a save, I suggest running a find and replace for the following: ModuleTrack > KFModuleWheel TrackWheel > KFWheel The config and persistence fields are the same, so all should be good if you do that. Sorry, should be the last time now! New steering module and a new type of track I've been unable to make up until now will land in dev shortly.

Perfect explanation

True; I'd be kidding myself.. Version complete it will be! Hehe. Sorry about that, I'm hoping to get some major releases out before too long! Yep, that's what I think I can use to fix the current issue with TS. I need to review the docs in depth, but I'm sure you're right

I honestly can't remember! It's a topological trick though, rather than something plugin specific, so will be the same if you use KF, FS or stock. I've been playing with this sort of stuff extensively doing crazy things for my wheels and tracks, so I've got fairly good at pushing the tools to do things you wouldn't necessarily think they could do. I don't have massive experience with FS, but usually not working at all means it's got its knickers in a twist about a named GO not being present or something like that. IIRC, the error handling in FS is good enough to disable the module, rather than spew ugly null-ref spam over the log. Feel free to send the part over though and I'll see what's going on. Is the swing beam really not movable? Looked like it was designed to follow the angle of the runway against the plane to save overloading the rear wheel. I suppose they're pseudo-technical concept drawings you're working from though, so the guy that drew them may have been an artist not an engineer and anything is possible. Annoyingly, that actually makes it more difficult! I'll have to think on that one...

Good stuff! What I did was this: configured the central collider to support the full weight the leg needs to take. The rear collider I configured with a very soft spring. You don't want it supporting weight, it's there to drive movement of a gameobject which the swing arm points towards. The swing arm Z axis is aligned to the right in that view, so as the suspension GO of the rear wheel gets moved the swing arm follows. No mesh attached to the rear GO, it's just there to derive the swing arm angle via the LookAt. It's what I used to set this up: You can play with placement and setting to derive the particular motion you want, which is probably a little different to the 747.

Have a look through output_log for the entry where KSP is trying to load the part (or preferably post the log). I've had a few gotcha's with PartTools exporting stuff KSP won't actually read, but the log will tell. It's frustrating, I know!

From what I remember of the FS code, you're not going to get away with that. Nor with the stock module. What's happening is this: The wheels are parsed into lists of wheel colliders and suspension components. The code runs through the lists moving the named suspension gameobjects the correct amount after reading the corresponding suspension compression modelled by the wheel collider raycast. This happens sequentially every frame, so your one suspension GO is getting moved initially by the first set of definitions in the list, then another amount by the second (this should explain the offset). You're thinking it will average the two, which it will not do (though I like your thinking!). Details may vary, but that's it roughly. The only option you've got (without writing a bunch of code to reinvent the wheel) is to use the trick with the collider placed right under the strut to model its movement, then create the illusion that the swing beam works by using a second wheel collider at the rear with a LookAt moving it. You don't have to have the rear set hanging lower than the front if you don't want that particular setup. I know it doesn't seem 'right', but it's easy and effective. I posted a couple of screen grabs somewhere, though I can't remember where... BTW, there are some tricks you can use with the LookAt controllers which may help if they decide to go a bit weird like they were for nli2work on the torque arms, but hopefully all is well on that front. Looks good though, and glad you got the bendy joints nailed.

I don't remember any steering problems mentioned (I probably missed it)? The maxRPM fix I've explained, and there is not a nice little RPM readout in the GUI menu which is useful if you go want to go config bashing. I've not even tried TS on a wheel myself, so I'll get back to you on that one.. The medium wheel is deprecated and replaced in whole by the converting wheel model. Both are still in the repo as I'm using the converting version to hack about still before completely merging the two. I'd suggest deleting the whole folder and unpacking again, it sounds like you've got some things in a muddle after the recent reorganisation. Yes and no. As with the stock or ASET, the plugin will now drive just about any wheel if you set up the config and know a few GO names and orientations, and I've written a module to override any wheel collider settings backed into parts the same as FireSpitter does. However, IIRC, TT added some modules which hack about with ModuleWheel (stock), which won't work my the KF plugin so you'd have to lose those features. There's a little more wizardry with the mud guards and stuff like that that may still work, but I've got no idea how that works without doing a little code diving. I think the short answer is yes if you want the KF features rather than TT's. I'll be honest, I'm not a fan of the engine/driveshaft thing, so not a route I'll be taking myself. Though I do really like the toggleable arches, so that may appear as a feature at some point...

I think you can use effects modules for particle emitters, so that might be possible. I do have it set fairly quiet, I didn't want it have the droning get too annoying. Maybe a little too quiet..

That's cool! I'm about to break everything one last change to modularise the plugin further and enable an alternative method of steering like that. Blame Spanner, he gave me the idea The only other thing I want to do with it will be adding more sounds for acceleration, braking and sliding, then I think its safe to say 'feature complete', document and leave it be.

You can change from the default using chargeConsumptionRate in the .cfg it defaults in the code, but can be overridden this way. Still can't wait for this, Spanner! You're welcome mate! Got a few updates and loose ends to tidy up, then I'm going to have a look at proper TweakScale support for all the parts. The issue someone (might have been you, Madrias?) had with the suspension not working right is caused by my recent changes in the way the suspension is handled. Previous, it was done by moving the suspensionTraverse object using transform.localposition. This is all well and good, but counter intuitive because it moves in the local axis of the parent, not the object itself. It's also affected by the scale of the parent object. Ah-ha, you might be thinking! Ideal for TweakScale. Yes, but also made it a nightmare to get things exported, into Unity and out as a part, all with scale 1, and without breaking the prefab model connection while rigging in Unity. Also limited suspension movement somewhat, so I've changed to using transform.translate which does work on the local axis of the named suspensionTraverse object, but it not affected by scale. TS will be broken for all wheels and tracks until further notice as I need make a little code change and configure TS to change a value in my module to make it work. This is why the wheels were stuck in the ground when scaled down. the suspension travel of the collider has been scaled, but the movement of the susTrav object in local space is not, and this is what needs to be addressed.

Agreed! Can't wait to get my hands on that Good work, Spanner! Side exit hatch is awesome, love it. Darren, thanks for showing off the parts in such style. Superbly produced, as usual with your vids Jeb and the Sugar Plum fairy is still my favourite, though. Got it, Madrias. Will see what I can come up with, I like that idea. Keep em coming! I'll reply more fully and to everyone else when I've bacon'd my way out of this hangover...

@Madrias: cheers buddy, means a lot. Pleasure having you aboard! I'll reply more fully later (about to walk over to the village pub for a few beers), but if you find Blender hard - it drives me to 28 Days Later levels of rage whenever I try to use it - I'd suggest Sketchup. It's really quick and intuitive, so for producing 3D concept art it's absolutely ideal. I like your idea for the cockpit, it could also fit well with the rover body theme Spanner and I have going. I kinda have a vision of a Kerbal sat in a little bubble canopy almost burried up to his eyes a little like R2-D2 in the back of an X-wing. Keen to see exactly what you have in mind, though. I'm sure Spanner will appreciate the comments about the DSR Another version is incoming with a few little fixes that's even better! Justin is quietly busy texturing the small tracks and wheels, so I'm looking forward to seeing them finished.

But I need sugar, damnit, SUGAR! Sorry, I may have had too much coffee...