Jacke

I'd have to check to be sure, but I think using ethanol with a smaller water fraction (example Ethanol90 over Ethanol75), required in some engines to function, only results in limited extra heat production and other reaction changes, unlikely to push the engine past any limit. The more likely reason to use Ethanol75 (and design to its use) is it's cheaper, easier to handle, and can be made with a less complex distillery.

It's not hard to get these keyboard control collisions, as well as have problems with inadvertent trim. (Trim is very useful in fine aircraft and rocket control. As well, the new Unity 5 UI helps by making the stock attitude control needles in the lower left larger and easier to read by default.) That's because another common source of issues is that in KSP, functions linked to [Key] will also be triggered on pressing [Mod]+[Key] (in addition to the functions linked to [Mod]+[Key]); in other words on Windows, pressing Alt-[Key] also acts as if [Key] was pressed. For example, @sarbian's excellent GCMonitor toggles the display of its control window with Alt-F1. This issue means bringing up and dismissing GCMonitor's window by pressing Alt-F1 twice also creates two screenshots, just as if F1 was pressed twice. So inadvertently triggering multiple actions is not just a problem with functions with the same keypress, it's also functions with similar keypresses differing only by whether they include using [Mod].

Wow! Very cool! And that shot at the start of the video, where we saw only part of an arm (part of the MSS, maybe the Canadarm 2, I think), it reminded me of the first scene in Earth orbit in "2001", where the orbital nuclear weapon platform goes by.

I think CKAN's problems come at least partly from trying to do something like Debian's package system, but without the standards hashed out in the Debian Policy Manual. Now I realise another facet of that issue: the problem of trying to turn KSP's mod system into a package system without those standard practices, which include having a standard package handling system with dpkg and the apt library, which also allow programs to figure out exactly what state a package is in. And there's not just 2, installed or removed. I imagine CKAN doesn't want to remove a mod's directories when it finds files created by the mod, things like plugin data, created configs, and/or log files. This is equivalent to a Debian's package's "configured" state. With Debian, when a package in status "installed" is removed and has those config and package related generated files still around, it gets put into "configured" status. The package can also be purged, which removes those files and any package directories now empty, with the package going back to the "purged" status, which uninstalled packages start at. Other programs (and sysadmins) can make inquiries to determine what a package's status is, "purged", "configured", or "installed", as well as others that happen in certain circumstances. So, it comes down to CKAN when removing a mod can leave it in the "configured" state. While Module Manager, if it sees the directories, it thinks the mod is "installed". Thus, the conflict.

How does ROMini compare with SMURFF's adjustments?

...making sure you also install ModuleManager.2.6.24.dll into GameData if you don't have it, as RPM won't work without Module Manager, and MM version 2.6.24 or later is needed on KSP 1.1.2.

Putting on 2 or more sets of Indicator Lights might help with using them for orientation, as well as being crafty with where they are put. I found that helps with Aviation Lights, even with them illumnating and the glow being visible even when they weren't in direct line of sight. I did something like that with Aviation Lights marker lights. I would put a red one on the left, a green one on the right, a white one on top, and a blue one on the bottom. "Top" and "bottom" can seem odd for landers but I find it works. (While landing, when the lander is bottom away from me slowing down from orbit, the blue light on "bottom" will be uppermost and white on "top" will be undermost, but red is left and green is right.) Use them for orientation in docking and landing. Here's a picture in the spoiler of them on an unmanned Mun 2-stage lander-return. (The non-stock tank is the Better Than Starting Manned Octotank, a 2.5m part half the size of the X200-8 tank.) Side towards the camera is the top with the white marker light. You can just see the glow of the left-side red and the right-side green lights, with the bottom-side blue one out of sight on the far side, but you can just make out its glow on Mun's surface. As he notes in the last post of that topic, @tg626 has release that mod as KOAS for KSP 1.1+.

When you launch KSP you should see the 4-part release number in the lower right, as well as an indicator whether you are running in 64-bit mod. There is an option in the settings to turn it off, but you shouldn't see a partial one. Although it could be some sort of graphics issue, I've never heard of one in the menu splash screens. Here are the recent KSP releases: 1.1.0.1230 1.1.1.1250 1.1.2.1260 You probably have 1.1.1.1250.

If you are running KSP 1.1.2, you need to have Module Manager 2.6.24 or later (current is 2.6.24) and remove any older versions. Earlier versions of Module Manager under KSP 1.1.2 will fail to run any Module Manager scripts.

That's just the Toolbar source on Github. Not all mods have install .zips on Github, even if they have their source there. As @blizzy78 said, you always should check the first post of the mod's topic to find out where to download the install .zip for a mod. And unfortunately, sometimes the information that CKAN has is wrong for one reason or another.

