DStaal

KSP has always had issues with things not holding their place on the ground - it's floating-point errors in the code, and not something that can really be dealt with without a massive overhaul in how the game universe is modeled. (And would limit the universe quite severely in other ways.) Mostly: Don't try to tie things to the ground to tightly, or depend on millimetric precision on their placement. Assume your ground based bases will wiggle a bit when you load them.

Double-click to unzip. Drag into place. Done.

Most mods are entirely self-contained - and this wouldn't touch those mods. What's really being discussed is mods that have user-created files - settings files and the like. Typically they are also put into the mod's folder, but this has the unfortunate side-effect of making it harder to upgrade the mod. When you do, you have one of two choices: Carefully merge the new and old folders, making sure to delete all the files that have gone away in the new version of the mod (if there are some), and leaving the settings file(s) while replacing all the rest of the mod's files. Replace the whole folder with the new one, and lose your settings. The discussion is about having a different designated location for those settings files from mods. This makes upgrading and maintaining mods easier, as you won't lose your settings, and it makes discovering that a mod has settings easier for those mods that have text-file only settings. This won't affect load times, would only minimally affect CKAN, and wouldn't affect Curse or SpaceDock at all - you'd download the same zip file, and it's only slightly different on the first install. (Where you might have to put the settings files in place.) ----- The above makes me think about one advantage of the GameData/PluginData/modname strategy over the PluginData/modname strategy: It's a simpler transition. For the normal 'merge contents of zip file into GameData' install process it's about the same, as the 'install root' hasn't changed. (Of course, a bad merge tool is more of an issue - older versions of MacOS had trouble merging to depth, which would mean that all other settings could get wiped out on a merge, for instance. But I believe this is fixed in the last couple of versions of the OS, and I'm not aware of any other merge tools that have the issue.) I'll admit I'm not a huge fan of that either, as it just means another level of merging when trying to install - but I don't actively find it harmful, and there's only a few mod authors that use it. (And they typically have very complicated structures, so it's useful for them.)

One nice thing about KSP - installing mods is exactly the same on Mac as it is on Windows or Linux. Put the collision fx's mod folder in GameData as described above.

And backing things up a bit - here's my logs: http://magehandbook.com/owncloud/index.php/s/N3OnwBxUeMrsqZz http://magehandbook.com/owncloud/index.php/s/8FLUk0dBGKiNVdL And the craft file: http://magehandbook.com/owncloud/index.php/s/fC8pZej7E1P4jI4 I run a long list of mods - the craft file I know uses SSPXe, Near Future Spacecraft, Better Science Labs, Pathfinder, Surface Lights, Koose, and at least one other for the boosters. However, the part that was noticeably rubbery was a stock radial decoupler. (A TT-70.)

For reference, the discussion had been focusing on where the 'PluginData' folder should be located. Options mentioned: KSP/GameData/modname/PluginData (currently common) KSP/GameData/PluginData/modname KSP/PluginData/modname ---------------------------- My personal opinion is that the currently common use is fairly stupid: It makes it hard to seamlessly update mods, as you can't just replace the GameData/modname folder with the new one - you lose your settings. Either of the other two options separate the settings from the mod code itself, allowing you to replace the mod easier. @Lisias is pushing for the last option, as it means that KSP/GameData should never need to be written to during a KSP run. (So therefore making it easier to spot/contain mods that are malicious, if such exist.)

I understand that. I don't use CKAN myself - because it flat out refused to work on my computer when I started playing KSP. (I was on an older computer and an older OS, and while KSP ran fine on it, CKAN didn't.) I haven't tried CKAN recently. And I agree on the point of a standard - but on the other hand, having a bad standard shouldn't prevent people from trying to push for better, and saying 'it's standard!' shouldn't be the reason to stick with a stupid design - and the current 'standard' is stupid. (And honestly - LinuxGuruGamer has the position to push through a good change here, if he wants to make life better for people. If he changed his mods to use either of the other two folder structures under discussion, that would basically be the new standard and would make life easier for lots of people.)

Yep, up to the point where the totals are the same reduction as if you'd just had the better ones. Part of the idea is that be water recyclers are supposed to be big and bulky - and you only need one per base. This lets you fill in using smaller ones. (And as you said, allows for more interesting and flexible designs.)

Honestly, I know I *could* update most of my mods without deleting that folder - but that's to fiddly and to much work. I have to work out which mods use this layout, which I have settings that I need to keep, selectively delete, then overwrite... vs. drop in and replace. (And then reset settings if they bug me.) And I disagree - there is consensus, on the 'GameData/modulename/PluginData' format. I can't think of another mod that doesn't use that format. It's a *bad* consensus, and the wrong layout by any objective measure (it's only redeeming value is it's ease of initial install), but it is the consensus.

