RoverDude

Ok your issue is the engine did not fall off. - - - Updated - - - Also - use those nice enclosed trusses I give you!!!

Pargentum - incorrect. The trusses are always your first part. Been that way for a while now

It's 1:1 mass-wise, the assumption is that some rudimentary sorting takes place during excavation. Yes, for realism there should be a loss factor. However had to compromise for gameplay reasons on this one (so in that regard, it's closer to Kethane (which is nearly lossless) than Karbonite (which is very lossy). - - - Updated - - - But we did speed up mining - you get full unattended processing And it's pretty brisk if you are on a good spot. Thing is, that requires using the prospecting tools to find a nice spot. Also as noted, have an engineer on board. - - - Updated - - - (Side note) I've been watching streamers, etc. play with the new systems and there may be some slight adjustments (from a config standpoint, not a mechanics standpoint).

tbh even last night I did a few rockets with just the basic nosecone... no issues? Show me screenshots of what precisely you are trying to land with that chute

I'll take a peek - probably catching it before it warms up. You're misquoting me a bit The scanner is behaving as designed. When you look at how people have been doing resource scanning for years - the number one complaint was that it took too long, and was not fun. That's why folks like SCANSat since you can just scan at warp. And I agree, but just cut out the middle man of the warp bit since once you're at a ten second warp anyway, the progressive scan adds nothing. Also as noted, it's just one in a series of prospecting mechanics. Background ore processing is a whole different kettle of fish. It's generating a tangible resource, and where you will be spending the lion's share of your time. And logical that once your infrastructure is set up, it could operate in the background. The analogue to scanning would be to have background progressive scanning. And people would just warp through it anyway (no value) as it is a one-time and relatively short event. Ore harvesting is an ongoing process (there is no end), so unattended ongoing processing makes sense. In any case, I'm comfortable with the mechanic as are many users.

The VAB fillable ore is by design. Also it would be mass neutral, not 2x (discounting tank mass). The latter is also for design reasons. It's kinda a no-win to use Ore on the pad just because you also need an ISRU (4 tons, plus funds) and power to do the conversion. This is not very helpful. But what I can guess at is that you don't like the mechanic? can't tell. Perhaps phrase things a bit more constructively and with detail.

I'll take a peek as well. It's nice not having the constraints we had last time Thanks for keeping this rolling, Nertea!

Hey guys - just a heads up (and probably a herald of sadness) but the proverbial cat is out of the bag, and the dres asteroid rings were in fact the nifty present that we snuck in for resources I did not anticipate the rumor getting out and everyone and their brother swarming that sad lonely planet In any case, I hope you enjoy it!

Hey! I can answer a few questions, and maybe provide some insight. Usual full disclosure, I authored the code for Karbonite, it's back-end framework (Regolith), as well as the stock. Also note that these are my opinions as a designer of a game system, and in no way reflect the official opinion of Squad, etc. etc. This was a very conscious design choice. My experience wit Kethane was, to quote another forum user, to start scanning and go make a sandwich. In my opinion, from a game design standpoint, that was not fun. Having to optimize what warp speed you can use to mitigate the pain of a long scan process was not fun. Now, if we take SCANSat as a comparison (and it's awesome for scanning - it's why I recommended it for Karbonite), the mechanic is different. Background processing for one, full time warp for another. Just get into a polar orbit, and hit time warp for ten seconds and you're done. So when I made the stock system, I looked at both of these. And in both cases, players generally used timewarp as a gameplay mechanic to circumvent 'un-fun' bits and get to the fun things. And I don't blame them. So I left in the hard part (getting to a polar orbit), added a cost (power and data transmission that varies based on the size of the body you are scanning), but took out the not fun part. Also - the stock scanner is significantly less accurate than the Kethane or SCANSat/Karbonite - by design. The reason is that we have a secondary scanner (the narrow band scanner) that gives you high detail, but operates realtime (more for landing planning). So in short, I stand by the design choice to not (in my opinion) punish players and provide a scanning mechanic that everyone tries to circumvent anyway because it is (for most players) not fun. The beauty of the stock resource system tho, is that if someone wanted to slap a Kethane grind in... well, they could This was another design choice, and one where I intentionally did not do what Kethane and Karbonite do. Real ISRU is hard. The stuff is heavy, the stuff is bulky. It imposes design constraints, and I think this is a good thing. What I find interesting as an outside observer is seeing, on the one hand, folks complain that refueling is OP, followed by folks complaining (to paraphrase) that the equipment is imposing engineering challenges. In my book I chalk that up as a win It is completely by design that you can't make little fuel hoppers. But it's also by design that you don't have to move around much as resources do not deplete (other than asteroids). So it's a balance consideration. Incorrect. Without the scanner, you can view the overlay either in map view or in the tracking center. To access it in map view simply double click on the planet and you will see the knowledge base option light up that will allow you to cycle through resources (one for now - Ore - but I look forward to seeing what modders add to the system). The cutoff is dynamic and it is relative. So if the planet averages 0% - 15%, a cutoff of 70% will just show things that are (roughly) 10% or greater. Each planet is random in each save, so I have no idea if you landed on a good spot. Also it's going to have a lot of variance, hence why you generally want to do a ground scan to unlock higher detail for that biome before using a narrow band scanner to zero in on your final landing site. Stock has a significantly more involved scanning and resource location process than Kethane in that regard, which may be why the scanner above caused confusion. The orbital scanner is just the very first step in a more involved prospecting process. Overheating wise - did you have an engineer on board? Probe based drills are going to be horribly inefficient (by design). After all, this is Kerbal Space Program, not Drone Space Program And one thing I have tried to do with the new systems is always put the Kerbals front and center. Drill heat will kick in inversely proportional to your deposit level, so a lousy deposit without a good engineer will be slow. Also - regarding the long extraction times. Remember that stock can continue drilling unattended. So go run other missions, etc. and when you come back to your mining station, you may well be brimming with ore This was also a design choice because watching drills is not fun, and artificially increasing the drill rate to compensate for a lack of an unattended processing mechanic is, IMO, not the best design choice.

