DStaal

With the caveat that EVA Resource Transfer requires a part be attached to each ship - usually at build time - to work. (A lot like a KAS pipe, without KIS.) So, not likely to be helpful at the moment, although it might be worth looking at to be able to handle these types of issues in the future.

Yes and no - They don't conflict, and your bases/ships built with mod will still work and look like they fit in. However, the parts used to build them will be hidden from further use, and they won't integrate into the other mod in any way. So, basically: It's designed not to hurt if you upgrade. You won't lose anything you've built, and you won't have useless resources someplace. But from then on everything gets the new parts. (And your bases built with this mod will be a bit OP in relation.)

And I'm working on one in Perl. (Though mine has a few other uses as well - trying to find common mod install errors.) Though I'll admit I hadn't quite got to the 'read the .version files and do something' step yet. Mine's here if it helps, or if we can consolidate a bit... (I haven't worked in Python, but I'm not to against it. Though I get shivers at the idea of semantic whitespace.)

You don't even need that much finesse actually - as long as they are somewhere inside GameData (including subfolders) you're good. I dump them in their own folder, just so I can keep track of them.

I like the idea. One comment: Could the 'Overwrite' parameter be limited to a central config file? I really don't see that as something mods should be playing with - it should be the player's choice.

I don't believe the current version of UKS hides EL parts - but if you have a version or two old, or if you have files from back then hanging around, you might still have the config file that hides them.

Not written up in a config file yet, but I was just working on consolidating the info in GitHub. That particular info was on a wiki page that @ibanix created: https://github.com/ibanix/UKS-KPBS_Compatibility/wiki/USI-LS-Compatibility-(Proposed) I've also created a GitHub issue to make it easier to find: https://github.com/DanStaal/DStaal_UKS_KPBS_Addons/issues/1 I'll be putting together issues for the rest of what we discussed in a moment, as I can dig it out of the thread. Feel free to click 'accept' on the invite I sent you and to start on a config file for them. (Unless I need to do something else to get the invite to you?) ------ Going back through the thread, it looks like @ibanix already created a PR for the USI-LS changes against the main mod - so in the next release those should be out.

I have a patch that adds some workshops and survey stations: https://github.com/DanStaal/DStaal_UKS_KPBS_Addons/releases (Main thrust is UKS, but it's got EL as well, and the UKS stuff won't trigger without UKS.) Productivity factors range from 3 to 5 - but the workshops don't have much capacity to hold Kerbals. If you want a large production, you'll want to build a big base with lots of workshops. (Each Kerbal gets their own! And the high productivity ones are end units, so you'd have to carefully design your base if you want to expand...) (Well, mostly: The central hub gets a productivity factor of 3 - enough to be useful, and it's got a lot of seats.) Nils has said something about doing his own EL integration at some point. I'm not sure if that'll be linked to one of the parts we're talking about for a more full UKS integration or not.

On the mini wheels: They seem to have trouble with small rovers. They do better with large ones. I'm guessing your rover is only two-three sections long? Try them on something longer.

I highly recommend (even for .zip files) The Unarchiver.

No mod, just stock is all you need at this point, IIRC.

Just quoting because I'd like to know as well. I'm working on a program that is intended to overlap in functionality with AVC - just doing it outside KSP itself - and I'd like to make sure I know how to read the version files correctly.

I'll say right up front that a GUI isn't going to be anytime soon. If I had a working version of XCode (which I don't, and I'm not sure how to get to - I need an installer for my archaic version of the OS), I could throw one together for OS X in an hour or so, but anything beyond that will take a lot of work and/or money. I don't know any cross-platform GUI toolkits well enough at the moment, so I'll be focusing on features that have relevance to me. Full listing however is easy - as I said, the code looks at every file and decides whether it's 'interesting' already, so it's not hard to have more categories of 'interesting'. Maybe I'll just sort the ModuleManager list and make headers optional - if I do that, anyone moderately fluent in command line operations can write a line to remove duplicates themselves if they want it. ('| tail -n+2 | rm' should do it...) My impression is that while they aren't supposed to cause issues, occasionally having more than one has. The question on whether I can re-parent GameData folders correctly is a good one. In the easy case - where it's just a mod folder - no problem. I can even special-case if they have ModuleManager in there and keep the more recent. The problem becomes what happens when it's a more complex case - say someone has nested a UKS install, but they already have a CRP folder. Which do we keep? (I suppose we could check the more recent timestamp/version file... Hmm.) Neither of those would be the default mode: You'd have to give an option at runtime, and probably confirm once the program's worked out what would be done. (As a side note to the above plans: I basically work freelance. The plans above are 'what would be easy and useful to me in my spare time'. But if people decide they want me to go in another direction, I can do that - I could effectively spent all my time on this if I could afford it. Not likely to happen, but if people are interested I can set up a Paetron and go that route.)

