NyanTurian

It seems my earlier theory about Kerbalism being a conflict may be true? I removed Kerbalism, Kerbalism System Heat, Rational Resources Kerbalism, and SIMPLEX Kerbalism using CKAN. Most of my installation is through CKAN, apart from a few mods. No more fatal error, or warning of any kind like before. Does Kerbalism itself conflict with this mod? https://www.dropbox.com/scl/fi/tst041taqngxkhiy5ndnr/Player_NoKerbalism.log?rlkey=01b2up7reezs8pb4ogouyoi8h&dl=0 EDIT: I have Kerbalism with its default config and Kerbalism System heat installed now without fatal errors, but I do get a warning about a Skylab power module radiator. Similar error was in the previous log. [WRN 19:04:33.441] Warning on PartSubtype Double on module ModuleB9PartSwitch (moduleID='meshSwitchSide') on part bluedog.skylab.powerModule.radiator: Could not find matching module [EXC 19:04:33.442] Exception: Could not find matching module B9PartSwitch.ModuleMatcher.FindModule (Part part) (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.ModuleModifierInfo+<CreatePartModifiers>d__10.MoveNext () (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.PartSubtype.Setup (B9PartSwitch.ModuleB9PartSwitch parent, System.Boolean displayWarnings) (at <a3c2951fc74e4639820ef37d2d29f386>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) B9PartSwitch.PartSubtype:Setup(ModuleB9PartSwitch, Boolean) B9PartSwitch.ModuleB9PartSwitch:InitializeSubtypes(Boolean) B9PartSwitch.ModuleB9PartSwitch:GetInfo() PartLoader:CompilePartInfo(AvailablePart, Part) <CompileParts>d__56:PartLoader+<CompileParts>d__56.MoveNext_Patch0(<CompileParts>d__56) KSPCommunityFixes.Performance.<FrameUnlockedCoroutine>d__62:MoveNext() KSPCommunityFixes.Performance.<PartLoader_CompileAll>d__58:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

Oh I see, I didn't realize the different branch. Thanks for the guide. I installed the Bluedog_DB folder from the Bluedog-Design-Bureau-1.14-Development.zip, but I still have a fatal error. https://www.dropbox.com/scl/fi/5clq15qbmwm8cl2o8jiu3/Player.log?rlkey=fmfdxe9njjr7xuj3fcjjembay&dl=0

I'm still encountering that issue despite changing that cfg, and then later replacing the entire Bluedog_DB folder. There might be something off about my install. Here's my player.log... https://www.dropbox.com/scl/fi/5clq15qbmwm8cl2o8jiu3/Player.log?rlkey=fmfdxe9njjr7xuj3fcjjembay&dl=0

Which cfg file do you mean? I did a comparison of the bluedog_Apollo_AARDV_Cargo_Block1.cfg and it matches the one from the master on github.

Has anyone had a similar issue with the current version of the mod? PartLoader: Compiling Part 'Bluedog_DB/Parts/Apollo/bluedog_Apollo_AARDV_Cargo_Block1/bluedog_Apollo_AARDV_Cargo_Block1' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) DontDestroyOnLoad only works for root GameObjects or components on root GameObjects. (Filename: Line: 589) Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype Supplies ---> System.Exception: Exception while loading field tankType on type B9PartSwitch.PartSubtype ---> System.Collections.Generic.KeyNotFoundException: No tank type named 'Supplies' exists I'm likely missing something somewhere since this is a new install. The mods I have installed are somewhat lengthy, but Kerbalism comes to mind as being possibly incompatible? When I uninstall Bluedog, these errors disappear. Which mods changes the AARDV Cargo vehicle to have supplies?

Did you manage to disable the ullage simulation? I made a career save with ullage disabled but ullage was enforced. When I raised the ignition chance to 100%, ullage was still being enforced. EDIT: I wanted to say thanks for maintaining this mod linuxgurugamer, it's a good alternative to have.

