navot

Thanks for reminding me. I think i used an older image format for some of the textures, which is no longer supported by KSP. I converted them and everything seems to work again.

The stock shrouds are the ones that only exist on the Engines. How did you install the mod? Did you use CKAN? Do you have ModuleManager installed?

The change was independent of the part, and for me it works fine on the ShroudedDecoupler Part The default option for the mod is to use the Stock shrouds. To use the decoupler to generate a shroud, you need to right click on the decoupler in question and enable it there. To add to those instructions, here is a small example of a custom texture pack, and here is some documentation of the config files.

I hard-coded the 20m some time ago because I thought who would need anything larger; that would be ridiculous... But I forgot this is a mod for KSP I changed it to infinity. You can download the new version from GitHub and scale the shroud to your heart's content! Out of curiosity, are there engines that large, or do you cover multiple parts?

I'm not sure what could cause that. Could you check if this also happens with a clean install and only DecouplerShroud and ModuleManager installed?

I don't know how KSP determines whether there is a part occluding the solar panel. My guess would be that it's using the colliders, since that would be more performant to calculate. The shrouds don't have colliders at the moment. I experimented with giving the shroud colliders, but it didn't work too well (I think the shroud tended to explode other parts or be indestructible).

The thing is, I don't know how well the dragcubes are generated (a dragcube is just a bunch of numbers). Right now, the mod calls a function in the KSP code which generates a dragcube for a part somehow, but how you are supposed to use it is not really documented. I'm also not certain what the correct values for a dracube would look like. For example, some values correspond to the are of your part, but when I calculated the area by hand, it differed from the generated dragcube. Right now the generated dragcubes mostly seem to reduce the drag on the rocket, but there are apparently some cases where the opposite is the case. FAR has a completely different aerodynamics system. It actually has a way to debug the aerodynamics (you can look at the voxels), and everything looks fine there. So if you are using FAR, the aerodynamics of the shroud might be better than with the stock dragcubes

The mod now works with FAR. I already saw your post in March and tried to implement it but gave up a bit too quickly. But hey, it's here now

I think the bump comes from the Engine. Also, it's smooth if there is another part covering the decoupler from the bottom

This fixed it. This green line is what you would expect from a hollow part, right? Thank you.

Thanks for the help with the config file. Now the changes do show up in the configcache file. Unfortunately, the mesh still isn't voxelised. Here are the Logs created by FAR after creating meshes and calling "GeometryPartModuleRebuildMeshData": [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2, COL0, COL1, COL2, COL3 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2, COL0, COL1, COL2, COL3 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Decoupler.2 - mesh build info: Meshes: Decoupler_2, COL0, COL1, COL2, COL3 No renderer found: COL0, COL1, COL2, COL3 [FAR v0.15.10.1] Updating __A [FAR v0.15.10.1] liquidEngine2 - mesh build info: Meshes: engine, obj_gimbal [FAR v0.15.10.1] Clearing visual voxels [FAR v0.15.10.1] Voxel Element CrossSection Area: 0.00202024684491434 [FAR v0.15.10.1] Std dev for smoothing: 3 voxel total vol: 22.7010875940323 filled vol: 5.99027710613602 [FAR v0.15.10.1] Voxelization Time (ms): 147 I looked at the hierarchy [Image], and the COL0 - COL3 are the stock colliders of the decoupler. I think the "No renderer found" is because the COL0-COL3 colliders also have a MeshFilter, but no MeshRenderer. This shouldn't have anything to do with my meshes not working, since they get voxelised fine. Any ideas why my mesh and meshcolliders don't show up there? Is there any additional info I could provide to pinpoint the issue?

I tried this, but it sadly hasn't fixed the issue: @PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]] { @MODULE[GeometryPartModule] { %forceUseMeshes = true %ignoreIfNoRenderer = true } } Are there specific things one has to look out for with procedurally generated or concave meshes?

That is a remnant of when I tried to add colliders to the shrouds. This shouldn't really do anything in the released version of the mod (that I'm aware of).

I've been trying to make my mod Decoupler Shroud work with FAR, but had little success so far. I looked at how Procedural Fairings / Parts solved this, and at the moment I am calling: part.SendMessage("GeometryPartModuleRebuildMeshData"); but it does not seem to detect the shroud mesh (Image). What does the GeometryPartModuleRebuildMeshData function need to generate the Voxels? Do the GameObjects need to be laid out in some specific way? Does it need colliders, or generate from the visual mesh? Do you have to register the mesh with FAR in some way? The code that is calling the function is in this file, if you want to take a look. Thank you

