Zorg

I believe your plumes look bad because they either your framerate is too low or more likely you have lowered the global particle limit below what the smoke trails require. I am personally of the opinion the SRB plumes look pretty great. I dunno who made them originally back in the day but it was long before I started maintaining this mod. Unfortunately they are the most performance intensive plume type in the mod because they are both high emitting and also the emitted particles persist for the entire physics range of 2km (to allow for the world relative trails). I have made several attempts at trying to make a decent looking SRB plume that also improves upon the existing ones performance-wise and failed to do so (on both fronts really). With respect to the edits you have above those are modifications to "user facing" parameters of the plume. The plume itself is a complex prefab config that exists in the core RealPlume mod. Changing the prefab is a no go as it could break all sorts of exisiting configs but if you wish to make a PR to change the individual stock SRBs to look better feel free to open a pull request on github preferably with before and after screenshots and I can see if it can be integrated. The majority of pure stock configs were done before my time as well so I dunno what they all look like exactly. I did the restock configs as I use stock parts only with restock. However before you make any changes do keep in mind this is how the solid plumes are supposed to look, these are mostly from BDB but they are using the same prefabs as the stock ones. I believe the stock ones should look much the same with the particle limit not cramping their style. Yes its probably 1000 active particles plus per booster but like I said I havent been able to make a better performing prefab that looks as good or better. If anyone can I would be delighted to include such a prefab in the mod. This is quite easy simply delete the config file for the individual engine you wish to revert to stock effects and the realplume will be gone for that engine with no ill effects.

Ye I just made the payload fairings. The Centaur (and its insulation panels) is all Cobalt. The decals are done using the fantastic Conformal Decals mod by CineboxAndrew. It projects the decal onto the surface of the object no matter the shape hence it looks like part of the texture.

Why do you tell big lies?

Centaur early fairing The 3 different Centaur shrouds available for now Left to right: OAO derived long shroud, OAO derived short shroud, Early shroud. Last two are not adjustable but the first one is fully adjustable in length.

Alright just to say something about the 1.10 bugs. We had not planned on any further patch releases for BDB v1.6 with the development of v.1.7 quite far along. If the mod continues to not load we might look into another hotfix for v1.6 if necessary but we will have to evaluate after KSP 1.10.1 which will hopefully bring some fixes.

Just in anticipation of the new Centaur SLV3B/OAO shroud, SLV3B standalone (none historical), Atlas Centaur long shroud derived from SLV3B used for OAO 2 initially and then other stuff.

You can always change the spacecraft volume as suggested above. Alternatively it is possible to patch out the sounds using some module manager wizardry but I expect that would be a bit tricky. There's no easy way to do it that comes to mind. Pestering for updates is against forum rules. I expect the current release works fine in 1.10 but its not tested. An official update will happen when I have time for it. You can get an older version of the RealPlume-Stock and replace relevant configs . this has to be done on an engine by engine basis. https://github.com/KSP-RO/RealPlume-StockConfigs/releases

If you have BDB parts with the SAF module that means you must be using the Development branch. Since SAF is not a dependency for the current BDB 1.6 release our netkan will only be updated once BDB 1.7 is out of dev and released. If using the dev branch it is suggested to check the bundled dependencies (which are kept up to date in the github folder).

clustering a lot of engines always comes with a danger of performance hits. Its just the nature of how particle effects work. The the stock rapier and aerospike in particular use a fairly complex plumes which doesnt help matters if you you are using several of them. You can press ctrl+P (option+p on mac) to open the smokescreen menu and reduce the maximum number of active particles. Lowering it too much can make plumes look bad but you can try to find a balance that works better for you. The plumes for those two engines were custom made but not by me so Im not 100% familiar with the config but I'll see if theres any optimisations that can be made when I get around to the next update. re upgrades your PC is fine, KSP in general is not a well optimised game and as such does not provide the best platform for performance especially when you start to mod it. You must judge for yourself where the right balance is for you and if you want to continue to use realplume. Keep in mind you can also delete configs for specific engines if you like so that they will revert to stock plumes while you use realplume for other stuff.

Ah fair enough. And no worries the available tone mapping tools are pretty powerful as is and I’ve been really enjoying using them. I did have some limited success with LUTs using ReShade previously where I would take a neutral screenshot, edit it in photoshop, and then apply those same edits to a neutral LUT texture template. It’s potentially a powerful tool as it lets you create colour profiles using the more comprehensive editing tools of an image editor. but I expect would have niche appeal among your user base so totally understand it’s not a priority.

If we were doing this we could also have a methalox config for the LMAE. Known as the RS18, it was considered for the Altair ascent stage but cancelled after failing to make the cut for the constellation program.

Regardless of what that old post might have (speculatively) said, I have no reason to believe that RealPlume and smokescreen would have any effect on this. This mod only affects moduleEnginesFX and the EFFECTS node, and has nothing to do with ModuleJettison. I've no idea what the cause of that might be or its solution, sorry.

Will take a look for the next update.

