SkyFall2489

C73 Just as expected.

Never gonna B E A N you down

2554

C70

Thanks for that, put it in the OP.

Probably my SSTO Jool 5 (seperate tylo lander pushed to tylo by the ssto, ISRU). I barely made it off Tylo with 0.05 units of EVA fuel left but Jeb made it home safe.

I got Summer Kerman once. Also Burger Kerman. That random name generator is fun.

In english, you're going backwards. You need to be going in the opposite direction.

Well, here's hoping Sarbian doesn't get angry.

Yep! @ColdJ

C44

Nope! @Ryaja

C44

C44

Here ya go, it might not be complete for a while.

2510

C43

Extraplanetary Launchpads, some life support mods, simple logistics, SSPXR

IMPORTANT: PAGE UNDER CONSTRUCTION, NOT FINAL Before I begin: 1. This is my own idea, it is in no way official, nor affiliated with any developer of ModuleManager. 2. I thought it would be helpful. 3. No one told me not to. 4. This is for you, @Ooglak Kerman. And all the others who wished to manage their modules, but could not. So, I figured that many KSP players who use a lot of mods may not exactly have the mods just the way the want. Or maybe a budding modder wants to learn some stuff about CFG files. Part 1: What is Module Manager? ModuleManager is a mod created by @ialdabaoth and currently maintained by @sarbian. A large portion of KSP's data are stored in text files with the .cfg extension. This includes resource definitions, part functionality, science flavor text and gains, and much, much, more. Sometimes, a mod may need to change this existing data as well as adding it's own. That is where Module Manager comes in to help. With ModuleManager, the text in CFG files can change what is actually loaded into the game from what is in the other files. For example, Snacks, a life-support mods, adds some life support supplies to all crewed pods using ModuleManager. THIS GUIDE WILL NOT TELL YOU HOW TO INSTALL MODULE MANAGER. Part 2: The Node Structure The CFG files are set up into a hierarchy of nodes. These nodes contain fields, where data is, and other nodes. Let's take a look at the definition of the Liquid Fuel resource. At the top, in caps, we see "RESOURCE_DEFINITION". This is the type of node. As it does not exist within another node, we call it a top-level node. Within it, are some other nodes and fields. First, is the "name" field. This is not what is displayed, it is an internal name. It is very important, however, for selecting that node for later editing. It also has some other functions for things like functionality. You may notice, that in the displayName and abbreviation fields, there is some #autoLOC_<numbers>. This uses the localization system, displaying a different value based on what language is selected for the game. This will be later discussed further. So, we have those fields, but we also have the "RESOURCE_DRAIN_DEFINITION" node, with its own fields inside. There could be other nodes inside that, and you can go on forever. Part 3: Selecting a Node for Editing At the top of the previous example, we saw the line "RESOURCE_DEFINITION". In front of that, we could have put a few thing, and behind it, we could have put a lot more things. If, at the front, we had an "@" character, we could select a RESOURCE_DEFINITION for editing. if we had a "+" character, it would make a copy and let us edit that. the "!" and "-" characters delete the selected node, but you still have to specify a little something. More detail on this later. Finally, the "%" character edits something if it already exists, and if not, creates it. At the back, we could have put some square brackets. Inside those brackets, we could select a name of the specific node to edit, as there are lots of nodes of the same type. The name is the same as the "name" field specified in the initial creation of the node. You can put the "*" character inside the name, and it will represent any number of any characters. So, "abc*" would select "abc1", "abc2", "abcde", but not "ab3". Additionally, the "?" character can be any one random character. If you want to select every part, you can put just the "*" character into the square brackets. After the square brackets, we can put a comma and then a number, or some other selectors. The numbers indicate which node to edit, if the node they are in have multiple with the same name. The selectors are: HAS, NEEDS, FOR, BEFORE, AFTER, FIRST, and FINAL. They will be discussed in more detail later. After each of these words, there is some stuff in square brackets, and then a colon between everything. Here's an example, from the Blueshift thread: Let's look at each line. First, it edits the parts with a specific set of nodes. Curly braces indicate that we are going a level in. Then, we edit a module node with the name "WBIWarpEngine". Again, curly braces. Finally, we edit the warpSpeedSkillMultiplier field to be 0.6. Remember to make sure that each opening curly brace is paired with a closed curly brace. This is one of the most common mistakes! Part 4: Selecting Fields Fields also need to have the selection character at the front, and can have the other selectors or numbers applied to them. Oh, and the number can be the star symbol to select all of them. If there is no number, the first one is used. These go before the new value, like this: @WhatEverThisIs, 3:NEEDS[xyz] = abc Part 5: Other Selectors There are a few things you can put after each selected node or field: 1. HAS HAS will only make the patch apply to parts with some condition. After the word goes a set of square brackets. Inside, you can put: <character><node/fieldType>[<name>]. The character can be @, # or !. If the character is @, then the patch will only run on parts with that node. If the character is !, then the patch will only run on parts without that node. The # character will be covered later, when we get to variables. The node type should be self-explanatory. is it a PART? MODULE? RESOURCE? The name is just the same as the name field when selecting a part. 2. FOR This one's simple, a mod name goes in the box. This lets Module Manager know that the patch is for that mod. 3. NEEDS For this selector, inside the box goes the name of a mod. The patch will only run if that mod is installed. The ! character can be used to make the patch only run if the mod is not installed, and the | character acts like a logical OR gate, so either of two mods can be installed and the patch will run. To determine whether a mod exists: A. if there is a patch, that runs at all, with the FOR selector carrying a name that is the same as what is in the NEEDS box B. Or, if there is a folder in GameData with the name you are looking for. 4-5. BEFORE and AFTER Mod names go in the box. These make the patch run before or after patches with FOR selectors of the mod name. Useful to avoid pouring the drink before getting out a cup, so to speak. 6-7. FIRST and FINAL Simply put, these just make the patches run before or after everything else. No square brackets needed. COMMUNITY UPDATING As it seems others have begun to add things to this, I will quote them here in the OP. Thanks, everyone!

Science definitions and amounts can be changed with some file-poking and module managing. Same with descriptions. Planet orbits can be changed with Kopernicus.

2507

C41

Still should work fine...

I was planning to create a ModuleManager Help Thread, seeing how many people needed help getting the mod to do what they wanted. The current owner/developer of the mod has said that they don't really see the point, but the new thread will be at no cost to them. However, I have not gotten explicit permission to. I've read through the community guidelines, and they say nothing about this, but I'm still not sure whether I'm allowed to start it or not. See pages 298-299 of the Module Manager thread for specific arguments/reasoning, on both sides of the debate.

I kinda expected this, but it's still hilarious. Might go well with my Astral Express warp-train.