EndlessWaves

Yes, to both - although of course feeding negative numbers into a field expecting positive ones isn't guaranteed to work.

The orientation bug is an old problem that's been through several revisions. Changing reference transforms isn't something I'd accounted for though. You should have steering, if you've got no control at all then that's not what I think it is and a craft file would be handy. Try this and see if it fixes it: https://skydrive.live.com/redir?resid=384BA28C8578E539!167&authkey=!ANyeZiLi8juoU5Y The current cruise control implementation is pretty rubbish so I wouldn't be surprised if it had major bugs, I did a quick test with those tracks and it didn't accelerate when it ran out of fuel for me though. It's not capped at the moment, and badly tuned so it may be just the overshoot - how long was it accelerating for?

That's after the model load so that (probably) worked fine, it seems more likely the error is somewhere in your config file. Int32.parse suggests it was looking for a whole number and didn't find it, there aren't many fields in a config that take whole numbers, attachRules perhaps?

I followed the behaviour of the landing gear and rover wheels and had them start enabled, it sounds like you're expecting them to start disabled like a rocket or jet engine. By pressing the motor toggle key on launch you're disabling the motors which is why they're not responding.

Thust is applied to the position of that transform in the direction of it's -Z axis so that definitely determines it. You may have got the reference space wrong, being a transform it does have it's own co-ordinates so you need to use that transform's TransformDirection method rather than the top level part transform's.

http://forum.kerbalspaceprogram.com/showthread.php/35336-Question-about-the-debug-menu I don't know the full extent of what you're doing but yes, you can almost always get the same functionality with PartModule.

Most of them are stored in CheatOptions.

At the same time? That makes troubleshooting harder. What error are you getting in the debug console/output log?

Which version are you compiling against? C# 3.0/ .NET 3.5? R4m0n made one a few months ago but I don't know if he kept it up to date or posted the source anywhere:

It's an error with the new part, have a look for an error message in the console (alt+f2) and output_log.txt (KSP_data folder).

Mechjeb 2 includes a functioning version.

The model is reloaded on each new scene, onEditorUpdate presumably only gets called in the editor so you'll need to call the code in another function that runs in the flight scene if you want to do it there (or save and reapply). I'd consider grabbing just MeshRenderer components rather than all renderers as it's also used for things like LineRenderers and particle effects. Also, it's worth considering if you really need to extend Part. There are callbacks on Part and GameEvents that allow you to create functions that only run in the editor in a PartModule derived class.

That means if follows the general controls used for engines, control surfaces, pod torque, RCS etc. Speed depends on the throttle, keys used to turn depend on how it's oriented relative to the control panel etc. One big advantage is that the tracks should always provide force in the same direction as everything else, so your command pod torque will always assist turning rather than opposing it or trying to tip you over. We started this mod before rovers so this was the original control system, rover mode was a later addition but backwards and forwards keys are handy for testing so it kind of became the default. It could easily be changed for the polished release if people find they prefer general for actual use. The reverse action only works with general control mode, with rover control mode there's a dedicated reverse key so it ignores that. It's not really the most obvious of systems and there's no manual yet, so suggestions on how to improve it would be welcome. Aye, until we get details of how the game manages conflicts between two versions of a plugin I felt it was more sensible to put it in a general place in case other people want to make their own track models, that way at least you know you're overwriting something and there may be a problem rather than multiple copies fighting silently in the background. That's the disadvantage of a modular part system, it doesn't lend itself to co-ordination between parts. There are potential ways to do it though so I've added it to the list of future refinements. They should provide the same torque when going in the same direction whether they're mounted backwards or forwards. Not very realistic but as you say pretty much essential for usability with the game's attachment system. They will go slower if you reverse the direction the vessel is going (i.e. hit the reverse key) but again they'll all provide the same torque regardless of mounting direction.

I doubt it's a vessel but it's perfectly plausible that it's spawned by an event. Did you use Resources.FindObjectOfTypeAll or Object.FindObjectsOfType? If it was the latter then that's only the active objects but the former should have detected it even if it wasn't loaded. Of course, it's plausible it doesn't use a CelestialBody component so it might be worth dumping the orbital component instead (OrbitDriver?).

Adding them should be easy enough, this.Events.Add(new BaseEvent()). The trick would be getting unique behaviour out of them when event functions aren't called with any arguments you can check to determine the name of the calling event. One alternative is to write a PartModule that handles the event and add that instead (part.AddModule), as the adding function returns a reference you can then set which fuel container it should apply to. If it's the same as the persistence file then it would be: string, bool, int, float, Vector2, Vector3, Vector4 or Quaternion and anything that implements iConfigNode. There's no renderer attached to the GameObject that your part-derived class (a component) is attached to, so renderer will return null. You need to grab the renderers from the child objects of the parts of the model that have meshes. You could use FindModelTransform(s) if you know what they're called or FindModelComponent(s) to grab all mesh renderers on the model.

0.20 of the game or 0.20 of the part tools?

Given the stock parts have also moved that may not be the problem. And even if it is, the game is in development and this sort of thing should be expected. The developers shouldn't spend time on backwards compatibility at this point.

HighLogic.fetch.currentGame will give you the current parameters, including the game name.

It should be automatic, if it's not working try adding wheelName = WheelCollider to the ModuleLandingGear section of the config.

I believe a some of the wobble is caused by imprecision rather than actual forces, if you run a search for wobbly joints in the unity engine generally then the solution is usually to turn up the calculation precision rather than rescaling for appropriate forces.

It's not derived from the model, it's explicitly set on the WheelCollider component and stored in the mu file. ModuleWheel doesn't seem to expose an option to change it in the config so you'd have to write a plugin that grabbed the WheelCollider component of interest and changed it.

Game bug/limitation unfortunately, I'm not sure of the exact conditions but basically the node system won't let you make the initial attachment on anything other than one axis, I believe it's the two defined last in the config file. It should be fixed eventually as the stock six-way hubs suffer from it but I don't know of a workaround in the mean time.

Kerbal Space Program\GameData\Squad\Parts\Structural\strutConnector\Part.cfg (a plain text file). The property you want is maxLength.

6 hours is the sidereal rotation period, noon to noon is slightly longer to account for the rotation around the sun. A month is obviously cultural not astronomical but the Munar orbital periods are on the wiki: http://wiki.kerbalspaceprogram.com/wiki/Mun It also has Kerbin's orbital period (a year). http://wiki.kerbalspaceprogram.com/wiki/Kerbin

Just delete the files you extracted. You haven't broken anything, it's just a quirk of the current version of the game that it'll stop loading all subsequent parts if it encounters and error in one. Remove the file with the error and it'll load the stock parts again.