KSPrynk

@TaxiService, I think I've found a bug on ground station upgrades applying across saves. When I do the "free" upgrade of a ground station in a Sandbox save, it populates that upgrade across a previously existing Career mode save. The frequency assignments are not carrying over (which is good, otherwise one save would screw up the assignments of others). This anomaly does *not* carry over to a new Career mode save (one started after the last Sandbox ground station edits), but adding more upgrades in Sandbox will then apply to the newer Career save, but *not* the older one. Which makes me think it's a Persistence file pathname bug. I think it's applying the changes to the next opened save file. It does not get cleared out by uninstalling CNC, running without it, and re-installing a clean copy of CNC (which I guess is good, so every in-save upgrade paid for doesn't get lost after a CNC mod upgrade). I'm using KSP 1.12.2 x64 with MH 1.12.1 and BG 1.7.1 and CommNetConstellation_PatchedCommNetManager_26July2021. I've got plenty of other mods (but not RemoteTech), and I haven't yet tried uninstalling to go mod-by-mod looking for an outside cause. This should be fairly fast to replicate on any instance of KSP 1.12.2 with Expansions though. STEP 1: Start a new Career save. Check ground stations (none should be upgraded). STEP 2: Start a new Sandbox Save. Start upgrading a few ground stations. STEP 3: Go back and check previous Career save; see if Sandbox ground stations have now carried over. The simplest band-aid fix for this may be to have Sandbox mode always start with all ground stations fully upgraded, that way there are no upgrade modifications that can be applied to other save files. But the cleaner solution may be force it to use the correct full pathname of the save when it's doing the upgrade, if that's possible. I don't know if any of this applies to a Science mode save. EDIT 1: Lacking a fix, is there a way to edit the appropriate file or, better yet, have a "cheat" mode window to arbitrarily remove (or add) upgrades to a save?

@Grimmas, @benjee10, I've thrown some re-balancing of the USI-LS patch at the wall in the GitHub PR and wanted to see what sticks. Still a work-in-progress, but I was looking for a sanity check. If there's anyone more experienced in USI-LS patches, feel free to come by there and comment (or run with it....) I love the work put into these parts. That greenhouse....

Cool, that helped - I *think* I found the spreadsheet, via discussion here, from nearly four years ago. Next step - finding the spreadsheet tutorial video....

@DoktorKrogg, is there a USI "scaling-guide" for balancing habitation time and/or resource converters based on the size of a part? I'm trying to assist development of a USI patch for Benjee10's Planetside Exploration Technologies mod. I'm looking for something better than trying to linearly extrapolate MKS 2.5m and 3.75m Tundra series parts to the 1.875m and short 3.75m modules in PET.

@benjee10, @Grimmas, I confirmed an NRE/functional bug in the USI-LS patch that was submitted for PR #8 on GitHub. GH user sac-winged-bat noted that Resources, such as Machinery and Recyclables, were not included in the patch. I tried out his additions and they appear to make hab modules function correctly, without NRE spam. I think the Hydroponics module also has some bugs; it's not switching agriculture type Resources so, for instance, you can't feed it Fertilizer and Mulch to get Supplies. Both the long and short 1.875m habs have the same crew support and life support timer capacity, and need balancing, as I'm guessing all the habitable parts do. I thought @RoverDude had a tool/cheatsheet for how to consistently scale newly created USI-LS compatible parts, but I'm at a loss trying to find it in the USI-LS and MKS GH Wikis at the moment....

I think you're spot on; it's probably intentional, to be realistic. In theory, true bi-modal NTRs should have enough radiator capacity to handle a reactor in steady-state electricity generation power levels, and minimize (or perhaps eliminate) the need for propellant quenching. But I've read docs suggesting bi-modals make some engineering compromises for power generation that can limit max isp. Plus they're more complex, hence many NASA Mars mission designs stick with plain NTRs for thrust and solar panels for power. @intelliCom, the trick with radiators is to find the balance between cooling and wasting propellant for quench cooling. You don't want to go too crazy on radiators, because that then becomes more mass eating into your total dv budget. To minimize radiator needs, it helps to minimize the number of NTRs to be cooled. Real LH2 NTRs have relatively low thrust - not nearly as low as real ion engines - so if you have burn durations of a few minutes; a few seconds at mediocre isp shouldn't be a big deal. I think some NTR mission profiles have had split-burn orbital pumping, which can be plotted with Maneuver Node Splitter. Landing and taking off on a high-g planet may be problematic, but why are you spraying radioactive fuel rod spalling and neutrons all over my nice clean planet, while flying over my base? I haven't tried out any of the LOx augmented NTRs, to see what impact Oxidizer has on the cooling profiles. FYI, I also still haven't tried to see if there's any MJ-compatible automatic power control for use in pre-plotted manuever nodes....

