Jump to content

JPLRepo

KSP Team
  • Posts

    3,141
  • Joined

  • Last visited

Everything posted by JPLRepo

  1. ah k. it's not important if the mod doesn't have that transform. if it doesn't find one. then it does nothing with regard to variants and no longer NREs and breaks the module. [edit] the new KSPField allows mods to use their own transform name for the base and apply variants to their mod fairing if they so wish.
  2. Part tools has been updated for KSP 1.10.x. Includes - removed old shaders that were causing confusion. - fixed exported internal spaces not working if you had your OS set to non-English. - uses newer Free TMPro that corresponds to the one we use in KSP. So make sure you update that in your project. - fixed issue where mod created fonts were not working/being loaded into KSP main game. - added some of the newer part shaders we now use. NB: Part Tools now requires Unity 2019.2.2f1 There is a link above to the older Unity 2017 version if you still want to use that.
  3. The doxygen API docs have been published for 1.10.1 Same link as above.
  4. It was. Though should be fixed now. But I can't guarantee what might happen with various mods. Basically there was a change made in 1.10.0 for open ended fairings that caused issue for all mod fairings. Which has now been resolved in 1.10.1. Has that been reported on the bug tracker? first I've heard of it.
  5. No you don't need any separate mod. See the OP for details of mods you can use with this mod and info about unloaded/background resource processing. Which is included with this mod. I don't support CKAN, nor do my mods support installation via CKAN. So I don't know what your issue is there with CKAN.
  6. It generates the same. If you Re seeing different then will need step by step what you did. It’s possible if you changed settings that they won’t change for an existing saves vessels. But i would need more information to investigate.
  7. Sorry but I am not sure what you are talking about. What "processing modules" are you referring to?
  8. Yes that's a known issue. It should be 0.05t. Yes there is a problem with modded fairings. Stock fairings work fine.
  9. Are you using any mods? Because there is a known issue with modded fairings.
  10. Thanks. If you want to. I can look at adding them in and add you to the credits for the mod. PM me the details.
  11. Yes. Stay tuned to the forum for more info on patch details.
  12. I've investigated the issue. and indeed. With all the changes that were made for fairings. It now expects a transform called "Base" in the model. Will look to patch this in the next patch so that it's a KSPField that you can override.
  13. The doxygen API docs have been published for 1.10.0 Same link as above.
  14. The API documentation can be located here. At each release we have been avoiding changes to public methods and variables signatures for some time now. So public method signatures and variables rarely change. No. The terrain should be the same shape. That is generated by the PQS system and remain sunchanged. The revamps for the surfaces of the Planets are texture and shader upgrades only. So they look way cooler. But the actual geometry is unchanged.
  15. 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. The Materials 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. Example: SUITCOMBOS { SUITCOMBO { 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. ICON: 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. Using GasGiantMaterialControls 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. Flag Parts Flags composition: 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 Paths Flags can be assigned pre-existing or new textures from the Flag browser. Flag texture path: KSP\GameData\Squad\Flags Stock flag parts path KSP\GameData\Squad\Parts\Utility\flags Stock BackgroundTexture path KSP\GameData\Squad\Parts\Utility\flags\backgroundTextures 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. Flags CFG 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 MESH { 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. Flags Variants Variant Example VARIANT { name = White displayName = #autoLOC_8007119 //#autoLOC_8007119 = White primaryColor = #ffffff secondaryColor = #ffffff TEXTURE { //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. Fairing Variants 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: VARIANT { name = Silver displayName = #autoLOC_6005005 themeName = Silver description = #autoLOC_6005006 primaryColor = #cecece TEXTURE { materialName=FairingsMat mainTextureURL = Squad/Parts/Aero/fairings/fairings_diff } EXTRA_INFO { FairingsTextureURL=Squad/Parts/Aero/fairings/fairings_silverDiffuse FairingsNormalURL=Squad/Parts/Aero/fairings/fairings_normals FairingsSpecularURL=Squad/Parts/Aero/fairings/fairings_silverSpecular BaseMaterialName=FairingBase shaderName=KSP/Bumped Specular (Mapped) BaseTextureName=Squad/Parts/Aero/fairings/FairingBase_silverDiffuse BaseNormalsName=Squad/Parts/Aero/fairings/FairingBaseNormals_goldSilver _SpecMap=Squad/Parts/Aero/fairings/FairingBase_silverSpecular _SpecMap=Squad/Parts/Aero/fairings/FairingsMat_silverSpecular _Shininess= 0.41 _Opacity= 1.0 _RimFalloff= 2.0 _AmbientMultiplier= 0.3 } } 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. Drag Cubes 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? Simple Explanation A system of defining the drag profile for an object. Complex Explanation 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 Fixed A single drag cube is generated and used for the part. Dynamic 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) Procedural 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. DragCubeSystem 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. IMultipleDragCubes 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. Other Items 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.
  16. I had to look this up because I'd never heard of it.... so that mod uses Kopernicus to define new celestial bodies. ResearchBodies supports Kopernicus. But unless someone has created a cfg file for the planets in that mod for ResearchBodies then it probably won't work. The way I see it is: a) you need cfg definitions for the planets in that mod to work with ResearchBodies. b) depending on how far away they are, then yeah the telescopes won't see them. Unless you: change the range of the telescopes (more cfg file changes), or move them so they are in range.
  17. The bug you quote above is fixed. As for a robotics symmetry bug. If someone can give me the bug number I can tell you if it's fixed.
  18. No currently it does not support other resource converters, and no it's not a simple cfg file trickery. I took a look and the nuclear generators in MKS are resource converters. So for 1.10 I'll add a new setting I think so you can turn on unloaded resource processing for all generic resource converters - IF they produce EC only. and then it will support your MKS ones. This allows it to be flexible for what you want but not impact others who perhaps don't want that. As for turning off the unloaded vessel processing. You can do that too. It just means all resource converters, TAC LS, etc will play catchup (process all resources when they are loaded or switched to). Just how TAC LS always worked in earlier versions when unloaded vessel processing wasn't a thing.
  19. Straight away in your log I see that you are running KSP 1.9 with Contract Configurator... which doesn't support KSP 1.9. So my guess is it's probably breaking things in contracts. I'd suggest: A) start a fresh install of KSP (you can have multiple copies of KSP on your machine). - Using KSP 1.9.1 (notice in your log you are still running KSP 1.9.0) B) only install this mod. V7.10 goes with KSP 1.9.1. C) try the pictures of the sun etc contracts. I just tried this in a fresh career game and the contract worked fine for me.
  20. Until Contract Configurator mod is updated for KSP v1.9.1 it won't be no.. and 1.10.0 comes out next week. So if Contract Configurator is not updated for 1.10.0 I'll have to look at making Research Bodies not dependent on that mod any more.
  21. High priority = 1. And will be last to shutdown and first to restart.
×
×
  • Create New...