PolecatEZ

That changes entirely if you also have Near Future Electric installed, the RoverDude reactors suddenly get their full stats and outputs that make sense...it will also screw the colony-based systems as their default fuel only lasts a few days. When I installed it I was happy to see the reactors from the other packs had thermal stats and all, but then I had to emergency drop new reactors to all my bases and tweak the temp/EC output loads.

Using SpaceY Expanded, designed and successfully landed an SSTO that can put 2025t into orbit. Cost of fuel is around 1.2 million credits. Design is pushed by 7 Emu engines and 8 Super Ratites, has 64 stock air brakes to slow it down and 144 chutes of various sizes for an un-powered landing (hits at about 14m/s and nothing breaks). Here she is on the launchpad:

Which version are you using? I'm getting massive stutter on landings and they've been anywhere from dead perfect to 2-3km off, coming out of a 60km circular orbit of Mun or Minmus. I came here looking for solutions to the lagfest being caused by MJ, which goes away if I remove it (but so does most of the fun in my game). I had a theory that Squad moved the surfaces of the planets around by a few meters, causing errors, as spaceplane guidance landings kill you now, so are there fixes somewhere or is the .685 dev version not the one we should be using?

You should be able to just go in the config and delete the module for the textureswitching, then reload the game. That may also just cause flickering on its own though...only one way to find out.

I completely removed CC and the .dll from the tools area. I was able to build craft using the new system without any issues. The native parts (the workshop truck and SkyCrane) were probably missing some resources but the models don't jive regardless and I'm thinking of killing those as well. That workshop truck with its free battery/generator and being the only thing with 100% efficiency doesn't seem balanced at all, but I understand this is the initial merger.

Is anything for MKS dependent on the new "configurable containers"? Its trashed every design I pulled up in the VAB or SPH by completely screwing with and re-configuring every fuel tank on the craft...sometimes to very odd combinations. ---- And if I take it out, all other fuel configs on parts no longer work and they're stuck at whatever that thing did to my ship. Ugh. Need to track down the MM file also looks like. --- Killed it with fire...everything back to normal. Deleted "Configurable Containers" folder and the .dll from the AT_Utils. My parts all have screwy fuel levels now (the ones I saved), but its just a matter of filling them with the slider. SpaceCrane part seems busted without it...I'll live. Question remains though, will anything good be dependent on this?

Nope, just happened to me last night. I have a Minmus base with plenty of hab time and supplies and about 20 Kerbals there, but its a complete lag fest. I think its a mixture of using MKS and K&K base parts, and especially the "transparent pods" feature (which can lag you even if turned off). I don't have any mods that mess with Kerbals other than the contract configurator for tourism (maybe?). So I decide to scrap the base by bringing back kerbals on a space available basis from other missions that pass by...once empty I'll try again without the craziness. I land and suddenly one of them is freaking out and made himself into a tourist...ok, he gets on the ship first, and I load up 3 other random ones. Those 3 were fine when I put them on board. After reaching low Minmus orbit, all 4 had become tourists...and stayed tourists all the way home...and are still tourists. Not the most useful report because I can't pinpoint the exact moment I noticed they were all 4 tourists, but I can say that I just started playing again 2 weeks ago and never used USI or MKS before that. 3 of us in the last few hours or so...just thinking the only thing I updated was Wild Blue Tools recently. Probably a coincidence, as I have no idea how that would give my kerbals bad touches, but its all I got for now.

You can double them up by flipping them so they're back to back and flush, and then use control group keys to raise and lower them. Haven't had an issue yet.

That's a case where you bring the mountain to Mohammed instead. Karibou!

By most "main parts" I meant basically the Hab modules, science module, greenhouse, and the cockpit control modules. The idea in MKS with the power couplers were so you could (in theory) have several independently sitting base sections without the need to connect them up physically and everything will still work together. The module you may be thinking of is the "power distributor" module, which is either the 2000m microwave antenna or the 500m integral ones in the power modules. This I don't know where you would logically put in the K+K parts except maybe the fuel cell doing double-duty as a distribution point as you said. That base central command piece already has sooo much going on - its really OP - and if you did put the distributor there then your power structure would need to necessarily be your central structure.

