EndlessWaves

The config files map to the public variables on the module classes, so an assembly browser will allow you to see the full and up to date list (although it's not entirely two way, not all of them will be usable in config files). If you do get into plugin writing then any .NET IDE is likely to come with one - MonoDevelop/Xamarin Studio, SharpDevelop, Visual Studio Express etc.

It's perfectly possible to write such a function, but whether the firesplitter plugin includes it I don't know. Your best approach to finding out may be asking the author.

ModuleEngines is unlikely to support that behaviour. You either need to write a replacement engine module or some sort of pre-processor that checks the available fuel (part.getConnectedResources?) and then modifies ModuleEngines propellants list based on the circumstances.

MakeReference is a public method on ModuleCommand, so you'd just invoke it the same as any other method. Obviously you'll need to grab a reference to the module first, they're stored in the Modules variable of the part you're interested.

http://forum.kerbalspaceprogram.com/entry.php/747-The-Making-Of-New-KSC I don't know if squad have released figures for parts, but you can probably guess from the texture sizes.

No, only the keyboard shortcut should have that behaviour, the on-screen button is a toggle.

Vessel is a collection of independent parts rather than a single entity so unless you can find a helper method you may have to calculate and apply the appropriate force to each part (assuming you want minimal stress).

You haven't included your plugin in the download so it's difficult to give advice on the programming generally, which aspect of it do you need help with?

Press the break button at the top of the screen (the red one) to toggle the breaks.

1. Are you sure those rotations are affecting vertex co-ordinates and not just being stored in the model file? IIRC in Blender it's something like edit mode rather than object mode, but freeze/reset transform commands are common as well. 2. Yes, they determine which direction and position in which things attach. First three co-ordinates are the position relative to the scene origin, second three are a directional vector.

Many of them won't be any use as that's for the whole unity engine (i.e. building an entire game on it, not just a mod), I'd just use it as a reference to look up the classes you come across. There are a few like Transform and GameObject that you'll use quite a lot but many you won't touch. You've got a lot of the required knowledge, there are just some elements that a more general purpose language like C# has to have as well as the general quirks that makes languages different. You don't need to go into C# very deeply. You generally won't even be using the standard libraries much (with a few exceptions, collections - various structures similar LUA's tables - are very useful), you just need to know how to structure you code - where each bit goes relative to each other.

It hasn't I'm afraid (at least on the plugin side, I'm not sure about the models). I've been distracted by the summer and other things.

http://docs.unity3d.com/Documentation/ScriptReference/index.html It is LUA that's the oddity unfortunately. They'll probably be more reference material later on, remember the game is still in development and hasn't reached full release stage yet. Some basic knowledge of C# is useful to begin with. I hate to say 'go off and read a tutorial' but you do need the basic knowledge of how the language is structured. Trying to nest classes like that, or access one particular copy of an object through it's class is fundamental language structure even before you get to the KSP stuff. For part position PartModule maintains a reference to the Part it's related to in the part variable, so part.transform.position will give you the position of the part. For the sun position you need to find something that gives you access to the sun object. In this case the FlightGlobals class maintains a static list of the celestialbodies in the game. Because this list is static (i.e. not associated with a particular copy of an object) you can access it directly through the class name - FlightGlobals.Bodies

Yeah, double click the assembly in the resources folder in the project and the assembly browser will open. Neither does anyone else, it's just trial and error. Poke around in the public variables and methods signatures in your IDE's assembly browser and try the ones with the most likely names. Some of the basic stuff is documented in the unity documentation, that'll help with getting relative positions of things for example. You generally want to do as little as possible. In this case you can make a module that you add in addition to those two that disables their events showing up (guiActive = false) and adds one of it's own that calls both their methods. part.Modules holds the list of the PartModules on a part, and for each of those partModules their Event variables holds the KSPEvent attribute properties.

Yeah, that's how the stock gimbal module works. Store the initial rotation and then each frame set the rotation to that plus maximum_gimbal * control_input (the latter being -1 to 1).

Relative to what? The planet/navball orientation? You could try progradeTransform.localEulerAngles - if squad have made those transforms children of the GameObject that the navball is attached to then they should give you the angles relative to the navball orientation (or localRotation if you want the quaternion).

Add one or more of the collider components in unity, a capsule collider would be a good choice here.

PartModule is a subclass of MonoBehaviour, so anything that applies there can be used for PartModule derivatives (and ScenarioModule ones).

The first line isn't doing anything, KSP is an empty namespace. Most of the KSP classes are contained in the global namespace so you'd generally only use 'using UnityEngine'. If you're using the mono compiler (which is command line) then you'll need to give it an explicit place to put the output along with the other arguments. It sounds like you may actually be using MonoDevelop instead. If that's the case then you can right click on the project (not the solution), choose options and set the output location and assembly (dll) name in there.

Saik0's project grabs the textures from the various PQSMod derived components attached to the planet gameobjects and combines it with height data. I believe the wiki ones were done using ISA Mapsat.

What error does the KSP_Data/output_log.txt file given when loading?

Yeah, you'll need to freeze/reset/bake all transforms in modelling programs, KSP has issues with model-wide transforms and they need to be baked into the vertex co-ordinates instead.

Well, unity will apply the texture even if you don't explicitly specify a UVMap, but it may be applying it at an unexpected scale, so you're seeing a single pixel or a massively tiled tiny version that averages out at your viewing distance

Any part with physicalSignificance set to NONE is massless for this sort of calculation so it's mass value should be ignored.

ModuleDeployableSolarPanel public variables: It doesn't look like there's anything there that exposes the features you're after so it's probably not possible with that module.