Firstly, here is the new PartTools package for 0.20. Please read the included ReadMe.txt!
GameDatabase & PartLoader
The system that KSP uses to load game resources has changed, its called GameDatabase (GDb).
GDb iterates through the various game data directories creating a list of files. Each file is assigned a url and then the assets are loaded in a specific order; Assemblies (dlls), audio, textures, models and then configs.
Once GDb has finished loading files it hands control over to PartLoader which compiles all of the game's configs into parts, internal props and internal spaces.
GameDatabase URL system
GDb assigns a unique url to every asset and config in its directory structure. No file extensions are stored in the url, this allows you to reference models, textures and audio without needing to know what the file type is. The legacy directories (parts, internals, etc) are all prefixed with the directory name however the new data directory, GameData, is not. Lets look at some examples...
File: KSP\GameData\Squad\Parts\Command\landerCabinSmall\ model.mu
GameDatabase 'Get' Methods
All of the assets held in the GDb are retrieved via the Get methods. They are seperated into asset type.
GetAudioClip - Gets audio clip from url
GetTexture - Gets texture from url
GetTextureIn - Gets a texture in the specified directory
GetModel - Gets model by url
GetModelIn - Gets model in specified directory
GetConfigNode - Gets a config node by url
GetConfigNodes - Gets all config nodes by type
For detailed information load the dll into VisualStudio or MonoDevleop.
KSPAddon & AddonLoader
AddonLoader is a simple system which allows modders to instantiate Unity MonoBehaviours without need to messily overload Part, PartModule or UnitTests. To do this you tag a component in your assembly with the KSPAddon attribute. This attribute allows you to set which scene the component is instantiated in and also if it should be repeatedly instantiated upon transition into that scene. If you want the component to not be destroyed then you should set 'once' to true and manually call DontDestroyOnLoad.
Previously, part configs had to define attach nodes with messy position values in the base config. Now you can define an attach node as being linked to a transform on the model. To do this you define an ATTACH config node like this..
There are two key names of attach nodes;
name = top
transformName = myTopTransform
name = srfAttach
transformName = mySrfAttachmentTransform
There is the 'top' node, this defines the traditional part heirarchy structure. If you only have one attach node then it should be called top.
There is also the 'srfAttach' node, this defines the surface attachment point. The name 'attach' is also valid for this node, you can only have one surface attachment node.
You can define two other values; size and method.
'size' allows you to change the node's sphere size in the editor and has no effect on gameplay.
'method' allows you to change the physic joint type. Its values can be; FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS. Not sure what madness you can do with this value, will leave it to you all to play.
NOTE: Attach nodes defined in this way are not animated with respect to physics and should remain static on the model.
In the old system, models were loaded directly from a part config's directory. This is still the case however can be overridden using MODEL config nodes.
MODEL nodes can be used to compile parts containing scaled, translated or rotated models. You can define multiple MODEL nodes to compile multiple models into one part. It also allows you to overload textures on the model.
Parts, Props and InternalSpaces can all use MODEL nodes instead of the traditional same-driectory loading system.
Here is a sample MODEL node showing all valid values
model = Squad/Parts/Command/cupola/model
position = 0.25, 0.5, 1.0
scale = 2.0, 2.0, 4.0
rotation = 0, 90, 0
parent = anotherModelTransform
texture = model000 , Squad/Parts/Command/landerCabinSmall/model000
texture = oldTextureName , newTextureURL
The 'parent' value is only valid in the second or subsequent MODEL nodes as they refer to a transform which must already exist in the part model heirarchy.
Texture overloading value is delimited by comma or semicolon just in case you have spaces in your new texture's URL. All materials using the old texture are swapped to the new texture.