DStaal

Note that MKS is moving away from EL to Ground Construction - which can't build in orbit, only on a surface. Now, that doesn't mean you have to build it on *Kerbin* - I'm working on a shipyard on Minmus for building otherwise orbit-only craft - but it does have to be launched from *someplace*.

Nope, the workshop doesn't contain a survey station - and you need one to build from stakes. EL reconfigs the standard MPL to work as one, or there are some others around, depending on what other mods you might be using.

Yep, those three sizes. And PBSalike would be ideal - MKSalike would be second-best.

It was just other ships/stations - but the other ships could be using PL, so you could play with it.

Exactly. Logic (in MM) goes: Assign default texture to resource. If there is a specific texture for this resource, replace default texture with the resource-specific texture. So, if there's a default, then that will be used unless there's a more specific texture. These will be used like the textures on the classic rectangular Kontainers, which are switched as the contents get switched.

Yep, Kontainers in the KPBS form-factor is the plan. (And probably depreciate the current MaterialKits and SpecializedParts storage parts at that time.) I have some code up there already that does most of the hard work semi-automatically (if you put in a dummy module, it uses MM to create correctly sized/cost entries for all the different contents - or it will, once it's been tweaked a bit, currently it's missing a few and I've had trouble finding the right ratios for the liquid/gas Kontainers). Original goal was to try to talk RoverDude into using it - help him keep all his Kontainers correctly balanced, and help others who want to write interop patches. So what it needs are textures I can apply to one of the KPBS containers in each size as the repaint. Of course we could leave without, just dupe the current containers - but I think we can do better than that. @dboi88, I can make up a list once I get the my MM script tweaked (then I'll have it all in one place) - but one thing I've added over the USI Kontainers (and would be the place to start) is a *default* texture. My code will use the default texture for any and all resources that don't have a specific texture of their own - so if we could get that in the three tank sizes, then we've got a good start. I agree on LS - I've added a folder in the repository to work on LS patches. At the moment I think the correct approach is to override any LS patches already in the mod, assuming that's possible, so that we take over that support. However, do note that KPBS has some parts that are LS-specific, and support multiple LS systems. How to integrate them is a better question; they have models and designs already that I'm not planning on taking over - but we want them balanced against the rest of the integration.

That telescope looks like a cannon...

Yep, as far as I'm aware. If it had worked, you wouldn't have needed to leave the launch pad. Just to check, are the Kerbals on Kerbin? Otherwise: I believe it is possible with the right combination of parts. Not easy, but possible.

You may want to take a look at this mod, to help you out:

1: In the life-support window, which you can pull up by clicking on the green box in the toolbar. This will list your current supplies usage, how long it's expected to last, etc. as well as both habitation and home time. If they actually get homesick, you'll get a notice directly on the screen, saying they've refused to work. 2: Assuming they've been returned to Kerbin and haven't already, try launching them in a ship. (Any ship, just get them out of the astronought complex and onto the launchpad/runway.) Often that gives them the nudge to reset, and you can then reclaim the ship. If that doesn't work - and they went Tourist with an older version of the mod - go into your persistence file and edit their profession back to whatever it was; you got caught by a bug that's believed to have been fixed, but the fix wasn't retroactive. If they went tourist in the *current* version of the mod, make a copy of the save, attach it to a Github issue (I'd say a new one, not the one that's closed), and then edit your copy to get their professions back. But note that's only if you are *sure* they went tourist in this version of the mod. (If you happen to have the log of when they went tourist, RoverDude would probably like that to.)

I care, because I've already done it. (I meant to mention it here last night, but I was already the last post and I didn't want it auto-merged in...) This is more than just USI-LS, but it's probably the right spot for that discussion as well, and with a bit of care we can keep things separate in case Nils277 wants to grab parts of it.

No. That takes support in the being carried itself.

I'd go with 2; let MKS provide the instant demolish if people want it. Make 1 available via soft-dependency if you want. Ideally with a dedicated part - but you could do efficiency like you have for construction and have the possibility of a dedicated part (or just use the same workshop) later.