Yes, it was. It seems to be RescaleZ causing the problem. I switched to Realistic Rescale 1.1.1 (3.2x), the Corona heatshield works correctly now and can handle a very aggressive reentry. For comparison, I tested the Hermes heatshield again, and that was fine too. I copied the atmosphere scale from another 3.2x rescale config, so that I have a 98 km atmosphere height through @Atmosphere = 1.12 and @atmoTopLayer = 1.25. Realistic Rescale normally has the stock 70 km height.

Yes, always heatshield forward. I tested on my old 1.11 JNSQ install and used up the entire ablator, but the max critical temp was stopped around 2,200K and the drag managed the rest. That was on a trajectory from 127km x 127 km, 54 m/s burn down to 129km x 31 km. A major difference is the atmosphere height being 85km in JNSQ and 70km in RescaleZ. Something in one of RescaleZ's configs might be outdated, maybe in the Physics.cfg where it mentions ablator.

Hello, I've been having some issues with the Corona heatshield (SG-RV3) overheating during reentry. It would seem the part doesn't generate sufficient drag to decelerate the return capsule before it manages to melt at around 30 km. I'm using RescaleZ 365 3.2X with 100% reentry heating and deorbit using about 40 m/s from 119km x 119km to a periapsis of about 30 km (~4,100 m/s velocity). I had some nearly critical temperatures with JNSQ in a previous version, but that is a smaller scale. Compared to other heatshields, this one severely under performs. It tends to fall apart before it's finished using up its ablator. I tested the Hermes capsule and its heatshield, and the stock 2.5m capsule with stock heatshield, and those worked as intended from the same trajectory. Attaching the stock 0.625m heatshield to the bottom of the Corona pod (SG-RV1) functioned properly and decelerated without issues. Oddly enough, the pod itself decelerates better than the heatshield after the heatshield melts.

Hello, I'm trying to understand this error I'm getting from Real Fuels-Stock. I have 12 errors like this regarding Bluedog Design Bureau parts that contain SolidFuel. This is from the Github master not the current release version. Here is the error those changes give: Is there a syntax error here or a missing module? There are other parts in the RF_BDB_Uppersolids.cfg that follow a similar structure like the [bluedog_UpperSolids_BE3] which don't produce any errors. EDIT: Deleting the part changes from RF_BDB_Redstone works.

I downloaded the most recent master file from Github for compatibility with the Bluedog Design Bureau v1.9 after I was receiving ModuleManager errors with Vega and Scout. It seems now there are more errors to deal with. Could I be missing a dependency? So far I have these to test with: B9PartSwitch, Bluedog, CommunityResourcePack, DMagicScienceAnimate, RealFuels, RealFuels-Stock, ReStock, SimpleAdjustableFairings, SolverEngines, Waterfall, WaterfallRestock, ModuleManager.4.2.1 The current version of these configs doesn't seem to include the Sergeant solid motor but the latest master on Github does? It seems more confusing when [bluedog_Athena_Castor30] in the RF_BDB_Peacekeeper.cfg doesn't create any errors. I tried editing the config to match the Castor30 as closely as possible, but still errors. What's missing? EDIT: It seems there may have been some duplicates involving that Sergeant solid motor. Deleting all of the changes for that part from the RF_BDB_Redstone config, it shows the correct amount of PSPC. The other errors in RF_BDB_Scout and RF_BDB_Uppersolids weren't helped by deleting since they still use SolidFuel. I suppose I'll wait for a proper update.