More notes on making it MKS compatible... These modules should be added to most of the main structures - this works beautifully and I've been testing this in my own game. These modules allow them to get power from energy distributors and tether themselves to the ground without need for KIS pylons: MODULE { name = USI_InertialDampener } MODULE { name = ModulePowerCoupler } MODULE { name = MKSModule } For command modules, these are helpful for constructing 100% K+K bases - you just really need one part with these per independent structure on the planet: MODULE { name = ModuleResourceDistributor } MODULE { name = ModulePlanetaryLogistics } MODULE { name = ModuleColonyRewards } These could probably be rolled up into a MM patch, but I just added these to the appropriate K+K parts directly and have been using it no problem. I think with the balance tweaks @tsaven mentioned above, it should be enough to get basic bases up and running with just K+K parts. If we could get an inline nuke plant or RTG (with some kind of radiators - water cooling maybe?) then we'd really be set.

I ran into a small issue that I had to edit, basically: The Carbon Dioxide wedge is found extremely deep in the tech tree away from the other life support wedges needed for TAC. This makes it essentially useless to use any of the entire system early in the game with TAC, as you'd need to use their basic models anyways to get the CO2 storage. Once I fixed that with a quick edit, it was basically so long and good-bye to ugly hex cans

That's just it, that license selection guide was basically written as an emergency response to the very nascent modding community at the time. Off-the-shelf solutions for licensing - many parts of which have no bearing on the game and lacking parts that fail to address KSP specific aspects. Besides, the legalese in the license is only as good as someone is willing to ever practically enforce it. They would need re-written in plain language - - Levels or Classes of License (KISS, 3 or 4 max "types" of license, ranging between "Full Open, Go Nuts" to "It dies with me!") - No license would grant any rights to any content outside the context of KSP. That would need to be handled by explicit separate agreement. - Be very clear (in KSP terms) what aspects the license covers. - Exactly what the internal enforcement would be and how, official forums, Curse, Github, etc. - Each level would have specifics covering abandonment, forking code, etc. - Each would have rights and responsibilities of both users and creators attached. - Each could be easily referenced in plain language, and users would be aware at a glance the type of support they can expect in respect to the longevity of the mod and impact on his game. This can include short disclosures at the top of the readme.txt "Class D license, continuing support of this mod is the sole right of the original creator and the mod may become obsolete at any time." - Portions of a mod package can be designated as having different license types.

That's first and foremost about the only thing you can do. There's a lot that comes down to personal philosophy, and that will never be resolved. I know what's "right" to me, but others have the absolute right as well to take a more Randian approach to life. Personally I see creating mods the same as taking up a leadership position, by doing so you take some responsibility as a public servant - including not plunging your little private empire into chaos by getting bored or liquided at a couple of rude constituents. If you can't or won't continue your duties (that go beyond "I just made some models and code), you should at least leave some machinery in place to soften the blow of you leaving...including successors, permissive licenses, whatever. There are no hard rules for it, and shouldn't be, its just what good leadership does. But again, that's a personal choice. People will be people, and some will choose to go Galt. As for permissive license while you are actively working on a project, that's a different story. And there is enough precedent for the branching disasters of a few mods to make the case that open licenses aren't the best in every situation, but they should be a parting solution for any mod author that just wants to walk away. Finally though...part mods. I've seen a lot of part mods that die for the simple love of a bracket or extra stat line in the parts.cfg. This is absurd, as most people with a modicum of notepad knowledge simply fix it on their own computers - so no real reason to restrict it from getting an updated .cfg. One solution I can think is to make a more open "catalog" site for distribution. Parts wouldn't come in packs, but be individual. Mod creators would upload their models and configs, and the configs would automatically be updated with bare minimum necessary changes to go with KSP versions. All other aspects of their licensing choices would remain the same, just a KSP version update won't abruptly kill their mod. .dll dependent parts would also have the .dll as another piece in the catalog and this would be noted.