Good question. I followed @lemon cup's directions (that was SO needed) and successfully conducted an NTR burn with an Eel and four YF-15 radiators. I was then trying it out with a MechJeb-controlled burn and realized I'd have to control reactor power ramp-up and ramp-down within a few seconds of the burn starting and finishing, respectfully, to avoid a core meltdown. I haven't tried out automatic control yet. Let us know what you learn! I'm liking this approach to propellant-based core cooling so far, but I need to check out other engines. P.S. - I also learned the hard way that updating to the latest System Heat (from 0.4.0 to 0.4.1) solved a lot of problems....

You're both talking to how real, non-bimodal NTRs are supposed to work. When there aren't a plethora of radiators, the brute force solution is to run propellant through the shutdown reactor. Many non-bimodal NTR mission profiles include a propellant fraction that's just for cooling. Unless propellant is being vented symmetrically, those same profiles probably also assume that useful thrusting is still happening during cool down (at rapidly degrading Isp). Unless you know exactly when to hit the shutdown button, you're either going to need another thruster to finish/correct the burn, or risk core damage, because you didn't finish cooling before the maneuver was finished. One approach could probably be like Spiff's proposal and add a cool down "flush" button that just consumes propellant - without thrusting - and can automatically and/or manually be turned off once safe temperatures are reached. LH2 tank propellant density is already a bit "gamed", so this arbitrary inefficiency would spice things up a little bit and encourage the use of radiators, while providing an escape option from the head-banging frustration of watching your core melt down in the middle of a mission. A more elegant solution would probably be a "cool down helper" indicator that predicts how much time would be needed to cool the reactor down to safe levels, so you could shut it down at the right moment, while still thrusting*. Even more elegant would be an "auto-shutdown in current maneuver node" toggle (MJ compatible, of course). Thinking out loud, I assume propellant turbo-pumps are optimized for max thrust under full reactor power, so propellant flow rate would likely be limited to that maximum - but Isp is going down with temperature, and if flow rate stays the same, thrust would also drop, right? So the maneuver burn would actually go a bit longer. A hypothetical "cool down helper" should probably account for that.... EDIT: * There probably should be a cut-off on thrusting availability once the reactor is below a certain temperature, so your Isp doesn't get horrific, and you're just dumping cold Hydrogen into space....

Alright, this is going to be a tough one: I've tried plain Stock 1.11.2, in a new career Save Game, with just FMRS, and with ToolbarControl, ClickThroughBlocker, SpaceTuxLibrary, RecoveryController, and StageRecovery. I threw in MJ and KER, just to do fast flight iterations. Not able to duplicate. I started with Stock contracts, then I added Contract Configurator. Still not able to duplicate. I threw the two Stock Expansions back in. THAT DID IT. Contracts got blanked out, after I did "Revert to Launch" while active in the *dropped* stage. I'm still tying to nail this down a bit further, but I took out Contract Configurator, StageRecovery, RecoveryController, and SpaceTuxLibrary, and it did NOT happen with the other mods installed (Expansions, FMRS, Toolbar, ClickThrough, MJ, and KER) . So I think I'm narrowing down to those previous four and the Expansions that don't like each other. More work to do.... EDIT: Ugh. I restored Contract Configurator, then removed it and restored the Stage Recovery trio. No joy. Then I put them all back and couldn't duplicate the problem. Which suggests there may be something with full-saves vs quick-saves before Reverting. I'm tapped out for now. But at least I ruled out a LOT of other mods....

@linuxgurugamer, I've just seen this behavior as well. It's also cleaning out all contracts (at least while using Contract Configurator), both active and archived, and MJ settings get reset. Steps to duplicate: 1) Build a Falcon 9-like rocket, with probe control on dropped stages. 2) Drop first stage (booster) before fuel runs out and complete flight with second stage (I do this all with MJ Ascent Guidance). 3) Once in orbit, use FMRS to jump and revert back to the dropped stage. 4) From the reverted, dropped, stage, use FMRS's "Revert To Launch" function. 5) Go and check your contracts. As far as I can tell, using FMRS Revert To Launch from the main mission (origin) stage, doesn't have this problem, either before jumping to the dropped stage or after coming back to the main. The way for me to recover was to re-load an earlier full save. I'm using KSP 1.11.2 x64 on Win 10, with both Squad expansions, ContractConfigurator 1.30.5, MJ 1042, and FMRS 1.2.9.1, ToolbarControl 0.1.9.4, ClickThroughBlocker 0.1.10.15, SpaceTuxLibrary 0.0.6, RecoveryController 0.0.4, and StageRecovery 1.9.5.1. I still need to do a completely clean install check on just Stock and FMRS, as my Falcon 9-like craft is using a bunch of NFT mods, but I never saw anything like this until I added FMRS and related mods today.