Launch first vessel has always required a manned capsule - - - Updated - - - You have launch sticks Point and go! Have had the opposite experience in my saves, and have not lost an experiment yet. Try adding in a pack chute.

Thought about it, and given they can only do each of these things once before hitting a capsule, path of least resistance is to just let them do their thing. Just one - Supplies Because that sounds like WAY too much work This is one of those cases where a framework really is not the right answer. I have a pretty specific vision in mind, and want to run with it. There will be some config choices, but limited in scope.

I say that despite the tool being unnecessary, the CTT idea is still an extremely valid one (i.e. no point in having 20 nodes for nuclear reactors when, between all of the mods that use them, we can sort that out in a handful). I also agree with the original mandate of not messing with the stock tree, because once you go down that route, we'll never get out of the tar pit. I do agree with the original mandate of using CTT to provide a framework of additional nodes for us all to work with. That worked out well, and made it a pretty cut and dry mandate with minimal contention. Nertea, let me know what you want to do, but I for one will pretty much follow your lead and adjust my stuff to accommodate the modified structure. Side note - hopefully we can add in our own icons now too

Sure, toss me a pull request

Short answer - yes. There are some ranges for the scorching in the config file. charMax and charMin are the fields you want, both are 0 to 1 I would *guess* (try this) setting the range from 0.0 - 0.0 would work for what you want

lol thanks Just give them a nice, safe desk job.

Paul - for now I would say either stick with defaults for the new parms, or look at the stock fuel cell's config

Not quite

Only one timer needed - no need for absurd batteries (just have enough for normal operations and a bit of a buffer and I expect you will be fine)

@Paul - yep, once the dust settles a bit

No recyclers that come with it, but trivial to make if folks want to make ones Trying to keep the part count light, and it assumes basic recycling already exists in all pods.

Thanks and let me know what you find - this is definitely in a scrappy alpha state

