NermNermNerm

Jacked with it until it worked. I think my mistake was in copying some other parts that did 'mesh = blah' rather than 'MODEL { model = blah }'. My guess is that 'mesh = blah' doesn't do anything, really, and if KSP doesn't see a MODEL object, it looks for a .mu file in the same folder as the .cfg file and uses the first one it finds. The shimmering I reported is because I fail at smoothing, and one of my cylinders is actually still an n-gon, and as the image is rotated in the preview window, the model gets one pixel wider a few times a second.

Yesterday I finally got my first ever part in a state that I was reasonably happy with and incorporated it into my mod! Yay! So I made a second one! And that went well too... But now I notice something I can't explain: my first part is now using the model from the second. Now, you can imagine there are a variety of ways I could have boneheaded that. But I've checked it every which way, and it's just not so. My .cfg's are pointing at different .mu's, and git assures me I haven't inadvertently overwritten my first .mu. Idunno - is there some kind of identifier baked in to the .file exported by Unity? I am using the same unity project for both parts. I also notice that when I look at the part-info page, the preview pic of the parts both seem to shimmy... Like it's actually drawing both models, one then the other.

Per this guidance, it doesn't matter: FWIW, I've got the debugger working, but I too am being hit with the ~10sec delay after attaching the debugger. The guidance also now specifies copying in a new version of UnityPlayer.dll and WinPixEventRuntime.dll, which could use some commentary on the following in the OP: Is this really necessary or do the old DLL's work (haven't tried it yet in that configuration) If it's really necessary, then it's kindof a breaking change in that you're pretty much forced to keep a development KSP folder around, one that's not Steam-Updated, as Steam's likely to stomp those back into its own version. That was sortof a good idea anyway, but it was never an idea that I followed since I spend as much time or more playing the mod as I do developing it, I like to play it in non-debug mode.

I'm just updating to 1.8 and hit a snag. I've got code that's trying to load a button image, but the old Texture2D.LoadImage method is no longer a thing. (See my example of what used to work in my GetButtonTexture method). Anybody got a pointer to a different way to load a texture in 1.8? Thanks. Derp, got my own answer by RTFM:

I am completely new to modeling parts for KSP and near complete neophyte at Blender, so this is bound to be a dumb question... I'm starting out by trying to create a thing that looks like a Tank. 1.25x.5m tank. That's it. And I've managed to do it, if you don't mind that the tank is faceted. I've tried using a "Subdivision Surface Modifier", which makes the magic happen in Blender, but when I export it (via collada) and import it into Unity, its effect is gone. The "Smooth" modifier alone seems to do absolutely nothing to help, and when I look at the manual, I get the impression that it's not the right tool for the job at all. I can see how I could fix it by just making sure that when I generate my Cylinder in Blender that I make it have a whole lot of facets, but I somehow have the idea that's not the thing to do and it'll tank performance. Any tips? If somebody can at least point me at the magic word to google, I'd be obliged. FWIW, here's the tutorial I've been following to learn the basics of Blender: And here's the video that I've been following to get a Blender model into KSP:

Have a look at the wiki help for this: https://github.com/SteveBenz/ProgressiveColonizationSystem/wiki#kerblab It's intentional that it's 5k days - you should bring more Kerbals. "Production" means how many are being produced & stored. I'm still looking for a way for the dialog to clearly state what's being produced & stored vs. what's being produced & consumed locally without being too chatty and confusing the issue even more. Thanks! I haven't used Configurable Containers - I presume that doesn't include any actual container parts, right? Which mod are you using for containers? (Or does this just re-use the stock fuel tanks for containers?) In theory, you shouldn't need to mess with volumes & masses. The Resources themselves specify mass/unit & volume/unit. (Though, as I recall, not in those terms exactly). So assuming Configurable Containers is built right, it oughta just work.

