Here’s some notes and details from the team with regards to the changes that come with KSP 1.10.0.
Customizable Kerbal Suits
Description of the process to edit and import customized EVA suits.
The Suit Picker
It is a tool introduced in KSP 1.10 Update, designed to let players choose among the available suits and colors for EVA.
Attached you will find the following (link to attachment below):
A UV Map file that lets you identify the wireframe of the model of the character.
And an ID Map so it is easier to select colors and create combinations.
Adding Customized Suits - Instructions
In order to add a new suit variant the player has to create a folder called Suits inside the GameData/Squad folder.
Inside Suits, other three folders called Config, Icons and Textures.
Then in the Config folder we need to create a .cfg file called SUITCOMBOS with the following properties:
DisplayName: The name of the variant shown at the suit title in the suit picker window.
SuitType: The suit type the variant belongs to; Default, Vintage (Making History) or Future (Breaking Ground)
Gender: The gender this variant belongs to; Male or Female
Name: A unique string to identify the suit combo, example CustomSuit1
Suit Texture: The path where the custom suit texture is (Textures folder).
Suit Normal Texture: The path where the custom suit normal texture is (Textures folder).
Sprite: The path where the texture variant icon is (Icons folder).
Primary Color: The primary color used in the texture variant button, in hexadecimal.
Secondary Color: The secondary color used in the texture variant button, in hexadecimal.
displayName = Custom Suit 1
suitType = Future
gender = Male
name = CustomSuit1
suitTexture = Squad/Suits/Textures/futureSuit_diffuse_redBlue
suitNormal = Squad/Suits/Textures/futureSuit_normals_redBlue
sprite = Squad/Suits/Icons/kerbalicon_suit_future
primaryColor = #012957
secondaryColor = #b3313a
To add more variants there’s no need to create multiple files, adding a new “SUITCOMBO“ block in the cfg like the one above is enough.
PNG or DDS:
PNG or DDS file formats have a different orientation in the game, if you notice your texture isn’t displaying in a correct way it may be missing a vertical flip.
Icons should be added to the “Icon” folder. It should be a small image only 33 pixels width 54 pixels height, preferably with transparency.
Make sure to add the texture and icon files in their respective folders: Icon and Textures. And more importantly; have fun!
Here is the link to the map files you can use.
Gas Giant Planet Shaders
Using the gas giant shader with new celestial bodies
Please ensure that you also add a GasGiantMaterialControls component to your object because it controls some of the features of the Terrain/Gas Giant shader. You can also use it to control the way that the shader looks by assigning the appropriate values to members.
Just about everything should be handled automatically for you, but please remember to call GasGiantMaterialControls.UpdateMaterialControlSettings() if you swap the material or shader for the celestial body. If you just set new values using the members on GasGiantMaterialControls, updates will be handled for you. All of the capitalised names referred to below are members of GasGiantMaterialControls.
I want to modify the movement speed of Jool's features
Get ahold of the GasGiantMaterialControls component on the Jool object and assign new values to the BandMovementSpeed member to change how fast the bands move, swirls can be controlled with the SwirlRotationSpeed, SwirlRotationSwirliness (which controls the final extent of the swirl rotation), and SwirlPanSpeed members.
Levels of detail
The gas giant shader uses two different levels of detail, so we read the textures in separately and blend the two depending on the distance from the camera to the pixel. The blend happens between the NearDetailDistance and the FarDetailDistance with the strengths of how much of each texturing pattern controlled by the NearDetailStrength (maximum strength of the detail texturing when zoomed in) and FarDetailStrength (maximum strength of the detail texturing when zoomed out). The texturing uvs for the detail texturing use the far uvs multiplied by DetailTiling.
I want to modify Jool's pattern
CloudPatternMap controls the pattern for far texturing and DetailCloudPatternMap controls the texturing for near texturing. For both we just read the red channel of the texture to get the pattern. (The green channel in CloudPatternMap controls the blend between the colours for the far texturing.)
I want to modify Jool's colour
The far texturing uses two colour ramps: ColourMap and ColourMap2. For the near texturing, we read the colour of both ramps using the value of the cloud pattern (since it's greyscale). We then take both of those colour ramps and blend between them using the value in the green channel of the CloudPatternMap. The near texturing uses one colour ramp: DetailColourMap. For the near texturing, we just read the colour of the ramp using the value of the cloud pattern (since it's greyscale).
I want to change Jool's movement bands
The movement bands are controlled by the MovementControlTexture. The red and green channels control the left and right movement speeds (black for no movement, white for full movement speed). The blue channel controls the blend between the texture reads for the two bands. The speeds from the red and green channels are then multiplied by the BandMovementSpeed member.
I want to change Jool's swirls
The swirls are controlled by the SwirlControlTexture. The red channel represents the x uv position of the centre of rotation, the green channel represent the y uv position of the centre of rotation, and the blue channel controls how much the swirl actually rotates. The pan speed of the swirls is controlled by the alpha channel in MovementControlTexture.
1 parent object without a mesh.
At least 1 child object with a mesh
1 background texture
1 flag texture assigned in the Editor (VAB or SPH)
Flags can be assigned pre-existing or new textures from the Flag browser.
Flag texture path:
Stock flag parts path
Stock BackgroundTexture path
Flags parts .mu file
This is the hierarchy order example from the RFP-1 Flag (1.25m)
The parent object “1.25Flags” is just an empty group or object holding the actual flag meshes.
When the part is spawned the first available mesh will be set and when the size or orientation is changed, the corresponding mesh will be the only active and visible mesh.
But in reality, all the mesh children should be overlapped and centered.
The flag meshes from the .mu file must have the same name as the one included in the cfg under the FlagDecalBackground MODULE
Flag Mesh Example
name = small
displayName = #autoLOC_6006063 //#autoLOC_6006063 = Small
meshName = 1.25SmallPortrait
orientation = PORTRAIT
In this example we can see how a mesh is referenced
All of the members must be included for each MESH added.
name is the key of how flag sizes are grouped, as we can have 2 flags of the same size, but with different orientation.
displayName This one should match the name but is not necessary.
meshName This string MUST match the name of the mesh included in the .mu file.
orientation can be only LANDSCAPE or PORTRAIT, as the flags can be toggled between orientations in the Part Action Window.
name = White
displayName = #autoLOC_8007119 //#autoLOC_8007119 = White
primaryColor = #ffffff
secondaryColor = #ffffff
//shader = KSP/Alpha/CutoffBackground
backTextureURL = Squad/Parts/Utility/flags/backgroundTextures/white_background
backColor = #ffffffff
name Name of the variant
displayName display name of the variant with an autoloc assigned
primaryColor primary color
secondaryColor secondary color
shader shader that flags use within the game.
backTextureURL Background texture assigned, if this is not set it will be transparent. Like the already existing TransparentBackground Variant.
In general, if you create a variant for a fairing part the same way you would any other part, it will be fine. But there are a few extra capabilities for fairings specifically that you can exploit.
The following will help you get the most out of them.
Variants for fairings have an extra block that you don’t typically see in other variants, called EXTRA_INFO. While this is not new or exclusive to fairings, there are some fairing-specific variables to set up. Take the silver variant for stock fairings as example:
name = Silver
displayName = #autoLOC_6005005
themeName = Silver
description = #autoLOC_6005006
primaryColor = #cecece
mainTextureURL = Squad/Parts/Aero/fairings/fairings_diff
shaderName=KSP/Bumped Specular (Mapped)
The way the silver variant is different from the rest is that it changes the shader for both the base of the fairing and the panels. This is done through the shaderName parameter as well as some material-texture name matching. If you don’t specify a shader name, the module will assign the usual Bumped Specular to both base and panels.
If you do specify a different shader, it will copy the shared properties and you will also be able to specify the rest as parameters in the EXTRA_INFO block (note _Shininess, _Opacity and so on).
The aforementioned material-texture name matching means that for the FairingsTextureURL, FairingsNormalURL, FairingsSpecularURL, BaseTextureName and BaseNormalsName textures specified to actually be applied correctly, the material name must be the start of the texture name (e.g. the base mesh has a material named FairingBase applied, the diffuse and normal textures are named FairingBase_silverDiffuse and FairingBaseNormals_goldSilver, both starting with the material name).
Repeated material parameters are also differentiated by this same principle (see the two _SpecMap parameters defined in the example).
For the toolbox preview to work correctly, the panel icon name must have a material that uses the Bumped Specular shader and that contains IconShell in its name. Also it must have the Icon_Only tag. The bases just work as long as they have the Icon_Only tag also. One additional configuration is that the base mesh must be named Mesh.
Below provides some background and useful information for modders on drag cubes. Changes made for KSP 1.10 are called out below. But first, Drag Cubes: What are they?
A system of defining the drag profile for an object.
Read any books by Michio Kaku, the theoretical physicist? In one of his books he stated that some cultures believe you achieve nirvana if you can mentally visualize a hypercube (also know as a tesseract), a 4 dimensional cube, being rotated in 3 dimensional space.
This is a 4 dimensional tesseract being rotated in 3 dimensions.
And here is KSP’s drag cube model.
It's important to note that the directions x+ (XP), y+ (YP) etc are relative to the part if placed without rotating it first. If you rotate the part the directions are relative to the part's orientation.
EG: if I rotate a part upside down so it's pointing opposite to the way when it's first selected in the VAB/SPH then it's cubes would now be opposite when placed.
All parts have drag cubes defined in a file called partdatabase.cfg.
Fixed, Procedural and Dynamic Drag cubes
A single drag cube is generated and used for the part.
Multiple Drag Cube entries can be defined for a part as separate cube entries for a part.
For parts that have multiple cubes they will have IMultipleDragCube implemented in their PartModule. These are usually defined for parts that move or have different profiles, eg: Deployable parts (fairings, etc), Robotic parts, etc.
The partmodule in these cases will calculate which drag cubes are appropriate and set the cube weight of each drag cube the drag system should apply in the DragCubeList (list of drag cube info on a part)
Are generated at runtime by DragCubeSystem when called (not at KSP startup) - eg: Procedural Fairings drag cube generation. Procedural drag cubes come at a performance cost and so are only used when necessary.
Part Prefab Drag cubes
A DRAG_CUBE node can be defined in a part.cfg file for a specific file. This will always be applied to this part and overrides anything in partdatabase.cfg.
These are generally cubes that have been manually calculated, most common are hollow parts as they need special manual handling to get the drag cube definition correct and will override any automatically generated drag cubes in the partdatabase.cfg.
This system will generate Drag Cubes for parts where a DRAG_CUBE definition has not been found in partdatabase.cfg or the part.cfg file. It is also used to generate Procedural Drag Cubes as required.
DragCube format in DRAG_CUBE node
cube = <name>, <area>,<drag>,<depth> x 6, <center.x>,<center.y>,<center.z>, <size.x>,<size.y>,<size.z>
<name> = the drag cube name.
These three floats will appear six times for each cube, the 6 occurrences being the XP, XN, YP, YN, ZP, ZN dimensions.
<area> = total pixels taken up by the profile.
<drag> = how much drag in the cube. This is calculated based on the red color within the image, applied to the std physics drag curve defined.
<depth> = how deep into the cube. This is calculated based on the green color within the image.
<center.x>,<center.y>,<center.z> = The center x,y,z position of the drag cube.
<size.x>,<size.y>,<size.z> - The x,y,z size of the drag cube.
Any PartModule can implement this Interface. If a part module implements this interface then the DragCubeSystem will use this interface when generating drag cubes for the part.
It is up to the PartModule implementing the interface to manage the drag cube weights as appropriate to achieve the correct blend of drag cube information based on its state.
Handling multiple PartModules using this interface
This is What has changed for KSP 1.10 release. Before KSP 1.10 variants and multiple partmodules could not implement IMultipleDragCubes on the same part.
ModuleJettison and ModuleVariants are used frequently together. Usually variants for different engine variants and jettison are used for shrouds on the engine.
The DragCubeSystem will define cubes for each of these modules and the two modules work in unison to ensure the correct Drag cube weights are set depending on their state. Note: In this combination the "Bare" cube on ModuleJettison although generated is not used. Instead each variant in ModuleVariants will enable it's variant drag cube entry. The "Shroud" cube is used from ModuleJettison when there is a shroud enabled and the meshes from the ModuleVariants are enabled based on which variant has been set.
Any combination of PartModules implementing IMultipleDragCubes on the same part outside of the two modules mentioned will fall back to using Procedural drag cubes, IF more than one of the PartModules has useMultipleDragCubes set to true. You could have two PartModules on the same part but only one or none of them has useMultipleDragCubes set to true. Example: An engine part that has ModuleJettison (for shrouds) set to useMultipleDragCubes true and ModuleVariants that only changes textures (not meshes) with it's useMultipleDragCubes set to false.
ESA Missions without Making History DLC:
Yes, the ESA missions can be run by users who have not purchased the Making History DLC.
No, this does not mean you can run any other missions without the Making History DLC installed.
IPartMassModifier has been added to ModuleJettison. This allows mods to implement mass change to parts when they jettison.
Application of mass to resource ratios in ModuleResourceConverter recipes has now been fixed/added.
Renamed a duplicated shader "KSP/Particles/Alpha Blended" to now have one named that and another named "KSP/Particles/Alpha Blended Scenery". This probably should have no impact on mods, as they probably don’t use this shader. But you never know.