aviin

Today I took some time to make a patch to convert the entirety of the USI Otter Submersible (now a part of the USI Exploration Pack) over to SunkWorks systems, much as @Caerfinon mentioned doing earlier in this thread. A quick rundown of what this patch does: 'Otter' Submersible Pod Added a SunkWorks dive computer with a pressure tolerance of 12,000kPA (1.2km dive depth), equal to Otter's standard pressure tolerance Added the SunkWorks suit switcher module so kerbals can change into a dive suit while inside 'Otter' Crew Cabin Added the SunkWorks suit switcher 'Otter' ventral ballast tank, 'Otter' radial ballast tank, and 'Otter' inline ballast plate Converted the ballast system to the SunkWorks one (making it controllable by the dive computer) Made the IntakeLqd tanks default to empty (like WBI ballast parts) Restricted the Jettison function of the parts to dump only onboard Lead ballast rather than Lead and IntakeLqd Quality of Life Attachment Rule Changes 'Otter' Submersible Pod can now have other parts attached to its surface 'Otter' ventral ballast tank, radial ballast tank, dive plane, rudder, high-powered spotlight, aquatic sample collector, R125 inline impeller, and R35 radial impeller can now be surface attached to other parts Note that the parts that are surface attachable can default to odd orientations, so you may need to rotate them into the correct position (attaching via nodes is completely unaffected by this) and symmetry, especially mirror symmetry, can get odd when surface attaching these parts (you may find you need to remove a part from the symmetry and then rotate it 180 degrees). Radial symmetry tends to produce better results overall. Unfortunately, I do not have to know-how to make these issues any better. The good news is that you can still use all the parts in their normal node-attached way and be totally unaffected by these issues (hint: hold down the Alt key while placing the part to force node attachment only). Additionally, I am providing a patch to enable the kerbal enhancements from SunkWorks (extra inventory space and modified pressure tolerance) to the 1.12 slim suit. Find the patches in the spoilers below: USI 'Otter' Submersible SunkWorks Refit Slim Suit SunkWorks Compatilbility Patch I hope others find these useful.

I've been spending some time making little patches to integrate mods with other mods that I use, and last night I decided to make some omni converter templates for use with @Angel-125's various Wild Blue Industries mods (Buffalo, DSEV, etc.) to add direct support for LH2, LCH4, and Lithium. These templates, like the other omni converter templates, match the output of the Convert-O-Tron 250 but have a slightly higher efficiency. I make no claim to have balanced WBI mods with any of @Nertea's mods. I just implemented templates that match the CryoTanks and NFP ISRU patches for the Convert-O-Tron 250 while maintaining the WBI omni converter efficiency bonus. But anyway, find in the spoilers templates for LH2, LH2+Ox, LCH4, LCH4+Ox, and Lithium. And now I'm editing this post to add NearFutureElectrical support items to some WBI mods. First, you will find a patch to convert the WildBlueTools S.A.F.E.R. fission reactor to output the more standardized DepletedFuel rather than DepletedUranium (making it match the NFE reactors) as well as adding NFE's RadioactiveStorageContainer module to it. Also, I've modified the appropriate omni converter templates for nuclear to utilize DepletedFuel rather than DepletedUranium. No attempt was made to change anything related to balance issues, just a change to DepletedFuel. I've also replaced the Uraninite Refiner omni converter template with one that processes Ore into EnrichedUranium at the same resource ratios as NFE's Whirlijig Nuclear Reprocessor. You will also find a patch for the DSEV D2LAB template for the Nuclear Processing Lab that makes similar changes as the above omni converter template changes that also adds NFE's RadioactiveStorageContainer module. Lastly, there is a patch for DSEV's DMB0 "Trinity" Tri-Modal Engine that makes the DepletedUranium-to-DepletedFuel swap and adds the RadioactiveStorageContainer module to it as well. It was absolutely killing me that WBI uses DepletedUranium rather than DepletedFuel, making interoperability between WBI nuclear systems and most other mods more complex, though I will say the generic DepletedFuel makes less sense than DepletedUranium. WildBlueTools Omni Converter Templates for CryoTanks (LH2, LH2+Ox, LCH4, LCH4+Ox) WildBlueTools Omni Converter Template for NFP (Lithium) WildBlueTools S.A.F.E.R. Patch for NearFutureElectrical WildBlueTools Omni Converter Templates Patch for NearFutureElectrical WBI DSEV D2LAB Nuclear Processing Lab Template Patch for NearFutureElectrical WBI DSEV DMB0 "Trinity" Tri-Modal Engine Patch for NearFutureElectrical Enjoy!