I've been trying to produce a patch to reduce fuel tank max temperature but exclude spaceplane parts MK2 and MK3. I can't seem to exclude them by tech required however. @PART[*]:HAS[~TechRequired[highAltitudeFlight]|[supersonicFlight]|[experimentalAerodynamics]|[heavyAerodynamics],#category[FuelTank]]:Final { @maxTemp = 1200 } @PART[Size3*,externalTankRound,externalTankCapsule,bluedog_DeltaIV_DCSS_5m,bluedog_DCSS_Tank]:Final { @maxTemp = 1200 } But I did find a solution by keeping the correct temperature for certain parts. @PART[*]:HAS[#category[FuelTank]]:Final { @maxTemp = 1200 } @PART[Size3*,externalTankRound,externalTankCapsule]:Final { @maxTemp = 1200 } @PART[mk3Fuselage*,adapterMk3*,adapterSize3*,adapterSize2-Mk2]:Final { @maxTemp = 2700 }

Has anyone produced a patch to reduce fuel tank max temperature but exclude spaceplane parts MK2 and MK3? EDIT: This works. @PART[*]:HAS[#category[FuelTank]]:Final { @maxTemp = 1200 } @PART[Size3*,externalTankRound,externalTankCapsule,bluedog_DeltaIV_DCSS_5m,bluedog_DCSS_Tank]:Final { @maxTemp = 1200 } @PART[mk3Fuselage*,adapterMk3*,adapterSize3*,adapterSize2-Mk2]:Final { @maxTemp = 2700 }

Oh thanks, its working now! I installed manually it, so I might have missed that dependency.

I noticed on my new 1.10.1 install that Werner Checker hasn't shown up since I had started playing Career. Looking my at KSP.log, I noticed it mentions a dependency called ButtonManager v1.0.0. Line 907: Load(Assembly): WernherChecker/Plugins/WernherChecker Line 907: Load(Assembly): WernherChecker/Plugins/WernherChecker Line 911: AssemblyLoader: Loading assembly at D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WernherChecker\Plugins\WernherChecker.dll Line 911: AssemblyLoader: Loading assembly at D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WernherChecker\Plugins\WernherChecker.dll Line 947: AssemblyLoader: Assembly 'WernherChecker' has not met dependency 'ButtonManager' V1.0.0 Line 951: AssemblyLoader: Assembly 'WernherChecker' is missing 1 dependencies Line 1200: WernherChecker Line 21321: Load(Texture): WernherChecker/Images/icon-24 Line 21325: Load(Texture): WernherChecker/Images/icon-38 Line 21329: Texture resolution is not valid for compression: 'D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WernherChecker\Images\icon-38.png' - consider changing the image's width and height to enable compression Line 21333: Load(Texture): WernherChecker/Images/selection Line 21337: Texture resolution is not valid for compression: 'D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WernherChecker\Images\selection.png' - consider changing the image's width and height to enable compression Line 21341: Load(Texture): WernherChecker/Images/settings Line 21345: Load(Texture): WernherChecker/Images/tooltip_BG Line 21349: Texture resolution is not valid for compression: 'D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WernherChecker\Images\tooltip_BG.png' - consider changing the image's width and height to enable compression Line 71729: WernherChecker Line 87151: [LOG 20:10:12.663] :BEFORE[WERNHERCHECKER] pass Line 87152: [LOG 20:10:12.663] :FOR[WERNHERCHECKER] pass Line 87153: [LOG 20:10:12.663] :AFTER[WERNHERCHECKER] pass Do you need my full log for this?

Hello, I wanted to ask: Does this support KSP version 1.7.3? I looked over the thread and saw that a few other people asked similar questions but there was no clear answer for support of 1.7.x. Has this shifted entirely into 1.8.x?

I recall something like RealFuels having its own engine module... I'll have to switch back to using SMURFF for the necessary adjustments. Thanks for clearing this up.

Hi, I've been trying to use Real Fuels to recover my first stage with powered landing but it continues to be destroyed well below 2600 m/s. StageRecovery DR velocity is set to 3000 and I'm using Rescale! 6.4x, which raises the atmosphere height to 112km. I noticed in the Info tab in the mod's window that it wasn't registering any propellants being used, despite the other requirements for powered landing being satisfied. Earlier in the thread, it was mentioned using strange or different fuels would be problematic. Is this still the case for Real Fuels or are requirements not satisfied for powered landing? Edit: I was testing a lower landing velocity and checked the in game console. It says something like: [LOG 07:52:55.509] [F: 36522]: Vessel Untitled Space Craft Probe was on-rails at 1.0 kPa pressure and was destroyed. [LOG 07:52:55.510] [SR] Controlling mod is null [LOG 07:52:55.513] [SR] FMRS is not active. [LOG 07:52:55.514] [SR] Searching in RecoveryQueue (0) for e8762eec-0fa0-4d86-9279-b4a4b95a6236 [LOG 07:52:55.520] [SR] Vt: 37.4546852606997 [LOG 07:52:55.521] [SR] Trying powered recovery [LOG 07:52:55.523] [SR] Attempting to use engines to reduce speed from 37.4546852606997 to 4 [LOG 07:52:55.524] [SR] No kerbal pilot found, searching for a probe core... [LOG 07:52:55.524] [SR] Found an SAS compatible probe core! [LOG 07:52:55.525] [SR] Target Velocity: 4 Final Velocity: 37.4546852606997 [LOG 07:52:55.525] [SR] Used following propellant amounts: [LOG 07:52:55.527] [SR] Stage was not recovered. Distance: 300.44km, Altitude: 29924m [LOG 07:52:55.527] [SR] D%: 0.958, S%: 0, Total: 0. Funds: 0 [LOG 07:52:55.532] [Vessel Untitled Space Craft Probe]: Vessel was destroyed. What does it mean by "Controlling mod is null"? Nothing is controlling the stage?

This is fairly trivial, but... I'm having some confusion regarding the way the procedural liquid fuel tank works with Liquid Hydrogen + Oxidizer. Other fuel tanks from stock and different mods using InterstellarFuelSwitch (currently installed) tend to create a much longer stage, usually around twice the size in volume, when Hydrogen is used. It seems that somehow the procedural LH2+Ox tank remains about the same in volume, yet holds much more fuel despite that. I have SMURFF installed, so that be incorrectly scaling something. Basically, is this the intended behaviour of the fuel tank? Thanks for keeping this mod going.

Congrats on the update! It's been a few months but I knew it would reach stable build. This is going to be epic flying in 6.4x rescale.

I see. I'll remember that whenever I change mod versions in career. I was using the master zip since the current release version of BDB gives me 10 errors in MM caused by using this mod and KScale64.

Hello again, I have downloaded the latest GitHub master zip as of today. There is an interesting problem I've noticed over the last master. Where has the Leo Nose Docking Module gone? When I installed the new mod files and loaded up my previous craft designed for the Gemini 8, I get an error saying I can't launch because the docking mechanism is locked, despite the fact I had purchased the part earlier. I've searched for it in the VAB menus and in R&D, and its completely gone.

I have downloaded the archive from your Github repository and I will be using it now. I was wondering, what should my SMURFF levers be set to for this BlueSmurff.cfg to work properly? I currently have them at tanklever = 1.0, enginelever = 0.8, podlever = 0.8. Should I reset all to = 1.0?

I haven't tried any GitHub versions. I'm using v1.01 of BDB currently.

The issue is that I'm not sure sure if that part is safe to use or will it affect the rest of the mod? Yes, the latest version of Sigma Dimensions (v0.60), Kopernicus (1.2.1-1), and KScale64 v1.302. I just flew a sort of Saturn V cargo lifter version with the 5.6m parts, like how Skylab was launched. There was some interesting effects with the engine mount reported as having an error in my KSP.log. After decoupling the S-IC from the SII, the ullage fired on the S-II and the retro rockets on the engine mount. Then I noticed about 30 seconds later the S-IC had exploded with lots of debris. The g-force tolerance was exceeded on the S-IC main tank by about 1000/50g and 110/50g on the 5.6m decoupler as the in-flight log wrote. The launch was otherwise successful. What is the intended delta-v of the S-IC + S-II + S-IVB with the cargo in the fairing? I managed 7,940 m/s with 33,000 kg of cargo. The whole Saturn V system had a LEO payload capacity of well over 100,000 kg, so this seems some what low.