My 11-year-old son and I talked over the space station problem - he gave me the idea that sounds like it'll kill two birds with one stone, at the cost of raising the difficulty a bit. The trouble with the station requirement is that what makes the most sense in the game is to not have a space station. You're better off building a single crew-transit ship with the scanner part just bolted on. Also, the part only requires one crew, so you end up with a station with one kerbal all alone up there - because until you get Tier-4 hydroponics, it doesn't make a huge amount of sense to have a biologist to run the hydroponics equipment. The idea we came up is this: When we design the new scanner part (assuming I ever can find the time to learn how to build cool parts), we'll make it much much bigger than the current part and make it require 2 crew, not one. That should help on a number of fronts: It'll make it so that you'll want to have an orbital station that you leave in-place, because you no longer will want to pay the delta-v cost of making it an integral part of a inter-planetary vessel. With 2 kerbals to support instead of 1, it'll make sense again to have a biologist on the station to run the hydroponics. It should help to balance the specialists -- right now you inevitably end up with too many pilots, geologists and biologists. On the down-side, it'll increase the amount of stuff you'll need to move up to orbit to support the station. I'm concerned that it'll make early game painful. I think the way to fix that would be to make a "Scanner-Junior" part that's not-so-massive and only requires one kerbal to operate, but it won't support T2+ operations.

