coredumpster

Following-up myself. Discovered that this hasn't been setup yet in the mod, so I have tested what's needed to enable this, and I have submitted a pull request to @Nertea's Dev branch. Fairly straightforward, just needs a block added to the .cfg file for each part. Here's the values I used for the volume ( taken from the Pull Req description ): Adding Cargo capabilities to Heat Control radiator parts. Modeled the volume values to align close to the Stock Radiator parts from a balance standpoint. As Heat Control parts are slightly smaller than the similar Stock sized parts, I took the 'packedVolume' from the closest sized Stock parts and reduced slightly for the HC parts. The larger parts I set the volume to -1, which enables manipulation by an Engineer in the field, but does not allow it to be stored in a Cargo Container ( IE, too big ). I left the micro-channel and surface mount-curved radiators alone for now, as my thoughts are those require specialized skills to install and should likely be limited to VAB. Fixed-1 Beta = 200L Fixed-2 Alpha = 75L Fixed-3 Gamma = -1 Fixed-4 Delta = -1 Conformal-1 = 100L Conformal-2 = 200L Conformal-3 = -1 Universal-1 = 75L ( I think this is a bit low, but is balanced with the Stock Small Radiator ) Universal-2 = 600L Universal-3 = -1

Is it possible to manipulate any of these radiators in 'Engineer Mode'? Are there limits on Engineer level ( like Level 5 needed to repair reactors with Repair Kits )? I have some radiators that I'm trying to move / add to a craft and can't seem to get the Radiators to be moveable. Have tried the XR-175, XR-500, Beta Fin, Alpha Fin. Added extra Kerbals nearby, and still no go. Can move around ISRUs, drills, engines, and other really heavy things, so shouldn't be a weight limit afaict.

Update: Something was borked with my System Heat install. Nuked it from orbit ( or at least from my GameData folder ), and re-installed a fresh downloaded copy, and it's all working as expected. I have loops, I have heat generators, I no longer have explody kraken vessels. Not sure exactly what went wrong where, but a re-install of the SH mod seems to have corrected whatever it was. ----- Original Message for Posterity ----- Looking for some help on where to begin trying to debug why I'm only seeing a portion of System Heat. KSP 1.12.3 w/ JNSQ + RationalResources plus lots of part packs like all of the Restock, Near Future, Far Future families, plus Planetary Base systems. No Life Support mods anywhere, just parts and helpers ( Engineer, MJ ). I'm seeing the System Heat entries on the radiator parts and the NF radiators, but I do not see System Heat entries on any of the heat generators ( Reactors, ISRUs, Drills, Nuke Engines, etc. ). I get the system heat UI which will show me loops, but in the VAB they are all 0's, no matter what I add. I have SH loop ids in the PAW for radiators, but again, not on any of the heat generators. I have some custom patches to add the RationalResource conversion chains to the PBS drills and ISRU, but even if that is hosing up those, it doesn't touch engines or reactors, which likewise seem to be impacted/missing the System Heat entries. I have combed through the logfiles, and nothing is jumping out as a red flag to me, so looking for pointers if anyone else has encountered this, and whether anyone is successfully using System Heat with JNSQ + RR in 1.12.3.

Update: Something was borked with my System Heat install. Nuked it from orbit ( or at least from my GameData folder ), and re-installed a fresh downloaded copy, and it's all working as expected. I have loops, I have heat generators, I no longer have explody kraken vessels. Not sure exactly what went wrong where, but a re-install of the SH mod seems to have corrected whatever it was. ----- Original Message for Posterity ----- I think I have a potential mod conflict, and not sure where/what might be causing it. Can't find anything that jumps out from the logs. I have a 1.12.3 install, with JNSQ and RR installed, along with a lot of the usual part packs ( Near Future, Far Future, Planetary Bases, etc. ). I do not have any life support mods installed. I'm trying to use Nertea's System Heat ( now part of the NF/FF family ), but I'm not seeing *any* heat output / system on things that generate heat ( engines, converters, reactors ). I do see the expected System Heat entries on the radiator parts in the VAB. I have the system heat menu that comes up, and I see the system heat menus, but all of my "loops" are showing zero input, zero rejection, no matter what I do. Is anyone else using System Heat successfully with JNSQ + RR? I've reached the stage of my career playthrough where I start using ISRUs to explore deeper into the Kerbol system, and my first drilling platform just exploded due to a weird overheating interaction ( taking out two of my Kerbals ).