Its why any responsible mod creator would put an open license on their work. I certainly did, and am quite happy with the mods that continued every time I took a long vacation. Someone mentioned bac9...which last I saw had an open license that I was more than happy to use as well to take his work in entirely new directions. Its an awesome thing to log in a year later and find bits and pieces of your work still living in iterations of your own and other projects, picked up by fresh blood you've never heard of before. The issue comes from some modders that are simply "my toys, I'm mad, I'm taking them and going home" when, because of the quality of their work, they had basically monopolized a particular concept for so long. In many cases, it is a function of pure childish ego when a far better solution would be "I need a break, here's the open license, go nuts." Absolutely nobody is saying that their freely given time and efforts forever chain them to continuing. Many great mods can continue to live with simple tweaks for version updates, but their creators chose to embed a timed kill switch on their work via licensing, and that is a shame.

Doing it wrong. Splash-downs don't count. Gotta smack kirba firma.

Alt-F11 is used by ModuleManager to reload the database when its installed. I think that's been a feature since 2.0.0+ When I had it installed it worked just fine. I'll try a different keyboard tonight, currently using a Razer Deathstalker. -------Update------------- I downloaded a Keyboard testing application and found out that my F12 key is dead as a door nail. The rest of my keyboard is just fine, every key except F12. I tried a few tricks to get it working again, but its not even registering through bios. Off to Wally World for my once a year visit...ugh.

I erased the entire game from my HDD and completely re-installed KSP...fresh build with no mods, still missing. I'm wondering if anything I have running in the background might be competing, but nothing turns up on a google search. I've shut down my mail client, print client, Steam, and TS which are the only things running that I can think of. I haven't added anything new in this regard in months, so no explanation for the fact that it came back for a week and disappeared again. If they could add the ability to re-map Alt-F12 menu to the bug list, that would be awesome.

I'm using the last one packaged with B9. I just re-stripped my KSP install completely and had Steam rebuild it. Zero mods - still no Alt-F12. I'm going to try a more radical re-installation than just wiping the gamedata folder and see what happens. If they'd just let you re-map that single function to another key or set of keys, it would be awesome...but no, it has to be complicated.

My alt-F12 menu has gone missing again and has been gone for about 3 weeks. I have a relatively short list of mods installed, but I've tried loading a base install and its still missing. It did magically come back for about a week early January but its been missing again for a while. I also can't seem to find any way to re-map it. Alt-F11 brings up some kind of file dump thingy, the other Alts also seem to work just fine. Yes, Alt-F4 works great! Alt-F12...nothing.

I got a lot of things remade (a few rotors, some cockpits), but then the case of the disappearing Alt-F12 function popped up again. If anyone has a cure for this, let me know. All other Alt+F# work except Alt-F12, completely locking me out of any kind of testing or reloading function. This brings mod development to a stand still. If seen a few other threads with that issue pop up, but they get closed without an actual resolution.

If you delete out the nodeswitch module from the part config, does it still break? I thought it was a compatibility issue with the weaponry mod, but I'll test it out in a bit.

I deleted the spaces and the parts show up fine, but the framerate drop is still there. The textures or models don't seem overly large, and nothing is throwing an error like I said before. I'm thinking the aiming module might be the culprit, as it needs to do a constant velocity/angle/gravity ballistics calculation to remain as extremely accurate as it is, and somehow it might always be "on" in the background, even without the weapons manager turned on or present or the bombs armed.

Anybody found a cure yet for the big frame-rate drop when equipping bombs in the VAB or having them in flight. No errors are getting thrown, but my framerate drops about 30-50 FPS, and it only happens with bombs. Missiles and guns seem just fine.

They randomly disappear or fail to load. I've had some luck reloading the assets - sometimes the game suddenly decides they're there. My theory is that it has something to do with how ATM loads textures, but really its complete voodoo to duplicate it, as about every 3rd load they magically re-appear even without adding or changing mods.