It is indeed related to that exact EL configuration file. The original recipe from EL for this was posted by @Tonka Crash in the EL thread. The values from the original post result in EC usage that is identical for smelting MetalOre and melting ScrapMetal. Because other mods might rely on the recipe as it appears in the EL release being what it is, I made a patch to add a new recipe specifically for Sandcastle that matches the original posted EC usage and then assigns that revised (reverted?) recipe to both Sandcastle smelters. It would probably be safe to just patch the original recipe, but maybe somebody out there is using some mod that really is (though unlikely) balanced around that incredibly high EC usage. Anyway, here it is if someone wants it: Sandcastle Smelter Patch:

Not saying that this is your issue, but if you clicked the GitHub link in the first post on this thread, it pointed you to the initial release, which in 1.12.5 (and probably other versions) causes what you describe. Use the SpaceDock link or else the current GitHub release.

For anyone interested... Ж-20 "Moroz" Spaceplane TweakScale Configs

I am aware of that, but it is my personal preference to keep them all separate for ease of editing. The "official" TweakScale patches for Squad parts are done in the same way. Of course, to each their own. Just my preference.

I've been making TweakScale configs for the mods I use that lacked them, and I did Blue Steel a few days ago. It covers all parts from the mod. Here it is for those interested. Blue Steel TweakScale Configs

I've been going through the mods I use and adding TweakScale support to the mods that don't have it and did Fuji a few days ago. In the cases of the P-XX6 Orbital Module and the P-GM9 Structural Section, I set the defaultScale to be 0.625 because that is the size of the attachment points, but both parts to flair out considerably larger, so feel free to change it if you prefer something different, but personally I find that setting the defaultScale to match the size of the attachment point allows for easier sizing to mate to other parts). At any rate, if interested, find it below: Fuji TweakScale Configs

Here is a full set of TweakScale configs for anyone interested. To get the most out of this, you'll need a recent version of TweakScale and need to have TweakScaleExperimental enabled (in other words, you need to have a folder named TweakScaleExperimental in your GameData folder, though that folder can be entirely empty). Luciole TweakScale Config

