Aelfhe1m

It's Hex.

Maybe a similar method to that used in Crew Light? https://github.com/linuxgurugamer/CrewLight/blob/1f2fb726ff03196e426fc44deac78b52a9b702f1/Source/SunLight.cs#L43-L55

I think you just need to edit the launchpad/runway instance and give it a facility type of "Recovery Base"

The resource names are defined in the file <GameData>/KerbalismSimplex/ResourceConfigs/SIMPLEXKerbalism-Resources.cfg You could edit that file but it is generally better to write a separate Module Manager patch so that your changes won't get overwritten if/when the mod gets updated. Simply copy the below into a new text file and save it into a folder inside your <GameData> folder. I suggest <GameData>/CustomPatches/RenameSimplexConsumables.cfg or something else equally memorable. @RESOURCE_DEFINITION[Consumables]:NEEDS[KerbalismSimplex] { @displayName = Snacks @abbreviation = snacks }

Sorry, haven't tested it.

Yes, the step size can be changed (it defaults to 1.25m). Setting it to half the default will hit most of the "standard" sizes (except 0.9375 but you can also set the small step to 1/8th of standard and get that with two clicks from either 1.25 or 0.625) @PART[procedural*]:AFTER[ProceduralParts] { @MODULE[ProceduralPart] { %diameterLargeStep = 0.625 %diameterSmallStep = 0.15625 } } And as @Stonesmile said while I was testing this. You can directly type in any value using the KSPCommunityFixes.

Those patches would work (the syntax is correct), whether they are correctly balanced is another question and up to you to decide in the end. Personally, I thing the antennapower for the MD-Antenna looks very low for an interplanetary dish. For comparison, the final patched values of the Communotron 88-88 in your MM ConfigCache are: Compared to your patches, the stock antenna would have much larger range but transmit about 4x slower and use about 40x as much EC. The Communotron HG-55:

@r3_141592654 Unfortunately it's not quite that simple. Yes the part info panel in the editor does show the "action name" as the type of science experiment being done but that "action name" can be defined differently on different parts. e.g. for the experiment discussed "bd_photometer": Vanguard 2 probe core - "Measure albedo" Pioneer 10 Imaging Photopolarimeter - "Photopolarimetry Measurements" Pioneer SUAE Atmospheric Entry Probe - "Collect Photometery Measurements" Pioneer SUAE Atmospheric Experiment Package - "Collect Photometery Measurements" And the text in the contracts is also variable: Gemini IV [no title] ATS-3 "Study the atmosphere" Explorer-30 "Use the photometer for some experimentation" OSO-1 [no title] OSO-2 [no title] Vanguard 2 "Measure cloud-cover distribution" The Nimbus wouldn't work for this contract as it has a different experiment (bd_mapping) that also sometimes gets described as measuring cloud cover. There is no real solution short of digging through the ModuleManager.ConfigCache like I did to get the above information, which is neither convenient nor something every user wants to do (or knows how to). One ugly fudge that can be used is the following MM patch that will add the experiment name to the "action name" field:

They are being calculated here: https://github.com/Kerbalism/Kerbalism/blob/1d6c68e090d9f07092306f2e0702aec4a5908e1f/src/Kerbalism/Patches/ModuleDataTransmitter_GetInfo.cs#L38-L48 Basically stripping out all the formatting code you get: EC(idle) = DataResourceCost * DataRate * Settings.TransmitterPassiveEcFactor EC (transmitting) = DataResourceCost * DataRate * Settings.TransmitterActiveEcFactor Max Speed = DataRate DataRate and DataResourceCost come from the ModuleDataTransmitter module (as shown in ModuleManager.ConfigCache); the transmitterEcFactors are from the Kerbalism settings page. Now as to how the DataResourceCost and DataRate values get modified during the ModuleManager patching that can be more involved. Starting here: https://github.com/Kerbalism/Kerbalism/blob/master/GameData/KerbalismConfig/System/ScienceRework/Patches-Antennas.cfg and also involving any mod specific patches or patches that globally affect ModuleDataTransmitter. For example here's an analysis of how the Mars Direct antenna got its final values: The Duna Direct antenna gets its calculated values overwritten by this patch in MarsDirect/Patches/MD-Kerbalism.cfg: Which is not doing what I assume the author intended since your MM cache has these values for that part: Searching through ModuleManager.log for any later patches affecting MD-Antenna gives: The patches at the bottom don't affect ModuleDataTransmiteer so can be ignored, leaving the JNSQ patches which only multiply antennaPower by 4.

The photometry experiment is built into the Vanguard-2 satellite (Easton-V2 "Narly" Probe Core if not playing with real names patch). You shouldn't need any extra parts to complete the contract. The relevant PAW entry is labelled "Measure Albedo" clicking it should bring up a "Photometry Data" science result window.

