Aelfhe1m

The composite lists the two image numbers in the caption at the bottom. For reference: https://commons.wikimedia.org/wiki/File:AS12-48-7133_(21470506269).jpg https://commons.wikimedia.org/wiki/File:AS12-48-7136_(21657315235).jpg Almost all Apollo images show only one of the astronauts at a time because the other would be holding the camera.

This mod is mostly cosmetic and doesn't interact with career (or cause any problems). All the extra buildings pads, roadways etc. will show up immediately. The stock buildings upgrade normally. Adding it mid-save shouldn't cause any problems but it's good practice to backup your save before adding new mods.

@Fergrim The MLI option is definitely there. How far down the tech tree have you gone? Single layer MLI is supposed to unlock with "Advanced Capsules Era Material Science", then 25 layers with "Lunar Exploration Era Material Science" and 50 layers with "Space Station Era Material Science". After I typed the above, I checked in my career save and there does seem to be some sort of possible error - but I'm not seeing the one you're reporting. Instead all my basic RO modular tanks and Procedural Parts tanks HAVE the MLI option when it shouldn't be unlocked at my stage of tech development. The option is not present on any of the other tanks just the basic (cylindrical) modular tanks and the procedural parts tanks. As for comms. I've got very little unlocked in that part of my career tech tree to check but all the options I would expect seem to be showing up in sandbox - first time playing with Real Antennas so I might be missing something but sliders for band selection, tech level, db gain and active transmission time which seems to match the user guide in the wiki.