Paul - if you need help with using the converter code just let me know (but it should be pretty easy to convert over from Regolith's syntax). Also - make sure you drop the regolith dependency in CKAN as it's deprecated (for now)

heh, nifty

So I have been considering over the past month or two the creation of a life support system tailored to fit in with the USI mods, and also bring together some the bits I like about other mods already on the market, and add a few of my own tweaks, etc. This is pretty much my interpretation of how, if I were to go buy Kerbal in a store, I would expect a stock-ish life support system to work. I've been playing with it and minus a few refinements am very happy with the result. With that, I am pleased to introduce USI Life Support. Basic overview stuff. Mechanics wise, it's pretty simple. Kerbals require supplies. Kerbals also require EC. these are both on the same timer, so I just check supplies for the status window. When Kerbals are done consuming supplies, leftovers, scraps, and 'anything else' is either tossed overboard, or (if storage is available) tossed into a 'mulcher'. The resulting organic slurry is called 'mulch' and can be used to feed greenhouses, etc. at the player's discretion (or in the case of MKS, converted into Organics at varying levels of efficiency). 15 days out, the visuals go yellow (sorry, no auto-warp-slowdown-thingie, use KAC). When supplies run out, things go into the red. If you leave them unsupplied for 15 days... well, they just say 'screw it', get grouchy, and quit. They are still in the pod. they still take up a seat. But they can't fly, can't EVA, and essentially do the Kerbal equivelant of spinning around in their office chairs, refusing to work, until resupplied. This is a design consideration in that all of us, at least once, has just flat out done goofed, and lost a whole colony of Kerbals via glich or other sadness. Yes, death/despawn will be an option. Not the default one tho. Mechanics wise, they are transformed into tourists, as they are essentially on a self-imposed vacation Once resupplied, they are happy as clams and will return to work. While on EVA, they will not quit. But if they are brought back aboard a ship and have been starved (and can't find a hot meal waiting) they will promptly go in strike, and begin their self imposed vacation immediately. Orange suited Kerbals (Jeb, Bill, Bob, and Val) are immune to the ill effects of life support. They will still consume supplies if given, but do not leave the job, because they are just that awesome. This always gives a player (especially a new one) an 'out' to test out a manned mission before actually committing your other kerbals, etc. to a horrible fate of snack deprivation. Yes, it's a bit more 'Kerbal' than TAC-LS, but also a lot more predictable and with harder consequences than 'Snacks'. It does, however, feel 'right' (at least to me) from a design standpoint. Parts wise: Three inline storage compartments. No extra recyclers needed. No resourced added to pods (the 15 day window covers all of the Kerbin SOI so no point). No random contracts. MKS/OKS Changes MKS wise, closed loop just got a lot harder/more interesting (depending on your point of view). The old C3 (now renamed to the Pioneer Module) will have a basic mulcher and greenhouse and can do recycling at 50% efficiency for up to four Kerbals. Kerbitats operate at 75% efficiency. Mk-IV modules (once released) will operate at 90% efficiency off-world, 100% efficiency on the surface (pulling in of local material is inferred, no extra drills required). Supplies come from organics. Organics come either from mulched supply waste, or from a combo of water/substrate. So surface bases are easier to get to self sufficiency - if they are on water/substrate deposits. Orbital will always be a pain - so you will need to fly up fresh organics or keep large stores. And since organics creation is not tied to the life support loop, building large surface farms is also pretty easy now. Dealing with hungry Kerbals So you can do some very interesting things. Run a command pod to dock reviving supplies/snacks to a starved out colony ship. Use one of your orange-suits to lead a mission and conserve supplies. Note that Kerbals are pretty damn aggressive about getting their snacks - the only way to lock them out of the biscuit tin is to click that little feed button by the resource on a part (same way we reserve some battery power for a probe). Note that a Kerbal about to starve (i.e. no supplies for 15 days) will in fact happily break open said biscuit tin. witty screen message included Design side note: So 'Mulch'. Waste was used, and too generic. And I wanted something that showed that the stuff was kinda useful, not edible, and felt more 'kerbal' (and less like poo!) if that makes sense. The idea of Kerbals tossing all of the spare bits and scraps into a contraption and getting out a semi-useful generic organic slurry had a certain appeal, hence the abstracted mulchers and mulch resource. The resource itself is just 'supplies' and has the visual representation of a translucent, semi-rounded green cube. What are they? Well... leave that to the imagination. But the labeling will read 'N.O.M.S. - (Nutritional Organic Meal Substitute)' on the tins LICENSE: Configuration files and code are licensed under the GPL v3 license. Assets, including Models (*.mu) and Textures *.png/*.dds) are All Rights Reserved. If you wish to use any of these assets in your project, just ask nicely DOWNLOAD: Get it at the GitHub Repo! https://github.com/UmbraSpaceIndustries/USI-LS/releases

0.2.0 IS UP! KSP 1.0 Compatibility Some experiment labels got mixed in shipping - this has been fixed. Fixed a parachute issue with the 0.35m nosecone Renamed the decoupler to a stack separator Disabled crossfeed in the stack separator The gyro is now an inline part Added a handy stack node inside of the two trusses Ballon and blimp parts have been deprecated for now (no worries they will be back later)