That's outstanding news! Ars Technica had a detailed performance review comparing M1 Rosetta2 performance and it sounded quite promising, with single thread performance ( key for KSP ) under Rosetta2 outperforming Intel based Macs. Thank you for being a guinea pig in true Kerbal fashion.

Similar question. I play KSP on a Late 2012 Mac Mini, and it's reaching the limits of what I can deliver ( have already upgraded it to 16GB RAM and SSD, which extended life quite a bit ). My main concern with the new M1 is that it's hardwired at 16GB.

Yeah, it's not a huge ordeal, as I've played without it for this long, and everything else is awesome. I was holding off upgrading until 1.10.x stabilizes a bit more, and I'm almost done with my end-game play-out on 1.8.1 ( first end-game playthrough on JSNQ ). I just need to crack Eve. I've got a vessel that can make it back to orbit from near sea level. My problem is keeping the vessel from burning up on entry! Eve atmo and orbital speeds are tough in JNSQ.

I'm playing 1.8.1 on a Mac. Installed this patch, as the patchwork quilt look bugged me a bit. ( It's only aesthetics, but that's part of the JNSQ appeal beyond the re-scale ) I'm seeing a *massive* impact on performance though. Game loads, but is massively slow to the point of unusability. Entering the Tracking Station the planets are very dark in apperance, and any attempt at zoom in or out, results in the dreaded 'spinning beach ball'. Nothing jumps out in the log, just the usual scene transition messages I'm used to seeing. It appears to be due to memory, as the process rapidly consumes all memory until it starts thrashing. I have 16G of RAM, which has been sufficient to play KSP ( I quit everything else, so KSP and a terminal window are the only things running ). Does this patch potentially drive different memory behavior of caching textures that would result in this increase? Or drive the use of different shaders? Removing the patch restores playability for me.

I was never able to get it working consistently with higher warps, so I ended up disabling many of the snacks penalties due to the issues, which then kind of defeated the purpose ( for me ), and I eventually removed the Snacks! mod when I moved on to playing JNSQ for a different challenge. For my end-game playout, I usually have a permanent station/base in Duna system, with a pair of cyclers moving cargo and personnel back and forth to Kerbin, and a couple of long-duration deep-space exploration ships/landers headed out to the far reaches of the system ( with either OPM or JNSQ making that even further ). So not being able to use high warps and having to keep jumping between vessels to restart processing becomes a big pain. At some point I'll likely give it a go again, but not until there's better handling of the resource processing at warp / background. That's long been a challenge for most life support-type mods.

I use it. It's helpful for managing reactors on larger craft ( stations ) with multiple reactors. Also, I use it for adjusting reactors on some of my long lived probes to dial-up / dial-down reactor performance to improve lifespan of the probe when spending long years in transit between outer planets in OPM / JNSQ. If it was incorporated into the Electrical/Heat panel, that would be a fine place for it, but IMO, it provides more detailed info than the PAWs. -C

I've seen this happen with crew tubes and surface attachable parts ( like radial adapters to add docking ports ). Solution I've found is to use the multi-node connectors, or if design can't use the multi-node connector ( or it's not yet unlocked in tech tree ), then I use the setting to temporarily allow unrestricted transfers to bypass the issue.

Usually that happens when you surface attach something to another part ( or have parts surface attached that don't both have allowed surface attachement CLS options ). What happens if you rebuild that with a multi-node connector in place of the crew tube with surface attached parts?

It will work, it will just run a little bit slower. Memory is probably the most important of these. I play JNSQ on a computer that is slower than the specs, but I do have 16GB of RAM.

Do you still have a leftover MM patch in your config folder that got carried over from 1.7.x? There was a Kopernicus performance bug in 1.7.x that was addressed by gimicking oceans onto Minmus, but placing them below groundlevel so they weren't actually visible. Intended for Stock inner + OPM. Maybe it's playing havoc with the JNSQ retextured Minmus?

I have as well ( outside of JNSQ ). I've fixed it by increasing the buffer factor that NFE / Dynamic Battery Storage uses to pad for high levels of warp. Default is 1.5, I've increased it to 2.0 and that seems to work better ( though I've not unlocked Nukes yet in my current JNSQ career ). I missed that update as well with my JNSQ install. ( I really should put that in a MM patch... ) Also, I did indeed have the Blacksmith RR patch applied, removed that and back to "normal" MPL. Thanks all! Happy I Don't Know Whating, -Chris