DStaal

I'd start with CTT - Community Tech Tree - and work out from there. MOLE is interesting and fun for some early-career stuff, and for mid-late game I'd pull in MKS. Also consider if you want a life support mod; USI-LS will give you plenty to think about and work with for tens or hundreds of hours. MOLE adds some science, but more importantly it adds some intermediate parts between the 1.25 and 2.5 parts, allowing your career to grow a bit more smoothly. MKS adds in quite a few parts for base and station building, as well as adding some new mechanics, which you'll start to get into near the end of the tech tree - giving you something you can have as a goal once you complete the tree. Adding in Extraplanetary Launchpads will give you some better goals and paths than 'build everything at Kerbin and launch it out', especially combined with MKS the idea of launching a starter settlement and using that to bootstrap to a full colony is easily a full end-game in itself.

Getting a chance to actually use these in the field: Anyone else wishing the Akita seat weighed just a bit more? A simple four-wheel rover fits a KIS container perfectly, but if you put a MK-V module in it, the rover will do a backflip (on Mun, and the very least) - even if it's only using front-wheel drive. (Yes, I back-ported. I don't believe it's relevant to this issue...)

Which works really well until you do something that knocks your Kerbal out while imparting ~100dv... Try pulling up the winch controller and using it directly. Or use your Kerbal's RCS - I typically just use the line to keep from drifting when doing dangerous work.

That is a question. I hadn't actually seen the issue this time - I just have a good text editor that can find these easily. There's probably some interaction between OS, Unity, and specific Unicode characters. (Assuming this fix actually solves the issue here.)