I've worked some more on the texturing update, and here is the current state of things. The current version can be found on this GitHub branch. It's now easier to make custom logo textures, so if you want to really customize your rockets by adding a logo to the interstage, you can. Here's a screenshot of this in action. Texture configs can now change the shader that is used to create the materials. This means, Textures Unlimited shaders, or the shader introduced in KSP 1.5 can now be used. Texture configs can support different shaders, so the materials can be loaded regardless of the KSP version or if Textures Unlimited is installed. Here are some examples of reflective materials. There are also some big changes to how the texture config files work (old config files will still be read correctly). I've made a quick example of how to make a custom texture pack here. It also contains a .txt file documenting showning some of the parameters and what they do. The code for this update should be mostly done. What remains to be done is to create better configs for the textures (the Textures Unlimited version of most textures looks bad at the moment, and most textures don't use the KSP 1.5 shader at the moment). If anyone has any feedback on the texturing or feature requests / change requests, please let me know.

I'm not aware of any other texture packs. What do you mean by old texture packs? If you mean texture packs for procedural parts of fairings or similar, they don't work because the texture configs structured differently. A while back, I worked on an improving the way the texture configs work, but I didn't quite finish. The current version of this can be found on this branch: https://github.com/nav0t/DecouplerShroud/tree/update. It makes creating config files a bit easier and supports different shaders (can be used with Textures Unlimited for example). I don't know of any big issues with this Decoupler Shroud version right now, so feel free to try it out. Here is the short version of how to create a texture pack: Create a new folder in your GameData folder with the name of your texture pack Put any texture you want to use in the folder Create a .cfg file for every texture in the folder Copy one of the standard configs from DecouplerShroud/Textures/TextureConfigs (I'd recommend TexDark.cfg for the simple version, if you want to see some variables TexDefault.cfg) Change the name to something unique Change any parameters you want. This step really should be elaborated more, but that'll be it for now. If you have questions or feature requests feel free to ask Here are some pointers for creating cfg files for the github version If you just want to switch the texture, "texture = _MainTex" is the color texture and "texture = _BumpMap" is for the normal map. Change the path to a file in your texture pack folder The v = 2 tells the program that it is a config using features of the Decoupler Shroud version currently on github. The base = default means you start off with the default texture config file and only the parameters that are given in your config file will be changed. This way you have to copy and paste less. The MaterialVariant regions are only used, if the specified shader is available. This way you can set different parameters if Textures Unlimited is installed, or the KSP version has the new shiny shader If you want to make a texture pack for the current version, look at the way Basic Procedural Textures changes the configs Hope this makes some sense. Edit: Here is a small example on how to create your own texture pack, and here is some documentation of the config files.

To elaborate on what @Electr0ninja said: The mod does affect aerodynamics, but it's not working as well as I would like it to. No changes are made to the rigidity or the mass of the rocket

The most likely reason for this not working is that you either didn't install the mod correctly, or you have some conflicting mods (I don't know of any at the moment). How did you install the mod? Through CKAN or manually? If you installed it manually, did you also install ModuleManager? Do you use other mods?

@linuxgurugamer First off, I just wanted to say a quick thank you for all your work and the contributions you make to so many different mods! I'd really like to see your changes to make this mod also disable gimabling, but I'm not sure if I should put it in this mod, just because of the name "Control Surface Toggle". I think the options to avoid name confusion would be: make a new mod with your changes, that just disables the gimbaling make your version with gimbaling and control surface disabling a new mod altogether under a new name, and discontinue this mod put the changes in @TheRagingIrishmans Smart Actuation mod, if that is something he'd be willing to do. just put the changes in this mod and not care about the name I haven't worked on this mod for quite some time, so I really wouldn't have a problem with discontinuing this mod or you making your current version a new mod. Let me know what you think would be best

@rmaine It's quite possible that there are some issues with the way the mod handles the aerodynamics. What it's doing at the moment is calling a function to generate Drag Cubes, which the game uses for it's simulation. I think I found the name of the function digging through the procedural parts of fairings mod. I'm not sure if the drag cubes that are generated are correct, or what they should ideally look like, but I'll try looking into it.

Thank you for handing me that bug on a silver platter ! I finally got around to putting your fix in the mod.

Thanks for pointing it out, and you are correct. It has already been fixed on the GitHub page, but I didn't make a release that has the changes yet.

At the moment it isn't, since the shader is hardcoded. Funnily enough, I started working on supporting changing the shader in the configs earlier this week, but I still have to figure out how to access the TU shaders. So this feature might come in the near future.

I tried reproducing this, but the problem didn't happen when I put a decoupler below a tweakscaled heatshield and decoupled. Can you provide some more detailed instructions to reproduce this bug?