Zorg

You can share the configs you made and I can help as much as I possibly can. However keep in mind I am only looking after "RealPlume" which only contains the presets and "RealPlume-stock" which gives those presets to stock parts and stockalike mods. Realism overhaul is a giant mountain of configs with which I am mostly unfamiliar. But without seeing your configs and or logs its impossible to say what exactly is going on with your installs.

Yeah the old Ranger was mostly incomplete. All new fancy parts have been made and are in the github development branch. We are trying to push out a new release as soon as we can. Looks like Friznit might have jumped the gun a little by putting the new Rangers on the probe page here https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Satellites. The new upcoming stuff is meant to be confined to the "Issues" section https://github.com/friznit/Unofficial-BDB-Wiki/issues/43 until the next release.

To be honest looking closer I am now a little unsure of what to do. What BDB wants to do: several solar panels switch the output for certain B9 subtypes. In the IDENTIFIER node it looks for ModuleDeployableSolarPanel https://github.com/CobaltWolf/Bluedog-Design-Bureau/blob/v1.7.0-Development/Gamedata/Bluedog_DB/Parts/ProbeExpansion/OAO/bluedog_OAO_solarUpper.cfg SUBTYPE { name = OAO1 addedMass = -0.0025 MODULE { IDENTIFIER { name = ModuleDeployableSolarPanel } DATA { OUTPUT_RESOURCE { name = ElectricCharge rate = 2.5 } } } } The problem here is I cannot patch the name of the module in the IDENTIFIER node with a NEEDS on Kopernicus since it appears that some planet packs like JNSQ are disabling the switch to the Kop version of the module with useKopernicusSolarPanels = False BDB itself choosing to use useKopernicusSolarPanels = False is not ideal as presumably this would cause problems with systems like Beyond Home with which we want to be compatible. With JNSQ carrying out its avoidance maneuver at LAST[JNSQ] and Kopernicus doing its actual solar module conversion at FINAL I guess the only thing we can do is engage in the dreaded Z wars and have a patch for LAST[zBluedog_DB] or something so that we can detect whether useKopernicusSolarPanels = False is being used or not and patch the solar b9 switches accordingly before Kop does its thing at FINAL. This seems messy and I really dont like it but I think it will work. I think this patch if its done like this should be in BDB so that we can keep it up to date easily as potential new parts are added. However If anyone has a simpler solution or any other bright ideas for BDB to work with all planet packs I would appreciate any thoughts.

Great thanks. Is this module used by Kopernicus in general or only multi star? If it’s the former we can make a fairly straightforward compatibility patch.

I think we would need to see logs from both of you. Is NateDaBeast also using a planet pack and if so is it also multistar? Whats common about all of those parts is that they are solar panels with a mesh switch. Associated with this mesh switch is a module switch that lowers the power output with the smaller panel sizes. If Kopernicus or the planet pack replaces the solar panel modules we can expect this switch to break. I expect the panels to still be functional but they wont be getting reduced output as intended for the smaller sizes. If this is indeed the case we would need to figure something out for compatibility.

Glad to hear. You may find Friznit’s unofficially official wiki a useful resource. I certainly end up referring to it when building stuff half the time https://github.com/friznit/Unofficial-BDB-Wiki/wiki

ah I misread the statement, thats a relief thanks.

Buggy and impossible in what sense? and how? More details and possibly screenshots or video are required. Apollo is due to be remade soonish but it hasnt been touched in ages and we havent heard any complaints about the RCS or docking/transposition. Some people do have trouble with CADS/APAS ports but that requires precise alignment.

A quick glance suggests this is because Community Resource Pack hasnt had its compatibility updated to include KSP 1.10.x. However CRP should continue to just be fine in 1.10. Please go to CKAN > Settings> Compatible KSP versions > and enable both KSP 1.10 and KSP 1.9. Everything should install now. BDB generally works just fine with CKAN, and we coordinate with the CKAN team to ensure our metadata files are up to date though its ultimately maintained by the CKAN people rather than in BDB's own repository. This situation was caused by one particular dependency not having had its metadata updated. And yes you can install some mods manually while still using CKAN for other things. Yes you just need to install the Dock Rotate mod alongside the dev branch.

If you wish to make a PR to RealPlume-stock you can make a folder for unkerballed start and submit. Or you can send make the PR to Unkerballed Start. Some mods keep their own files for RP compatibility. If you wish to use older plumes you can download an older version of realplume-stock. The prefabs for the older plumes still exist but you would need to get the engine configs from an older version. Up to you to pick and choose what configs you want from those versions. Thanks, I will remove that patch for the next update.

Cobalt would have the final word on this since he made that engine, its not necessarily straightforward given the engine was made without that setup in mind even *if* he wanted to.

The "showstopper" bug happens when two patches try to patch the same part. In this case it appears you have installed BDB twice into two different locations. Make sure that BDB is only at GameData/Bluedog_DB

That patch requires everything to be buffed to be specifically named in the patch. I guess its not yet been updated for the new RL10s (and Vega as well).

I've not seen any issues in either KSp 1.8.1 no 1.10.1, make sure that your B9 part switch and BDB dev install is up to date. If it is and there is still a problem, please post your module manager log and modulemanager.configcache files.

Oh I didn't realise a 3.125 to 1.875 was being discussed here I just added it in as a variant for the 3.125 to 1.5 adapter using the same textures since why not. Glad you find it useful. This sounded like a familiar problem. The key ``vesselType = Probe`` needs to be added to the part cfg so that the engine mount/avionics unit can actually function independently. It often gets missed in testing due to the presence of a probe core on the payload.