I *hate* that layout. It means I lose my setting every time I update a mod. To add to the above: If it has to be in 'GameData', far better would be 'GameData/PluginData/modname'. 'GameData/modname/PluginData' doesn't work well. It's just the standard and KSP players are used to it. It's horrible, but it's what everyone uses.

On one hand you want a license that makes it easy to continue a mod when the mod author leaves, gets busy, etc. On the other hand, there's a disservice to the community to having multiple slightly-differing branches of commonly-used mods in circulation. (We do have a couple of mods where that's the case - and I know at least one other mod author who says they don't bother to troubleshoot mod interactions with those mod sets, because it depends on which fork you're using, and which build of that fork.) But that's easy to solve: any Open Source advocate will understand that you want to *contribute to the upstream where possible*. You only split where necessary, whether due to differing visions or due to other issues. Most mod authors here are welcoming to improvements to their code, so there's rarely a reason to fork unless the author leaves the community. It's *polite* to ask the mod author (if they can be contacted) if they've left or if they are just temporarily busy - and it saves both you and them work when they do come back and you want to re-merge the forks.

I'm on the other end of the spectrum - while I have a few mods I consider essential, I tend to throw in everything that looks good. My current count is somewhere around 200 mods. Load times for me are much faster than they used to be - in the order of 10-15 minutes I think, but could be shorter. On my old computer I used to start KSP, then go leave to cook and eat, and come back in time for it to finish loading - load times were over half an hour or more. I still tend to start KSP and walk away and do something else, but now I don't plan an hour in advance.

The recycler stacking is somewhat complicated. It works like this: Each recycler reduces the amount of supplies used by it's own ratio for the amount of Kerbals it's rated for, up to the max ratio of the ship. The max ratio is set by the highest ratio recycler on the ship. So if you have one 80% recycler good for one Kerbal on a 6-Kerbal ship, the max ratio for that ship is 80% - but you're not reducing the supplies by 80% yet. As you add more lower-ratio recyclers, the less supplies you will use - up until you get to reducing the entire ship's supply usage by 80%. Even if you only have the one 80% recycler and everything else is 40% recyclers - but you'll need a lot of the latter. My suspicion is that your SSPXr ship has one very efficient recycler, and you're adding less efficient recyclers and not hitting the max for that ship yet.

Possible - but I use MacOS as well. I'll get you those logs as soon as I get a chance.

I don't have time to fire KSP up again tonight (why I didn't have them attached already...). I'll get them tomorrow. I do have the config.xml file in the right place and KSPe installed.

@Lisias - Your most recent build didn't work for me. I went to launch a ship and the side boosters looked like they were mounted on springs instead of decouplers - even after I added some struts on. I reverted back to @wolderado's version, and the ship was fine.

With the stock CommNet, they appear to work fine. One's a relay, the other's direct-only. (Though I haven't deployed one into flight mode in 1.5 yet.)

Neither. They are separate mods, and will work independently. (Though odd things happen when you try to mix-and-match on the same ship.)

I know I've tried to push for something similar a couple of times, but since I didn't have a mod which needed settings it was hard to push...

It's not UTF8, at least by the time I get to it. I get warnings when I try to open it in that encoding, and I get missing characters. (The missing characters could be a font issue.) That's why I asked. I tried ISO-Latin-1, Windows-Latin-1, Mac OS Roman, DOS Russian, Windows-Latin-2, and a few others. I wonder what's mangling it.

Out of curiosity - what editor are you using for the readme.txt file? (It's in some oddball text format that I can't identify - I can read the English text just fine, but the Russian text never looks right.)

For nuclear pulse propulsion, there are two mods - I'm not sure how well either work with 1.5 though:

I don't know any utilities for this either - but it's also worth checking out the Buffalo, which recently added some buoyancy controlling and underwater engine parts. But no, no readouts that I know of. (Might be worth mentioning to the Kerbal Engineer maintainer - it could be something they might be interested in, if you ask.)

There are a couple of mods with parts you can walk inside of - mostly mods for building planetary bases, though I know Omicron is a bit like that as well. (And I haven't seen any that are updated for 1.5, though some are pure parts mods so should be fine.) Are you just looking at doing a set of parts, or are you looking to overhaul the entire game? If it's a set of parts: The more the merrier, I haven't seen many pods and such like this and as long as your part is different from what's offered I'd say go for it. If you're going for the full overhaul - godspeed and good luck. It'd be an interesting project, but a large one.

And a bit of testing, and I found my issue. The fix is to add the second line here: KEI_EXCLUDED_MANUFACTURERS { manufacturer = Station Science Directorate manufacturer = Wild Blue Industries } I'll put in PR. Edit: PR created.