Jacke

You're free to do whatever you wish on your computer. But as someone with decades of experience working with computers, I know things should be done in a certain way because it tends to lead to less problems. When you have the ability to patch someone on compiling or loading once (like with Module Manager and KSP), you do it that way because you're preserving the original and keeping your patch separate. Debian developers do this with every upstream Linux program when they package them. It's about the same amount of work the first time and a lot less work going forward. As well, if you're playing KSP from the Steam install (not a good idea, you should copy it twice, once as a version backup and a second time to mod), your changes in the stock files can get overwritten without you knowing. If with a mod like FASA, keeping your patches separate means you can install a new version of the mod and just have to check if your MM script needs updating. If you writing your patches into the base game or the base mod, you have to keep a record of them as well as patch each new version. I've patched KSP and many a mod, all by MM files. For several KSP versions. If you want to make more work for yourself, feel free to do so.

You shouldn't modify files that you don't produce. Create a Module Manager config to change the nodes when they are loaded into KSP. It's no more work and keeps the changes separate.

The official link goes to the Kerbaltek Hyperedit page. Look at the whole page. Download the latest complete version and the replacement Beta 2 .dll at the bottom of the page.

You know, that's from the written version. The film's version obviously has greater ratios, maybe 1:8:27 ? Maybe greater?

Do you mean Canada? I'm in Calgary and have no issues. I just downloaded it again from Spacedock. Be very careful if you can't access Spacedock. I suggest clearing your browser cache and looking for other issues. Try downloading other mods hosted on Spacedock.

EVE comes as two .zip archives on its download page. EVE itself is "AnyCPU-EVE-Release.zip", which has "GameData/EnvironmentalVisualEnhancements/" containing the plugin .dll's and the .shader's. EVE's stock config is "AnyCPU-Configs-Release.zip", which has "GameData/BoulderCo/" containing all the config files. It's done that way as other VFX mods, like RVE and SVE, use EVE's plugins and shaders but provide their own configs. Neither of EVE's two release .zip archives as I described above contain other .zips. That's likely EVE source code .zip archives. I think I know what happened. 1. Go to the first post. Briefly read it over it again. 2. Near the bottom of that first post, you will find a links in bold labled DOWNLOAD. I quote it here. 3. Follow that link to the Github EVE page for releases tagged "EVE-1.1-2". 4. This is one you're not familiar with. The .zip's are named as source code. You want a release .zip. And somehow they're not tagged. So.... 5. Look to the upper left on the Github page and see a box "[ Release | Tags ]" with "Tags" hi-lighted. Click on "Release" to go to the complete Release page. 6. The Release page has all the releases from the most recent at the top. You will see the versions have both source code and release .zip archives. Pick whichever you want to try, 1.1-2 or the Prerelease of 1.1-3. 7. For that version, download "AnyCPU-EVE-Release.zip" and "AnyCPU-Configs-Release.zip". Those are the two .zip archives you want.

I've downloaded FF 1.0.10-2467 earlier today and just now. Clicked on the Spacedock link in the first post and then "Download" on the Spacedock page. It was working at those 2 times.

I didn't completely understand what you said there. However, you shouldn't use this mod except on KSP 0.90, which is long past. It will not work correctly on later KSP versions.

Another way to do this. Click just after the last text you want to be before the break (the ')' above) and type "Enter" three times. DON'T start typing text yet, or you will encounter the IPS4 (the forum software) backwards typing bug. You should have 2 blank paragraphs between the now-broken quote. Your cursor will be on the 2nd blank paragraph. Click to move the cursor to the 1st blank paragraph and you should be able to enter your comment and do other editing without issue. For example, I deleted the rest of the quote that was below the above quoted text. I really, really hate IPS4. That it doesn't have a proper raw mode is just one of its ills.

They mean the mod-specific PluginData directories. Any subdirectory named "PluginData" under GameData (most commonly "GameData/<mod dir>/PluginData/" or "GameData/<mod dir>/Plugin/PluginData/" ) is not scanned by Squad and will only be accessed by a mod that deliberately paths to it, usually just the mod that includes it.

