Rodger

I still can't replicate, and both the modules in question look the same in both your and my config cache. I don't see anything weird going on patch-wise, and no errors to do with the fuel cells (and the only errors on related parts you had, to do with B9 UI groups, I also had in my game). I did happen to see "AlternateApollo" is probably installed incorrectly, having "AlternateApollo-1.8.1/GameData/AlternateApollo" in gamedata. But honestly no idea what might be causing the other issue.

Tags added, thanks. And the Fuel Cell patch seems to be working fine for me, consuming the correct fuels. Was it still using monoprop, or not doing anything? Might be a log/configcache situation. This is I think due to the in-dev .png normal maps, and version 1.35.1 of KSPCF. Its fixed in 1.35.2

Thanks for testing. I've made a patch, but I'm not sure how good it is - if you want to try it out and let me know how it feels. It still seems like it's wanting to roll around a lot. Do you tweak the control surfaces much to get it working well? The numbers are green at least: the test patch: https://drive.google.com/file/d/1fTCFMe-wkAEqmY4t4tfjMXPIpnCS98jn/view?usp=sharing

Sorry I didn't see this earlier, but there was a fix about 9 months ago for this issue on github, I think it's after 1.13 was released though. If you want to use TACLS still, you can just download this patch: https://raw.githubusercontent.com/CobaltWolf/Bluedog-Design-Bureau/master/Gamedata/Bluedog_DB/Compatibility/TAC-LS/Command.cfg and place it in the Gamedata/Bluedog_DB/Compatibility/TAC-LS/ folder. AVC should be fine to use too, it was only MiniAVC that had issues.

I’ve tested the x15 with FAR and it seemed to fly ok (I couldn’t tell much difference to stock in terms of handling at least), and I’m not even sure what would need manually setting for a FAR patch, as it automatically generates everything from the mesh as far as I know. If someone knows otherwise though, and finds something critical that needs patching, please @ me and I can look into it more.

BTW @Taco Salad, I think what happened is CC tries to replace the normal fuel switch with that 'Edit Tanks' button, so the LDC and Atlas tanks are the only CC patches that actually worked, and other tanks that still had normal fuel switches are tanks that couldn't be patched. It seems like the CC patches are auto-generated, and don't cover enough configuration options for BDB, and was possibly being done in the wrong patch order pass to be effective too.

Not sure how this would happen, if you post your ksp.log I can have a look

There should be a fuel switch yes. Do you have fuel switches on other tanks?

I've not seen that before, and honestly at this point I'd consider starting from scratch, with a fresh ksp install, and using CKAN mod manager to install everything. If you really want to try troubleshoot the current install, maybe try this forum for general modded support https://forum.kerbalspaceprogram.com/forum/70-ksp1-technical-support-pc-modded-installs/