Note that for textures we'd want texture files, not integrated textures - so we can switch them with Firespitter. And here's the link to the plans that were discussed for future long-term development. http://forum.kerbalspaceprogram.com/index.php?/topic/133606-122-kerbal-planetary-base-systems-v140-1feb17/&page=27

Probably. Hard to tell from that, but usually that means you haven't installed them correctly. Undo whatever you've done, re-download, and try again.

Ok, ages ago I wrote a simple set of MM patches to help integrate UKS with KPBS. Then it got noticed a bit, and a few of us made some big plans. Then 1.2.2 came out, USI updated everything, I couldn't run the latest versions, etc, etc, and it fell behind a bit. @TheRagingIrishman offered to take over the main effort, but stuff got put on hold until @RoverDude released his balance spreadsheet, which hasn't happened yet... So. I got a new computer for Christmas, and I'm interested in playing with both MKS and KPBS again. Nills277 isn't particularly interested in doing MKS integration himself (which is fine: if he doesn't play with it, it's a complicated thing to integrate correctly), and no one seems to be doing much with it, so I'm reviving my patch set. I've renamed it, in the hopes of eventually doing a 'real' release, and I spent some time today reorganizing and cleaning up. Current repositories: GitHub: https://github.com/DanStaal/KPBStoMKS GitLab: https://gitlab.com/DStaal/KPBStoMKS I like GitLab from what I've seen, but I know they aren't the big name (and aren't quite as stable), so I've got it on both. I may drop one or the other if keeping them in sync becomes to much of a hassle. Current Status: Current Release is 0.9.5, with logistics, power distribution, Ground Construction, and Kontainers support. https://github.com/DanStaal/KPBStoMKS/releases/tag/Release-0.9.5 Repository Structure: I'm trying to teach myself good Git usage using this as well, so I've got the repository structured for a 'Git-Flow' workflow. That means there are several branches: Release, where the main releases will be made to. If you just want to grab the last tested & stable version of the patches, go here. This still has the old version of the patchset. Development, where the main development occurs. Currently has most of the latest changes. Various 'feature' branches, which are focused development on specific features that may or may not be included in main development. At the moment there's really only one active 'feature' branch: MKS_Workshops. It's intended to house development for the big plans that got discussed ages ago, while the main development will be trying to get something that does basic integration. (There's also the old 'master' branch, which I may delete at some point.) Plans: Short-term: Next on our list is to get USI-LS support written up and functional. This will probably be two versions: A 'Basic' version for working with just USI-LS (which we'll be sending to Nils277) and a full MKS+USI-LS version which will stay in this pack. Check to see if Multi-Hub has a node at KPBS height, and if not add one. Long-term, I'd like to see support for the MKS industrial toolchain in the KPBS form-factor. We had an interesting idea of how to break that up back in the KPBS thread ages ago - I'll look up the links. It may not be possible with the current way MKS is structured, we'll need to take a new look at it. How You Can Help: I welcome discussion and PRs. If possible, please put the PRs on the correct branch - that's either 'Development', or a feature branch dedicated to the features you're working on. (At the moment that being the industrial toolchain workshops in the feature/MKS_Workshops' branch.) This should be fairly easy, as I've set up 'Development' as the default branch to look at. Also, while I can code fairly well, I have *no* modeling or texturing skills. I've tried. Really. I may try again in the future, but if you have some skills in either, they would be welcomed. Currently we could use: Textures for the tanks. (Small, medium, large) For any/all of the MKS resources. I can do without, or have a default, or just have a couple, but ideally we'd have all of them. License: MIT.

If you're going that way, it would seem to be cleaner to have something like: @PART[FOO] { MODULE { name = GroundWorkshop Enabled = False } } as the blacklist. That simplifies your MM patch, and means people reading .cfg files don't have to look for multiple things. And it's only one more (static) line for the part author to copy-paste.

