KSPrynk
-
Posts
244 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by KSPrynk
-
-
@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....
-
25 minutes ago, DoktorKrogg said:
There is whole spreadsheet for it in fact. I don't know the link off the top of my head but @RoverDude can probably get it for you (or it may have already been linked elsewhere in this thread). I seem to recall there was even a video explaining how to use the spreadsheet on YouTube or Twitch maybe...?
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....
-
4 hours ago, lemon cup said:
On the topic of reactor shutdown, I have not been using KA engines recently and noted their behavior, so I would have to do some testing just like you, and see what occurs. On the previous page you can see some other users discussing the matter; in a nut shell - real-world NTRs would also need a spool-down cooling cycle. So it could honestly be a feature of these KA engines that you should leave your engine running, throttle the reactor back down, and let the cryo propellant do most of the reactor cooling, before finally cutting both the reactor and engine throttle to 0...
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....
-
5 minutes ago, intelliCom said:
Thank you. The ISP and thrust being crummy is a little painful, but at least I can use them now. It makes sense as to why it does this, but it does seem like a lot to consider compared to other engines in stock and NF. Would it be safe to let the reactor sit on automatic control?
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....
-
6 hours ago, Nertea said:
Maybe the second use case does make sense if all you want to do is exhaust propellant for cooling.
6 hours ago, Spaceman.Spiff said:Maybe a “cool down” option could use some propellant in exchange for providing a temporary powerful cooling source.
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....
-
4 hours ago, KSPrynk said:
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.
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....
-
On 9/11/2020 at 2:58 AM, TomfooleryYT said:
Hey, I need some help. There's a constant bug I keep running into.
Whenever I use FMRS to recover stages, not every time, but very often, it's messing with the saves to where if I try to go back to the Space Center, it reloads back to a previous quicksave or FMRS save. the only way, I've found to get around it is to close the game and relaunch it, but this causes a significantly earlier save to load and I have to reload the most recent quicksave (which I do before I close the game) and got back to space center again.
I don't knwo if this is a known issue or if it's just something off about my install in particular. let me know if you guys need anything from me to help diagnose this problem. thank you!
@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?
-
2 hours ago, Exo's Lab said:
I am glad that people still enjoy this mod, even if it is quite rough around the edges, perhaps I should find someone to maintain it.
@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.
-
On 2/28/2021 at 11:48 PM, CDSlice said:
The Restock+ Pug plume seems to be rotated 90 degrees:
Also, the plume for the Restock+ Valiant looks to me like it is located too high on the model, it is coming from above the engine bell instead of from inside the engine bell.
Edit: The Restock Terrier has the same issue as the pug with the plume rotated 90 degrees. I have the latest versions of Restoc and Waterfall
@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).
-
1 minute ago, Spaceman.Spiff said:
Your old post and this one make some excellent points. It's a cool
(get it?) idea, but whether or not Nertea wants to spend the time making configs is the real deciding factor. It would be interesting to see though.
The config changes were pretty easy after I did the first one; just a matter of consistent parameter scaling, and I didn't care that they were the same models. To really make it clean, it would just be an additional fuel mode selection, and maybe some cost penalties and/or an additional tech level upgrade prerequisite (like NearFutureSolar). I was lazy and copy-pasted into a new, unique partname config which otherwise referenced everything the original config did. That's probably not Nertea's style though....
I wanted to do plume coloration, which should probably be something between LH2 and LF, and I was going to research Real Plume, but since then, we've had Waterfall and SystemHeat, neither of which I've researched the parameters on. Of the two, SystemHeat is the one I wonder about most, because mass flow rates change (I think - I scaled up thrust to inversely correspond with the drop in Isp, so it may cancel out), and I don't know if the reactor cares or the working assumption is that it's chugging out a fixed amount of waste heat kilowatts for a given power setting, regardless of propellant or how much is passing through. When SystemHeat finally went mainstream, I was curious if I could do reactor cooling by turning down the reactor power, but keeping the throttle open. That's open cycle cooling, which you need to do for NTR burns if you don't have radiators (which a bi-modal NTR would, for electrical power during transit coast). It doesn't seem that easy, so I'm resigning myself to making sure I have the minimum required amount of radiator capacity installed.
33 minutes ago, WarriorSabe said:Yes, none of this is new information to me. It's just not relevant because it defeats the entire purpose of the patch, which is to make KA not require Cryo Tanks
Yeah, it's just hard for me to suspend disbelief and think anyone would feed RP-1 into an NTR. That's practically rollin' coal....
-
5 hours ago, WarriorSabe said:
Yeah, but.. I think you're missing the point. I'm pretty sure the reason for the LF patch is so users don't need CryoTanks. I can see it for the ones that by default can take LF though, like the Nerv
Actually, Methane NTRs have come up before (see KA forum in April 2020), for the same reason Methalox is the Great New Thing in combustion rockets. As @Spaceman.Spiff points out, you have better performance than kerosene, but less than Hydrogen. It also runs cleaner then Kerosene, and doesn't freeze into solid goo after you've been in orbit for a while. It doesn't require much power to keep cryogenic, and you don't have individual H atoms making your tank walls brittle or diffusing all the way out to the other side. It's easy to source raw materials, since Carbon can be be found just about every place there's water, and you don't need a bunch of steps to create a complex hydrocarbon molecule, so ISRU is easy.
I think Nertea's noted before that he's using extremely dense values for LH2, on the order of slush, because many people have a hard time understanding why they need huge LH2 tanks. The mass of those low propellant density tanks, plus the mass for zero-boil off cooling and insulation, almost cancels out the performance gains of LH2, unless, like many launch vehicles, you're topping off right before launch and burning it before boil-off and tank embrittlement become a problem. That's fine for starting your trip, but trouble at your destination, months or years away. In KSP, my Hydrolox upper stages forego solar panels and eclipse shadow batteries, because I'm leaving active tank cooling turned off. But I need that mass overhead on my LH2 NTRs if I still want propellant for the trip home.
I've modded KA engines to run on LiquidMethane (changed the resource name and lowered Isp) and the resulting vehicle performance is outstanding. Perversely, not because of the engine performance, but because I could cram much more propellant mass into a fixed payload fairing volume. CoaDE has a whole section on how tank mass fractions ultimately cap your maximum delta v.
The big unknown for Methane NTRs is whether they'd deposit a reactor channel-clogging layer of Carbon soot during high temp CH4 decomposition. How all those molecules recombine depends on operating temp and pressure. If all you get is Methylene (CH2) and loose H2, you're probably golden. It may be you WANT some free Carbon, because some fuel rod designs are surrounded by graphite, which gets eaten away by free Hydrogen.
-
In reference to some earlier Kopernicus Stable vs BE vs Parallax excitement, which resulted in active craft having their solar panels closed, documented here:
...I have some additional details on my conversion of an active KSP 1.11.1 Save Game from Stable to BE during Parallax upgrade - my solar panel extension hot keys got erased. I tried out a previous craft file, after clearing the missing KopernicusSolarPanels module error, and the hot key assignment was gone. Easy enough to replace it, but it may explain why active craft wouldn't re-extend the panels with a hot key press.
EDIT: I should further clarify, these solar panels were edits of copies of current Stock/ReStock .cfgs, which I set to be non-tracking, in order to give myself some larger early-tech level panels. Except for a unique part name and changes in mass, cost, entry tech, and the aforementioned disabling of tracking ("isTracking = False"), they're the same. I didn't add or delete any modules that weren't there previously.Ignore that edit. I have another, later tech level, active craft with unmodified extendible panels that had the same issues.
-
5 hours ago, Gameslinx said:
Download the stable Kopernicus https://github.com/Kopernicus/Kopernicus/releases
@Gameslinx, @R-T-B, how tied at the hip are Parallax and KopernicusBE vs the relatively recent 19+ Stable versions? I had previously been using Parallax 1.2.0 with a Stable version of Kopernicus for KSP 1.11.1 (R.28). Then after I upgraded to Parallax 1.2.1, I got the dreaded "You've got a planet pack running and something's broke in Kopernicus, don't open your current Save Game" warning (I'm using OPM 2.2.9).
I resolved this by downloading KopernicusBE 19+R.80, but all my Save Game solar panels got borked, fortunately not lethally as far as I can tell. Craft files had a warning about a missing Kopernicus module (I just added an arbitrary part, then re-saved, which I assume forces a refresh the next time it loads), and all my active craft suddenly had their solar panels closed. My hot key wouldn't re-extend them, but I was able to do it manually, one panel at a time, in the PAW.
I read the BE commentary about the new KopernicusSolarPanel module, so I'm assuming my Save got dropped right into the thick of it. I guess my questions are:
1) Despite the Parallax pre-requisite/compatibility checks and warning, is Parallax intended to be good with Kopernicus Stable, or is Parallax needing something that stays in BE, and
2) If I reverted back to Stable again right now, would I end up shooting my Save Game in the foot until the KopernicusSolarPanel module conversion issue is settled?
2 hours ago, Gameslinx said:Press Alt + 3 (try Ctrl + Alt + 3 if Alt3 doesn't work) during flight to show the colliders that Parallax uses
Yes, I've used that previously. What was interesting was my earlier rover sometimes appeared to be floating even higher above the white collider cubes (possibly due to being in a near-constant state of bounce flight), and sometimes the cubes were significantly higher than the apparent terrain. Which made me wonder if something other than the wheels was interacting with the cubes. Using the DebugStuff visualizer, I also made a point of not letting the stowed Light Scanning Arm get too close to other objects.
-
1 hour ago, Jacke said:
But if things were right, even if you were colliding, you'd think it would cause a drag force, not an acceleration.
Yeah, that still has me scratching my head. The DebugStuff tool did show some interesting boundary boxes on some of the NFT parts I was using previously. I tried another "cleaner" rover design, and it behaves better.
-
@Jacke, thanks for the visualization utility info. Do you know if Parallax's terrain collider cubes interact with anything other than wheel and landing leg contact points? I try to build my rovers low to the ground, and I'm wondering if the cubes are hitting other components hanging underneath the rover, inside the suspension stroke height of the wheels.
-
29 minutes ago, KSPrynk said:
I'll see if I can just Alt-F12 the Stock rover to that location....
And I tried this in Sandbox mode and the Stock Rover/Skycrane at coord 5, -160 seems to be much less affected. I have a suspicion my custom rover has some model collision issues that I'm not seeing. I don't supposes there's a utility in the forums to visualize these, is there?
-
29 minutes ago, Jacke said:
Asking for what the devs will likely want.
Can you provide the logs (see the first link in my signature), the savegame(s), and the .craft file(s) required to recreate this? Also, a list of the actions you went through after landing the rover up to experiencing the strange motions. The logs will list all the mods, so with the savegame and the .craft(s), they should be able to see what happens themselves.
I think this is the sort of thorny context-sensitive bug that will need that sort of analysis to track it down.
I'll check to see if I've got a dropbox/FTP I can use. I've been using the free stuff, which is marginal at best for just log text files. My craft and save game may be problematic as I've got half the Near Future Tech suite installed for the rover, and dozens of others. It'll likely be faster for me to try again using the Stock Rover/Skycrane craft, which I think uses the same wheels (although I am using ReStock as well).
My initial landing was around 5 deg N, 160 deg W (per MJ and ScanSat coord), which is Lesser Flats. But that's where I first got into trouble. I'm currently parked on a hillside, wedged into an Olivine outcrop, to keep from sliding, in the Lowlands to the southwest of those coordinates. I'll see if I can just Alt-F12 the Stock rover to that location....
-
Can somebody try out Parallax with a rover on Minmus? I've got a small 6x6 using Rovemax S2s (0.2m suspension travel) and I'm getting kicked all over the Lesser Flats, gaining speed with every bounce. Even with brakes on, I eventually slide into something that tosses it into the air. I've added a RW and am using MJ to right myself when tossed hard enough, but settling into a static position seems to be a matter of luck.
More, interestingly, I'm able to climb a 20 deg slope without stepping on the gas. With the RW holding me upright, and my front wheels on the slope, I appear to be getting pushed uphill by the terrain.
I'm using KSP 1.11.1 x64 on Win 10 with Parallax 1.2.1 and KopernicusBE19+R80.
-
These models look great and also make me glad I recently upgraded to 64 GB of RAM (yikes). I've been looking forward to this for a long time. A few questions:
- Will each single-engine model have "compact" mount variants to pack more across a given tank/base diameter?
- Will there be a corresponding set of switchable variant and single port CH4/Ox RCS blocks in different thrust sizes, or a patch for existing Stock/ReStock RCS selections? The individual port configuration RCS blocks with integrated fuel cells in NFLV NearFutureMethalox seem overly complex for a compound-curvy KSP-ish Starship.
I haven't tried out any of the LOx augmented NTRs, to see what impact Oxidizer has on the cooling profiles.
(get it?) idea, but whether or not Nertea wants to spend the time making configs is the real deciding factor. It would be interesting to see though.
[1.11] CommNet Constellation v1.5.7 [10 January 2021] - Beta 4 of CNC+CNM for KSP 1.12.2!
in KSP1 Mod Releases
Posted · Edited by 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?