Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Rodger

  1. The bigger fairings are new subtypes on the existing 6.25m fairing base. And @thunder175and @Nemitis, there's an update for FAR now, which along with the first patch I posted fixes the chute deployment with FAR. The patch is included in BDB's dev branch now too.
  2. Well it does confirm the issue being deployment while shielded at least, thanks for testing it. As for the other issue, it's also due to the parachutes being changed to RealChuteFAR, the parachute housing is trying to stage the chute and not being able to find it. That stuff's hard coded into the module though, so best I can do is disable that module when FAR is installed. Just means you might need to do more manual staging on aborts.
  3. @[email protected] patch will convert the parachute back to the stock module and enables shielded deploy, which may fix the issue (unless FAR stops stock chutes working?) https://drive.google.com/file/d/1-mST24I2XXVwHHCsP-K-8Fx8q1BSeA8R/view?usp=sharing
  4. Hmm, the latest version of FAR from a few weeks ago does mention "Respect shielding for chute deployment", so I'm going to bet on that being the issue, and because it's a FAR function, my patch for stock/realchute wouldn't work. I'll let the FAR dev know.
  5. Are you both using craft files, instead of building them fresh? There may be an old depreciated version of the chute in the craft file you're using. It should look like this: There's also an error from TweakChutes which is bundled in JNSQ, probably trying to patch a chute that's also getting patched to a RealChute module, but that's probably not a big issue. Otherwise it might be due to FAR making the parachute think it's fully stowed, so not deploying? Did you try staging the "Landing and control Module" first to pop off the drogue/nosecone? If this is the cause, this patch might help (just put it anywhere in GameData): https://drive.google.com/file/d/1-lhPDqaTrjeQtVGR_eb6F418BoEQNd1_/view?usp=sharing
  6. The community fixes issue was caused by the BDBNIC textures mod, and was just causing the game to never finish loading, so sounds like a different issue. If you can upload your ksp.log file somewhere (zipped if it’s big) and link it here I can have a look
  7. Yep go for it, it seems like that patch is working well on my end
  8. I wonder if you can use a B9PS module to switch the data in another B9PS module's subtypes... Yeah, at some point it's just a lot simpler to do a +PART instead lol
  9. Looks like that was due to not having a default subtype in the modules, before the subtypes got patched in separately. Should be resolved, see Buffalo2 thread.
  10. @Caerfinonand @Angel-125, it looks like it happens when you have Sandcastle but not WildBlueTools installed, which seems to imply something wrong with the patches in buffalo2/patches/B9PS.cfg, where the b9ps modules get added. So you can avoid it by installing WBT and using it's omni-storage feature. The "BEFORE[Sandcastle]" means it requires Sandcastle, not just 'run before sandcastle if it's installed', which seems like it might be the intended behavior? Otherwise you won't ever get the B9PS modules if you don't happen to have Sandcastle, so the ModuleInventoryPart patches might need to be separated out into patches with "BEFORE[Sandcastle]", and remove the "BEFORE[Sandcastle]" from the B9PS patches. And the actual error might just because there's no default subtype applied before patching in other mod's resources. Try this version of the patch: https://drive.google.com/file/d/1-i-LzPPmONzqotFppdDx0V-E0tW0Ksca/view?usp=sharing Place it here, replacing the old one: GameData/WildBlueIndustries/Buffalo2/Patches/B9PS.cfg
  11. It's very important to "familiarize yourself with the model" ...right? I'll just keep telling myself that lol Should be fixed now, thanks. I'm also soft-depreciating the methalox RL10-b-2 and a-4-1n separate part variants in favor of a subtype on the main engine parts. If any craft had them they will still work, but now you'll just be able to switch fuel types on the extendable RL10s. (I can't do the same for the main non-extending RL10, since it has multiple engine variants already, so that one's methalox version will stay as a separate part)
  12. I still can't reproduce it, with BDB (dev or master branch), RealChute, KSPCF 1.22.2, Kerbalism, SkyhawkScienceSystem, SkyhawkKerbalism, and even RSS. My ksp.log with it loading fully: https://drive.google.com/file/d/1-VVxAyKQwZ5G6ExApJt665BzgsHgxbbn/view?usp=sharing The fact the version change of KSPCF triggered it for you is probably a good clue still, but even with 1.22.2 I can't get it to happen.
  13. I've just launched my BDB testing install, with KSPCF, and RC both installed, and it launched fine... Some other people have had similar issues loading with realchute and BDB though, and we're not sure why yet. Everyone who's reported it had kerbalism installed too though, but unsure if it does anything to do with drag cube generation/parachutes?
  14. That’s just an optional patch in BDB, not the default setting
  15. We can't really give proper support for RO installs, maybe try the RO discord? But you could try this patch first: https://drive.google.com/file/d/1-OiSO4lwoEVtndGBZO3XDcqj4FfTCay7/view?usp=sharing Just place it somewhere in GameData. It may not do anything though, especially if there's a deeper cause for drag cube generation failing.
  16. If you make your +PART patch run in in the FINAL pass, it will have the restock models. eg: +PART[restocked-part]:FINAL { @name = new-part-name etc } If it isn't run in the FINAL pass, it's possible to copy the part before the models are swapped. Though I think restock swaps models in the "000_ReStock" pass, so just as long as your patch is after that alphabetically it should work too. It's generally best to use FINAL for personal patches anyway.
  17. It's not pulled into the main branch yet, but I have an updated version of BellaTU with fixes for the GLV decoupler, Titan I tank ends, a panel on the Transtage, the truss structure on the Centaur avionics, and a new simple set of textures for the Atlas CELV Skirt so it mostly matches the rest of the Atlas parts: https://github.com/Rodg88/Bella_TU/archive/refs/heads/dev.zip
  18. Disable the "Temporal antialiasing" setting in the scatterer settings window (the blue circle button on the toolbar when in the KSC view)
  19. Pretty much, we don’t have any active coders on the team. The bdb module was based on deployable engines anyway, and it’s more up to date this way. With this change, you’ll now be able to retract deployed engines in the vab instead of needing to replace it with a new copy of the part, and in flight they will retract when you shut down a deployed engine.
  20. Just a heads-up for people using the dev branch, the current version of it has a new dependency - DeployableEngines. A copy is included in the dev branch's GameData, or get it here: https://github.com/post-kerbin-mining-corporation/DeployableEngines/releases (you might already have it if you use Nerta's CryoEngines or KerbalAtomics)
  21. Rename 'Mk33CryoEnginesCRP.txt' in the Mk-33/Extras folder to 'Mk33CryoEnginesCRP.cfg', and make sure you have Community Resource Pack installed. It might also require the CryoTanks mod? Or having it just enables the boiloff system. https://github.com/post-kerbin-mining-corporation/CryoTanks/releases
  22. You might need to set the KAS connector/plug, from the yellow hose that is attaching the launchpad to the base, into "docked" connection mode, so it all becomes one craft.
  23. Here’s fine. Do you have BellaTU installed? I did an update for that recently-ish, but pretty sure I did miss some parts. I can probably give it another look soon. IR isn’t going to be supported in BDB, and not even sure that part would work in IR. So unless Zorg really want to start losing hair at an accelerated rate it’s unlikely
  24. AFAIK SystemHeat is a hard dep for FFT. You could maybe make a patch to make a super op radiator to 'solve' any heating issue, or just build craft as intended by the mod.
  • Create New...