Glad you like the concept. Command line isn't to hard - especially if all you need is to run one program like this. Getting Perl to run on Windows... That can be a bit trickier. (It's not hard, but Perl is designed for some very Unix concepts, so you basically have to work with a port of some kind. Strawberry Perl is the leader, I believe.) The easiest GUI would basically be a simple wrapper that has buttons for different options, runs the command-line in the background, and outputs to a window. I may get to one - once everything else gets done. Finding all unneeded files in GameData is fairly easy (I'm looking at all of them anyway) - if we can just agree on what 'unneeded' means. There are two possible approaches: Listing every type of file that we don't want, and listing every type of file that we do want. The former is more work, and likely to leave stuff out which would be harmless, in the end. (Other than some wasted disk space.) The later is easier, but any errors are far more dangerous - pointing out a needed file as unneeded could mean someone deletes/removes it, and then things go wonky. Similar concern on the folders in the main KSP data folder - I was thinking I need to look there for a couple of things anyway, long term. (KSP version...) There since we're talking about folders it's much more likely to use a list of 'good' items and flag everything else - but again that's the more dangerous option, as if something goes wrong it's more likely to cause problems for the user. Still, just listing them isn't a problem in and of itself. I'll put it at the top of my to-do list on the program. What's your thoughts on having the program have an option to do some automatic fixes? (Re-parent items in nested GameData folders, remove older versions of ModuleManager, stuff like that.) I'm trying to decide whether it's a good idea or not.

Just to clarify: We're not going to have to brave the gates of hell to get our parts, right?

Still haven't gotten into parsing and downloading .version files, but I have a couple of nifty features added today: First off, it can create a list of all top-level folders, including which have a .version file in them. Secondly, it can list all top-level directories with the last modified date of the most recently modified file in them - oldest to newest. (So the mods that have been updated recently are at the bottom, and the ones that haven't are at the top.) It's currently throwing an error I need to track down - though I have suspicions. It's harmless. And for those who want to see what it's capable of, here's some sample output (my current GameData, with all options turned on): The order things appear in the output is currently hard-coded - if anyone has suggestions on a better order I'll take them. (I'm also considering a flag to disable the headers.) I might also be able to make the order a command-line option.

Download the zip file linked in the first post. Unzip. Copy the contents of the 'GameData' folder in the zip archive into the 'GameData' folder in your KSP install.

I'd also take a look at Wild Blue Industry's mods: MOLE, Buffalo, Deep Space Exploration, Pathfinder. Pathfinder is really a competitor to RoverDude's UKS, but it can play nice with it if you turn off some of the settings. MOLE is really good in early exploration. (Launch a fuel tank, turn it into a science lab...) Orbital Tug can be very useful for in-system orbital work. SCANSat gives a feel that you're actually scanning, instead of just hitting a button. (And can make you prioritize: Do you want to scan everything, or do you want to find a landing point quickly?) StationScience enables a bit more long-term science, giving your Kerbals a reason to go places other than 'it's there'. WayPoint Manager will make your life easier. EasyVesselSwitch and EasyBoard are also mods that will save you more time and aggravation than you'd really think they should. And if you want to have interesting names for your ships, take a look at Champagne.