That's all handled at the EL layer - EL has recipes, and if you change the recipe, everything that builds/recycles will change to match. MKS ships configs to change the recipes, so the KPBS parts use them. (As the part doesn't care - only EL does.)

I actually wasn't really thinking about time being the lever here - It sounded to me like Allista was thinking of having some part (even just the workshop itself) be necessary for the demolition. So time is there, but really the lever is *mass*: Having the part, vs. just having a Kerbal go EVA. If you're willing to spend mass on a disassembly yard, you can get better return. If the two ships are close enough with ~0 relative velocity, sure, docking isn't *technically* required. I'm not sure I'm that good a pilot. And if the ship being demolished drifts beyond loading range, how do I get it back? Presumably I have it unmanned (so I don't demolish a Kerbal) and some of the parts have been demolished, so there's no guarantee of any type of control. Of course I could move the ship doing the demolishing - but that's most likely a large station, and may not be very mobile. So... I wait until their orbits intersect again? (Or have a tug just for this purpose, which is a clunky solution.) And note that KSP has tendency to shift orbital velocities somewhat as center of mass changes - so if you're moving the mass over part-by-part, your relative velocity is changing. In practice, I'd believe docking should be required - or at least allowed - as it will solve a lot of headache issues for users. But that can be more complex, which is why I suggested it be 'put in a hanger and disassemble there'. (Which makes sense from a realism standpoint to me as well: You don't want pieces flying loose, and you want to be able to get at things from different angles without having to worry about where your safety line is, etc. Keeping the whole process inside - even if you don't pressurize the hanger - will make it much easier and safer.) Ground of course is a different issue. There you can actually park and be sure of 0 relative velocity. (Well, within the confines of KSP's physics.)

I was mostly commenting that what you were envisioning was a lot more controlled and processed than the normal 'Explode! Explode! Explode!' of recycling parts in MKS, where I sometimes have to wait for three or four explosions to clear just so I can see the *next* part I want to explode. I think making it a process, with a slightly higher return rate than the demolition block, would make sense - the only thing I worry about is that EL's equivalent mechanic (which does process over time) is the buggiest part of EL in my experience. Of course the details matter: Are they taking minutes to break something down? Days? In general the longer they take to break something down, the higher the return rate I'd expect. Also be aware that doing things like this in space would require you to actually dock the parts into place, which is where EL tends to have issues. Better would be to integrate it with Hanger and abstract it: Allow you to recycle your stored vessels. Then you may not need USITools - but you'll want to balance against it, for people who are using both. (Again, I’d expect disassembly in a controlled setting to be more efficient.)

Well, I was going to say that currently USI's version is a bit more 'explody' than what Allista seems to be thinking, but I suspect that's a front-end detail.

Pilots, to find sites. Technically you can find sites if they are close enough without a pilot - but I'm not sure those stakes are close enough. And it might be worth pulling down that top drop-down and seeing what the choices are, in case there are more than one.

I'm pretty sure that's on his long-term plans for USI-LS, he's mentioned it once or twice. But that's long-term, and when and how (and even if he'll get to it...) are probably still open.

I'm thinking I may need to revive my patch set: I had Kontainers in KPBS style, and was working on an adapter part - though honestly I think I may take a look at how the current walkways interact with the multihub. Heights were *very* close before, and connecting a 'tube' walkway to a multihub would be a decent base connection in my mind.

No, I was keeping that distinction in mind. Even power receivers are moderately sparse in MKS - though quite a bit more common than transmitters, not everything has them. I was thinking of the central hub in this case as the use-equivalent of the Tundra Pioneer, so it should be able to receive power there as well. And MKS adds the power receiver to the stock fuel cells, so that's an obvious place. But I'm not sure what the equivalent of the Duna Pioneer would be in this view, which would be where the other power receiver. That said, your list is probably decent. It is more common - it's just not everywhere, like MKSModule and the InetertialDampener modules.