zyp

It's not a matter of getting access to the parts sooner, my whole point is that I think I get access to the entire part selection too soon. 300 science points is really cheap for the range of functionality across these parts. Even if the fuselage technology is the same, the contents and capabilities of each module is still different. Consider that by not unlocking the 160 point node containing the stock science lab, you've already covered over half of the cost of the composites node for only a small fraction of the functionality. If you're going to edit the tree, I suggest not just adding a single node but an entire branch of nodes that starts out with Whipple Shielding containing a few basic core parts and then lead to nodes containing modules with more functionality. Then there's the IACBMs. It doesn't make sense that you get access to the parachute version of the 1.25m IACBM from SDHI SMS before the standard version, and getting access to the 2.5m IACBM before the stock 2.5m docking port is also unbalanced. I have not suggested this either, I also want to keep it realistic. KIS distinguishes between internal access and external access to a container, making it possible to make both pressurized storages that's only available from inside a vessel and unpressurized storages that's only available from outside a vessel. On the topic of pressurized KIS storage, I've considered the idea of a life support mod that has food as a KIS item rather than a normal resource. Food can then be consumed from each internal-accessible KIS storage in the same CLS space. This way we avoid the unrealistic pumping of food, while still allowing resupply runs.

I'm not opposed to having them late in the tech tree, but I don't like the all or nothing aspect of having everything in the same tech node. Stations are launched in parts and evolve over time, so it makes sense to start with something like a basic habitat, and then you unlock more functionality for your station later. Compare this to your Service Module System (which I'm also playing with and enjoy) that have the parts spread across a lot of nodes, even though they're designed to be used together on a single launch. I've been planning to do exactly this. My node modules will be launched with extra hatches installed for possible future expansion but covered up until they are needed, and then I can do spacewalks to remove the cover panels and install the necessary docking hardware. I agree completely with having the end rings toggleable but the side nodes fixed. Speaking of KIS, have you thought about making a module with a large volume container with EVA access? Considering the volume limits on the containers, just sticking a bunch of the small containers into the warehouse module isn't very practical. Since KIS can do containers with internal-only access, the logistics module should probably be one. That way kerbals can go there to pick up parts to bring along on a spacewalk. This is of course limited to parts that's small enough to fit in a kerbal's own inventory.

Hi, I'm playing with this mod in my 1.0 career playthrough, and will submit feedback as I find stuff to report. Is there a reason all parts have TechRequired = composites, rather than being grouped along with stock parts of similar functionality? I like the idea of building my station incrementally as I progress through the tech tree. Having all station modules under a single tech node kinda removes the point of playing career. The science module isn't updated for the 1.0 science lab changes. ModuleScienceLab got new options, and there's also a new ModuleScienceConverter. I like the idea of Kanddak's module making the end rings toggleable instead of having two of each module. With CKAN, extra dependencies is a non-issue, and you could just make it optional with a modulemanager config. I'm tempted to incorporate this module into my current playthrough. That's all I have for now, since I've yet to unlock composites in my current playthrough. I'm now thinking about writing a modulemanager config to patch TechRequired as a temporary solution to play the game like I want to.

I discovered that mining when the rock resource of the asteroid is not full (either due to venting or using rock) causes the rock resource to fill up without new space being added before it's full. Looking at the source for REGO_ModuleAsteroidDrill, space is not added before it's needed, but asteroid mass is not subtracted before space is added either. The implication of this is that is that a single small asteroid can give you an infinite supply of rock for the mass driver and extractors. It seems to me that the natural fix would be to simply always add space and remove mass. Also, it seems like the total space available for an asteroid always being 0 is simply because ConvertSpace in USI_AsteroidTank only increases availCapacity, not maxCapacity. I'd send pull requests for both fixes, but I don't like submitting untested code and I don't have a C# build environment available.