I have just updated a few mods one of them has got to have conflicted with it. I just reinstalled FAR fresh install and still get it, error says A clearer description with more details would help (screenshot, follow the troubleshooting steps here). At a minimum, what is in the directory "GameData/KSP-AVC/" ? Mine contains a bunch of files all with "KSP-AVC" in their names, as well as a "Textures" subdirctory.

I think the other solution to this issue, done by a few mods, is to have their config file not end with the ".cfg" tag. Some use the ".dat" tag.

The current version of Biomatic (1.1.0.1) also includes a Module Manager script to add its module to every part with a ModuleCommand module, ie. all manned and unmanned command pods. I previously used Science Alert's similar function to help get biome science. What I would do for small biomes I couldn't get otherwise is make a Quicksave, warp until I hit a biome with new science available and dropped out of warp, note the latitude and longitude on VOID's HUD's, then load the Quicksave and repeat the orbit, but exit warp before passing over the biome and run the experiment while in it.

Real rocket scientists only use terminal velocity when finding out what speed a falling object will approach. For rocket performance and ascent profiles (initial vertical climb, programmed turn, gravity turn, coast, orbital insertion), they model the whole thing and find out what the performance is for small changes. Real rocket engines usually don't have much throttle range so they can't use fancy throttle control like what is common in KSP. There's only changing the propellant load and changing the timing of the orbital insertion. Except for very high thrust rockets like some surface-to-air missiles, most real rockets don't accelerate fast enough to get to the point where reducing engine thrust will improve performance or avoid damage from overheating. Again KSP can be different, but terminal velocity isn't useful here, drag accel and Q are. I saw that in Mech Jeb's Ascent Guidance where using terminal velocity limits resulted in substandard performance. The previous use of terminal velocity in KSP as an efficient ascent guide was based on an analysis that only works for a rocket that ascended vertically. That sort of worked for some of the ascent in KSP before new aero, as rockets often had a large initial vertical climb. With new aero or using FAR, even with Kerbin's 10% size compared to Earth, rockets are best flown with the programmed turn starting around 100m and 100m/s, perhaps just a bit higher. They quickly get to close to flying horizontally, which completely breaks the usefulness of terminal velocity as a guide.

I looked at your KSP.log. I think your issues have nothing to do with Module Manager, so my comments are in a spoiler.

Bummer you're under the weather, @timmers_uk. Get well soon! Both mods are trying to affect the same thing, ambient lighting, probably through the same mechanism, but neither one was coded expecting the other to be fiddling things too. Testing them together will give you an idea if they play nice together. But I'd likely just install whichever one worked best for me in the current context (I can easily switch mods). I use Ambient Light Adjustment, but I can see the appeal of a mod that you can set to a threshold that will automatically lighten dark scenes just enough.

Hey, dude. You shouldn't say you're an idiot or the question was stupid. Critique the behaviour, not the person, even when self-critiquing. You're human. People miss things all the time especially when it's not real-life life and death. In all the furball of KSP knowledge we all have to keep current in our head, you forgot about one mod switchover. When quickly checking this mod and thinking perhaps you post asking about its future, you missed going back one post. It can happen. I really try to avoid making mistakes in my posts. But I still end up editting a lot of them them within 5 minutes of posting. Most often for a silly typo.

Chemtrails...is there nothing these Wonders of Science can't do!

I see from another topic that @Diazo is away from KSP for the next while, so I'd thought I'd reply. Look at the 2nd last post before yours. Diazo has ported this mods functions to another and this mod is no longer supported.

I agree on that one. Especially because.... Thinking this one over yet again, PROVIDES wouldn't be an improvement, because the FOR[NAME] block indicating the mod means the MM script is effectively part of mod NAME because it changes mod NAME. That can mean there's other files and stuff, like .cfg's or a .dll, Or not, and this MM script is all there is to mod NAME. PROVIDES would be more misleading in the first case, the more common case. FOR is about as best a single word to express both cases as exists in English.

Perhaps it would have been better if FOR was called PROVIDES. EDIT: Thinking this one over yet again, PROVIDES wouldn't be an improvement, because the FOR[NAME] block indicating the mod means the MM script is effectively part of mod NAME because it changes mod NAME. That can mean there's other files and stuff, like .cfg's or a .dll, Or not, and this MM script is all there is to mod NAME. PROVIDES would be more misleading in the first case, the more common case. FOR is about as best a single word to express both cases as exists in English.

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.