jd284

It mostly plays nice, but reduces the masses of the various modules, including some hubs and such with crew capacity, thinking they're crew pods. So that changes the balance a bit, but nothing game breaking. It just makes you wonder why some things are way heavier than others until you realize this is what's going on. Other than reducing the dry mass, it doesn't interact with USI parts at all so there's no potential for other problems. SMURFF is just an MM patch, after all.

It's one of the reasons I went with RSS+SMURFF instead of RO, plus a few handpicked mods from RO. IHMO RO is just trying to do too much at once, and KSP not really suitable for too much realism due to bugs.

It's in USILifeSupport.dll as part of ModuleLifeSupportExtender.

Presumably it was @RoverDude's choice not to do it like that, especially since the demo charge gives you the choice of either 50% Materialkits or 50% recyclables. Getting both at the same time would mean you'd have a 100% recycling rate, which nobody has achieved even on earth, let alone in space, so that'd be rather broken.

You lose even more mass with the alternative, when you just crash it into the surface instead... However rather than creating a new resource for useless junk, it's just not carried into the vessel and discarded. It's not that the "missing" mass is destroyed, though. It just doesn't become part of the vessel like the rest.

It would probably be a good idea to put that as a comment in the beginning of the file, since that's not at all obvious.

I finally tracked down a long-standing issue with KerbalEngineer locking up the game when a ground base is targeted with the rendezvous window open. Posted issue #126 about it. Somehow the intercept angle becomes infinity and this causes an infinite loop when trying to clamp it. I can offer to make a PR to fix it, but I'm not really sure which of the possible fixes would be best.

Are there any PDU transmitters that work without crew? If not, I think at least the microwave transmitter should work unmanned, for all the others I'd accept that you need crew to maintain the (virtual) cables.

The easiest way to debug this is to open the KSP.log file and look for lines with "Config(@PART[Tundra_Agriculture", in that line it tells you the MM cfg file that causes the modification.

Kerbal breeding program in the Colonization module.

That's small change compared to Roverdude's warp drive which you can get for the low low price of 25 million. After the first 25 million to unlock the part. Luckily you'll pretty much only need one, ever.

Yes, better habs are always good, to reach the 50y cap without spamming hundreds of modules. Another idea would of course be another tier of logistics, obviously orbital logistics comes to mind but maybe also ground transportation between remote bases, basically automating long-distance kerbal transfers. Not sure if that can even be done in KSP though

No, these bonuses apply only to the MKS greenhouse/agriculture parts. The Nom-o-matics have a flat 100% load regardless of crew or kolonization bonuses.

Yes, looks like it's fixed, thanks! Closing the ticket.

@RoverDude, since you asked for bug reports... I found another issue with catch-up. It seems during catch-up, the efficiency parts are not taken into account. I noticed this because my Organics depleted even though I have positive production, and since the last fix on logistics this isn't because I ran out of Substrate but another effect altogether. Normally my Tundra Ag Module has an Agriculture(S) load of 377.8%. During catch-up, the load drops to 289.58% (and so now the Organics production is negative). This 289.58% is the exact load I get when turning off my Ranger Ag efficiency part. So it seems the efficiency parts are not active during catch-up. Maybe the efficiency calculation also needs to run more often during catch-up. (Can't easily supply a savegame since I play RSS...)

At the moment there's no difference whatsoever, the cooling works the same on Moho as on Eeloo.

I think the problem is that you're trying to revive crew in the same ship that made them go crazy in the first place, so if they revived they'd just go crazy again from lack of hab. You probably need to improve the hab situation first before the Medbay can help. It works fine if you have people that went Tourist on an away mission, and can save them in a ship with better hab. Or if you dock a rescue vessel and improve the hab situation that way. Though personally I never actually used it on a spaceship; the effort of bringing a rescue ship is generally much, much greater than remote-controlling the vessel and sending it back home, or to a nearby base that has a medbay and plenty of hab.

It's not, there's an infinite loop in the code if a module has less than two bay configuration options. (Well I suppose you could add a placeholder configuration which does nothing, to workaround the bug using MM though.)

Build bigger warehouses. Your storage should cover 6 hours worth of production for each intermediate resource. Otherwise at least background production will not work correctly, and with even less storage larger timewarp is affected too, as you've found. No, not with a complete rewrite of the converter mechanics. It would also break many legitimate use cases of the current system. So just add more storage.

Oh yeah, I realized that, but somehow I thought multipliers stacked multiplicatively. Since they don't, the hab-quarters obviously benefits from an external multiplier a lot more than hab-commons.

Is there ever a reason to configure the Ranger hab to "Hab-Quarters"? It seems to me like that's always a worse choice, because the 16.8 months times the multiplier of 6.2 = 104 is already better than the 83.6 months of the quarters, even if you have no other multiplier parts, and if you do the multiplier is still always better. Seems like something isn't properly balanced, either the multiplier is too high or the quarters too low.

I don't think it being a root part or not, or the order, even matters. I've had my space station changed to "base" because I docked a lander with Konstruction cradles. I wish the game wouldn't change the vessel type at all after launch, there's just no good reason for it, and it's never changing it the right way either. (I made a ticket about that too.) Or at least never override something I changed manually.

Huh, so you did, but somehow neither online nor in cmdline client did the changes show up till now. In any case though, that version still works fine for me. Logistics works during converter catch-up and everything is well. Thanks!

Sorry I don't see any changes since an hour ago, did you push them?

Both commits throw an exception during OnAwake. Seems like maybe part.vessel is null there? EXC 22:02:48.868] NullReferenceException: Object reference not set to an instance of an object USITools.ModuleLogisticsConsumer.OnAwake () PartModule.Awake () UnityEngine.GameObject:SetActive(Boolean) ProtoPartSnapshot:Load(Vessel, Boolean) ProtoVessel:LoadObjects() Vessel:Load() Vessel:Update() BUT! If I move the initialization of lastCheck to FixedUpdate instead of OnAwake and use "vessel" directly instead of part.vessel, everything is fine! Logistics keep updating while the converters catch up, the container doesn't empty, and Bob is happy that we'll never again run out of coffee on the Moon. Thanks a lot for the quick fixes! I guess that means local logistics only work for parts with USI converters during catch-up though.