The error mentioned above by @OrbitalManeuvers is caused by a typo in the Bumblebee Sensor Package config file. The typo prevents running the barometer experiment from an action group. Here is a Module Manager patch to correct the typo and let the barometer experiment work as intended. I prefer patches like this over editing the original files, but obviously it could be done that way, too. Bumblebee Sensor Package Barometer Fix // -------------------------------------------------------------------------------------------------------------------- // Bumblebee Sensor Package Barometer Fix // -------------------------------------------------------------------------------------------------------------------- @PART[bb_Sensor]:NEEDS[Bumblebee] { @MODULE:HAS[#experimentID[barometerScan]] { @useActionGroups = True } } I didn't come here to talk about that, but I saw that error and had to fix it before I felt comfortable posting what I actually came here for... While I was doing a personal update on the Knes TweakScale configs, I decided to write some for Bumblebee. I always enjoyed using the electric props from Firespitter to make things like quad copters and whatnot, and when you combine that with TweakScale, you can make some pretty neat low part count stuff. TweakScale for Bumblebee seemed like something interesting to play with, so I wrote the requisite configs to do so, and I decided I might as well share them. So here they are. Note 1: Some of the parts will require the latest version of the TweakScale Beta with TweakScaleExperimental enabled, but if you're only after the props, pretty much any version of TweakScale will do. Note 2: Scaling up the size of the props exacerbates the issue of the Bumblebee props continuing to generate thrust when they run out of available EC. Rest assured the problem exists even on standard sized props without my patch installed, but the thrust values are so low that they typically wouldn't be enough to move your craft. Scaling up the size increases the size of that latent thrust. Bumblebee TweakScale Patches // -------------------------------------------------------------------------------------------------------------------- // Bumblebee TweakScale Patches // -------------------------------------------------------------------------------------------------------------------- @PART[bb_Aeroshell]:NEEDS[Bumblebee,TweakScale] // Bumblebee "Apiary" Aeroshell { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } @PART[bb_Chute]:NEEDS[Bumblebee,TweakScale] // Bumblebee Main Parachute { %MODULE[TweakScale] { type = free_square } } @PART[bb_Core]:NEEDS[Bumblebee,TweakScale] // Bumblebee Drone Probe Core { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_Decoupler]:NEEDS[Bumblebee,TweakScale] // Bumblebee Decoupler { #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_Drogue]:NEEDS[Bumblebee,TweakScale] // Bumblebee Drogue Parachute { %MODULE[TweakScale] { type = free_square } } @PART[bb_HGA]:NEEDS[Bumblebee,TweakScale] // Bumblebee "Antennae" High Gain Antenna { %MODULE[TweakScale] { type = free_square } } @PART[bb_Prop]:NEEDS[Bumblebee,TweakScale] // Bumblebee "Wings" Contra-Propeller { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_PropSingle]:NEEDS[Bumblebee,TweakScale] // Bumblebee "Wing" Single Propeller { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_RTG]:NEEDS[Bumblebee,TweakScale] // Bumblebee "Stinger" RTG { %MODULE[TweakScale] { type = free } } @PART[bb_Seismometer]:NEEDS[Bumblebee,TweakScaleExperimental] // Bumblebee "Proboscis" Deployable Seismometer { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_Sensor]:NEEDS[Bumblebee,TweakScaleExperimental] // Bumblebee Sensor Package { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_SingleTruss]:NEEDS[Bumblebee,TweakScale] // Bumblebee single-mount Truss { %MODULE[TweakScale] { type = free } } @PART[bb_Skids]:NEEDS[Bumblebee,TweakScaleExperimental] // Bumblebee "Knees" Skids { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } @PART[bb_Truss]:NEEDS[Bumblebee,TweakScale] // Bumblebee Truss { %MODULE[TweakScale] { type = free } } @PART[bb_Dunaprop]:NEEDS[Bumblebee,TweakScale] // "Dragonfly" Low Density Contra-Propeller { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } Enjoy or not as you see fit