I released 1.0.7, which includes the changes I mentioned to allow for upgrading parts from Tier-2 onward. I've used it quite a bit in my own play-through, and I like it. I added a section about it in the Wiki. It's a bit challenging to get it done right, but I like to think that anybody familiar with EPL or PKS will be able to piece it together without reading the wiki. The only rough spot I can find (that I haven't already ironed out) is that the automatic resource transfer system will always want to transfer stuff away from bases that produce stuff. So, for example, if you have a base that produces rocket parts, but it doesn't produce enough rocket parts to upgrade everything you want to upgrade, you can't send down more rocket parts easily. You can do it, but you need KAS or some other shenanigans to link the ships. My own playthrough is progressing. I'm Tier-4 at Mun, Minmus, Duna and almost Gilly. I've got a base on Dres at Tier2 now. The Dres base was really challenging, as it's a bear to get encounter nodes to Dres and it takes a crapton of Delta-V and you've got to ship a lot of heavy loads out there to ensure that it can be a one-way-trip for the Kerbals. I just about blew it, coming into Dres too fast and had to eject some Rocket Parts from the crew module, which allowed me to just barely get a capture, then I had to use one of the cargo modules I had sent in earlier to shove the whole mess into a circular orbit. Then I discovered I didn't have enough power to actually run the ship when I decoupled the supply ship and had to use a bunch of rocket parts to build a wad of RTG's onto the ship. Planning! Yeah, that's a thing you can do! But I didn't. Or at least not in a timely fashion. Upon arrival I had a ship with a big slug of reactor fuel a few hundred days away. So the Tier-0 base sports a veritable porcupine of RTG's - mostly in order to support the ISRU unit. The next step on Dres is to build a Tier2+ base, plus a crushins rover on the limited budget of rocket parts available. Have you guys tried Near Future Electrical? I tried it in the past, but I just installed it again to find a really great new dialog for power & heat management! It's great stuff! Perhaps I can find a way to run my Dres base off of Solar after all.

Well, it's a game, so making sense isn't necessarily crucial I'm going for a couple things with Hydroponics: The first is to avoid what ended up happening in MKS - where hydroponics became just better than agriculture in every way. The second is that I wanted a concept that bundled food-consumption and "recycling" into one concept that's easier to do math on than, say, where MKS ended up with its recycling+consumption+colony-supplies model. So the arbitrary "you can't store it" thing reflects both the recycliness of hydroponics and the desire to have a clean break between the landed and en-route/orbital parts of the mission. From a mission-planning perspective, I think it simplifies matters quite a bit - because what happens in orbit stays in orbit. In my own playthroughs, I see a couple things: For there-and-back missions (e.g. your T0 mission), it's best to just calculate how much top-tier snacks you'll need in each phase, and bring that many. Yes, the landed base can produce snacks that are useful for both the orbital base and the return journey, but I find it best to ignore that and use the extra food as a buffer against crappy maneuver node planning. Once you get T2+, you'll find there's really no reason for your kerbals to return. So, once you get to this "permanent" stage, you can pretty much quit doing hydroponics for your orbital base and supply it from local agriculture. For brief junkets (e.g. you want to take some kerbals from Duna to Ike so they can get their stars), yes, you should bring snacks and yes, you haven't much alternative but to bring T4 snacks because hydroponic modules are too ungainly for short junkets like this. I find that these missions are so short that it doesn't really impact your planning. Further, if it's just a flag-collecting journey or some other such thing lasting less than a week, you can skip the snacks and it'll all work out because of the grace-period built into snack consumption. So anyway, play the mod a while, and you'll see that you don't have much need for stored hydroponic snacks. It could be that I've nerfed hydroponics a bit too much. Now it's primarily an en-route aide, and not a great one at that. As to the roadmap, I feel like I'm pretty much done. Right now I'm in the final phases of testing a couple of capabilities that I've already mentioned before - particularly being able to upgrade modules on-site if you have Extraplanetary Launchpads. I felt like making the requirement for EPL made sense because if a player doesn't have EPL, then it must mean they don't want the ability to build outside of the KSP. Maybe they feel like it nerfs the game too much, or maybe it's just too complicated. If that's so, then upgrading probably won't be their cup of tea either. If you do have EPL, there are all kinds of wacky things you can do in order to get the effect of upgrade-on-site, and I feel like once you get going with the mod, you're just going to do that, and the consequence of doing that are some wonky-looking bases and a bit of "will-the-kraken-strike" drama that nobody needs. So yeah, that's a thing now. I'm happy with that. The other change that still needs validation in my playthrough is to make it so that once you've unlocked enough T3 techs that you can skip Tier-1 and go right to Tier-2. Once that's done, there'll be no alternative but to face the peril of designing some parts. I've been cribbing off of a number of other mods and stock parts, but there are a large number of parts that suck: There's no small snack storage. Particularly none that looks good on early Minmus missions. The orbital scanner doesn't look the part. The factories are identical, and identical to the ISRU parts, and that's highly unfun. I'd love to have a larger farm part. But I find the whole process of part design really daunting - I've gotta learn my way around modeling tools (when even picking the modeling tool is a perilous choice, it seems) and nobody is worse at photoshop than I am. But the most important thing to do is to hear what people think. I haven't heard a lot of feedback; certainly none from people who had extended experience with it. That's disappointing, but I suppose pretty much normal. I didn't provide Roverdude a whole lot of feedback even though I played MKS to death. But trust me, I'm listening. Right now the best piece of feedback is from the few folks who complained about the early game experience and suggested that a dedicated food-container with a proper early-game form-factor would be good. At first I didn't agree, but after a bit of soul-searching, I fully see their point now. One other piece of feedback I got really early and I'm really glad I listened was that I had a "colony supplies" analog, and (sorry, I forget who), told me to skip it and see how you get on. I now feel that he was more than correct. One thing I'm disappointed in with my playthroughs is the role of the manned orbital station. The scanner, right now, seems a force-fit. But I'm low on ideas of how to make that better.

I've noticed that on sprawling bases when landed on non-perfectly-flat spots (e.g. not on Minmus' flats), there are times when I'll come out of time-warp and the base will flip up in the air and crash down and break stuff. You can also see this effect (although in a smaller way), by just time-warping briefly. What I'm seeing is that when you're not time-warping, the ship will flex a bit to conform to the slight variations in the surface. When you're time-warping, it undoes whatever flexing it did, causing some parts to clip into the surface. When you come out of time-warp, KSP detects the collision and chucks the clipping part of the base up. I believe that it's worse when you come back to the ship from, say, a long time warp spent elsewhere. That'd probably be because of some floating point errors in the calculation of the planet's rotation and the ship's relationship to the planet. Obviously, this isn't really specific to KPBS - you can also see shenanigans like this with landing struts on other ships. But it seems to me like with KPBS, the effect is worse just because typical KPBS bases (particularly large sprawling ones like I tend to have), have a large footprint, and so the error gets magnified. Is there a recommended way to build bases to avoid this sort of problem? I know that MKS has implemented an "Inertial Dampener" that seems aimed at fixing this sort of thing...