Making a patch only apply if a given mod is installed MM uses :NEEDS to mark that a patch should only be processed if the mods it needs are present. Each patch may only have a single NEEDS statement, but more than one mod can be specified within the needs. @PART:NEEDS[Tweakscale,ModularFuelTanks] The above example is a patch that would only be applied if BOTH Tweakscale and ModularFuelTanks were found in your GameData folder. Patches can also specify that they need a given mod NOT to be installed. @PART:NEEDS[!Tweakscale,!ModularFuelTanks] In this case the "!" character stands for NOT and is specifying that this patch should only be applied if Tweakscale and ModularFuelTanks are NOT present. You can of course mix and match both required and not required @PART:NEEDS[ModularFuelTanks,!Tweakscale] NEEDS can also recognise the "|" character to mean OR @PART:NEEDS[Tweakscale|ModularFuelTanks] This specifies that the patch should be applied if EITHER Tweakscale or ModularFuelTanks are installed (or both it's not exclusive) MM "knows" which mods are installed based on several tests: there is a DLL with the specified name somewhere inside the game's folder there is a folder with that name inside GameData there is another patch that has a :FOR[] statement containing the mod name there is special code inside the mod's DLL (assembly) to tell MM to add a name to its list of recognised mods So for example MM would believe that Tweakscale was installed if: it found a file called Tweakscale.dll it found a folder called GameData/Tweakscale it found another patch with :FOR[Tweakscale] if another mod had code inside its DLL that told MM Tweakscale existed MM includes a full list of all the mods it has found near the start of its logfile (KSP/Logs/ModuleManager/ModuleManager.log) NEEDS can also be used to check for subfolders within GameData @PART:NEEDS[TriggerTech/KerbalAlarmClock] Because of the way Module Manager detects mods it is VERY important to make sure that you completely delete a mods folder and all its related files when removing a mod. An empty folder will still cause MM to treat a mod as being present and it will apply any patches related to that mod which can lead to errors or unexpected behaviours. Also all patch authors need to be careful to use FOR correctly, since Module Manager uses this to detect the presence of a mod. ONLY the original mod should use FOR[Modname], ALL other mods or personal patches should use BEFORE, AFTER or NEEDS when referring to the name of another mod. Controlling the order in which patches are applied - FIRST, BEFORE, FOR, AFTER, LAST, FINAL When doing patching Module Manager starts by scanning through the GameData folder to find all the contained patches. Then: Nodes with no operator are loaded by the KSP GameDatabase first. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed. All patches with :FIRST are applied. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. For each recognised modname: All patches with :BEFORE are applied All patches with :FOR are applied All patches with :AFTER are applied All patches with :LAST are applied in order All patches with :FINAL are applied If two patches have the same priority in the above list then they will be sorted based on the filename of the files containing the patch or if they are in the same file then the order with which they appear in that file. Consider the following (very contrived) example: Module Manager will produce the following patch log for this KSP install: Notice for example that BEFORE[Handwavium],FOR[Handwavium] and AFTER[Handwavium] all occurred before FOR{ModA] but that LAST[Handwavium] occurred after all the BEFORE/FOR/AFTER passes (and before FINAL)

Should be fully compatible. There's nothing in how SSS modifies parts that should interfere with it.

@DeadJohn Stage recovery's powered recovery should work with any fuel. Very exotic engines that don't use "ModuleEngine" or "ModuleEngineFX" and SRB's (propellant name like *solidfuel*) should be the only exceptions.

I've got some custom Manufacturer icons that I saved in a GameData/ZZZ_Custom/Icons folder as 32x32 px dds files. As long as I name the icon exactly the same as the mods folder name in GameData and (optionally) have another named the same with _selected suffix then they seem to show up fine in game. I haven't made any specifically for my RP-1 game (not enough parts to need it) but the ReStock+ and Squad Expansion icons I use for other games are showing up fine.

9 September 1958: First flight of the Sirocco orbital launch vehicle carrying the Venti 1 satellite. Unfortunately the second stage failed to ignite after a guidance program error resulted in an attempt to light it prematurely after insufficient ullage. 19 November 1958: The second Sirocco flight took advantage of lessons learned and a successful second stage ignition inserted the Venti 2 satellite into a 235 km x 5,382 km orbit. 25 January 1959: Third Sirocco launch placed the first solar powered Venti 3 satellite into orbit. Then on 1st April, Venti 4 was launched into a polar orbit. 10 July 1959: Sylvain Roux piloted the maiden flight of the XA-201 Thunderbird rocketplane. Inefficiencies in the flight profile meant he just failed to reach the Karman Line, topping out at 97,667m altitude before gliding back to land at the cape. There was a period of concern when the spoilers sheared off when Sylvain deployed them a little early. Despite touching down a little faster than intended because of this, the drag chutes deployed correctly and brought the Thunderbird to a safe stop on the runway. A post-flight inspection determined that despite the total loss of both spoilers, the damage to the airframe was otherwise minimal and the plane was cleared to resume flight tests after relatively minor repairs. 30 July 1959: Later that month, Charlotte Cook took the Thunderbird for a second flight. A better flight profile allowed her to easily exceed the Karman Line, reaching a staggering 132.4 km peak altitude before returning for an incident free landing at the Cape. 25 October 1959: The seventh Sirocco launch placed a biological capsule into a 230 km orbit before successfully returning the data to Earth in a re-entry capsule. 15 November 1959: Reginald Morrison piloted the third flight of the Thunderbird. Collecting useful science on hypersonic flight during a sustained 1.6 km/s flight above 65 km altitude. Unfortunately, he overshot his approach and ran off the end of the runway. The plane did not suffer any significant damage however and Reginald emerged from his misadventure unscathed. 16 December 1959: A night launch from a Sirocco rocket placed the Simoon 1 probe into a 280 km parking orbit around Earth. 26 minutes later the GCRC booster fired launching the probe onto a trans-lunar trajectory. A minor error in timing the start of the burn unfortunately resulted in a slightly wider fly-past of The Moon than had initially been intended but some useful science was still transmitted back to Earth. 12 February 1960: Another night launch placed the Simoon 2, sister probe to the unsuccessful Simoon 1, into Earth orbit. The TLI burn went without a hitch this time, sending the probe to fly-past The Moon at less than 3,400 km before escaping Earth's gravity entirely. Mission controllers monitoring its trajectory estimate that it will return to Earth's near vicinity in just over 4 and a half years time.

Contributions for this thread: Selecting Nodes - or how to use :HAS Consider the following nodes partially extracted from the stock files: How would we select the cupola part to change it? The most common way you will see this done in MM patches is @PART[cupola] This is actually a special shortcut for @PART:HAS[#name[cupola]] Because it is a shortcut for selecting nodes based on their name fields it won't work for nodes that don't have a name field like the EXPERIMENT_DEFINITION node in the above example. To select those you need to identify a field with a useful value and then explicitly refer to it in the HAS clause: @EXPERIMENT_DEFINITION:HAS[#experiment_id[crewReport]] You can also select nodes based on whether or not they contain a certain subnode. For example the cupola PART node above has several MODULE subnodes (as do almost all PART nodes), so the following patch would affect it: @PART:HAS[@MODULE[ModuleCommand]] This selector will affect every PART node that has at least one MODULE subnode that has a name field with the vale "ModuleCommand" (remember [X] is a shortcut for :HAS[#name[X]]) We can also multiple conditions. e.g. @PART[*]:HAS[@MODULE[ModuleCommand]],RESOURCE[ElectricCharge]) This breaks down as - select all PART nodes that have a name field with any value (* is a wildcard), and a MODULE subnode with a name field containing the value "ModuleCommand" and a RESOURCE subnode with a name field with the value "ElectricCharge". In this example the "," represents AND. MM also allows you to use "&" for AND so this could also be written as @PART[*]:HAS[@MODULE[ModuleCommand]]&RESOURCE[ElectricCharge]) Which you choose to use is a matter of personal preference as they will behave identically. Unfortunately MM only recognises OR in a limited number of places. You can use it inside the name shortcut or in a :NEEDS clause but it won't work inside of a :HAS clause. So the following will work (MM uses "|" to mean OR) @PART[cupola|Mark1Cockpit] @PART:NEEDS[modA|modB] but this WON'T work: @PART:HAS[@RESOURCE[ElectricCharge|MonoPropellant]] You would need to write separate patches for each resource type @PART:HAS[@RESOURCE[ElectricCharge]] {} @PART:HAS[@RESOURCE[MonoPropellant]] {} b. Choosing which subnodes to edit :HAS is also used within the contents of a patch filter which subnodes are affected by a given change. Suppose for example we wanted to changed the minimum number of crew required to operate a cupola in the above PART example. First you would use a selector to choose the cupola PART node, then inside the contents of the patch you would use another selector to choose the ModuleCommand MODULE subnode: @PART[cupola] { @MODULE[ModuleCommand] { @minimumCrew = 0 } } Because both PART and MODULE have name fields we can use the shorthand [X] form here. We could also have written out the patch in the full form: @PART:HAS[#name[cupola]] { @MODULE:HAS[#name[ModuleCommand]] { @minimumCrew = 0 } } but that takes more typing. If a subnode does not have a name field or there are multiple subnodes with the same value in the name field then you will need to use a HAS to identify the specific subnode based on some other unique value. For example suppose we have a part with two experiments - a temperatureScan and a barometerScan. This would look like: To change the temperatureScan's action name we would use: @PART[foo] { @MODULE[ModuleScieneExperiment]:HAS[#experimentID[temperatureScan]] { @experimentActionName = Take the temperature } } Notice how we first use :HAS[@MODULE[ModuleScienceExperiment] to identify that we want to affect ModuleScienceExperiment subnodes then we use an extra :HAS[#experimentID[temperatureScan]] sub-clause to narrow this down to just the MODULES with an experimentID field with the value "temperatureScan". NOTE we use @ when selecting based on subnodes and # to select based on fields If instead of only modifying the foo PART, we wanted to modify all PARTs that had a temperatureScan experiment MODULE then we would repeat the selector on the main node as well: @PART:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[temperatureScan]]] { @MODULE[ModuleScieneExperiment]:HAS[#experimentID[temperatureScan]] { @experimentActionName = Take the temperature } } c. Selecting nodes that do not match a specific criterium Suppose we want to select all PART nodes that do not have a "bulkheadProfile" field: @PART:HAS[~bulkheadProfile[]] or all PART nodes that do not contain a MODULE subnode with name "ModuleCommand" @PART:HAS[!MODULE[ModuleCommand]] Notice that we use ~ when comparing fields and ! when comparing subnodes. d. Lists of fields Consider the following node RESULTS { message = One message = Two message = Three message = four } Suppose we wanted to change "Two" to "2". How would we do that? MM provides indexers to distinguish between identical options @RESULTS { @message,1 = 2 } Here the ",1" means the second message field (indexes count up from 0). You can also count from the end using negative indexes (",-1" = last value, ",-2" the second last and so on). The wildcard index ",*" means select ALL. We can also modify specific values within fields that have a list of values. For example: PART { name = foo node_stack_top = 0.0, .9, 0.0, 0.0, 1.0, 0.0, 2 } Suppose we want to change the .9 in the second value to 1.0 @PART[foo] { @node_stack_top[1] = 1.0 } The use of the index here will work for any field where the values are separated by commas. But what if the mod author had used a different separator? PART { name = foo otherfield = one|two|three|four } then we specify both the index and the separator @PART[foo] { @otherfield[2,|] = 3 } // result PART { name = foo otherfield = one|two|3|four }

In principle to patch that template would be something like: // There is no name field on the OMNICONVERTER templates so use ConverterName field which looks unique // and replace space in value with wildcard @OMNICONVERTER:HAS[#ConverterName[FusionPellets?Processor]] { // again no name field so use ResourceName field instead @INPUT_RESOURCE:HAS[#ResourceName[Ore]] { @Ratio = 15 // new number here } } Although how WBT uses the templates may affect the end result.

Writing some code to change the flavour text based on in-game date would probably be a bit overkill , although avoiding mentioning population at all might have been better than picking a single data point, especially one that's only a little more than a decade old and that may well be obsolete by the end of this year.

@Eleven Take a look at the OP. Restock improves the stock parts. Restock+ adds some "missing" parts.

Yes. You can't use MM to change the NEEDS of another patch.

Use CapCom for that (yes it works with 1.12.3 and earlier). The CC contracts don't show up in the debug offered section because they are running on a somewhat different system than the stock contracts so the stock system doesn't know about them until after they are accepted.

Although if you're going that route then be aware that there are two launch clamp pumping processes: the _ClampPump Process is defined in the RO Kerbalism config and supplies EC, oxygen, LOX, H2, LH2, food, water and nitrogen at 10 u/s. the RefuelingPump Module is defined by RealFuels and supplies modular fuel tanks with any (pumpable) resource they contain at 10000 u/s For maximum realism you'd want to decrease the pump rates. Also, while fuel costs are a smaller fraction of the total rocket cost in RP than in stock, filling the tanks on the pad essentially gets you fuel for free and makes KCT rollout slightly quicker and cheaper too. Decreasing pump rates could compensate for the decreased KCT rollout time by requiring you to fast forward a few hours on pad while waiting for tanks to fill. (It would also decrease the current fuel bonus you get during engine spool up prior to clamp release)

Yes, copy text into new text file and save with a .cfg file extension to anywhere in GameData (e.g. GameData/ZZZ_Custom/WeldableDockingPorts.cfg)

Module Manager patch to make any non-animated (e.g. extending, shielded etc.) docking port weldable:

Some suggestions for new challenges: Eve landing and ascent (hard) Jool 5 - land on all the moons of Jool Grand Tour - use a single vessel (mothership) to visit every planet and moon, landing where possible Start a new career with a larger tech tree Outer planets mod to give you more destinations One of the planet packs that adds additional star systems - interstellar is a whole new level of difficulty, especially if you don't install any of the mods that add FTL A new career in an upscaled system 2.5x and 2.7x can still be done with stock parts but the delta-V margins are harder (try JNSQ or KSRSS) or go full scale with RSS with or without RP-1 for the full career challenge

The upgraded pads also come with larger size limits. 20mx25m at 20t => 25mx33m at 60t Well it is a single player game so the only person you're cheating is yourself, set yourself whatever rules and goals you choose. Although one of the reasons to play RP-1 is the realism.

There are some national flags in the collection here: https://github.com/willwill2will54/Flag-Pack Also some individual countries covered: https://github.com/miki-g/KSP-Slovakia-Flags https://github.com/Venthe/KSP-Polish-Flag-Pack Collections of real world company logos:

Yes 20t pad. At least in my version the Engineer's Report only counts the mass of the rocket not the launch stand. So as long as the rocket (minus the MLP parts) is under 20t it still allows it to launch. Note: I really pushed the mass for the below screen shot for the purposes of demonstration. The engine on this rocket also has a ~1.5s spool-up time before releasing launch clamps.

It's easy to make your own: Go to commons.wikimedia.org Type "flag of <countryname>" into the search in the top right (e.g. "flag of Scotland") and press return At the top left of the search results click license and choose "no restrictions" to make sure there are no copyright problems with using the flag Look at the flags found and click one you want. Click the "more details" button Click open in Media Viewer Click download and select "small" (you usually want about 512 x 320 or smaller .png) You can use this directly by saving it into a folder inside GameData. E.g. GameData/ZZZ_Custom/flags (NOTE: the last part of the folder name must be flags) or if you want to save a bit of memory/disc space then you can use a graphics program like Gimp or Paint.net to convert it to a DDS file before saving it into the flags folder. See also this tutorial: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Create_custom_flags!

Or @PART[*]:HAS[#CrewCapacity[>X]] for all parts with crew capacity of more than X. You can also use < but not >= or <=

@LEC Be careful when inserting modules at the start. There are some stock modules that use index numbers to link to each other, so inserting something at the beginning can break those functionality. e.g. the Mobile Processing Lab: PART { ... MODULE { name = ModuleScienceContainer ... } MODULE { name = ModuleScienceLab containerModuleIndex = 0 // <==== NOTE ... } ... } There are other examples, animations for instance. It might be better to first move the ModuleInventoryPart to the end (clone new copy - $MODULE[ModuleInventoryPart] {}, then delete first copy - !MODULE[ModuleInventoryPart],0 {}), before inserting the ModuleCargoPart at the penultimate position (index = -2)

Elaborating on @obnox twin's point, most RL design concepts have either had large wings on the booster stage; mounted the spaceplane piggy back (like Shuttle and Buran) so that the plane's wings are as close to the rear of the combined vehicle as possible; or wrapped a small spaceplane in a fairing for launch. Without one of these choice the centre of pressure tends to be too far up the vehicle for stability.