I have noticed some inconsistencies in the TweakScale configs for this mod. I know @Well has mentioned in the past that he doesn't really use TweakScale himself and never really liked making changes to the TweakScale configs. Totally understandable, but last night I decided to make some fixes myself and I figured I might as well share them here for others. Basically they are mostly adjustments to "defaultScale" to correct incorrect values, though some had a "type" change as well to be more in line with common TweakScale conventions. I should note that there are several engines/boosters included in Knes that have larger diameters at the end of their shrouds, but I left the defaultScale values matching the other end because it just didn't seem to make sense to set a defaultScale to match a diameter that is invisible unless the engine is part of an upper stage. It isn't super important whichever way you set it, but for me, I like that initial scale value that appears in the PAW to have some resemblance to what the part physically looks like, though in this case it does fly in the face of the "standard" TweakScale convention of setting the defaultScale to match the diameter of the largest end of a part. Additionally, I added TweakScale support to the parts that were missing it. I believe that every part in Knes will now have TweakScale support when my patch is applied. Lastly, the process of updating these made me also realize that the titles of both SafeSystem parts are swapped by default, so I made a little patch to correct that, too. This affected all three localizations, but the patch corrects all cases. To use these patches, just create a new .cfg file in your Gamedata folder called whatever you want and paste the information below into it and save it. Do NOT delete the "official" TweakScale patches from your Knes folder. These supplement/correct those. They do NOT replace them. NOTE 1: Because this could affect previously saved craft, I do not recommend using these updated configs unless you are using a new save. NOTE 2: I have done my best on this pass to catch any of the parts I personally missed correcting, but I cannot guarantee that there might be something missing or incorrect somewhere. Caught myself making mistakes a few times and though I think it is about perfect now, I could be wrong. NOTE 3: I have completely ignored the part Dual Payload Adapter K-375 "Kylda" purposefully and left it as is, though I do feel that the defaultScale is probably incorrect. It is such an odd part that I don't even know how to handle it. The "official" Knes TweakScale support for the part will just have to stand as is. NOTE 4: Knes could use a corrections pass on "bulkHeadProfiles" as well. I may do something similar for that as well at some point. Being that Knes is my absolute favorite mod of all time, I cannot help but want to see it perfect, even if it is only my idea of perfect. But it never hurts to share with others. Knes TweakScale Fixes/Additions // -------------------------------------------------------------------------------------------------------------------- // Knes TweakScale "defaultScale" Fixes // -------------------------------------------------------------------------------------------------------------------- @PART[_Knes_Utility_Adapter_09375_0625]:NEEDS[TweakScale,Knes]:AFTER[Knes] // L-07 "Racoon" Service Module { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Station_Module_EndCap_0625]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter K-0625 "Inori" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[_Knes_Structural_Adapter_09375_0625]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter 0.625 0.9375 "Zoe" { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Structural_Adapter_125_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter K-0125 "Caroline" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[_Knes_Station_Module_EndCap_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter K-09375 "Betsy" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[_Knes_Station_Module_EndCap_Small_0625]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter KB-0625 "Maia" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[_Knes_Cora_Adapter_125_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter K-09375 "Both" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[_Knes_Cora_Adapter_1875_125]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Adapter K-125 "Kiss" { @MODULE[TweakScale] { @defaultScale = 1.875 } } @PART[_Knes_L3S_H4]:NEEDS[TweakScale,Knes]:AFTER[Knes] // H4 "Thor" Fuel Tanks { @MODULE[TweakScale] { @defaultScale = 1.875 } } @PART[_Knes_L3S_HM4_Engine]:NEEDS[TweakScale,Knes]:AFTER[Knes] // HM4 "Themis" Cryogenic Engine { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[Knes_Structural_Kylda_125]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Payload Adapter K-125 "Kylda" { @MODULE[TweakScale] { @defaultScale = 1.25 } } @PART[Knes_Utility_SafeSystem]:NEEDS[TweakScale,Knes]:AFTER[Knes] // SafeSystem 1.875 / 2.5 Abort Adapter { @MODULE[TweakScale] { @defaultScale = 2.5 } } @PART[Knes_Cargo_Pod_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Cargo Pod "Minotaur" { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[Knes_Crew_Pod_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Command Pod "Viking" { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Mireille_LFO_short_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // M-09 "Cassis" FuelTank { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Mireille_LFO_medium_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // M-09 "Myrtille" FuelTank { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Mireille_LFO_long_09375]:NEEDS[TweakScale,Knes]:AFTER[Knes] // M-09 "Mirabelle" FuelTank { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[_Knes_Vesta_FuelTank_0625_3125]:NEEDS[TweakScale,Knes]:AFTER[Knes] // LRBA-FT "Hunger" Fuel Tank { @MODULE[TweakScale] { @defaultScale = 0.625 } } @PART[_Knes_L3S_AR4_Avionics]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Probe Core AR4 "Baudry" Avionics System { @MODULE[TweakScale] { @defaultScale = 3.75 } } @PART[_Knes_L3S_Engine_Viking5]:NEEDS[TweakScale,Knes]:AFTER[Knes] // L3S "Viking 5" Liquid Fuel Engine { @MODULE[TweakScale] { @defaultScale = 0.9375 } } @PART[Knes_EscapeTower_Small]:NEEDS[TweakScale,Knes]:AFTER[Knes] // Launch Escape System "LastChance" { @MODULE[TweakScale] { @defaultScale = 0.625 } } // -------------------------------------------------------------------------------------------------------------------- // Knes TweakScale "type" Changes // -------------------------------------------------------------------------------------------------------------------- @PART[_Knes_L3S_PAL]:NEEDS[Knes,TweakScale]:AFTER[Knes] // Ariane "Drako" PAL Booster { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free } } @PART[_Knes_mrk_Antenna]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-5a Antenna { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_Sat_NanoSat]:NEEDS[Knes,TweakScale]:AFTER[Knes] // K2 "Kassler" Nano Sat { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free } } @PART[_Knes_mrk_SolarPanel_Pyld]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-3b Solar Panel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_mrk_SolarPanel]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-3a Solar Panel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_mrk_SolarArray]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-30a Solar Array { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_Hermes_SolarPanel]:NEEDS[Knes,TweakScale]:AFTER[Knes] // Callisto SolarPanel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_ATV_SolarPanel]:NEEDS[Knes,TweakScale]:AFTER[Knes] // ATV "Einstein" Solar Panel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_mrk_SolarPanel_Nano]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-1A Solar Panel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } @PART[_Knes_mrk_SolarPanel_Pyld_Track]:NEEDS[Knes,TweakScale]:AFTER[Knes] // MRK-3c Solar Panel { !MODULE[TweakScale] {} %MODULE[TweakScale] { type = free_square } } // -------------------------------------------------------------------------------------------------------------------- // Knes TweakScale Additions // -------------------------------------------------------------------------------------------------------------------- @PART[_Knes_STEAM_Power_Module]:NEEDS[Knes,TweakScale] // STEAM "Vesta" Power Module. Rechargeable Battery Bank { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } @PART[_Knes_STEAM_Cargo_Tank]:NEEDS[Knes,TweakScale] // STEAM "Blamont" Monopropellant Module { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } @PART[_Knes_STEAM_09375_cargo]:NEEDS[Knes,TweakScale] // Nano "Minos" Pressurised Module { %MODULE[TweakScale] { type = stack defaultScale = 0.9375 } } @PART[_Knes_STEAM_125_cargo]:NEEDS[Knes,TweakScale] // Small "MiraGino" Pressurised Module { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } @PART[_Knes_Hermes_Antenna]:NEEDS[Knes,TweakScale] // MRK-5b Antenna { %MODULE[TweakScale] { type = stack_square defaultScale = 0.3125 } } @PART[_Knes_Diamant_Fairing_0625]:NEEDS[Knes,TweakScaleExperimental] // KEREB-D "Assiduous" fairing { %MODULE[TweakScale] { type = stack_square defaultScale = 0.625 } } @PART[_Knes_Diamant_Fairing_09375]:NEEDS[Knes,TweakScaleExperimental] // KEREB-D "Wallace" fairing { %MODULE[TweakScale] { type = stack_square defaultScale = 0.9375 } } @PART[Knes_Aero_Fairing_09375]:NEEDS[Knes,TweakScaleExperimental] // Knes Fairing (0.9375m) { %MODULE[TweakScale] { type = stack_square defaultScale = 0.9375 } } @PART[Knes_Aero_Fairing_125]:NEEDS[Knes,TweakScaleExperimental] // Knes Fairing (1.25m) { %MODULE[TweakScale] { type = stack_square defaultScale = 1.25 } } @PART[Knes_Aero_Fairing_1875]:NEEDS[Knes,TweakScaleExperimental] // Knes Fairing (1.875m) { %MODULE[TweakScale] { type = stack_square defaultScale = 1.875 } } @PART[Knes_Aero_Fairing_250]:NEEDS[Knes,TweakScaleExperimental] // Knes Fairing (2.5m) { %MODULE[TweakScale] { type = stack_square defaultScale = 2.5 } } @PART[Knes_Aero_Fairing_375]:NEEDS[Knes,TweakScaleExperimental] // Knes Fairing (3.75m) { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } SafeSystem Titles Fix // -------------------------------------------------------------------------------------------------------------------- // Fixes the titles on the two Knes "SafeSystem" parts that have swapped titles // -------------------------------------------------------------------------------------------------------------------- @PART[Knes_Utility_SafeSystem]:NEEDS[Knes] // Fixes the name on the 1.875 to 2.5 SafeSystem part { @title = #autoLOC_Knes_Utility_SafeSystem_1875_title } @PART[Knes_Utility_SafeSystem_1875]:NEEDS[Knes] // Fixes the name on the 1.25 to 1.875 SafeSystem part { @title = #autoLOC_Knes_Utility_SafeSystem_250_title } Anyway, hope it is useful to someone. I felt like this needed done a long time ago, but I just never took the time until now.