That's intentional, as I didn't want Hydroponics to be any sort of replacement for farming.

That's by-design. If you have a big enough crew cabin to support 4 kerbals, then you must have the necessary tech to have a variety of storage cans to choose from. Moreover, if it's a crew cab with 4+, it's going to be a big ship, so there's no reason not to build on your own storage to the vessel of whatever size you need.

I'm still sitting on a new release that fixes an assortment of issues I've seen in my own playthrough. In my playthrough, I've now got Tier-3 on Mun, Tier-4 on Minmus, Tier-3 on Duna and Tier-1 on Gilly. At this point, I think there's a lot to like about the mod, particularly: The diet ratios for the tiers is good. Each tier has the right comfort level. The crew numbers are good - you have to have a whole lot of kerbals to make things work, and I think that's good. The Experience Requirements for generalists & specialists work out well. It's a challenge to rotate the right kerbals through your colonies. I had a goal of making it not very fiddly with the numbers, and I think I hit that. You wouldn't want to play this mod at the higher tiers without the built-in calculators, but I never feel a need to reach beyond that to do planning. There's also some stuff I'm not so happy with: The aforementioned parts -- the most critical being small containers for early-game. I also wish for them in my Crush-in scrounging ships. The built-in supply stashes in command modules really are sufficient, but this is KSP; excess is the watchword. It gets repetitive. I've got some ideas for that... The crew tab in the cupcake dialogs are hard to divine, particularly when you have a mix of specialists and generalists. I just am completely a blank on how to present the data more clearly. The density of the "Shinies" resource might be too high. I find it very challenging to land SSTO's full of shinies. The watchword here is "might". I can't tell whether this is a bug or a feature. Maybe I just need to get better at designing heavy-lift SSTO's. So like I said, it gets repetitive. When you reach a new tier you need to float up a new base, a new rover, and haul resources to and from the old and new bases. At Tier1, it's not a big deal, the Tier-0 base is kinda hardscrabble anyway. At tier-3, I'm strarting to get bothered because the Tier-2 base was decent, but at Tier-4, my only solace is that this is the last time. I've got two ideas: Imagine that you just made Tier4 on Duna! Yay! For the next launch window, instead of launching a whole new base, you build a cargo craft that houses a bunch of Retro-Kit parts that are configured for "Duna T3->T4". You fly that out to Duna and, once you land it close to your base, you click a button somewhere and the retro-kits get consumed and your parts are now Tier 4. Of course we'd sure want to ensure we had qualified Kerbals to do the upgrades, and maybe it should take some time to get it done. I'd also like to skip a tier if you've already done this thing before. In particular, I'd want to skip Tier-1, which is the most boring tier if you've already been through the motions. My thought is that if you have already got a Tier-4 somewhere and a Tier-2 somewhere else, that'd just flip a bit so that Tier-0 breakthroughs take you straight to Tier-2.

Totally agree with the need for this - I'll have a look at your patch. I've got it as a high priority to learn how to make parts.

I spent my dev-time this week mainly on creating a walk-through -- a guide to playing the mod from T0 to T4. I'm a bit torn on how best to deliver help in KSP: Mods are inherently community-driven, IMO, the help should be especially so. Having documentation that's easy to contribute to, and yet still curated, seems to me essential. I personally don't mind leaving the game to read game rules & such. In fact I rather prefer it. An on-line help system is vulnerable to outages. (E.g. GitHub blocked my account twice while developing this thing because I think it was the clusters of image downloads and thought the images were being used in a spam campaign.) MechJeb doesn't do a KSPedia entry at all; USI does a really nice KSPedia page, but honestly, I'm often left wondering which documentation I should believe when there are two sources. At this point, I've got two ideas: Find a way to generate the KSPedia entry from the wiki. Have a KSPedia entry that points to the wiki page Opinions?

