navot

The quickest way to get decoupler shroud on every part would be to edit the file [Your KSP Folder]\GameData\DecouplerShroud\DecouplerShroud.cfg and change the first line from: @PART[*]:FOR[DecouplerShroud]:HAS[@MODULE[ModuleDecouple]]:HAS[!MODULE[ModuleDecouplerShroud]] to: @PART[*]:FOR[DecouplerShroud]:HAS[!MODULE[ModuleDecouplerShroud]] Keep in mind that updating this mod will reverse your changes and you'll have to make them again, or make a copy of the cfg file and put it somewhere in your GameData folder (I'd recommend changing it after updating to get any new config values) I tested it with some parts and it worked fine, but there might be some bugs or performance issues with this, and I can't guarantee that it won't break a craft or save file (it probably won't, but I felt like putting some disclaimer here)

I've tried to reproduce it with only DecouplerShroud installed, but it didn't happen for me. Then again, I don't think it would be DS, since it only disables and enables the engine shrouds in the editor. One interesting thing about the bug is that it only enables one of the shrouds(the NERV's shroud is split into two shrouds), which would also indicate that another mod causes this, since DS only changes the state of all shrouds at the same time. What I'd recommend doing is first making a copy of your installation, so you can mess around with disabling mods without breaking anything. Then try to pinpoint when exactly the shrouds reappear. My guess is that they reappear the first time you reload the vessel after decoupling the decoupler below the engine (just a guess, could happen at some other time). I'd also play around with different crafts, to see if it's some specific engine/decoupler causing the problems (My guess is that it shouldn't matter). If you have repeatable steps you can take to cause the bug, delete some mods and check if the bug still happens.

@Jesusthebird I found a thread for the mod. It is called Smart Actuators here. I didn't know this mod existed when I made this mod, so the features are probably pretty similar, but he says he wants to also disable engines gimbaling when they are off, which is something I'm not planning to add to this mod.

@Gordon Dry Sorry for taking so long to respond. Did all your issues with this mod resolve them self? I don't have any experience with FAR, but I think I heard somewhere that it disables the control surfaces in space by itself. If that's the case (again, not sure) the patch should check if FAR is installed, and if it is not add ModuleCSToggle to the parts. I'll probably look into that in the coming days

I think you may have misunderstood me. The normal decouplers with decoupler shroud enabled are fine, it's just if you installed the version from GitHub with the custom parts and used one of the custom decoupler parts that you have to worry. That is because there were four different versions of my custom decouplers for the different sizes, which no longer exist, because now there is only one part that gets scaled. And if you did already use them in some important craft, you can just make sure that the files in ShroudedDecoupler_0.cfg to ShroudedDecoupler_3.cfg are still somewhere in your Gamedata folder and it should work fine, but you won't just have the one scalable decoupler

Choosing the diameter works the same way as you choose the top and bottom width when you turn off automatic size detection

I've added some basic scaling of the decoupler. I'm modifying the price, mass, and ejection force. Let me know if I forgot about something. Also, make sure if you are upgrading to remove the old Shrouded Decouplers from any important crafts, or they won't load

Totally forgot about the 1.875m size... Scaling options is a good idea, but I don't want this mod to depend on TweakScale, so I might try to implement my own version of part scaling

I've added custom decoupler parts, which have the same stats as the stock decouplers, but don't have a surface on the side of the rocket and use the DecouplerShroud by default. I initially made this to make an SLS style rocket, where the orange sides shouldn't be interrupted by a white decoupler. If you want to have a look at them you can download the current version on GitHub. I'll probably make a Spacedock release soon, but I'm a bit hesitant since I don't want to clutter the parts list if no one wants this part and removing it might break someone's craft files I've also added a dark and an orange shroud texture, however the orange texture doesn't quite match the look of the stock orange yet

It should work just fine in KSP 1.3.1. I think all of the mods versions should work fine with KSP 1.3, but I've only changed how CKAN determines which KSP versions the mod works on in the last update.

Nice Job! One quick note is that I just changed the textures in my mod from png to dds, and changed their names to avoid loading the png texture instead of the dds texture when the mod isn't installed cleanly. Because of this, if you do a clean install of the latest version of my mod, the top and inside textures of your pack are just white, since the textures it is referencing no longer exist under their old name

@Gordon Dry Thanks for reporting this issue and providing steps to reproduce it. I turns out that I tried to clean up some materials that aren't created yet, causing the error. It's fixed now on the latest GitHub release

@Warezcrawler Thank you for giving me some pointers! I updated my mod and tried running it in KSP 1.3, but it didn't work (not a big deal but it would have been nice if it ran). Did these functions change between 1.3 and 1.4 or is it something different in my mod that causes this?

But at which point did it turn blue?!

As this mod isn't really that complex, KSP updates don't tend to break it, so the mod will probably run just fine on KSP 1.4.3. If you encounter any issues with the newest version please let me know.

I think my understanding of how KSP deals with normal maps goes down over time... Did you make the Striped_NRM.png normal map yourself, if so how? I'd also recommend copying the autoscale options for the top node, since your with your textures the top is just stretched around one time

CKAN also tries to install an old version on KSP 1.3.1, so I deleted the version history on Spacedock and hope this stops CKAN from trying to install old versions (at the moment it hasn't change, but I hope that is because it takes a bit to update that information)

What version on KSP are you running? I checked with KSP 1.4.2 and it was installed correctly for me. However if you are installing an old version of the mod (< 1.2.2) it won't work correctly, since that is the version I fixed it. I just checked with KSP v1.3 and CKAN tried to install the wrong version. I don't really know how to tell CKAN not to do this, apart from simply deleting the mod history on Spacedock, so I might do that

@Tyko I had a look at it and managed to reduce the problem without having more than 24 verts per circle, by just having more circles vertically. Procedural Parts also does this to some extent, but it also has more than 24 verts per circle, since it doesn't have to match a decoupler that typically has 24 verts. It still doesn't look perfect, and still has some squiggly lines, but PP also has that a bit if you look closely. At the moment I divide the main cylinder 20 times, but if you want to, you can raise this value in the config, to reduce the effects further.

@Tyko I implemented some scaling and auto scaling features that should be similar to the way Procedural Parts does it. I've done some more digging on this, and if I understand it correctly, pink is the color a normal map should be if it is saved as a DDS file, while PNG normal maps are red. So I guess the reason Tyko's normal maps worked and yours looked weird is because his normal maps were DDS files, and yours were in PNG format (haven't tested it out though)

I used http://cpetry.github.io/NormalMap-Online/ to convert the height map to a normal map

The way I created the normals was to create a heightmap which I converted into a typical (blue-ish) normal map with an online converter, and then used the KSP Unity tools, which gave me the red normal map. If by the herringbone issue you are talking about the vertical lines not looking completely straight, that is not a problem with scaling, but a result of how the mesh is made up of triangles, on a shape that is more cone than cylinder. This gets better when you have more vertices, but then the shrouds don't fit the parts as nice (most parts only have 24 vertices on a circle)

I guess so, but where do those pink normal maps come from? I guess that is a DXT5nm formatted normal map after some quick googling, which does make some sense, but then why does the unity tool not generate pink normal maps when I run it?

Nice work! I think the corrugated normals are a bit too strong, but that is just my opinion. How did you generate the normal maps? Yours are more pink, and the ones I generated with the Unity tool are red. When I changed the way the textures are handled I also wanted to add texture scaling similar to how procedural parts does it, but didn't get around to implementing it yet. I might work on that this weekend.

I have also not been able to replicate this. In case this is still happening, are you also running any other mods?