AtomicRocketBooster

There are some newer patches for USI and the NF Suite here (Reactor Pack) and here (MKS) that have been floating around. (I wrote that second one) Which makes me think - these should probably be a PR to one of these repos. This question comes up a lot.

Yep, so I did exactly that (and checked the cache to make sure things went through): but when the game starts up, two things happen: The message on startup says "Colliders Enabled: False" (This message appears before MM even runs) None of the colliders actually seem to collide in-game Hard-code edits seem to apply. This is leading me think that the collider settings are pulled before any patches get applied.

Question about enabling collisions: I tried using a MM patch instead of hard-coding the cfg, but it doesn't seem like the changes were actually applied - I think the cfg gets read before MM gets a chance to run. Has anyone else gotten the MM approach to work?

I think there still might be something busted with the CKAN metadata? Looks like it's claiming Parallax 2.0 conflicts with the two texture packs? I've tried refreshing the metadata a few times, uninstalling everything, and am not sure what's going on. Clearly this isn't impacting everyone. Edit: After refreshing for the 10th time it finally started working. Not sure what happened, but looks like we're good to go!

So after more experimentation, this still seems to be a problem. Landing autopilot seems to be able to handle engines mounted on robotics parts (usually - it still acts up sometimes) Maneuver Node autopilot seems to struggle - throttle control is totally wacky, oscillating from 0% to 100% constantly. You can work around it by using SmartASS node guidance and doing the burns manually, but there's definitely something broken.

Thanks for sharing. 2 questions: Can you create a ship with some harvesters/drils launch it, and share the logs after that point? Can you also share the ModuleManagerConfig Cache (Main Gamedata folder) and the ModuleManagerPatch.log (KSP/logs/Modulemanager) The logs you've shared indicate that the patches are being applied successfully, but there's probably something wrong with the Harvester Index field, which I'll be able to debug using the cache. It's likely some mod adding new modules to your harvesters and changing the ordering of the modules.

Just started playing around with the CommNet Throttling patch based on some things I was seeing in the debugger, and I'm seeing some really impressive performance increases - on the order of 10fps! I have a ton of relays and active ships - probably ~100. Are there any known issues with just enabling it by default, or are they just theoretical? I have yet to encounter any issues on my heavily modded install with an unpacked delay as high as 30s. I have to imagine that it's very rare that losing comms 30s later than you might have would have any measurable impact on gameplay - most comms issues would be when you're landing, messing around on the surface, or performing maneuvers while shielded by a celestial body, which all would usually take on the order of minutes

Has anyone gotten automated burns to work with engines mounted on robotic parts? For example, I used the breaking ground servos to create some stowable engines, and while manual burns work fine, any MJ automated ones (for example, landing autopilot or node execution) will only fire for <1s at a time. The behavior looks similar to what happens when you have engines that are off center and apply a large torque, but these engines are balanced and any torque is very small. Servos are locked and autostrutted - the engines aren't moving anywhere while engaged. Edit: So this seems to be working after a save/reload. Probably something like the thrust vectors not getting recalculated correctly until you reload the scene

Hello - I think I'm encountering a bug related to this mod where the Mission Control Contract limits don't get applied correctly. I have a L3 Mission Control, so contracts should be unlimited. However, on my save, which had limits when I was on the L1/L2 mission control, those same L2 limits are still being applied. When I remove CC, the limits are all removed (however, then I'm stuck with the boring Stock contracts!) I will try some other debug steps but has anyone experienced this issue before? Edit: Here are some logs Edit 2: Looks like CC adds in some limits in addition to the stock ones? If so, this doesn't appear to be documented anywhere.

In the KSC at least, there's already the giant Astronaut Complex right there - Infrastructure seems pretty built out already. For other biomes, I would probably expect it to be much cheaper, but still required in some capacity. What I did is just went into the save and added a bunch of habitation and life support points to the KSC biome. Haven't decided what to do to other Kerbin biomes - probably add a smaller number based on some hand-wavy estimates.

Hello - it doesn't appear the 1.4.1 release from November (which is mentioned in the Github Changelog) is flagged as a release within Github, and hasn't been pushed to SpaceDock/CKAN. Is that something you can do easily @maja? Can download straight from master, but that's always a bit risky - and also means most people who don't check github aren't seeing the newest fixes

I assume you downloaded the linked folder and saved them as .cfg files in Gamedata? Do you see the patches getting applied in the ModuleManager log? Just share your module manager logs+cache.

Doesn't work how exactly? It works fine on my install so you'll have to be a bit more specific

Earlier in this thread, I posted a patch that works mechanically - however I haven't play tested it much (and actually haven't played much KSP at all recently) so the balance could be wonky. If you're interested in testing it, it could definitely use some eyes EDIT: Here's a link to the comment

One more thing I've identified: Deuterium (not LqdDeuterium) is used in a couple of minor processes (Water splitter and Deuterium freezer) but I can't find storage for this resource anywhere.

Hello - were the freezers removed at some point? I'm digging through, and for the life of me can't find them anywhere. Without the freezers, it'd be a lot simpler to just convert all the gaseous outputs to Liquified ones. (e.g. Hydrogen > LqdHydrogen)

So, after a ton of tweaking, I have a collection of USI-System Heat compatibility patches that are somewhat balanced. Swap Options, etc, all work as expected. I've been playing with it for a bit, and things seem to be working as expected Obviously, this would be game-breaking to anyone who already has extensive USI infrastructure built out. Should I submit these as a PR to System Heat, or is the USI repo the place for these to live?