For anyone who knows their syntax, do these lines, in the new Waterfall effects for individual engines (looking at Waterfall Restock)... !EFFECTS {} !MODULE[EngineLightEffect] {} ...basically say, if you have the EngineLight mod, delete that module for that part, to give precedence to the new effect? And if so, does that mean leaving EngineLightRelit installed allows engine parts, like SRBs, KA NTRs, and NFP Ion Engines, or other third party engines to still use their EngineLight patches, without screwing up the Waterfall lighting effects for those that do have it? I tried the new Waterfall with and without EngineLightRelit, and nothing seems obviously broken. Likewise, without doing a side-by-side video recording, I can't tell if EngineLightRelit is adding or detracting from the engines with Waterfall light effects.

@Nertea, I don't know if this is a function of NFE or SystemHeat, but I'll post here since it came up as I was testing out SH 0.3.8, with all the Extras installed, NFE 1.2.1, and Heat Control 0.6.0 radiators: - I'm seeing my NFE reactors all default to Enabled upon launch (I haven't tried KA engines yet). This is problematic if radiators are not actually active at that time, because the cores destroy themselves within seconds. There's no Reactor Enable/Disable button in the PAW while in the VAB, only in flight, so I can't launch the reactor in a shut down state. I tried to set the Auto Shutdown Temp to a level lower than operating temp, but that didn't work. I've done this with various reactors on a Station Core with a giant stack of unfilled batteries (just to watch the Auto Power setting in action), with and without radiators attached, and with and without the radiators deployed/activated. - System Temperature doesn't change with power level. Assuming there's enough radiator capacity, it'll run to max nominal operating temp regardless of Power Setting. I'm trying to logic out the thermodynamics of this. Electricity production varies with Power Setting, as does the Core Life clock (although it's not actually extending the clock time, like it used to, at lower power settings, it's just counting down at at lower rate) and EnrU consumption as well. Presumably, if EnrU is getting burned at different rates, corresponding amounts of heat are getting dissipated somewhere in the chain - reactor, generator, electricity consuming part - which the radiators still have to deal with. But the radiators aren't showing any variation with reactor power either. - I've clicked the button and looked through the SH and NFE Wikis and I still can't figure it out - what does the reactor hibernation mode do?

@Exo's LabI'm looking forward to your next project, but I think MPE is a fantastic addition, to fill in what Stock and OPM were missing. While I was hoping for a Parallax texture pack to go with this, I'd say, from comments above, that many of us would appreciate whatever can be done to de-bug and continue maintenance for future KSP releases.

@CDSlice, I'm not seeing it. I'm using KSP 1.11.1 x64 on Win 10 with Restock and RestockPlus 1.3.1, Waterfall 0.5.0, and WaterfallRestock 0.2.0. Are you using all of the same? Note, there were some pretty significant changes within the last week, so you'll want to make sure everything is up to date (I don't use CKAN).

@Nertea, I think I found a visual bug in WaterfallRestock. One layer of the engine plume for the ReStocked LV-T45 Swivel, closest to the nozzle, is visible through spacecraft structures when the engines are surface attached, not node attached, to a part. The LV-T30 Reliant is not visible, as expected, but I haven't checked all other engines. I'm running KSP x64 Win 10 with Waterfall 0.5.0, WaterfallRestock 0.2.0, EngineLightRelit 1.6.3, and ReStock 1.3.1. I confirmed the problem is fixed when WaterfallRestock is removed. I have not verified if there's a similar problem with Stock Waterfall Effects by @Knight of St John. Craft to replicate (all ReStocked): 1x Mk 1 Cmd Pod, 1x S3-3600 tank, 2x LV-T45 surface attached to bottom. I dropped an Issue in the WaterfallRestock GitHub. EDIT for additional info: confirmed this also happens when attaching LV-T45 engines to multi-nodes on engine plates. BTW, the plume effects are beautiful. I love the Mach diamonds on the Methalox cryo engines.... EDIT 2: Removed Engine Light from the equation. Also, the effect is most visible in the dark, but other enviro or FX mods amplify the effect (haven't narrowed down which).