Tiling multiple decals across one texture is just one way to do it. See my post on the previous page for a suggested way to patch individual textures into the generic decal part. (if you want to avoid cluttering the flag picker)

As far as we know the current official release should be fine in 1.9. Can't guarantee that but in general part mods that worked in ksp 1.8 tend to be fine in ksp 1.9 Missing parts are probably due to very old parts in the previous BDB1.5 release that got deleted a few weeks after the BDB1.6 release. If the weird textures are on Titan (prometheus) parts, those are old parts that had their textures deliberately crushed because they have been replaced by brand new Titan parts in the BDB1.6 release (they will be deleted entirely in the next update)

BDB parts are balanced against stock *parts*. If they seem overpowered, its because the stock part balance is an overpowered balance (deliberately so the game is easier). If this sounds strange to you think about how small a rocket is needed to get to the moon in stock parts vs what is required in real life. It has long been the case that if you want your rockets to have more realistic performance you need to play at 2.5/2.7 scale. This is true for bdb, and *its true for stock parts as well*. For instance both the BDB Titan II and the making history Titan II can send the Gemini/Mk II all the way to the Mun at stock scale. But in 2.5x scale they have just enough Dv to get into low orbit, just like the real thing. Put simply no patch is required for BDB parts at stock scale. Their performance is similar to stock parts (broadly speaking)

Any specific combination of parts? I used a titan about a week ago, I usually stage the lr91 4-5 seconds prior to decoupling but just curious about the thermal patch i think I staged at 10 seconds prior and it was still fine (Lr91-aj11).

The author of the mod already stated in a reply to you that you can indeed use the flags folder. There is a dedicated part that uses flags and its right there at the top of the features list. In fact both of my screenshots on this page were all made using flag based decals. If you didn't want to do this (for instance you wanted something with a different aspect ratio and didnt want that in amongst the game flags) , the best thing probably would be to patch in extra subtypes to the generic decal part like so: the following patch is untested, its based on something I did during a beta test of the mod, i havent had a chance to try the release. @PART[conformaldecals-generic]:AFTER[ConformalDecals] { @MODULE[ModuleB9PartSwitch] { SUBTYPE { name = yourdecalname //must be unique to each subtype title = yourdecaltitle // visible title primaryColor = Black // not functionally important, used for the list in the part action window secondaryColor = White MODULE { IDENTIFIER { name = ModuleConformalDecal } DATA { TEXTURE { name = _Decal //same for all subtypes textureUrl = file.path.to.your.texture //path to your textures somewhere in a folder in gamedata } } } } SUBTYPE { .... etc } SUBTYPE { .... etc } } }

Super stoked to see this released! I was shocked at just how effectively the the decals project onto and conform to the part. With other decal mods theres usually a lot of fiddling with the offset tool and scaling to get it to not clip and also not be floating over the part to some extent. This just works! The fact that it accounts for features on the normal map (like the ribbing on the tanks) is another very cool feature.

Yeah itll be fine. The required fx models will still be in plume party and the configs to apply them to SOCK parts are within SOCK part configs themselves.

I dont see how realplume could cause that. Can you reliably reproduce the problem? And if so does it go away when realplume is removed? In any case I really seriously doubt how smokescreen could be affecting the planet rendering. Im not entirely sure. Plume party has two components 1) provides plume models for people to use in their own mods 2) configs to replace the plumes for stock. The second part could potentially clash, not 100% sure. In which case you should remove the configs folder inside PlumeParty. I believe the version of plume party typically bundled with other mods such as Knes usually dont have the configs folder anyway. If you are installing PlumeParty on its own, there is no need to install it since stock parts will be covered by realplume. If you are installing it because its a dependency for another mod, then removing the configs folder should solve any potential conflicts. Its still important to have PlumeParty in this case since the effects might be used in the mods engines not covered by realplume or even for rcs plumes.

Absolutely. Please make a PR to the v1.7 development branch if you do so. I suspect the probe cores are covered by some generic blanket patch within RA that covers parts with both antennas and command.

It should be pointed out that things change frequently on the development version. We wouldn't recommend using that in a save you care about unless you are willing to take the risk that there might be bugs or even craft breaking changes from time to time. https://github.com/CobaltWolf/Bluedog-Design-Bureau/tree/v1.7.0-Development

OAO-3 Copernicus parts are now up on github. Also added Tarsier space tech and Research bodies compatibility. If anyone uses those mods let me know if there are issues. I only did a cursory test for TST. Since OAO-3 only has one instrument, I made the lower block a customisable service module. The top and bottom covers are optional and the front and rear panel are deployable doors. Hopefully people will find it a useful legoable part.

You're going to have to give more information Which version of BDB? Which version of KSP? Which parts are affected? A screenshot or two of some of the craft loading errors would help too. A logfile is essential Finally you said that you havent updated KSP or BDB recently and that its *mostly* BDB parts that are affected (so other mod parts are also affected?). This suggests the root cause is not BDB but you need to help us to help you by providing a lot more information.