RoverDude

Those come from SCANSat - not sure where those values come from?

Awesome, glad you guys dig the stuff And I see no issue with having a giant KAS module. FTT is pretty much just a parts pack. I just need to do the giant 5m cargo bays in a way that can accomodate both MKS and OKS modules.

No worries - side note, that converter hasn't changed in ages

Love the command pod!

You can actually attach multiple jaws simultaneously.

Oh... I made a whole video on how to use the mod It's earlier up in the thread, ping me if you can't find it hrm... I'll have to play with captures and such and see about balancing and all that jazz.

Did you see the video? It's pretty close

Totally get that you are trying to help, but to be very clear, I have zero intention of attempting to dictate/encourage/etc. anything at all beyond 'Don't crash KSP please' and 'If several mods already have the same resource definition for something, please be nice and reuse it'. Now, for all of this, there will still be just a single definition, so mods will not have to define their own versions if they take this dependency (or they can still do their own definitions as long as they follow rule one, and try to follow rule two). But that's pretty much it. If anyone wants to begin their own discussions and expand upon this, awesome! rock on! But I have every intention of keeping my goals very very specific. Or, in otherwords, if everyone mutually agrees, for example, on the density of oxygen (which we're very close on), I'll reflect that mutual consensus. But I'm not going to suggest what that density should be beyond selecting a default if no consensus can be reached.

Just like any other mod... you drop it in GameData....

More concrete example please - i.e.e what you input, what you got, what you expected. Reason being multi-input single output is what I mostly use this for

Excellent - just bear in mind the RCS thrust is off right now - should be 750 v 50

Define wonky? And KolonyConverter derives from TacGenericConverter, hence why they are in lockstep. But I want to eventually break that dependency. Yep right ballpark Again, not set in stone yet just ideas.

So my thought for this is to have some action required by the player (taking a core sample on EVA, exploring in a Rover, etc.) that generates a resource. This resource in turn fuels the science outpost which generates a steady flow of science based on how much stuff the player can return to it.

IMO Hydrogen should be hydrogen Right now I do not bundle the example atmo stuff that comes with ORS (it's bundled with KSPI). I would not mind talking to Fractal about it as there are some oddities I have questions on, but he's MIA at the moment.

Make that happen and I will happily test it for you and sing your praises from the mountaintops (FYI this thread got buried - so toss me a PM if you wish to have a tester)

Oh, I run an engineering team for a day job... we don't do overtime (we work a 35 hour week). Bear in mind I do this for two reasons - first, it's good to keep my hands in code. And second, it's my creative outlet No worries - again, this is more of a one year lay my thoughts out all in one place thread. But if there are any unemployed modelers looking to join a project, that would actually make my job a billion times easier (PM we with a work sample and we'll talk!) Nope, keep on keeping on. Because the stuff on that list is super long term stuff, so it may be a VERY long time before I decouple life support. For all of this I'm not in a hurry, but do like to let folks see behind the curtain sometimes

Oh, the core ones are all useable There's a method to the madness (like resource consolidation) to make things work out. And I'd say consider the stuff laid out here more like a one year plan (or bits I had lying around anyway). MKS/OKS is pretty much stable other than the occasional optimization and the move to CRP. Karbonite is stable (after it's move to CRP), just needs more parts. Asteroidal Resources is about to launch. My usual MO is to focus on one mod at a time and stabilize, then hit the next one (which is why I had to stabilize MKS before OKS, and OKS before Karbonite). 0.24.2 wrecked a bit of havoc, but that appears to be settling down. On a personal note, I do all of this stuff for me first - plus it's my creative outlet. Just don't expect all of this in a week... again, one year plan Just figure folks probably wanted to know how all of the pieces fit together.

Is there a document or documentation on the sensorType stuff? Side note - my intent with the next MKS release, since it is going to have Karbonite bundled, is to switch to the single scanner. That being said, what would happen if someone wanted to scan for something for which the ORS maps are not present (i.e. a scanner that included, say, Ore, but the user did not have MKS installed)?

So I have a few mods. And I have a plan. The purpose of this thread is to serve as the master thread for all things USI, especially since a lot of these bits interact, and also a place to discuss the WIP bits for all of the mods that I work on. The current stable of USI mods can be found in my sig - here are the other ones I'm currently toying with... Outpost Science A stand-alone or complimentary piece for MKS that is a science outpost. Featuring new science experiments designed with rovers in mind, and including repeatable data-gathering experiments that can fuel ongoing science generation at a new Science Lab MKS module. Advanced Mining Tech A bunch of new mining goodness - there's a separate thread for this Other musings: Biofuel converters for MKS (more realistic ISRU for folks who think Karbonite is to sci-fi-ish). MKS shipyards - a more formal integration of EL and MKS (Possibly a fork, possibly pull requests to modularize parts of EL). Basically rather than going from Ore->metal->RocketParts, change the equation to require more varied resources to get down that journey. Karbonite/ORS enhancements specifically to encourage extractor and converter diversity

Interesting idea, look forward to seeing what you come up with.

Not sure if that was for me or OP. If me, then I'd let someone in the community do it If OP, feel free to use MKS models, etc. - Just follow the CC rules. Alternatively, I'm not opposed to working with OP jointly on a Karb-MKS/OKS-EL 3-way love child of mods that would be a separate pack and take all three dependencies.

Awesome! Thanks! And yep looks like I missed a decimal place Age, eyes, and all that jazz. Heya, read this a couple of times. So the intent of CRP is not to dictate resource interactions, etc. - it just has a primary and a secondary goal. Anything beyond that is left as an exercise for the players/mod makers. Primary: Ensure ORS maps do not collide. So if I define Substrate and it's disposition, nobody else should also define it with a different map. Now whether they choose to convert substrate into fluffy unicorns, or substrate into silicates, that's their call provided they stick within conservation of mass. Could I have two mods that both use silicate, with one converting it into unicorns with a net loss of 20% and another converting it into silicates with the same ratio (resulting in 60% overage)? Sure. But that's outside of the bounds of what this mod does, and can be explained away that you are harvesting silicate-rich or unicorn-rich materials. An example of this is how Asteroidal Resources handles conversions. In short, anything beyond making sure we do not break eachother's stuff is out of scope for the primary goal of CRP. If only this is achieved, life is good. Getting folks to agree is like herding cats as it is, and having your stuff crash is a fantastic motivator for cooperation. Secondary: Play nice and not stomp over eachother's resources. This is just a list of materials used by multiple mods, with agreed to densities and also (to be added) conventions - i.e. one unit is 1L or 5L. Nothing forces folks to play nice, but it does make life easier. If this is achieved I'll be very happy, but it is still a secondary goal. So I agree that there are tons of loopholes, etc. in KSP resources and Khemistry in general, but that's a huge problem that is well beyond the scope here to solve. I just want stuff not to crash - - - Updated - - - Challenge accepted.

CLS not required, but code changes are because Squad broke stuff.

Serves me right for hitting the big download button

I'll check the tank weight - bear in mind most of this has not gone through a balance pass Also figure the weight of that tank includes delivery mechanism, etc. RE gimbals - I'll need to do some experiments and see what makes sense visually, etc. - although so far I've found having little thrusters tied to the RCS system to be incredibly effective at keeping large asteroids on track