Still have to get a career going to test out Mk1 reentries in KSP 1.1.2, but I'm familiar with reentry as it is on Earth, as well as back in KSP 1.0. Reentries from 90deg polar orbits face an extra 175m/s velocity increase compared to Kerbin equatorial prograde reentries, as Kerbin is turning at 175m/s to the east, which helps the prograde reentries. At least it's not as bad as a retrograde reentry; coming back from a retrograde orbit, the reentry will be at 350m/s greater speed.

After Squad rolled out the new forum software (IPS4, ugh), they got topic link conversion working (old link "/thread/..." to new link "/index.php?/topic/...") and it still happens now automatically. However, post numbers have never converted (old link "/thread/.../post...." to new link "/index.php?/topic/.../&page=...#comment-..."). Have to search out and find those manually. Or not. Lost a fair number of links meself.

Based on figures I've seen in the past (old textbooks I don't have to hand), for people the 2.81kg food per day is high but may be due to factors like packaging and other things included. Just the food (non-dehydrated) is about 1kg/day. Packaging shouldn't increase by more than 50%, so packaged about 1.5kg. The 10L volume is about right. Above that has to be including other personal requirements grouped with food. 1.0kg/day of water is an absolute minimum. People even doing mild work put that up to 4.0kg and it can go higher. I think oxygen will ramp up less than water. It's common to store Oxygen as LOX even in things like aircraft supply systems Here's numbers from my first source below, quote copied in the spoiler. Third column is what I think are good working values. Oxygen almost certainly would be carried as LOX, 1.141 kg/L, as the space reduction is a greater benefit than needing the equipment to warm it to deliver as a gas. INPUTS Source says Working values Food 0.62kg 1.00kg Water 3.52kg 4.00kg Oxygen 0.84kg 1.00kg OUTPUTS Solid wastes 0.11kg 0.20kg Liquid wastes 3.87kg 4.50kg Carbon dioxide 1.00kg 1.30kg https://en.wikipedia.org/wiki/Life_support_system https://en.wikipedia.org/wiki/Human_spaceflight#Safety_concerns https://en.wikipedia.org/wiki/Space_food https://en.wikipedia.org/wiki/Space_medicine https://www.nasa.gov/pdf/500436main_TA06-HHLSHS-DRAFT-Nov2010-A.pdf DRAFT Human Health, Life Support and Habitation Systems

@aluc24, if you'd like some advice on managing manual installs, PM me. @Svm420, using the word "laziness" is an insult; don't try to wiggle out of your word choice. Lots of people want to play KSP with mods and just don't know how to do things so they don't get burned by the rate of change. Insulting them isn't going to help anyone.

Both EVE and RVE are working. Try following and asking on their topics.

@TriggerAu will have to comment about changing KAC, especially about it picking up changed Kerbin times, but I have a suggestion. Did you try changing the KSP time system to Earth time in the standard settings? It defaults to Kerbin time, which is likely hardwired to stock Kerbin days. Earth time is likely hardwired too, but at least that's the time scale you want to adjust to. Haven't tested it thoroughly for the recent versions, but selecting Earth time has had KAC show and use Earth times in the past.

I've used parts from the Aviation Lights mod in a similar way, to put Navigation Lights on my spacecraft, but it's more for me to better orient the spacecraft, and when left lite on a docking target, see how it is oriented. You actually don't want them on the docking ports. You want them on the spacecraft at points like an aircraft in the Wikipedia article, so you can see how it's oriented. You can do this with Indicator Lights too. For docking in shadows, it can be helpful to use the stock Illuminators Mk1 & Mk2 aimed forward to light the target as needed. But the best solution is the Docking Port Aligment Indicator mod. With it, you'll get properly aligned and docked just right.

