Aelfhe1m

@EngineeringEnjoyer All the experiments are available in native DMOS parts, having USII installed (which works fine with 1.12 in my experience) adds wedge shaped alternatives for many of the experiments.

There are several good YouTube videos offering tutorials on building for that mission. The one by Carnasa is perhaps my favourite for simplicity of design (includes a craft file you can download and take apart to see how it's built).

Just unzip it and put the whole ParallaxLifelessEve folder into your GameData directory.

Have you read the Getting Started -> Building a Sounding Rocket page in the Wiki? It has sections where it talks about how science works with procedural avionics and Kerbalism in RP-1. Basically all low atmosphere and surface science is marked as already researched (0 value) at game start. In order to start gaining science you must reach 40km to start getting upper atmosphere science. Also make sure that you start your experiment in the avionics' PAW before launching your sounding rocket (or at least before getting to 40km), science in Kerbalism trickles in over time automatically while your vessel is in an appropriate biome/altitude, provided the experiment is present, started, there is enough electric charge, and a communication connection back to KSC.

Well you could edit one of the unused values (colours 21, 22, 23 and 24) at the end of the file to include white (either pure white with the value #ffffff or KSP off-white #ececec), but it is generally better not to edit a mod's files directly but use a Module Manager patch instead. This prevents your changes being undone if the mod updates in the future. For this case, copy the following text into a new text file and save it somewhere in GameData as a .cfg file (I'd suggest creating a folder for your own patches if you don't already have one and saving it as SimpleRepaint_Colour.cfg): @SIMPLE_REPAINT_COLORS:AFTER[SimpleRepaint] { @COLOR_24 { @name = white @title = White @color = #ececec // or #ffffff if you prefer } } If you want to add a second colour choice for the other white variant, you could do another patch altering COLOR_23 provided you used a different name and title value. If there is another colour you want to add then a simple way to find the #value for that colour is to go to Google and search for "colour picker" and it will display a simple web app

Atmospheric ascents are tricky to calculate, but for airless bodies the maths required is quite straightforward. This (old) thread might help: You can also use the Transfer Window Planner mod to do the work of calculating interplanetary dV for you: Once you have all the numbers, then making the delta-V chart is "just" a matter of laying it all out in the graphics or diagramming software of your choice.

@Javascap That sounds weird. One of the saves I'm playing at the moment is a planes focussed career and once a plane has been built, the only operating cost is usually refuelling and other consumables (snacks), unless I mess up a landing and it needs repaired. There is an overhead associated with recovering a vehicle based on its distance from a recovery base, so if you are not sure whether a given airport has been configured for recovery or not then it is a good idea to refuel (assuming you're using Kerbal Konstructs and have some extra airports/bases installed) and fly back to a location you DO know is a recovery site (like the KSC)

Not as far as I know using the stock EVA construction, but it's not too difficult using KIS. The two systems can work side-by-side independently.

You can't move a part in EVA construction if: it's too heavy (not the case here) has other parts attached to it (e.g. docking port, solar panel, communication antenna etc.) is the root part of the vessel (usually the first part placed in the VAB unless you used the re-root tool). It's most likely the third problem you are running into here. A root part cannot be moved in EVA construction even if it's the ONLY part of the vessel.

As mentioned in the OP, the Russian parts are supplied by the Tantares mod. The assembled craft files for the ISS will not load unless you have both HabTech and Tantares correctly installed.

Toolbar stores its settings (including window positions) in GameData/toolbar-settings.dat Deleting that file will cause it to be recreated, but you'll have to reconfigure everything, adding back in your lists of buttons for each screen etc. Alternatively you can open it in a text editor and change the x, y settings for each of the toolbars to try and move things back on screen. (I think the starting default position is x =300, y = 300).

While the exact layout shown isn't possible, Historian Expanded allows you to overlay various pieces of telemetry information on your screen in a customisable manner. This can be either for screenshots or displayed persistently during flight (with or without the rest of the GUI).

In the save file, purchased tech is stored in the SCENARIO/ResearchAndDevelopment node. Each TechTree node you have unlocked has a node entry with a list of parts purchased, one line per part, with the part name (not title). e.g.

There are some limited options available inside KER itself. Click the KER button on the app bar. Select Edit beside the HUD you want to change. To apply a dark shaded background to the HUD panel click the BG button at the top of the editor window Each value colour can be changed individually by clicking on the coloured square next to its label in the installed section The labels are fixed as bold white text.

Share log files by uploading to a file sharing web service like Dropbox or Google Drive You may be able to recover a backup of your save game. KSP keeps several recent copies in <KSP>/saves/<savename>/Backup. Copy these to a safe place before trying to debug this issue any further. When you have a working version of KSP without the error then copy one of the backup files into the <savename> and rename it to persistent.sfs (after deleting the persistent file that was there previously)

Not sure it's a good idea. Some contracts may be hardcoded to specific agents. However, aggressive ModuleManager patch to do this - may also delete any mod agencies that use Squad flags: // delete any agent using a flag from GameData/Squad/Agencies/ !AGENT:HAS[#logoURL[Squad?Agencies*]] {} Result from MMPatch.log on a mostly stock test build.

When deleting a subnode the correct syntax requires {} at the end (for a key an = value is required). Also the way you were editing the OUTPUT_RESOURCE node would have caused duplicate keys to be created. You need to use @ to tell MM to edit the value. Corrected patch (untested)

The lander can use a direct antenna, but the orbiter needs to have a strong enough relay antenna to bounce that signal to Kerbin. And with a single orbiter it will only be able to transmit when the orbiter can see both Kerbin and the lander. If either is in radio shadow then no connection can be made. Some useful resources:

Depends how you want to change the texture. The Conformal Decals mod gives a better "flag" based painting option than the stock flags, but uses added parts which prevent the craft from being loaded if the mod is not present. This is the simplest and most flexible way to add multiple markings and custom text to craft (e.g. ID numbers). Example: For a simple single solid colour on a part the easiest way is to use TexturesUnlimited and TURD If you want something more complicated then you can leverage the existing variants system on the parts: make a copy of the default texture atlas (located at GameData/SquadExpansion/MakingHistory/Parts/Structural/Assets/Panels.dds), open it in a paint package and then save the modified texture into your own folder inside GameData (I use ZZZ_Custom/Textures in the example here). Add a ModuleManager configuration file. The below example shows two simple variants - red and blue - each of which only changes the colour map and reuses the stock bump map: Select the new part variant when building the craft in the editor inside KSP Any craft built using repainted panels with either method can be loaded into a pure stock version of the game and will just appear with the default white colour variant for the panels. Panels repainted using TexturesUnlimited will also cause a warning about missing modules to be displayed, but this is safely ignorable.

Not sure what you mean about only seeing an "i" in stock storage. They look OK in a test I just did (KIS NOT installed). They also worked fine attaching and detaching them with an EVA kerbal on the launchpad. (The RTS needed 2 Kerbals because of its weight (100kg) but that wouldn't be an issue in orbit or on most other planets or moons where gravity is lower)

@Bizobinator It's probably not SunkWorks. I just checked my ModuleManager.ConfigCache file and the jetpack in my game build is still showing 17L. You can find out which mods are affecting the jetpack by opening the file Logs/ModuleManager/ModuleManager.log in a text editor and searching for Jetpack.cfg/PART[evaJetpack] In my current game build I get 14 matches from 8 different mods: Depending on what mods you have installed, your list will likely be different. Once you've identified all the patches being applied it's then a case of looking at each one and seeing if it modifies packedVolume

The ground tether should still be there. It's provided by one of the dependencies, USI Tools. Perhaps you're looking on the wrong parts? It's only present on a limited number of parts by default - the MKS wide landing legs, MKS hubs, Salamander Pod and a few others. You can check that it is being correctly configured by searching your ModuleManager.ConfigCache file for "name = USI_InertialDampener" (without the quotes) to see which parts it's being added to. I personally use a custom ModuleManager patch to add it to all probe cores and command pods: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[USI_InertialDampener]]:NEEDS[USITools]:FINAL { MODULE { name = USI_InertialDampener } }

Oops, slight typo with a missing bracket, but I've now tested it on an instance of KSP with just Kerbalism installed and it seems to work correctly. @PART[*]:HAS[@MODULE[Configure]:HAS[#title[Sickbay?Modules]]]:FINAL { @MODULE[Configure]:HAS[#title[Sickbay?Modules]] { @slots = 2 // 1 } }

You need to connect an RTS1 from one vessel to a JS-1 on the other using an EVA kerbal before you can transfer resources between them. This is demonstrated in this video linked in the OP.

@kerbnub The "AddConfigurableSickbay" flag is removed by this patch during the AFTER[zzzKerbalismDefault] phase of patching, so won't be available to use as a test condition during FINAL, Unfortunately that's the same patching phase that sets up the number of config slots earlier in the same file, so you need a different approach to override this. Try (untested): @PART[*]:HAS[@MODULE[Configure]:HAS[#title[Sickbay?Modules]]:FINAL { @MODULE[Configure]:HAS[#title[Sickbay?Modules]] { @slots = 2 // 1 } }