EngineLightRelit seems to be missing its dependencies Toolbar Controller and Click Through Blocker resulting in multiple assembly load exceptions throughout the log. KSP assembly loader is notoriously fragile with one failing assembly often causing other unrelated assemblies to also fail to load correctly. Edit: Also B9 Part Switch is using an old version. Upgrade to v2.20.0

The best way to request help is by providing links to zipped copies of your log files. See: However, from a quick look at that screenshot, the first thing that stands out is two copies of ModuleManager DLL. Delete the older one. If you are using the most up to date version of BetterTimeWarp then you are missing its dependencies (Click Through Blocker and Toolbar Controller are linked from the mod's OP). If you haven't updated BTW yet, then you should do so. Also check each mod's .version file and see if there is a newer version available compared to what you have installed (installing AVC will help with this process).

I've come across some unexpected behaviour when trying to delete a single node based on one of its keys during a processing loop. Here's a stripped down test case: Adding the :HAS[] clause to the delete seems to change the behaviour of the ,0 index clause in a way I hadn't expected.

Assign crew to an inflatable part before launch? You don't. There's no empty space inside them before they're inflated for any crew to fit into.

Go to the Kerbalism options page (Pause menu -> settings -> difficulty options -> Kerbalism 2). There is a radio button and a slider at the bottom of the left column of options. The slider controls how long the message stays on screen and the radio button allows you to switch from Kerbalism inbuilt messaging system to the stock system. Once a message has faded off screen it can still be accessed through the logs tab of the vessel monitor GUI or if you switched to stock messages then recent messages can be viewed with One Window Edit: Research and Development building -> Archives tab (top left) -> click green review science report button If the report hasn't finished transmitting yet then it is also visible in the tooltip for the appropriate line in the flight GUI data tab

I haven't looked too deeply in the log, but I did notice that you're playing KSP 1.12.3 but you have some very dated versions of some mods installed: B9PartSwitch v2.13.0.0 / vv2.13.0 - that's for KSP 1.8.1 you should be using v2.20.0 Firespitterv7.3.7287.12431 - for KSP 1.1.3, upgrade to v7.17 I didn't check any further but suspect several others are also out of date so I'd recommend going through all your other mods and checking that you have the latest version of each and that none of them have any known issues with 1.12.3 listed on their forum threads.

I originally missed placing a PARTUPGRADE in my BDB patch above. The GitHub version has been updated with: //Tier 9 cryo9 = Modern Cryogenic Engines @PARTUPGRADE[bluedog_Apollo_Gen2]:NEEDS[SkyhawkScienceSystem]:AFTER[Bluedog_DB] { @techRequired = cryo9 }

Untested, but if you replace the contents of OrbitalEnginesLFO.cfg with the below, it should do this:

Depends how you define "compatible". Collect science type requirements in contracts are always a bit tricky with Kerbalism. It won't throw any errors and the contracts should usually be completable but given how long some Kerbalism experiments take...

Here's the patch I'm currently using that includes all the BDB parts so far released: EDIT: I've decided to start a GitHub repository for various patches I've created/modified. So far I've mainly just added the patches for Skyhawk Science System's tree. Supported mods: ASET PRC rover ASET ERS rover Airpark B9 procedural wings Benjee10 Suit pack Bluedog Design Bureau - the patch above Explodium burning engines Feline Utility Rover IDFlags KerbalizedDecals Modular launch pads NRAP PlumeParty's vapor vents Real Chutes Rover Science Starship Expansion Project Starship Launch Expansion TAC self destruct Taerobee Universal Storage 2 - some missing parts from main patch USI Sounding Rockets Vessel notes And updated versions of some of the patches that radical2638 contributed to a pull request on GitHub: https://github.com/CessnaSkyhawk/SkyhawkScienceSystem/pull/54

You could use :FOR[zKcalbeloh] in your mod to make your configs run after that RSS global wipe while not adding any dependency since MM executes FOR passes in alphabetic order.

Which contract is that? Is it from this mod or another contract pack?

That part was deprecated and is marked as Tech "unresearchable" in the current version of SCANsat. However, the contract might not require that exact part (depending on how it was written) and may work with other parts that implement the SCANsat low resolution altitude mapping function - e.g. "R-3B Radar Altimeter" or "R-EO-1 Radar Antenna"

The API you want is KSPUtil.dateTimeFormatter: int secondsPerDay = KSPUtil.dateTimeFormatter.Day; Should work with 6hr/24hr or any properly implemented custom day length (e.g. JNSQ's 12hr days)

Andromeda Antenna 1 is in folder /Tantares/Parts/z_deprecated_8 Hammal Battery 2 is now called hammal.battery.srf.2 and is in folder /Tantares/parts/any_battery/progress