OOZ662

Looking at how MM_AddResources.cfg works and the way Paul implemented the human consumption rates, I assume that even when I get it working the pods will only contain supplies for 1/4 their intended endurance, but I really don't feel like hand-editing 360 entries...

TAC isn't adding resources to my command parts even though the mod appears to be installed correctly, including Module Manager and the configs from TAC. I have no idea where to start as the log file is too large for my brain to handle. Note that I deleted TacLifeSupportRecyclers before this startup, so that may be in there. Even though I have zero Module Manager experience, this bit in the MM config for adding resources to pods caught my eye: NEEDS[!modularFuelTanks&!RealFuels] Does TAC require Real Fuels? I use MFT already but would rather not use RF and the OP only mentions Module Manager as a dependency.

Module Manager 2.3.3, right out of the US ZIP.

I know I ought to be asking in the TAC thread, but...I like it here... I installed only TacLifeSupport and TacLifeSupportRecyclers as discussed earlier, but I notice in the VAB and SPH that none of the pods (except a certain few from mods that are designed for TAC) contain any resources besides electricity and monoprop. I assume this will result in the quick death of my Kerbals during a trip in my station ferry plane. Is there an easy way to remedy this through MM, or perhaps a specific file I'm missing? I'm using the human resource consumption rates as well.

It'd be nice to have a quick reference for how many Kerbals each generator can support for those of us terrible at math as well.

So, could one only install the "TacLifeSupport" folder of TAC (i.e. NOT -Containers, -HexCans, -MFT, and -Recyclers) plus the US TAC Pack to get a working setup? The parts that come with TAC are fugly and I never see myself using them unless they fulfill a role US doesn't, so I'd rather not have them eating RAM.

Human rates seems fine with me, but if people want to use other independent TACLS parts or modules they're probably going to imbalance or conflict, so at least having a config available to compatible-ize US with other TACLS systems would be a good idea.

And, as I recall, the red lights are "up."

I have a pretty terrible computer, and these parts always seem to murder my gameplay as soon as they're put to use (generally through FPS issues but also kicking me over the 32bit RAM in use limit), which is unfortunate since I lack the creativity to build a station out of stock parts and there doesn't seem to be other sorts of things like this mod available. I have noticed, though, that even with Active Texture Management, my launcher rocket looks absolutely horrid texture-wise from setting it to quarter texture sizes, yet the FusTek parts sitting on top look pristine and perfect as if ATM isn't affecting them. Am I missing something here? Do I need a config file specifically for FusTek? If so, I'll definitely need help with it as I can't really get my head around ATM's config file structure. I figured I'd ask here first since other mods seem to be compressing down fine; I'd like to figure out why FusTek might be an outlier before going to the ATM thread, if I need to.

Mine have never not retracted when finished transmitting science.

If you go to the web search of that image search, it leads you to a Wiki article explaining their function.

I'm really kinda surprised there isn't a huge red link to the dev thread for TAC news at the top of the OP. Might at least reduce the number of people asking.

You missed it by four posts.

I believe the decision is based on having a lower number of unique parts in the mod rather than the difficulty of creating them.

The "issue" with FAR is that it currently doesn't see the containers as being sealed/closed in due to the way the models used to have to be made. Apparently that's changing soon.

I must admit it is great fun having to completely rebuild a vessel essentially every time I add a mod. Except minus the fun. It doesn't help that ModAdmin constantly deletes my module manager dll as well, but that's just me not learning to use it right, I guess.

This is something I struggled with for a long time in stock KSP with the docking clamp. I don't know how it works out for radial-ish things like US wedges, but the easiest way to see it is to just make a basic rocket and look directly into the node as you try to add something to the stack; it's won't snap together, just wander around the surface. If you rotate your view toward looking perpendicularly to the node, they'll pop right together. Long story short, try jangling your camera about.

I noticed that stock air intakes can only be "toggled" via action groups, not specifically opened and closed. So for instance, in a non-RAPIER space plane... Group 1: Jet engines on, rocket engines off, toggle intakes Group 2: Jet engines off, rockets on, toggle intakes By default, you close your intakes if you use the 1 key instead of staging to start your engines. If anything goes wonky in the flight and you end up using an action group in an improper order, you'll toggle the intakes improperly. Easily "fixed" by simply leaving the intakes open forever, but...yanno...

Do the animations work? i.e. do the docking ports rotate when their mode is switched, do the warehouse doors open? If not, it's likely an issue with your Firespitter plugin (or lack thereof).

You're probably hitting the RAM ceiling.

CLS-4-lyf (This message is more than 10 characters now.)

Here's the details...

If you have a look at the dev's blog, you'll see that the system is balanced to put realistic masses into the volume of the tanks at realistic pressures.

I've seen that in a lot of parts mods and have started taking it for granted.

KSP is a 32bit (apparently large address aware) application and thus tops out at 4gb usable RAM space.