This is really early alpha, but it's already found an issue for me, so I thought it might be useful to others... https://github.com/DanStaal/KerbalModuleCheck/tree/master The goal of this project is a stand-alone .version file update checker and basic install sanity checker - A program that you can run to find common errors in mod installs, and can help you keep things up to date without launching KSP. The intent is to piggyback on AVC's version files for updates, and to rely on the users for install and info. Currently I'm working in Perl, as it's my normal preferred language (and is cross-platform), and starting on the command line. I'm open to changing that in the future if it makes sense, but I'd have to have something that works for me. (That is: Under OS X 10.7.5. ) Inspiration is primarily from trying to keep track of what I need to do with the recent update to KSP, but I'll admit the recent kerfluffle about CKAN gave me a push to start writing as well. CKAN however is a slightly different beast: It aims to be a way to find and install mods. There is no intent for this program to ever be a way to acquire mods - though I may aim to help install them eventually, once the user has acquired them. Also, CKAN won't run on my machine, so it can't help me keep things up to date. Currently the only requirements are a basic install of perl, and a knowledge of how to use the command line. I'll probably be adding non-stock Perl modules shortly, but then I'll probably actually package it correctly and even write some docs as well. At the moment, you'll need some basic understanding of code to figure out the options (I suggest running with '--errors'). However basic operation is: Download, feed the script to whatever version of perl you have available, and feed the script the path to your GameData folder. It'll spit stuff out to STDOUT. (So: 'perl module_check.pl /path/to/GameData') Current features: Find nested GameData folders Find ModuleManager installs (will flag multiple installs) List all .version files List all top-level GameData folders that do not contain a .version file. (A quick-and-dirty version of 'all mods without a version file'.) 'Squad', 'PluginData', and any invisible (by UNIX convention) folders are skipped, and excepted from all the above checks. Planned features: .version file update checking Automatic downloads of outdated mods from Spacedock or Github, if the .version file points there. (I'm not sure I can do it from Curse, but if I can from there as well.) Wishlist features: Automatic install/upgrade of mod from downloaded zip file (with mod author support) GUI If people have ideas for other common errors in installs that I can check for, I'm open to listening - however I don't want to have lots and lots of checks for different mods' issues. Try to keep them to general issues that are common among lots of mods. (I'm open to special casing issues if the mod is important enough however - ModuleManager being the main case in point, as it's nearly essential for any modded install.) As it's a Perl script, I'm going with the Perl-standard Artistic License v2.

I'll admit I just assumed they had such a thing - though I guess you could fake one with a pull request. Anyway, I've added you, pending your acceptance.

Ideally your first point of contact should be the CKAN. Once you have confirmed it's not a CKAN install issue, (which it is in this case - so you shouldn't get past that) you should go to mod author. That's with the current setup. If CKAN gave install config control to the mod authors then the process should be to proceed directly to the mod author. That's part of the current problem - because CKAN doesn't give the mod authors any control over how their mods are installed, and can't consistently do it correctly, mod authors don't want to deal with support requests concerning mis-installs from CKAN. Unfortunately it's not clear to the users (and likely never will be) that if they use CKAN all issues should first be taken to CKAN, and only afterwards taken to the mod authors. The correct fix therefore is for CKAN to play nice with the mod authors, and help them to make sure that CKAN only installs mods correctly, by making sure that the mod authors (who are the ones doing the support by default) are the ones in control of the install process. I'm not exactly clear on why they didn't do that. It's polite, and generally the way it works in the OSS world, the only exceptions being full linux distros that have an official distro repository - where it is very clear that those packages are the distro's responsibility, and they have separate support forums that will deal with support. (Often the actual install process is slightly different on various distros as well, so they are the ones best in control of what needs to go where.)

Notably CPAN is completely voluntary on the programmer's part, and gives them complete control of their own metadata. I think it's one of the best and most successful distribution systems out there. Yes, your program can break because a dependency's been changed/broken - but that's not a problem that a distribution platform can solve on it's own. (And CPAN allows you to specify which versions of a dependency are required, so it mitigates as best it can.) (And actually - I've been a CPAN user and subscribed to their mailing list for a decade and a half now, and I can't think of the incident you're referring to. If you can, can you point me to a link? I remember an incident like that with Javascript - because the dev didn't like the behavior of the distribution platform's team - but I can't think of one on CPAN.)

I think Universal Storage has some. (Note: Their fuel cells run on H2 and LOX, not liquidfuel and oxidizer.)

The toggle's called UKS.

Interesting. As for your power issues: Try fuel cells, they may help.