I realized today while playing around with the original Buffalo that the Buffalo drill no longer functioned as a drill, presumably caused by the removal of the BARIS prerequisite sometime back (and me not having BARIS installed). This same issue affects the GondoDrill from the Heisenberg mod. Anyway, I went ahead and made a MM patch that will fix the drills from both mods. Here it is in case anyone else needs it: I also found myself wishing the center of mass on various Buffalo (and Heisenberg) crewed parts was centered rather than below center, so I made a patch for that as well. It will give you an option on the PAW while editing a craft in the VAB/SPH to choose between the original ("Default") or "Centered" center of mass for the affected parts. This one requires B9PartSwitch: Anyway, hopefully someone will find this useful.

Any news?

I have been meaning to mention this for ages but kept forgetting until now. Using the PAW to adjust how far the Callisto cargo bay can open actually changes how far it can close instead. Sorry if that is confusing but try it and you will see what I mean. As always, love all your mods. They are essential to my KSP experience at this point.

Nice parts! I am always a sucker for parts that let me build little shuttle-like craft. I did find a problem with one of the parts, however. The science lab appears to be in the wrong category and lacks its crew capacity. Easy fix on my end by modifying the cfg, but I am sure there are others who wouldn't know how to. Looking at the github page, I noticed you had a KNES compatibility patch at one point to use some of its IVAs. Might I ask why you deleted that? I grabbed the now-deleted file and used it and it was a nice improvement over the stock IVA option. I'm very thankful for the community members who bring back and maintain older mods. Thank you soooo much!