Anybody know how to inject code into the "Recover Vessel" scenario? I want to give some extra prestige rewards for certain cargos.

I haven't tried it, but I think the answer is going to be 'no'. When I've used this mod in the past it's been in conjunction with USI, and, at least in that mode, it required "Material Kits", which were part of the USI production chain.

Just updating the thread today - I've been keeping a pretty steady pace of releases at once a week, but this week I'm not going to make one. I've been fixing things around the edges for the past couple of weeks, but I hit up against a clump of issues that required attacking some of the older chunks of code that I had written before I really understood configuration nodes and what they were all about. Anyway, it's a pretty widespread but valuable refactor, and I haven't given it enough play-time to be confident that it's really right. In my own play-through, I only just now got a full Tier4 base up (on Minmus): So yeah, 17 Kerbals, 8 of them specialized in rocket part production, and not really any to spare among the other 9, and they're pumping out 30 rocket parts/day. The whole base was, I think, somewhere around 60k parts. So if the Kerbals here wanted to replicate the base, they'd be at it for 5 years. I'm not entirely sure if that's a bad number or not yet; my thought is that maybe I'll double the productivity/kerbal of the rocket part producers. Building all this made it clear that the dialogs need to get better in order to support bigger bases, so that's where I've been at.

I'm writing a mod that replaces EPL's production chain... Or maybe can replace it. Honestly, I'm not really sure what people will want. My mod requires a whole lot of kerbals to produce rocket parts and lots of production infrastructure to keep the kerbals all fed & such, but no infrastructure like you see with EPL, where you have to math out all the production chains and heat and whatnot, which, if you do all your math right and apply sufficient hardware to the problem, allows you to generate rocket parts quickly. I figure that some folks, particularly those who've been using EPL for a long time and have a good grip on the math would prefer EPL's production chain, but other folks, who maybe find my mod's simple production chain and requirement for a big, balanced non-automated base more compelling will prefer mine. Right now, I effectively support both because I left the recipe for building rockets with RocketParts as the main ingredient. (My production chain ends in RocketParts too). Right now, I lose either way: My core constituency are annoyed and confused because of all the "useless" EPL production parts EPL adherents are happy to have their old friend around, but maybe a little confused that there are two ways of achieving the same ends I'd really rather give users a choice - either they get one way or the other. But, since this involves parts getting deleted, this is a tricky thing to make into a setting. What to do? Just carry on like it is and document the feature away? Maybe instead of deleting offending the parts, I could shunt them into a "EL Legacy Production" category in the Editor? Let the presence or absence of a mod be the decider (e.g. if SimpleProduction is present, then let that nuke the EL production parts?) None of those answers seem really satisfying. Right now my leaning is towards 2, especially given SimpleProduction is not maintained (or at least it's last KSP version listed in CKAN is 1.3.1...)

In my mod, I've got cases where I want to consume and create resources. I've been using ResourceConverter.ProcessRecipe, but I believe that may not be the right API because (I'm pretty sure), it runs into trouble if the resources involved in the recipe are located in different stages. E.g. LF in a tank in the booster stage, ore in an orbital stage (just for example). I got my example from USI-LS, which uses this api for snack consumption. It does something vastly different for production (and it's hard to unwind from local logistics). Anybody know a better API (or a better way to call it) so that I don't have this trouble? Or examples of mods that do this kind of thing and aren't broken in this way would be good too.