Ok so I have functional patches for USI+System Heat - they're pre-Alpha but would love some feedback. They cover: MKS_Processor125 (1.25m MPU) MKS_Processor250 (2.5m MPU) MKS_Processor375 (3.75m MPU) MKS_Drill_01 (Small drill) MKS_Drill_01A (Small automated drill) MKS_Drill_02 (Medium drill) MKS_Drill_02A (Medium automated drill) MKS_Drill_03 (Large drill) MKS_Drill_03A (Large automated drill) Duna_PDU (Duna-class PDU w/ integrated reactor) Tundra_PDU (Tundra-class PDU w/ integrated reactor) I explicitly did not cover the USI reactors - they're all base resource converters and don't do any special USI stuff. There's no reason to use them over the existing System Heat fission reactors from NFE unless you just like the models better - in which case, you can write your own patch. You should be able to just patch in a SystemHeatFissionReactor module - no need for the special connector. However The heat outputs for these are totally wonky. The PDUs and drills need what feels like a ton of radiators, while the MPUs need barely any. How should I balance those heat outputs? Some ideas: Come up with some "heat output/ton" balance Calibrate it such that they need the same radiator mass as before (would need a lot more testing) Something else? @Nertea How do you balance the other converter/reactor/harvester modules?

In reference to the USI patch: I've been noodling with the BaseConverterAdapter bit and have cobbled together a (very lightly tested) MM Patch for the 1.25, 2.5, and 3.75m Material Processing Units: @PART[MKS_Processor*]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries] { !MODULE[ModuleCoreHeat] {} MODULE { name = ModuleSystemHeat // Cubic metres // Sets volume to be equivalent to fully loaded mass+machinery volume = #$../RESOURCE[Machinery]/maxAmount$ @volume *= #$@RESOURCE_DEFINITION[Machinery]/density$ @volume += #$/mass$ moduleID = isru iconName = Icon_Gears } !MODULE[ModuleOverheatDisplay] {} @MODULE[USI_Converter] { !ThermalEfficiency {} !TemperatureModifier {} @GeneratesHeat = false } MODULE { name = ModuleSystemHeatBaseConverterAdapter systemHeatModuleID = isru // The shutdown temperature of the part shutdownTemperature = 800 // The temperature the system contributes to loops systemOutletTemperature = 500 // Heat generation (kW) systemPower = #$../MODULE[USI_ConverterSwapOption]/INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]/Ratio$ //set the heat ouput as proportional to the EC usage/Ore. @systemPower *= .9 //lets assume 90% of EC usage turns into heat. moduleID = baseConverter } } @PART[MKS_Processor250]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries] { @MODULE[ModuleSystemHeatBaseConverterAdapter] { converterModuleIndex = 6 } @MODULE[USI_Converter],1 { !ThermalEfficiency {} !TemperatureModifier {} @GeneratesHeat = false } +MODULE[ModuleSystemHeatBaseConverterAdapter],0 { @converterModuleIndex = 7 @moduleID = baseConverter2 } } @PART[MKS_Processor375]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries] { @MODULE[ModuleSystemHeatBaseConverterAdapter] { converterModuleIndex = 7 } +MODULE[ModuleSystemHeatBaseConverterAdapter],0 { @converterModuleIndex = 8 @moduleID = baseConverter2 } @MODULE[USI_Converter],1 { !ThermalEfficiency {} !TemperatureModifier {} @GeneratesHeat = false } +MODULE[ModuleSystemHeatBaseConverterAdapter],0 { @converterModuleIndex = 9 @moduleID = baseConverter3 } @MODULE[USI_Converter],2 { !ThermalEfficiency {} !TemperatureModifier {} @GeneratesHeat = false } } Seems to work as expected in basic usage - haven't dug into any of the efficiency calcs at all, but the switches work decently well. Also haven't really considered balance at all. Feel free to play around with it and see what you think.

So I don't know if this has been mentioned elsewhere in the thread, but why do we have the CLSInterfaces.dll bundled in with this mod? It leads to conflicts and errors when used with CLS. Probably makes more sense to leave this out, no?

Noticed what I believe to be a minor bug: When this+cryo-tanks are installed, all the fuselage pieces update to have LH2 and/or Ox however the cargo bay pieces do not - still only have LF/LFO/MP options. Also might be nice to have LH2/Ox-only variants in addition to the LH2/Ox/MP variants. Pretty sure this is the file where it all happens

IVAs are a separate CKAN download

Is there a way to keep the warp heights/magnitudes from the base game and only get the improved physics warp? Wasn't able to find that option.

Love it! Glad this mod found a new home Is there a GitHub (or equivalent) link you can include in the OP? Makes things like bug reporting a lot easier.

So I really like the idea of @ProgorMatic's patch. As someone who both uses SSPX and USI and starts new games all the time, it's basically perfect for me. I think even if we go with the other one, a full refresh bringing everything into the same balance scheme is awesome - it could maybe live on as an extra or something? (Similar to the optional LFO patches) I think the main problem with ProgorMatic's patch, as I think about it more, is that anyone who's already using both USI and SSPX either can't update, or will see the life support and performance characteristics of their crafts in flight change dramatically. Maybe it's too conservative, but we're really late in the game maturity cycle for breaking changes. Maybe ProgorMatic's could be the default experience, with an optional patch if you need backwards compatibility? The total overhaul patch is just too good to not release in some way, but compatibility is also important and we're so late in the game, you have to give people the option to stick with the existing system.