TouhouTorpedo

If W_L and W_R are your wheel meshes they need to be under Wheel or they won't turn with it. then its fine and you can export.

I haven't played this in ages, I started with one of the earlier releases. Sounds like a lot of the really interesting and long overdue features are finally going in.

Annoyingly, thats exactly what I did! It sounds like your GPS was cutting out as they are pre-programmed to do. (legal restrictions on their operation) although you was far below cut off speeds and altitudes, they can be a bit variable and some cut off much much sooner. Alternatively, might have been knocked out by shock on engine cutoff/drogue deploy. It'd be a good idea to test the performance of a few modules. Still, I'm suprised you didn't use the IMU telemetry for tracking position instead of the GPS (or at least thats what it sounds like was being done with the voice over on the launch), which off the shelf modules tend to be unreliable in extreme conditions. If the IMU is capable of guiding the rocket, I'd expect the accuracy to be sufficent to track it. (aircraft all used to be guided this way) Great to see another Peter Madsen engine, I love his work. Also props to your guidance control computer designer for getting it to go in the direction it was supposed to be going! (though I'd have done the tracking differently) I think you guys are gonna have to really rethink your recovery techniques though. Heat1X didn't deploy, Sapphire did not appear to deploy, and LES test didn't give enough time to see how it would have behaved (but did seem to work). Think your next test needs to be a quick and dirty parachute experiment. Also consider fitting an alternate, different parachute redundancy, so they can't fail in the same method. EDIT: Hearing from a few more people on the youtube (probably danish speakers) It sounds like it was a telemetry error, where the altitude was slated to be increasing when the rocket was falling. A timer or static pressure sensors could be potential ways to prevent this occuring again. Hopefully a lot of lessons have been learnt aside from checking the guidance!

Bigger engines are planned in a later release, or you can just edit the cfg's of the ones you have and increase the MaxEngineTorque property in the meantime. I didn't want to hold back a release on a part that'd be handy, but not really absolutely neccesary to the functionality, when I could get a lot of feedback on how the mod runs in the meantime. - which I'm getting here! I'll add a bigger engine next release sure. Hang on, are you saying that pre-mechjeb 2 versions and infernal robotics can be installed without interfereing with each other? I find that highly suprising if so, as I'd expect their modules to clash. Starting to consider an update to the current release removing those hinges, and placing them in their own download. Seem to cause a lot of hassles for people when they're there for convienience if people have the stuff to get them working - I didn't expect so many old mechjeb users out there.

Oh hang on, I misread a post. Derped.

WheelCollider needs to be wheelCollider. the modules are all case sensetive.

It doesn't do that yet. The actual behavior is pretty variable on the vessle though. Torque outputs per cylinder are as follows: Electric - 16 RCS - 32 LiquidFuel - 48 what that translates to depends highly on your vessel mass, what wheels you use, and how much fuel you took with you. Also, Updated the OP with some notes in bold on installing process, including a link to the forum post on Infernal Robotics, which puts the loose hinges back in again (as well as the damned robotics parts, but I only installed the plugin myself). I would not recommend running Infernal Robotics with pre 2.0 mechjeb versions. If you insist on earlier mechjebs in 0.20, then any robotics parts are not going to work properly as far as I am aware. You can just delete the DRBallBearing and TTDRhingemod folders though without any ill effect on the wheel side of the mod, if neccesary.

Not exactly correct. The unofficially updated Infernal Robotics DOES work in legacy. I am running it myself.

Alright, the other alternative then is delete DRBallBearing and TTDRHinge. Those two are what cause the problem if the user has an older mechjeb.

go into plugins folder, and if you have any of the following TTModularWheel, TTOmniWheel, TTGraphicFlipModule, TTLiftRamModule - Delete them. They are part of Multiwheels 0.5. Also if you have an older Mumech.dll from mechjeb's prior to 2.0 version, I recommend these are also removed.

Technically you can already do this. The Dual Wheel pod retracts somewhat like stock gear do, and uses an electric engine built in it now. (so its no longer using magic cheat power) if you was interested in it using Liquid Fuel, you can turn off the built in engine in the CFG, or infact just add a Liquid Fuel Modular Wheels Engine - that will add extra power to any Modular MultiWheels powered landing gear attached. Sorry no, no idea. I've resized the wheels before when messing around. If you do succeed though, be aware you may need to adjust the contactdisplacement variable in the CFG, to ensure ground contact visually.

None of them are wrappered with PART{}, because I wasn't using it. A problem with doing what you're suggesting though is the end user is going to have to move the files themselves as well, and given theres already been one CFG update since release, I don't think its a good idea. If people are desperate to change it to the new system, it can be done simply like you said, if the user knows how. If they don't, they're best off installing as per the instructions say- by just unzipping in the KSP root. EDIT : Thanks for asking though rather than just outright posting a link. I appreciate you're just looking to do good, but I think it'd just end up causing confusion.

Quick update already, was an error in the cfg of two wheels that made them not look right. Thats fixed now. v0.6.1 fixed a missing line in CFG for noarchwheel_S and noarchwheel_ms EDIT: hmm, that should've been 0.6.0.1, but i've already uploaded it with that in the readme now. oh well!

JUST RELEASED - MULTIWHEELS 0.6 adding new rover/car size wheels, and a selection of engine types. 0.6 changes the way the mod behaves, and now wheels must be powered by an engine. You don't need to physically connect wheels to an engine, but you will need to get fuel to the engine in the case of a LiquidFuel engine. You can use RCS, or even electricity in some cases. Landing Gear wheels come with an electric motor that consumes power, but they can have supplimental power from other engines. Heavy vehicles will now act like heavy vehicles. Multiwheels on lower gravity planets will grip better! http://kerbalspaceprogram.com/modular-multiwheels-and-omniwheels-v0-6-tt-plugin-for-ksp-0-20-and-0-19/ IMPORTANT NOTE - YOU MUST DELETE THE PLUGIN FILES FROM MULTIWHEELS 0.5 TO INSTALL THIS. changes: v0.6 Fixed sticky wheels - no longer have to wobble things to life. Made new gravity compensation system. Wheel friction increases on low gravity planets/decreases on high gravity planets Made new timewarp compensation system. Added Engines - three types, Liquid Fuel, RCS and Electric. Added new Car Wheels - smaller, lighter wheels for small rovers. Added config system - you can turn "cheatwheels" mode on and off, and configure the low gravity and time warp compensation.

You've still not done what I suggested, either about putting the animation above everything in a new game object - you've also got quite a lot of stuff in the wrong place now. Make this your heirarchy Port >CenterFlap1 >CenterFlap2 >GearBox >OuterFlap1 >OuterFlap2 >Retract (ANIMATION MUST BE ON THIS ONE) >>wheelCollider (WHEEL COLLIDER GAME OBJECT HERE, NO MODEL) >>suspensionParent >>>Wheel (BLANK GAME OBJECT, NO MODEL, NO COLLIDER) >>>>wheelmodel1 (MODEL, NO COLLIDERS) >>>>wheelmodel2 (MODEL, NO COLLIDERS) Next screenshot you do if it doesn't work ensure you are showing exactly that heirarchy.

No, there should be no animation of the wheel rotating. Remove that. What you needed was an animation to retract the wheel, or placed where you would have placed it if you did want it to retract. (what the animation actually contains doesn't matter, but absolutely do NOT animate suspensionParent, Wheel or wheelCollider. Animating a parent of these in the heirarchy is fine) Did you reduce the wheel mass like I said to do by the way, so the brakes might work?

Makes sense. I find a good chunk of my load time is sitting on the stock IVA's loading. Updating these to PNG/TGA really needs to be made a higher priority, or at least updating the proprietary format to have compression.

No but it doesn't have to. Thats what all the past few pages were argueing about. It works just fine in 0.20.2 without using the new system, thats where I've been doing the Multiwheels 0.6 development. Maybe I'll update it since its being requested so much, but I'm disapointed it would have to be done since that breaks backcompatability with a still supported version...

why does the wheel have an animation? applied? quite sure that isn't right. Something I do I think you may be missing is having the animation applied to one game object, that is parent to the suspensionParent. Then set your animation on that game object only, and be sure that animation name exactly what you tell it to use.

I'd like to see Mohawk McCool Rad Science Dude land a rover on Duna with KAS.

Ah wait, I think it could be wheel mass. go to your wheelcollider and reduce the wheelmass property to about 0.1 that might resolve the no brakes problem.

Yes, if you hit it hard enough. Its just another fuel tank like any other. You can use any Liquid Fuel tank with the Fuel Engines also. I'm probably going to scale the Truck fuel tanks down just a bit, as I think they are a bit too big in appearance at the moment. The Car fuel tank is just right though. Might be tempted to make a small motorbike style tank for smaller nippier vehicles, and the weight of all wheels I'm probably going to reduce, since theres engines now (the weight of these I might put up).

Todays updates : Fixed a few old bugs regarding lagging C of G and contact points * Made the speed the wheels give dependant on the mass - sounds obvious, but not if you use unity wheel colliders! * Tweaking and balancing the small engine to be lots of fun on very small rovers (50m/s acheivable), but utterly inadequete for a 40 ton lorry (barely 10 m/s) * wheeltorque now inversely proportional to the root of the speed - Done this instead of directly inverse proportional because it behaves a lot better at low speed, and still allows reasonable top end and acceleration. This also makes it feel a lot more dynamic now, if you hit a hill you may slow down quite a bit and have to crawl up it. Added new parts * small car fuel tank * truck fuel tank more teaser screenies: Both of those were running on one cylinder, and thats where I got the speed figures from. The Truck on one cylinder is horribly slow, but still pushes well enough. The atv was pretty good fun, very nippy and pulled little wheelies easy, while being quite controllable. Still to do : Consider adding a dedicated Truck engine. This isn't absolutely neccesary though since 4 to 8 cylinders in a truck of decent mass does just about do the job, but for something extremely heavy thats pushing the part count a bit.

I'll look into a way to change all my mods to a different control method then, it sounds like this current one is only causing problems.

Spoiler Alert : The double axle wheel actually does the same thing! I'd intended to do it that way as a placeholder and lead up to double wheel colliders, but situations where you'd even notice the difference are so rare I didn't do it. Although if I did code it up to work with double colliders, it'd at least be more stable. The other option would be a Left/Right disabling code, just like I've done with the trailer wheels, so you can make them more stable on one side than the other. ...second thoughts thats a good idea. Maybe I'll do that.