Loving this mod. Don't know how I have played for so many years without ever installing any of your mods, but this playthrough is practically the Well Space Program. Lol

Regarding non-switchable resource containers, I have only seen similar issues to what I described if I have used a ballast vent on one AFTER I had an issue with a Buffalo chassis not working right in the same session. Otherwise, things seem to work beautifully. And about adding SunkWorks modules to non-SunkWorks parts... yeah... I have been doing the same and jeez is it opening up a world of possibilities. Laythe is calling... :D

I installed SunkWorks this morning and am loving what I am seeing so far. I have noticed an issue with the ballast vent part, though. Several, actually. Specifically, I have had several circumstances where using it to convert a tank to a ballast tank, the tank has kept its original resource, not only visually in the SPH, but even after launch. I have also seen on one occasion a part seemingly lose the IntakeLqd resource visually in the SPH, the attached vent suddenly decide to offer the chance to convert the tank again, and the part, upon being converted again, now have double the volume of IntakeLqd capacity both in the SPH and after launch. And the removal of EC from a tank's resource list if it had it is somewhat random with a tank sometimes losing it upon conversion and sometimes not. All tanks involved were chassis parts from your Buffalo rover mod. I specifically did everything I could to mitigate potential issues by assigning resources to the chassis parts before attaching a vent, but it still misbehaves randomly. Oh, and on several occasions after the tank is converted to ballast, the PAW will no longer display for any part until I launch the vessel and revert, after which the tank will no longer show as a ballast tank. There are also some idiosyncrasies with the wardrobe changer, too, where the wrong image will be displayed in it for the selected kerbal if you have already used it prior to change the suit of a different kerbal. I do have a question about the dive computer. Will it interact with the vent parts from the Buffalo pack, or are the two dive computer systems from the two mods incompatible? And I know the Buffalo dive computer says it will use tanks assigned as trim tanks as general ballast tanks but the SunkWorks dive computer does not. Is this by design? Love all your mods and have for a long time. Looking forward to seeing how this and the others progress. EDIT - This was using the version prior to the one you released today, so if any of these issues were already addressed, I apologize.

Last night I decided I should write an application for calculating antenna strength of vessels. I know there is the Google Docs one that many people use, but I wanted an application to do it. Thus was born Kerbal Antenna Kalculator! Click on the plus and minus buttons to add or remove antennas and you will get immediate results in the green area below. The little question mark button in the lower right will open a small window with additional information. This is for Windows. You may need to download and install the .NET Framework v4.5.1 in order to run it. Download (v0.1 for Kerbal Space Program v1.4.5.2243) DOWNLOAD LINK REMOVED UNTIL I FIGURE OUT A SOFTWARE LICENSE TO APPLY TO THIS

Very nice. I will have to download it shortly. In the meantime, I made a second monolith for personal use. TMA-2, correctly sized. At 2km long, it's huge (rescale setting is a whopping 1111.1). The novel of 2010 says it should be 950,000 ton, so I did that, too. Way too big to use except with HyperEdit (it crushes the launchpad immediately). Since this is alien technology, I decided to just get rid of the battery entirely and make the whole thing not use power at all. To make TMA-2 able to reorient at a reasonable rate, I had to keep moving the reaction wheel torque up... and up... and UP. At a setting of 30000000000 (yes, thirty billion), it can be comfortably controlled. Wish I knew enough to make a .dll that could place one of these in orbit of Jool when a new game is started...