Sigh. Spoke too soon. ModuleManager is still awesome, of course, but after I fixed it so the rules get executed in the correct order (verified in the log), the modules and resource I deleted are still showing up in the VAB. @PART[KKAOSS_Workshop]:NEEDS[ExtraplanetaryLaunchpads&PlanetaryBaseInc]:AFTER[PlanetarySurfaceStructures] { -MODULE[ELWorkshop] -MODULE[ELConverter] -RESOURCE[RocketParts] (Tried ! instead of - too, just for good measure, but no joy). Derp: !MODULE[ELWorkshop] is bad !MODULE[ELWorkshop] {} is good. Shame about not getting an error message, but I could have read the examples more carefully too...

@blowfish Ah, took me a sec to internalize that, but yeah, I get it. ModuleManager is so awesome.

I'm trying to figure out what I'm doing wrong in... What I'm trying to do is a little ticklish, but from what I read, it should work. So, PlanetaryBaseInc defines a Workshop part that only exists with ExtraplanetaryLaunchpads. In the PBI config, it adds some EPL stuff to the part: https://github.com/Nils277/KerbalPlanetaryBaseSystems/blob/771ef186b701cdef782ff69597e0b1d04f32ed37/FOR_RELEASE/GameData/PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg#L102 But I want to use my own mod's production chain instead. So I wrote this, which should the modules laid down by PlanetaryBaseInc. Seems to me like a :AFTER clause should ensure it all works... https://github.com/SteveBenz/ProgressiveColonizationSystem/blob/8c8828417a6d85d636fee5e06a09d57e19be90bd/src/ProgressiveColonizationSystem/GameData/ProgressiveColonizationSystem/KKAOS.cfg#L36 But it doesn't. And when I look at the logs, I see: [LOG 2019-04-09 21:49:26.673] :AFTER[PLANETARYBASEINC] pass [LOG 2019-04-09 21:49:26.673] Applying update ProgressiveColonizationSystem/KKAOS/@PART[KKAOSS_Workshop]:NEEDS[ExtraplanetaryLaunchpads&PlanetaryBaseInc]:AFTER[PlanetaryBaseInc] to PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg/PART [LOG 2019-04-09 21:49:26.673] :BEFORE[PLANETARYSURFACESTRUCTURES] pass ... [LOG 2019-04-09 21:49:26.748] Applying update PlanetaryBaseInc/ModSupport/Configs/KIS/KPBS_MM_KIS/@PART[KKAOSS_Battery_Tank,KKAOSS_Fuelcell_Tank,KKAOSS_Liquid_Fuel_Tank,KKAOSS_Small_Ore_Tank,KKAOSS_RCS_Tank,KKAOSS_small_Rocket_Fuel_Tank,KKAOSS_ScienceJr_Tank,KKAOSS_Xenon_Tank]:FOR[PlanetarySurfaceStructures]:NEEDS[KIS] to PlanetaryBaseInc/ContainerSystem/tank_xenon.cfg/PART [LOG 2019-04-09 21:49:27.053] Applying update PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop/@PART[KKAOSS_Workshop]:FOR[PlanetarySurfaceStructures]:NEEDS[Launchpad] to PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg/PART [LOG 2019-04-09 21:49:27.053] Applying update PlanetaryBaseInc/ModSupport/Parts/KAS/gangway_flexible/@PART[KKAOSS_KAS_Flexible_Corridor]:FOR[PlanetarySurfaceStructures]:NEEDS[KIS] to PlanetaryBaseInc/ModSupport/Parts/KAS/gangway_flexible.cfg/PART ...In spite of the :AFTER, it ran my rules before the PBI rule. Can anybody give me a clue why?

I finally finished (mostly) the integration with Extraplanetary Launchpads. It needs a week of tire-kicking, plus K&K has an integration with EPL, and I want to tweak it to work with my mod. The whole effort was a good bit more than I had originally anticipated, but in hindsight, I should have seen it coming. The production pipeline as it was before was built only for tiered stuff, and this required a blending of tiered and untiered production. That percolated to a bunch of different spots (e.g. the resource transfer system needed to be updated to cope with it.) Resource Transfer was one of the things I was concerned about. I didn't want to implement a big GUI for doing inter-vessel resource transfer -- mainly because it's pretty obvious what to do and there's no need to make the player spell it out every single time. That's still something I believe, and, short of some niggling things with Tier-4 Snacks, I think it works. I'm also coming to a grudging acceptance that the research model is okay. But I do think that Scanning research requirements need to be nerfed or dropped. Right now that's the long-pole for all tiers, and it's also the one that you can't force to go faster in a way that makes sense. Finally, I've decided to make manufacturing rocket parts really labor-intensive. The way I have the numbers hashed out right now, one kerbal (Mechanic/Engineer) makes 2.5 parts per day. That's in stark contrast to EPL, where an engineer can assemble a craft with ~100 parts in a day. I'm happy with the net-result, even if it is a bit wonky. It flat out requires a big base. It also is something you can put off until later - that is build your base up to Tier2 in everything but off-world construction, then make a giant Tier3 base that starts at Tier0 Off-World Construction. Thing is, once you finish Tier0 research, you can use the parts you crafted to build Tier1 rocket-construction parts and just carry right on until you catch up with the rest of your production chain. So, I'm going to kick the tires in my own playthrough this week with every expectation that I'll release it next. I'm confident because right now it appears to be only slightly wonky. And one thing you can say about KSP and mods, if you get it to only slightly wonky, you're actually doing alright... And with EPL-integration done, that wraps up my personal list of key features. After that, my next target is help & documentation. If there are any YouTubers out there that would be keen to make a video that explains how this Mod works, I'd be very happy to chat about it.

As to the unfortunate Kerbal - well, I'm afraid I'd call that by design. A Mun voyage is supposed to be a 1-day affair, and this one appears to have strung out past 9 (the 2 or 3 days on-board and the 7 days of foraging). Sorry about that! But this is a life-support mod, and it does add a new way to screw things up, and, given it's your first go at it, well, that's how it often happens. Or at least it does for me. I suggest you watch a few ShadowZone videos (https://www.youtube.com/channel/UCkKhZJXIx7YkHnpLXxUjYsQ). And after you get the claw-part unlocked, you can go mount a rescue. I agree with you that there needs to be a tank earlier in the tech tree. I didn't notice it before, but the smallest configurable B9 tank is all the way up at "Fuel Systems". I'll see about starting a pull request in the B9 mod to get the smallest tank bumped up from 'Fuel Systems' to 'General Rocketry'. I'd also like to find the time to learn enough about creating the art to create a simple cylindrical tank that could be used for early missions. Fertilizer takes a *long* time to go through at the early tiers. 100 units of fertilizer will last for quite a while. 500 is (as I recall) enough to progress you to Tier-1. I agree that all the different tiers of stuff makes the UI for changing tank types pretty awful. My plan is that once I get the thing to basically function in all ways, I'll get after some stuff like that. However, you might not have noticed that the B9-tank types are configurable in-flight. Also, it's intended that you might do something like create a Tier-2 base on the surface of a body, and then truck the snacks up to a station in orbit, so your kerbals will consume a mix of agroponics, Tier2 farmed snacks from the surface, and Tier-4 snacks from Kerban. So having different working tiers on a station at once is within the realm of reality. And you really don't need a huge variety of tanks. The bases and such in my playthroughs generally have around 4 tanks, for fertilizer, snacks, and shinies. Also, it's assumed in this that a Tier-1 base is effectively made obsolete by the advent of tier-2 equipment. It doesn't have to be so, if you don't want it, but I think most players are happy to send up new ships. Particularly given that advancing to a new tier is usually a long-term affair. My own playthrough is sitting at T3 on Minmus, T2 on the Mun, T1 on Duna (waiting for T2 parts) and T1 on Gilly (with a much-anticipated launch to Dres in the offing). I appreciate the candid feedback! I hope you'll keep persevering!