Aelfhe1m

Perhaps Roster Manager is the one you're thinking of

Just an update on 1.3 progress. The most recent 1.2.2 release version (Historian v.1.2.7) is also compatible with 1.3. A recompiled and partially updated 1.3 specific beta version is available in the dev branch on GitHub. This includes work on localising all generated text coming from Historian: I've still got more work to do on updating the documentation and properly testing some of the new features but I expect to do a proper release later this week.

Typically this is done using a ModuleManager patch file (or several) The ModuleColorChanger module (AFAIK) is self contained. It allows a light to be turned on and off by the player. You define how the player will control it through the various properties hence these lines which affect the attached parts PAW menu: toggleName = Toggle Lights eventOnName = Lights On eventOffName = Lights Off If you want the light to respond to some in game event then I believe it requires a custom module. I'm also not really sure how lighting animations are configured in KSP but I believe they require some prep work on the model in Unity.

It won't break RO but RO does not include any configuration files to resize/balance the parts to fit with RO.

Not sure that's possible with just config. Might need a custom part module. (or you could leverage the Indicator Lights mod)

After reading the wiki page you linked (not that that's official per se ) I edited it to try and make it clearer.

It uses the same bit mask pattern as SituationMask but determines where the result will vary by biome as well as situation. SrfLanded = 1 SrfSplashed = 2, FlyingLow = 4, FlyingHigh = 8, InSpaceLow = 16, InSpaceHigh = 32 In the example given situationMask = 63 says the experiment will work everywhere (1 + 2 + 4 + 8 + 16 + 32 = 63) but biomeMask = 3 restricts biome specific results to just 1 (SrfLanded) + 2 (SrfSplashed)

This is a problem with several part mods and how they interact with rescue contracts. So of course somebody wrote a mod...

Based on my initial testing so far, if you supply values for all your localisation strings in the en-us section then other languages will fall back to using the English versions but if there are any missing from the en-us block (even if present in say the ja block) then the English version of the game won't use the alternate language definition. i.e. a custom localisation config of: Localization { en-us { #mymod_one = one #mymod_two = two } ja { #mymod_one = 一 #mymod_three = 三 } } Will work fine in the Japanese version of the game for all three tags (using the English fall back for #mymod_two) but the English game won't fall back to using the Japanese definition for #mymod_three Edit: this is based on using calls to Localizer.Format(template) or Localizer.GetStringByTag(tag) in a C# module to populate text in a UI window.

You need to use the dev version of MechJeb. There's instructions in the OP for installing it either manually or through CKAN

You need a copy of the tree.cfg file.

In Steam right click on KSP and select properties then go to the language tab. After you change a language Steam will then download the localised files for that language. If this doesn't seem to be happening then you can go to the "local files" tab and try verifying integrity.

Ah well there's your problem. Baked tablets are only good for archive storage. You want to keep them nice and moist for rapid updating scenarios...

Aim for a low altitude landing spot. The higher the altitude of the landing site the less braking effect you'll get from the thin Martian atmosphere. Also make sure to include both drogues and main chutes and even then you'll likely want to use rockets to wipe off residual velocity before touch-down. NathanKell included several videos in his RP-0 YouTube series about Mars missions - try this one to start with (disclaimer: I haven't rewatched it to make sure it's the right one, just picked based on title)

AFAIK KSP pugins need to be compiled as .NET 3.5 libraries.

It's not just inflating the outer shell but also equipping the interior space with furniture, shelves, containers, equipment, machinery etc. etc.

@jonrd463 I've seen similar behaviour in a variety of spaceplanes recently (not just ones with OPT parts) but mainly in roll oscillations that start out gently but quickly build up to wild tumbling. Some planes can be fixed by playing about with adjusting control authority on the reaction wheels (or just disabling them and relying on RCS) but others I've just had to fly manually instead. Another tactic I've been using to mitigate is turning on fine controls and setting the max velocity on the docking auto-pilot very low (0.2 or so) but at that point it's no longer saving me any time so that's often when I switch over to manual. The save this is happening in has a HUGE amount of mods so I'm not ready to point a finger at any suspects.

I thought that might be the case but just wanted to check. I can understand the tracking stations not working, they are quite new after all , but it's also not working for me with the regular monoliths. The same rover visited monolith00 and monolith02 on Gael but couldn't get a reading from either: PS: They are identified in SCANsat maps as monolith00 and monolith02

@DMagic There seems to be a minor inconsistency in the way the information text at the bottom of the main map and zoom map windows show anomalies. In the main map the text says "Anomaly: <name>" whereas in the zoom map it shows "?: <name>" These images were taken in Galileo Planet Pack if that makes a difference. PS: second image also shows a potential problem with orbital science's anomalous signal detector in my (VERY) heavily modded save - it always shows "No anomalous signal detected" even when I'm right next to an anomaly (log).

@DC Early game rockets will tend to produce highly eccentric orbits (just look at the real life Explorer, Vanguard etc.). To reliably get a more-or-less circular orbit I need the final stage to NOT be a SRB - some form of RCS or multi-ignition engine is needed for really fine control. However to try and minimise the eccentricity you can let your AJ-10 stage coast to apoapsis (provided its above the atmosphere) and then use its RCS to align pro-grade before staging the sergeants. Practice flying the first two stages consistently to get more or less the same burnout apoapsis on each launch. After that playing with the amount of fuel in the sergeant stages can help to target more closely having just enough dV in the final stages to circularise - doing a test flight and pausing the game just as you pass through circularisation can help gauge how much fuel to remove but reducing the weight of the final or penultimate stages will of course have knock on effects on the other stages. To be honest I wouldn't worry about it and wait until you've unlocked better tech before trying for precision orbits.

@ClLaw When you extract RP-0 to your GameData folder it should include the bin/yml2mm script. Open a command prompt (on Windows open the start menu then type cmd and press return), Change directory to the GameData/RP-0 folder (type cd "e:\Games\KSP\1.2.2 RP-0\Gamedata\RP-0" - changing the bit in red to match where you've installed your copy of KSP that you're installing RP-0 on - and press return) Then type the "perl bin/yml2mm". This should create a Tree.cfg file in the same folder. Edit: I typed the above from memory but I got the location of the folders a bit wrong. I've now actually checked and here is the corrected version. Download the master branch from GitHub (link) Extract the zipped RP-0-master folder to a temp location (e.g. e:\Games\Temp\RP-0-master) That folder will contain the tree.yml file, the bin folder with the script, the source files and output GameData folder. Open a command prompt (on Windows open the start menu then type cmd and press enter) In the command window change the folder to the unzipped temp folder (type cd "e:\Games\Temp\RP-0-master" and press enter - changing this to reflect the actual path you unzipped to - you may also need to switch to the correct drive first e.g. by entering e:) Type perl bin\yml2mm and press enter to compile and replace the Tree.cfg file inside the temp GameData folder (e.g. e:\Games\Temp\RP-0-master\GameData\RP-0\tree.cfg) You can now replace the RP-0 folder inside your KSP GameData folder with the version from the temp GameData folder to have an up-to-date version of the mod. Sorry for any confusion my mistake may have caused anyone.

Almost. Deleting a module requires empty braces after the filter so: @PART[Tundra_ASM]:NEEDS[!Karbonite]:FINAL { -MODULE[ModuleResourceConverter_USI]:HAS[@INPUT_RESOURCE[Karbonite]] {} }

I've only skimmed the article (interesting read) but it's about "pure" gravitational slingshots. You can get a much bigger boost by taking advantage of the Oberth effect during your sun-dive and doing a powered slingshot - burning fuel while whizzing past close to the Sun (or Ciro) gives you a lot more dV than burning it out at Earth's (Gael's) orbit.

@MaxL_1023 and @CatastrophicFailure. Most of the articles I could find about Jupiter -> low solar slingshot missions were in various science journals behind paywalls - however there were a couple of mentions in JPL studies including: https://interstellar.jpl.nasa.gov/interstellar/probe/requirements/concept.html and http://www.esa.int/gsp/ACT/doc/MAD/ACT-PRE-MAD-InnSys-McNutt.pdf (only brief mention). There's also a nice article about the science goals of the FOCAL mission to 550 AU on Centauri Dreams (http://www.centauri-dreams.org/?p=785) but not about how to get there efficiently.