RoverDude

Cryo storage baked natively into USI-LS.

I've actually moved everything over to the stock system. KIS is fully deprecated in the next release. Which I really want to do sooner rather than later, as there's some good stuff in there. In the interim, I'll probably be doing regular constellation pre-releases.

KSP Version? and try a clean install - I've never seen this cause an issue like what you see above.

More a side effect that came along for the ride for something else I was working on

Just gonna leave this here....

1. Ahh. yeah, tbh I think the close orbits make more sense lore wise. 2. Good deal! 4. Fair enough - log a github issue and that gets it on it's way to the list. Also completely unrelated... USI-LS is getting a thing....

1. Just the one. No real need for two, since the only real reason for an orbital biome is the endpoint for your planetary output - either as hoppers or as a leap to the next system. And if there were two you would have the whole mess of being in the wrong one when you expanded infrastructure. 2. / 2a. - Not hard at all - pretty similar to other MKS bits. Bear in mind the hoppers are probably some of the first getting a refresh since right now they are placeholders. 3. Nope. 4. Is there a reason you'd prefer the different status? Once in WOLF it is a one way trip. Not sure if there are ramifications of a Kerbal being 'assigned' but lacking a vessel to be assigned to.

Yep - to get the boost you need helpers and a foreman. The Konstruction bits are slated to be assistant parts - but for the current test, the only helper is a Salamander pod.

In the constellation test, drop a Salamander pod. Have four Kerbals around. An Engineer in the Salamander. Then right click on the Salamander and there should be an Enable Konstruction button.

Sadly, that would have the same kind of vessel overhead (even as a single part) for the volume of wolfy-ness most saves will have. We're exploring a few options

Yep, @DoktorKrogg and I have waxed philosophic about the lack of a physical WOLF manifestation. The reason they are not vessels as you see now is because those tax a save pretty hard when you end up with too many of them - and MKS / WOLF by it's very nature encourages a LOT of infrastructure. The current philosophy (and where we are at today) is that your physical manifestations are the 'faucets' on the plumbing that is WOLF. That is, you may have a single orbital station for off-world ship construction, or a capstone manufacturing colony to make all of your MatKits, etc. - but the plumbing would be WOLFy, and hidden, with your only access via hoppers. The other is that having something physical there but super cool looking would be great - IF it can be done in a way that does not tax resources. This is something we'll be looking at as the rest of the pieces fall into place. And yeah, rebuilding an OSE analogue was definitely a 'my-personal-playthrough-driven-development' moment There are some other things in that category that we're working on currently.

Thanks - @DoktorKrogg did most of the heavy lifting on this one

Yep, making you manually build up routes is by design. WOLF is some powerful stuff, and setting up infrastructure is hard. MKS is already an end game activity, this just moves that capstone role up to WOLF. Also the rub with things like ship cost, etc. is they have no bearing in sandbox mode - so we have to keep that into account. Or folks gaming by having the tiniest ion probe possible make the trip. Sure it's more efficient, but you would have to do a lot of them to balance it out.

Make sure you do a WOLF survey with the stock resource scanner (The one in science that's a large boxy thing). That scans and unlocks the resource veins.

What you see there is a replacement for OSE Workshop. There may be other things being worked on.

For those interested, you can grab the new Konstruction code/bits out of the pre-release of the USI Constellation here: https://github.com/BobPalmer/USI_Constellation/releases/tag/2020.12.31 This is a dev build. It's relatively solid, but bear that in mind - bug reports/feedback appreciated. Back up your save. This includes both the KonFabricator part, as well as EVA Construction enhancements - there are links to both design docs in that pre-release link. This also includes a whitebox version of the Packrat rover that uses the new stock inventory system. The old Packrat is now legacy. While I use this in my own save with no ill effect, back up your save. It's a pre-release.

For those interested, you can grab the new Konstruction code/bits out of the pre-release of the USI Constellation here: https://github.com/BobPalmer/USI_Constellation/releases/tag/2020.12.31 This is a dev build. It's relatively solid, but bear that in mind - bug reports/feedback appreciated. Back up your save. This includes both the KonFabricator part, as well as EVA Construction enhancements - there are links to both design docs in that pre-release link. This also includes a whitebox version of the Packrat rover that uses the new stock inventory system. The old Packrat is now legacy. While I use this in my own save with no ill effect, back up your save. It's a pre-release.

I get what you are saying, but disagree (and that's ok!). An established route is already a sunk cost. There's no real benefit to being able to delete them - each expansion of a route comes in the cost of having to physically make the trip. Sometimes you'll luck out with a really good one - sometimes it's going to be less expensive, but each time you make the run you're optimizing efficiency and layering it into an existing transportation network, not wholesale upgrading your entire fleet. Engines aside, different payloads and strategies exist and will be experimented with to get optimum trips added to your network. Having a new route be affected by the inefficiency/efficiency of prior routes just feels off. You are paying for that route expansion in the hear and now, and as it stands, it remains a really predictable result. Extremes could result in weird stuff like zero-TC expansions, etc. when in reality, any dramatic difference in route cost would either be so late in the game it did not matter, or so early that the issue would solve itself as the TC/Capacity ratio nears peak efficiency asymptotically. And in short., I don't think that is something I'd want to mess with (at least regarding this specific aspect - there are other things on the drawing board regarding routes, but they touch on other areas).

I think that gets a bit sketchy since part of what's involved is figuring out the right mix of vessel sizes, etc. to optimize the load. Not sure if this particular system of WOLF is one that needs a patch tbh.

@DoktorKrogg may have more insight, and I could be wrong, but I believe that once the TCs are spent and the route is created, all you can change is what's on that route, not redo the route/cost itself since stuff gets gobbled into WOLF (which is what makes it so efficient).

Sorry, to be 100000% clear - I was talking about the Ranger modules for the MKS mod which I am moving to the stock inventory system. zero to do with the stock game.

They can in the next update (at least for Stock inventory and MKS).

Yeah, there's stuff in the works on that front. Just not an ETA. In theory, with Konstruction you could easily expand bases out since it also includes enhancements for EVA Construction.

And a new feature is getting the tires kicked There will be a constellation pre-release in a bit, but in the interim, here's a pic and a link to the design doc: https://docs.google.com/document/d/1x1Gwwt0u8RwZf3zVa26D7gfxvYZ1YT9LytOrMaHUyaw/edit?usp=sharing

New goodies incoming The KonFabricator allows you to turn MaterialKits and Specialized Parts into useful things in-situ. No dependencies other than the Konstruction mod. Just finished the code, on to testing (I'll drop it in a USI Constellation pre-release), and then hopefully the big release by the end of the weekend.