Not Backticks. Curly quote. ’ or ‘ vs `. Opt-']' and shift-opt-']' on Mac, I'm not sure what on Windows. Or, more commonly put in automatically by your text editor as 'curly quotes' when you type the normal vertical tick apostrophe. This has been a recurring issue with the SEP mod - what happens is that KSP will concatenate all science defs into one file which it reads - and if there is an issue reading it, it'll abort loading right there, leaving out all further definitions from it's superfile. I'm not sure what all can cause it, but sticking to ASCII seems to keep things in order. (A backtick is ASCII, curly quotes aren't.)

The Karibou has always been tricky to enter from the front, but I'm not having any more issues than usual with the latest update. (EasyBoard makes the process much simpler - my normal process these days is to toggle boarding with EasyBoard and jump in.)

Since I apparently have a better set of tools for this than most: I just downloaded the latest version off of Spacedock, and checked for non-ASCII characters. I found 18 - all curly apostrophes. Lines: 79, 190, 290, 295, 330, 403, 403 (yes, twice), 406, 413, 416, 419, 425, 426, 461, 461 (again, twice), 505, 528, 528 (twice).

Hmm. I'd actually done a complete copy over from the dev link you gave me, so it should be up to date. Though looking at my disk, I do note that as a *copy* it left the old versions of the model in place. The config does reference the new one however, and the ship was new, so I would have thought it would take the new model. I'll admit I didn't think of the possibility that they charged to *nearly* full - I noticed on the first I used that it wasn’t charging to full, and made sure to activate immediately on all the rest. But I hadn't run down the first pod that far, so I wouldn't have noticed if it changed to 95%, as I probably wasn't much below that. I will note that I had much less trouble with the mk1N than I'd had in previous tests. Earlier versions tended to wobble even under SAS, while these had no such issues. If you changed something on that, good work. (If you didn't, it may be because in previous tests I had DERP fuel cells radially attached, which could have thrown the balance off.) Oh, and feel free to use the images if you want.

Ok, longer breakdown. With pics. This was moderately eventful - though not through any fault of this mod. We'll start with the initial launch of the testing craft: Designed to test the monoprop fuel cell in action during both atmospheric and non-atmospheric landings: You can see the two carriers arranged for separation and deployment. (And eventual de-orbiting of the test carriers.) As an indication of how smoothly this round of testing went, soon after the above picture was taken it was realized that no antennas had been installed on the above craft - leaving the expected mission profile impossible to preform. A secondary rocket was quickly sent up with the smallest, cheapest antennas we could find. Here it is immediately after separation of the two test racks: And here we have the results of the first set of tests: You may notice that while the fuel cell (and custom monoprop tank) are present, the escape pod has self-destructed. This is believed to have been an issue with the monoprop tank - a redesign (to copy the fuel cell instead of the parachute...) has appeared to solve the issue. As the above only affected the non-atmospheric tests, the atmospheric tests were run: Tests fully successful - the escape pod had power all the way until landing, and the parachute was deployed by remote control instead of relying on the internal triggers. The Fuel Cell did approach thermal destruction on reentry (I believe it went over 80% of the heat threshold), but survived. Even if it had been destroyed, it is anticipated that landing could have occurred via battery storage from that point.[See note below.] As a side note: this was the first water landing using the REKT pods in our program. Rumors had been heard that they did not float - this has been confirmed. Immediate recovery is recommended. The above test was preformed with an apoptosis of 1,300km; the fuel cell survived multiple areobraking passes and supplied power throughout. (Note that the initial orbit was not circular - a deorbit from a circular initial orbit would have been beyond the dv capabilities of the mk1A, from prior testing.) This brings us to our third try at testing on Minmus: Finally, no external issues came up, and the initial landing was attempted from high orbit: ~530,000km. This was managed with ease: (You may note revised monoprop storage at the bottom of the pod, holding 10 monoprop. It was locked for this initial test, and never used.) As the 'extreme' test succeeded without incident, a suggestion was tried, concerning landing more than one pod at once: The test craft was deorbited with the pods still attached, and the pods jettisoned near landing. This was only partly successful. While both pods fired their landing rockets, only the pod being focused on successfully landed. It is currently unknown whether this is because it was the focused pod, or if the pod in the background had some excess horizontal velocity that resulted in a crash. (The Landertron system already having been shown to not handle horizontal velocity.) Final notes: The monoprop fuel cell appears to solve most of our deployment power issues. It is currently recommended that they are attached whenever possible - the only likely exception being stations in near-high Kerbin orbit, which are expected to benefit more from the combination of parachute and our current monoprop tank. Our custom monoprop tank obviously needs more testing. The fuel cells do not *charge* the batteries of the escape pod, they only maintain the current level of charge. It is therefore recommended to *always* start the fuel cell *immediately* upon releasing from the parent craft - this preserves as much EC as possible should the fuel cell fail at some future point. There were notes from the manufacturer on support for the IndicatorLights system being integrated. While there were some blinkenlights on the fuel cell, no other lights were noted, and the blinkenlights did not appear to have meaning. It is likely that our old IndicatorLights software was incompatible with the manufacturer's support; unfortunately hardware issues prevent us from upgrading. Another test run at some point in the future for the multiple-landing approach should be interesting, though it is likely to be put off until our current Minmus orbital station reaches end-of-life. In short: It works.

Actually, KAS winches can extend a line that's attached to a Kerbal, without any hooks at the end. And yes you can still control the Kerbal. Probably the best safety line at the moment. I've used it as such on a couple of occasions when I was doing complicated work likely to get me lost.

I haven't gotten to actually trying out yet, but I've got ships on the way that are intended to be attached using KAS and the new Konstruction parts. (I'm currently playing with a personal patch that adds KAS lifting capability to those parts - I submitted it as a PR as well, and RoverDude has integrated it, so I'm expecting that to be in the next release.) Even without the lifting helpers, the Konstruction parts are designed to move these around.

@Carrot, try the Mountain Goats. I've had no problem with them. Also, I've noticed that a lot of wheels in 1.1.3 get blocked at the top of their suspension travel - if they aren't overloaded, leaving the scene (or reloading KSP on occasion) and coming back usually fixes that.

I'll probably have a more detailed review of the fuel cells up later today (I took pictures and everything!), but I had a couple of issues that I want to make sure are issues with my install, not with your parts, which prevented about half my tests. From the rest: It looks good. I find it a bit odd that it doesn't actually *charge* the batteries - it just maintains their current level of charge. But that's just an oddity to keep in mind, it even makes some sense. My only other comment is a bit of a general comment on mod-making, from what I've seen overall: I believe it's best practice to put an abbreviation (or something) of your mod name into the part names in your part files. Part names are globals, and this prevents collisions. (And makes it easier to figure out what part is acting up if something starts spamming the log or gets deleted at game load.) Not a big deal, and most of your parts are fairly uniquely named anyway, but it's something to think about going forward. (Especially since changing the part names is a breaking change.)

Could we get a pic? IIRC, the ducted fans only work at lower elevations an Duna, as the atmosphere is so thin that even surface-level pressure isn't enough in some places.

If you don't mind waiting until Monday when I have some time, sure. Also note that I am playing 1.1.3 as 1.2 onward doesn't run on my machine. (I have some scripts for downgrading parts if needed.)

There's been some talk of additional resources, but you have to answer the question: Why? What's it's use? Because a couple dozen parts for a resource that basically duplicates a resource you already have just clutters things up.

Monoprop Fuelcell, yesss...

I asked about the KerbalLab a while back and didn't get an answer. I got the feeling station parts aren't high priority.

One thought - from my understanding from reading the current USI threads, you can trade mass for EC usage in at least some cases. Might be worth a look at balancing that way. (And for the full MKS integration project you'd probably want to have something with ColonySupplies and a med center - which can reset habitation.)

Just as a question: What's the compare/contrast between this and ESLD beacons? (Just wondering how to chose between the two - should I ever be able to.)

Besides, the current setup allows many mods to have what are essentially combined files: A part (or other) config file, with MM patches after the main config, or even mixed in. Making MM use a different extension would be a major breaking change for *lots* of mods.

Though I can't be much direct help, I offer what help I can give. If nothing else, I still have the GitHub and GitLab repos with configs for storage, EL, and a height adapter available, which I can add control of. (Or you can fork, of course.) Some of those configs would need to be modified slightly I know - storage currently adds Planetary storage to the large storage containers, when MKS has moved it to a logistics center, for instance. It'll probably need to get moved to the Central Hub.

Stalled. USI is in a bit of a flux so we don't want to do to much until it settles down. (And I can't help anymore, as my computer that can't run the latest version of KSP, and therefore can't run the new MKS.) There is no particular conflict between MKS and KPBS however. It just doesn't provide many of the base-supporting and resource conversion paths that MKS introduces. KPBS does support USI-LS, and for a basic science or habitation base you will have no issues. What you won't be able to do is build a medical or industrial base with KPBS parts.

Nope. OPM only adds planets, it doesn't touch stock I believe.

Probably the best example is KIS itself: The container and the container mount. The containers will snap into the mounts, and you can remove/attach them to the mounts with any Kerbal, without a tool.