I suggest belt-and-suspenders safe upgraded+modded gaming techniques. We want games to just work, but if you want the cool features on a game with mods that's under active development, you have to do a bit more to live at the performance edge. And if you would like help, give a few more details. Backups, backups, backups. Make sure any game you have from a previous version has its savegame copied to a safe location before you use it to see if you'll have problems. Don't know what OS you have, whether you run 32-bit on Windows or 64-bit on which of the 3, or whether you get KSP from the store or Steam, but all of this can be adapted to any of them. Start with the base KSP game. No mods. Wipe the previous download as possibly corrupted. Clean out the install directory of ALL files (move them to a safe location if you're not sure you might need something from them, like a savegame not backed up). Download the game fresh. If on Steam, after it finishes, ask it to verify the files. Then run it once, unmodded, to confirm it's okay. Don't even leave the first menu screen. Record the new version number (should be 1.1.2.1260). Then exit. Copy the whole game directory to a new location. This is your pristine unmodded copy of 1.1.2.1260. Then copy that one again. This is your working copy of 1.1.2.1260. This one you mod and play, via a direct link to the game executable, KSP_x64.exe on 64-bit Windows. I give more details on using these copies here. Then launch KSP from your working copy, without mods. Make a sandbox or a career game. Make simple fresh craft. Play with it a bit. Then check your mods for updates (especially Module Manager which has a need new version for KSP 1.1.2) and add them in, only a few at a time. It's a pain, but you can avoid some of the bugs. You work around them and find what works.

This is a general problem with stock and mods having a lot of key usage collisions. Isn't helped that many functions, like KSP screenshot (F1), activate even if modifier keys like Windows Alt (KSP Mod in the Wiki) are held. So when I toggle the window for @sarbian's GC Monitor with Alt-F1, I get a screenshot per press as a bonus. Don't know if there's a good way to make this significantly better than it is.

But with a bug killing Module Manager before it gets out of the garage, I think the Hype Bus has blown a tire. Probably equiped with 1.1.0.

Which is why you back up the Steam directory immediately after it updates (as well as stop its download by deleting local files and making sure its directory is empty before telling it to install the new version). I backed up my Steam copy of KSP this morning. That's my pristine copy of 1.1.2.1260. Then I copy it again. That's the copy I mod and play from using a link to its KSP_x64.exe. And Steam can't affect either one. Do the same after hotfixes.

I did some testing earlier and found a version of 1.1.0. If you're quick, you might be able to get a 1.1.0 install before 1.1.2 shows up and things change. Then copy it out of the Steam directory into a backup directory so you can't lose it again. Here's what I found earlier yesterday. I just tested the "prerelease" verison and it is still 1.1.0.1228 for 32-bit, 64-bit, and apparently the rest of the files. 2016 Apr 29 Fri KSP on Steam under Win 8.1 64-bit for different settings of Beta dropdown NONE 1.1.1.1250 prerelease 1.1.0.1228 previous 1.0.5.1028 32-bit .exe 1.1.1.1250 64-bit .exe 1.1.1.1250 Squad parts Go for the "prerelease" Beta setting and you should get 1.1.0.1228, which is just before the KSP 1.1.0 version, 1.1.0.1230. Hopefully the changes are trivial. I suggest you delete everything in the Steam KSP program directory so it has no cruft. Set the Beta setting to prerelease, then download it. When it's finished, I highly suggest you Verity the Integrity of the Game Cache to make the all the KSP files are correct. THEN take Steam offline or exit its client so it can't update until you've save KSP 1.1.0.1228 elsewhere. I suggest following what I posted here about saving an unmodded copy of the KSP verison, then saving another copy to mod and play. You don't run KSP through Steam. You use a link to the 64-bit executable KSP_x64.exe of the modded copy.

K-SPOOOOOOOOOOOONNNN!!!!! Indeed. I should get on and test a mod updated for 1.1.1 in 1.1.1. Or sleep and later test it in 1.1.2. And that's our IPS4 software. Hopefully GregroxMun is either asleep in the bunkhouse or out in the roundhouse. And for some reason the title of this topic has me thinking of a similar phrase. Found the version of it I was looking for. Here's my suggestion for the theme for KSP 1.1.2.

Indeed. As someone's who's coded priority operators (and may they all be suffix operators...) I completely understand. Starting to get the hang of the syntax. Wish I had better documentation (many of my old MM topic links from the old forum software I couldn't find the post and post numbers didn't auto-translate). Of course, I could always go diving in the source. Where it likely uses standard library calls. But I think I have a solution.... Keep spaces out of scripts except for indentation, values, and comments. And where the '|' is above, only ',' is allowed, AND. So try this (may work). @PART[*]:HAS[@PLUME[Kerolox-Lower|Kerolox-Lower-F1]]:FINAL { // changes go here } And if that doesn't work, and the only possibilities of PLUME names that start with "Kerolox-Lower" are those 2 and only those 2, try this. @PART[*]:HAS[@PLUME[Kerolox-Lower*]]:FINAL { // changes go here }

That's complex and not likely soon. Will be much less fateful than the shift between Unity 4 to 5, but will have be deliberately and carefully done by Squad. Before then, many of the issues are KSP's to fix, and even those it's can't, the quality of the workarounds can be improved. KSP 1.1.2 is coming in a few hours. Hope for the best from it.