BDB (and near future spacecraft in that log) is just reporting that something it's trying to use is not present, likely due to some installation error. In this case it seems to be the folder in your GameData WildBlueTools, which should be providing an ingame resource and a plugin, which are both not present in your log. The folder being there makes BDB assume WildBlueTools is installed, so BDB is expecting the resource to be present, and when it isn't causes a b9 error. You should first remove the folder WildBlueTools, and either reinstall it fully (esp if it's required for something else in your install), or just leave it removed. If after this you still get a b9 error, a pic of the error can make it easier to diagnose too There's also a lot of errors related to the older version of tweakscale/KSP Recall, I'd recommend removing everything related to them and replacing with Tweakscale Rescaled, which will fix those exceptions, and generally be a less buggy version. You should be able to switch from old TS to TS:R without issues with craft or anything. (as long as you fully remove everything that was installed with old TS/Recall)

I made a patch for myself to address this issue a while ago, it might be worth a try: @PART[RobotArmScanner_S*]:FINAL { @MODULE[ModuleRobotArmScanner] { @cancelScanDistance = 1 @emergencyStopDistanceFromSurface = 0.1 @firstJointRotationLimit = 95 } } Just copy that into a new txt file inside your GameData folder (I keep all my own patches inside a folder like "MyPatches" inside GameData to keep track of them), and change the extension from .txt to .cfg

That's certainly one of the biggest log files I've seen in a while, I recommend zipping them, it makes them a ton smaller to download lol The log is almost entirely kopernicus errors though, I'd try reinstalling that (and dependencies) to start with.

I've fixed this and it's on dev branch now, thanks

The heat shields have the same stats as stock shields already. You’ll have to either adjust your reentry to be shallower, and/or decelerate at kerbin. Returning from Eve with an AP around Duna actually means you need to decelerate more than a plain Duna return too - anything beyond the ideal hohmann transfer (lower PE or higher AP, the further you are from matching the target planets solar orbit) means more energy to shed. I’d say direct return from Sarnus probably voids the shield’s warranty too lol Also what system scale are you playing at? Larger scales will have a huge impact on heat shield performance. You could always just patch them yourself if you really want to tweak them too.

Barring installation issues, if you’re playing with the setting for individual part unlocks with funds, you’ll still need to go to R&D, unlock the appropriate nodes and purchase each part to use them (or pay for the full node unlock). Otherwise it should be fine with either Community Tech Tree or the stock tech tree. Other third party modded tech trees aren’t supported on our side, if they have issues it’s best to report it to them.

You can zip the log and upload to something like Dropbox or google drive. However first, this is possibly just an issue with Tweakscale - if you have it, I’d suggest fully uninstalling it (and ksp recall) and installing Tweakscale Rescaled instead, it is much more stable than the other version.

@theJesuit Hey, just noticed a minor error from some of the simplex patches, which are using FOR[KerbalismDefault], causing incorrect activation of patches depending on default kerbalism The following patches: [LOG 03:34:14.606] :FOR[KERBALISMDEFAULT] pass [LOG 03:34:14.668] Applying update KerbalismSimplex/Support/SimplexNFSpacecraft/@PART[*]:HAS[@MODULE[ModuleCurvedSolarPanel]]:FOR[KerbalismDefault] to NearFutureSolar/Parts/SolarPanels/deploying-curved/nfs-panel-deploying-curved-25-1.cfg/PART[nfs-panel-deploying-curved-25-1] [LOG 03:34:14.668] Applying update KerbalismSimplex/Support/SimplexNFSpacecraft/@PART[*]:HAS[@MODULE[ModuleCurvedSolarPanel]]:FOR[KerbalismDefault] to NearFutureSolar/Parts/SolarPanels/deploying-curved/nfs-panel-deploying-curved-375-1.cfg/PART[nfs-panel-deploying-curved-375-1] [LOG 03:34:14.668] Applying update KerbalismSimplex/Support/SimplexNFSpacecraft/@PART[*]:HAS[@MODULE[ModuleCurvedSolarPanel]]:FOR[KerbalismDefault] to NearFutureSolar/Parts/SolarPanels/static-curved/nfs-panel-static-curved-25-1.cfg/PART[nfs-panel-static-curved-25-1] [LOG 03:34:14.669] Applying update KerbalismSimplex/Support/SimplexNFSpacecraft/@PART[*]:HAS[@MODULE[ModuleCurvedSolarPanel]]:FOR[KerbalismDefault] to NearFutureSolar/Parts/SolarPanels/static-curved/nfs-panel-static-curved-375-1.cfg/PART[nfs-panel-static-curved-375-1] [LOG 03:34:14.704] Applying update KerbalismSimplex/Support/SimplexNFSpacecraft/@PART[*]:HAS[@MODULE[ModuleCurvedSolarPanel]]:FOR[KerbalismDefault] to TundraExploration/Parts/RodanV2/TE_CD2_TRUNK.cfg/PART[TE_18_DRAGONV2_TRUNK]

Looks like it's because Kerbalism Simplex is incorrectly causing BDB to think stock Kerbalism is installed due to some incorrect syntax. For a temporary fix, you should be able to change the first line in GameData/Bluedog_DB/Compatibility/Kerbalism/KerbalismCargo.cfg @PART[bluedog*,Bluedog*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[#switcherDescription[Cargo]]]:NEEDS[B9PartSwitch,KerbalismDefault,!LRTR,!Profilesimplex]:AFTER[Bluedog_DB_1]

If you’re using RSS without RO, you could try this It should work fine in 1.12 still. We’re unlikely to be providing part scaling patches for 10x on our end though, especially as SMURFF exists. There also shouldn’t be a b9ps warning with kerbalism, there are patches that should be allowing them to work without error. @Publius Kerman if you want to post a link to your zipped ksp.log I can check if somethings wrong in that regard.

The parts are scaled like stock ksp, which is .625x give or take, with engine performance being 25% irl thrust, and quite heavy dry mass for tankage. This ends up being “overpowered” for stock scale (just like stock parts are), and ideal for 2.5-2.7x scale. BDB isn’t made for RO, so we don’t provide any scaling patches for RO/RSS, that’s all done on the RO team’s side, and its a fair bit more complicated than just a scale multiplier. RO uses entirely different custom systems for engines and resources, and there’s likely mass ratio changes for tankage too. There should be some BDB RO patches out there, though from what I’ve heard they are unfinished. (The only help I can offer is if you try them and get a missing resource definition error on startup, you can press esc to skip the error instead of closing ksp)

Seems like it might be due to some other mod, as it’s unlikely to be something BDB would be affecting. Would need a full ksp.log to look into it either way.

Unlikely afaik, the unofficial wiki might as well be official to be honest. The included craft files might be some help if you’re unsure about some craft

Search your GameData folder for any instance of 'RealNames.cfg' and remove, otherwise will need a KSP.log to diagnose.

Basically the only such texture (ie shared among multiple parts) would be the glow from the insides of some engine bells lol As it is, the way it’s currently set up with pruneable part family folders, is basically the same functionality already. Just remove rocket family folders like atlas/titan/saturn and leave stuff like probes/apollo/skylab and you’ll be left with a lot of the science with a lot less parts overall.

Notepad++ can just search inside all cfg files in a dir