Just ran across this when I decided that I needed a proper Monolith on the Mun. Nice! There is a bug, though, in v0.6 with the Monolith. Though you've converted the texture to .dds, the .mu is still looking for the .tga and so the Monolith comes out pure white. Easily fixed on my end, but when you get around to updating again, definitely something to do. I also like Nicholander's idea of the Monolith being a command module to keep it from being labeled as debris. Personally, I modded it for my own use to match as close as I could to the "official" size and mass of TMA-1 from the book. So a rescale factor of 1.85 (without importing it into Blender to get an exact number; I just tweaked it until the VAB size values matched what I wanted) and a very low mass. 2010 (Chapter 25) mentions that the mass of TMA-2 (the giant monolith in orbit of Jupiter) puts its density at about that of air; the mass of air in a volume the size of TMA-1 would be 0.0022 tons, assuming a density that is the same as TMA-2. I added top and bottom attachment nodes, made it a command module, gave it a little SAS so it could orient itself, and set the vessel type of the part to SpaceObject, well, just because. I know, I know, all this is wildly unnecessary in a game like KSP, but it's what I wanted . Anyway, thanks for the nice part pack. I look forward to any updates that may come.

Having resurrected a few of these parts myself in the past for personal use, this seemed like a great mod. As I did for myself a long time ago, might I suggest a rescaled Quest Mk1 Command Pod that is comparable to the Mk1-2 Command Pod in size and stats (i.e. a 2.5m part)? Even if it weren't rolled into your release, I'd like to share it here for any who might be interested. Essentially this is the Quest Mk1 Command Pod rescaled to 2.5m, with the cost, tech tree placement, mass, resources, and IVA from the Mk1-2 Command Pod. I also tweaked the placement of the attachment nodes slightly to eliminate the gap between this part and other parts. Considering that it is intended for a crew of three, this size makes a ton of sense. PART { // --- general parameters --- name = mk1podCrew3R module = Part author = Original by C. Jenkins, Part fix by Fiddlestyx, TechTree inclusion by Blspblackdeath, Part description & Stats update by TheMoonRover, Rescaled and tweaked by aviin // --- asset parameters --- mesh = model.mu scale = 0.1 rescaleFactor = 2.5 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_bottom = 0.0, -2.89, 0.0, 0.0, -1.0, 0.0, 2 //node_stack_bottom = 0.0, -2.99, 0.0, 0.0, -1.0, 0.0, 1 node_stack_top = 0.0, 3.83121, 0.0, 0.0, 1.0, 0.0, 1 //node_stack_top = 0.0, 3.93121, 0.0, 0.0, 1.0, 0.0, 0 bulkheadProfiles = size2, size1 CoPOffset = 0.0, 0.5, 0.0 CoLOffset = 0.0, -0.35, 0.0 // --- editor parameters --- TechRequired = commandModules entryCost = 7600 cost = 3800 category = Pods subcategory = 0 title = Mk1-2 "Quest-X" Command Pod manufacturer = Kerbal Space Program description = This upscaled version of the Quest Mk1 Command Pod carries three kerbals, just like it did originally, only now with elbow room! Warranty not included. Void where prohibited. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 // --- standard part parameters --- mass = 4 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.15 angularDrag = 2 crashTolerance = 45 maxTemp = 2400 vesselType = Ship // --- internal setup --- CrewCapacity = 3 INTERNAL { name = PodCockpit } MODULE { name = ModuleCommand minimumCrew = 1 } RESOURCE { name = ElectricCharge amount = 150 maxAmount = 150 } MODULE { name = ModuleReactionWheel PitchTorque = 15 YawTorque = 15 RollTorque = 15 RESOURCE { name = ElectricCharge rate = 1.2 } } MODULE { name = ModuleScienceExperiment experimentID = crewReport experimentActionName = Crew Report resetActionName = Discard Crew Report reviewActionName = Review Report useStaging = False useActionGroups = True hideUIwhenUnavailable = True rerunnable = True xmitDataScalar = 1.0 usageReqMaskInternal = 5 usageReqMaskExternal = -1 } MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 2.0 } RESOURCE { name = MonoPropellant amount = 30 maxAmount = 30 } MODULE { name = ModuleConductionMultiplier modifiedConductionFactor = 0.003 convectionFluxThreshold = 3000 } }

You need to adjust some of the input settings to recreate the prior behavior. From the "Settings" option on the main menu, go to the "Input" section and "Flight" subsection. In order for these assignments to stick, I had to clear each one then assign it again, for the record (just unticking a mode would not save). In each of the key bindings under "Rotation", you'll need to untick "Docking (Translation)" (again make sure you actually clear the assignment first). Add a secondary assignment to each entry under "Translation". Set "Translate Up" to W with only "Docking (Translation)" ticked. Set "Translate Down" to S with only "Docking (Translation)" ticked. Set "Translate Left" to A with only "Docking (Translation)" ticked. Set "Translate Right" to D with only "Docking (Translation)" ticked. Set "Translate Forward" to LeftShift with only "Docking (Translation)" ticked. Set "Translate Backward" to LeftControl with only "Docking (Translation)" ticked. Under "Throttle", untick "Docking (Translation)" and "Docking (Rotation)" for both "Throttle Up" and "Throttle Down" (again make sure you actually clear the assignment first). Under "Other", untick "Docking (Translation)" and "Docking (Rotation)" for "Launch/Stages" and untick "Staging" for "Switch Translation/Rotation" (again make sure you actually clear the assignment first). Hit "Apply" down at the bottom and the "Accept". Things should now be back to the way you remember. I actually came here looking for the answer to the same question and when I saw no one had replied, I took a minute to work all out. It is my sincere hope this helps.

This is not a support request, but a solution to a problem I was going to ask but solved on my own. If you're like me, you already had Kerbal Space Program on Steam. Now that KerbalEDU is out, you might like to launch it via the Steam interface. You've got two options in how to do it. Method 1: Non-Steam Game Shortcut In the menu bar at the top left of the Steam interface, click on "Games". From the drop-down menu, click on "Add Non-Steam Game to My Library..." In the new "Add a Game" window that appears, scroll down the list until you find the "KerbalEDU" entry and left-click on the little box to the left of it. Click on the "ADD SELECTED PROGRAMS" button at the bottom of the "Add a Game" window. This will add a KerbalEDU entry to your Steam Library. Unlike a normal Steam entry, this one will show no news and have no playtime counter. The Steam Overlay will continue to function if you'd like to use it, though. Method 2: Override the Default Kerbal Space Program Shortcut Right-click on your KerbalEDU shortcut and left-click on "Properties" in the menu that appears. You should now be looking at a window that is labeled "KerbalEdu Properties", you should be on the "Shortcut" tab, and the text in the "Target:" box should be highlighted. Press Ctrl-C on your keyboard (which will copy the text to the clipboard) and the click on the "Cancel" button. Find Kerbal Space Program in your Steam Library. Right-click on it and in the little menu that appears, left-click on "Properties". In the new "Kerbal Space Program - Properties" window that appears, you should find yourself looking at the "GENERAL" tab. Click on "SET LAUNCH OPTIONS..." In the new "Launch Options - Kerbal Space Program" window, click on the box near the bottom and input a quotation mark. Then press Ctrl-V on your keyboard, which will paste the path of KerbalEDU into the box. Now follow that by another quotation mark, a space, and then %command%. You should ultimately end up with something like "C:\Path to KerbalEDU\KSP.exe" %command% where "C:\Path to KerbalEDU" is the location of your KerbalEDU folder. Click on "OK" and then "CLOSE". This method is certainly more complex but it has a few advantages over the other method. Firstly, you'll still get the news feed for the game's entry. Secondly, your playtime counter should continue to increment. The caveat, though, is that even when Steam updates KSP, your shortcut will still be launching KerbalEDU and even though you'll have downloaded the update, since Steam doesn't patch KerbalEDU, you will still be playing the old version. If you want to undo this, you can easily go back in and blank the box you entered the KerbalEDU launch options into. You could even add the Steam version of KSP as a non-Steam shortcut using method one if you were so inclined. So anyway, there you have it. It is a shame that there is no mod version of KerbalEDU that you can just throw into a default KSP install, but such is life, I suppose.