Rodger

Looks like there's a small bug where the patch "AngleCanMods/SIMPLEXTechTree/SIMPLEXTechTree-KerbalismConfig/@PART[FuelCell]:NEEDS[ProfileDefault]:FOR[KerbalismDefault]" is using FOR instead of NEEDS, causing other mods to trigger kerbalism patches. Just need to change it to NEEDS[ProfileDefault,KerbalismDefault], if that's the intended behavior at least

Hmm well if you and @Falcon Aerospace can zip your ksp.log (from main install directory) and modulemanager.configcache (from gamedata) and post them here https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/1378 (you can just drag the zip file into a github post), might be able to find some clues

Running the current version in 1.12.5 is not a problem. Those kind of B9PS errors will be more to do with the part mods those parts are from, or some incompatibility between those part mods and some other mod trying to edit them. Not B9PS itself. So I'd probably try posting those errors in the relevant mod's thread, or their github issues page if they have one. The main log people will ask for for support will be the KSP.log in the main install folder, the same folder as the KSP exe. Zip it and upload it to a file sharing service like google drive to share it (it's way to big to just post it on the forum).

Not really, all I can suggest is what I already posted above. I can't reproduce it at all, and the only clue is it's happened to someone else who also had very low fps. That person @Blufor878 also posted about how apparently they had some luck with assigning those engines to an action group for manual activation, so I'd say it's worth a try.

If “SWE” in your gamedata is Solid Waterfall Effects, that’s likely the cause of the ullage motor plumes being bugged. As for the J2 issue, all I can say is the low fps is the only thing that seems likely to have broken the deployment and activation. The dev for the deployable engines mod has retired from ksp1 as well, so your best bet is fist trying the action group workaround posted above, or maybe removing graphical mods like scatterer and EVE/upgrading your PC to get a more stable frame rate.

Yep, and I f you download the dev branch from github it’s available now, but I’m unsure when the next update will be released on space dock/ckan, could be a while. The temp fix I posted above you can just do in notepad, should be quite simple. Just delete the two lines I mentioned.

You may need to make sure you have the latest version of Waterfall

Might need a KSP.log, and possibly ModuleManager.ConfigCache, to see if anything's changing something that would cause this. From looking at the base configs, it should be compatible with both the tantares parts. But going to test in-game. Edit: Looks like they aren't compatible due to the angle-snap docking feature the BDB port has, which the tantares ports don't use. If you want to edit a config to get it to work right now, you can go to GameData/Bluedog_DB/Parts/Apollo/bluedog_Apollo_APAS75.cfg, and comment out/delete the lines "snapRotation = true" and "snapOffset = 60", lines 61/62. Edit 2: We'll be removing the snapRotation and snapOffset lines in the next patch (it's on dev branch now), so the above is the suggested fix in the meantime

Should be fixed now in KSPCF 1.29

So there's an interaction with Shaddy and KSPCF's new custom faster drag cube generation, where the translucent shaders cause drag cubes to generate incorrectly (the translucent parts will just be ignored). So if you have both Shaddy and KSPCF 1.28+ installed, you may get issues where translucent parachutes aren't slowing craft down enough. For now, you can disable the KSPCF drag cube generation feature if you want to keep using Shaddy, or just not use Shaddy until a fix is available.

Come across an issue where this mod is using FOR[KerbalismDefault] instead of NEEDS[KerbalismDefault], so it's declaring the pass that other patches are looking for to enable kerbalism compat. FOR should only really be used by the mod itself. Should be a simple fix, I think it's only in Compatibility/Kerbalism.cfg

Hmm yeah I can't reproduce it on my end, this may be the case. That may be an altitude when the planet changes how it renders in your visual setup which may cause lag, so that could be an explanation, though it's still odd that some lag would prevent the engine from firing. If you want to upload your KSP.log I can have a quick check, but not sure there'd be anything in particular that could cause this that would be visible in it.

Are you getting the issue when just staging the engines, without using a custom action group? Staging them should deploy them then start them automatically once deployed, with the single press of spacebar. If that’s not happening, what exact version of the j2 are you experiencing it with?

For a possible fix, you can try making a new text file anywhere in GameData, rename it to KSHBDBFix.cfg, and paste the following in there: @PART[bluedog_skylab_powerModule_radiator*]:NEEDS[Kerbalism,Bluedog_DB,SystemHeat,B9PartSwitch,zzzz_KerbalismSystemHeat]:AFTER[zzzz_KerbalismSystemHeat] { @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[meshSwitchSide]] { @SUBTYPE,* { @MODULE { @IDENTIFIER { @name = SystemHeatRadiatorKerbalism } } } } }

Just from looking at what you have installed, for the first error I suspect Kerbalism / KerbalismSystemHeat may be causing issues for parts that switch radiator capacity. It's not something we test against or do compatibility for, but they may be able to add compatibility on their side. The 2nd error doesn't seem to be related to BDB, that's a Cryotanks tank type afaik. In the log, there's b9 tank type errors, but they mention "FBCM" instead of "LH2OCryo", and may be related to parts from the mod Flat-Bottom Shuttle Systems. In fact, it looks like that was fixed 9 hours ago, so try updating that mod.

Keyboard controls would probably be good enough, as long as reliance on MMB dragging for panning is gone. The 'horizontal' VAB mode camera panning is especially weird atm, you pan the mouse up and down to move the camera sideways lol The shift-scroll combination for 'fast zoom' is also pretty weird, doesn't seem different enough to the normal scroll zoom to justify it. It could be scrapped to make room for a more useful control, like holding shift for a SPH pan or something.

Being so reliant on MMB means you can't play on most laptops without an external mouse. This was no issue in KSP1, you could easily play on laptops without control issues. The main change I'd like to see is set scroll wheel scrolling to vertical camera panning, with shift-scrolling for zoom. Even with a mouse, I'd prefer this control scheme. This wouldn't remove MMB usage entirely though, so maybe allow that to be rebound to a modifier key + left or right click for other uses, like focusing a part. It would also free up MMB drag for a SPH style free pan, which is a more niche use, so not required for play thus still allowing laptop use (maybe it could also be bound to modifier + arrow key), but would be a nice addition. The lack of SPH camera controls in KSP2 is just a straight downgrade/missing feature.

You can post bugs here and tag me, or in the issues section on the github https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues

If you have System Heat installed, the bdb boiloff mechanic should be disabled automatically.

Thanks, looks like the SSS patch isn't getting applied. And after checking, it seems like the last release of SSS doesn't actually have the required patch. If you download this (just save link as): https://raw.githubusercontent.com/CessnaSkyhawk/SkyhawkScienceSystem/main/ModSupport/Bluedog_DB/Apollo_CrewPod.cfg and place it in your GameData/SkyhawkScienceSystem/ModSupport/Bluedog_DB folder, that should fix it for now, until there's a new release of SSS. Same goes for @Royalswissarmyknife

This is fixed for the next version, but for now you can download and install this patch

Actually @Spike88 if you're able to, could you zip and upload the 'ModuleManager.ConfigCache' file from your game data somewhere and link it? It would help see if the SSS patch is working or not.

So SSS does patch that part's required upgrade: https://github.com/CessnaSkyhawk/SkyhawkScienceSystem/blob/main/ModSupport/Bluedog_DB/Apollo_CrewPod.cfg But from looking at that patch I don't see how it wouldn't work. Perhaps patch order? I'd say it's likely fine to ignore at least, and I'd be interested if you can actually unlock the probe core functionality with SSS installed in-game.

@Spike88 and @Queen Ultima, that could happen if either the upgrades.cfg and/or the Shared folder are not present in the Parts folder, causing that upgrade to not exist. The Apollo capsules have an option to enable probe control, unlocked via that upgrade, so unless you want to use the probe option, and the parts still loads, there should be no issue. I could also make it an optional patch in BDB Extras, like the Gemini and Mercury pods if it causes issues.

It's 1.25 / 0.9375