SpacedInvader

Just in case anyone else ends up with the same issue and lands here, this appears to be an issue with KRASH where after a simulation session, it fails to reset the ability to quicksave and load back to "True". You DO NOT HAVE TO START OVER, just open your persistent.sfs file for your save (while not actually in playing in that save) and change the lines "CanQuickSave = False" and "CanQuickLoad = False" to "True", save it and you'll be back on your way.

The issue was resolved on the RF side by a patch, so hopefully that's the end of it.

Thanks for this, sounds like I may have experienced the issue so I'll throw this in my custom folder for good measure.

I have tried using hydrolox to fuel Duna missions in the past and things didn't really go so well because I couldn't really prevent boiloff, though IDK if it had anything to do with this specific issue or just failing to properly account for it. Is there an easy(ish) way to test this? Seems like at the very least, if it really is going to be an issue for me, it can be quashed with a MM patch, but I'd like to be sure its needed for my applications.

That's fair, though according to Starwaster (who doesn't actually participate in RF development anymore), the RF team may not even the forums anymore and suggested posting it to the github issues or the RO discord and I'll have to look into doing one or the other. EDIT: Have posted this to the RF github page, so hopefully it catches their attention.

I see... I mean, if you're not really involved anymore, then I'd say don't worry about it too much. As I mentioned before, the only reason I pinged you was because you were the only person I knew to have worked on RF (at least at some point in the past) who had been active here for a while. There's also the fact that since I posted this, I've decided not to use the info mod because now that I've finally got a chance to test it without it breaking my game, I've found it doesn't actually work for most non-squad experiments. So if you want to put in the effort to track down the issue, its mostly to try to fix it for the sake of fixing it or if it ever comes up again. Since LGG is responsible for the other two parts of the interaction, he may be able to fix it on his end if its important. That all said, what's different about your branch compared to the official? Looks like its been several years since your branch has been updated based on the github info?

@linuxgurugamer Sorry for the ping, but this one is sorta nasty and now that I've got it figured out I wanted to make sure its on your radar. Have also posted this on the Real Fuels thread, but I'm not sure how active they are these days. Anyway the issue is that there is a rather nasty 3-way interaction between Real Fuels, Extended information about scientific experiments in VAB & SPH, and Rover Science Continued, or potentially their associated dependencies. To replicate, have the following installed (also to be clear, except for BG, everything on this list is a dependency for at least one of the three primary mods): Breaking Ground (BreakingGround-DLC 1.7.1) ClickThrough Blocker (ClickThroughBlocker 1:2.1.10.21) Community Resource Pack (CommunityResourcePack v112.0.1) Extended information about scientific experiments in VAB (ScienceSituationInfo 1:1.3.5) Module Manager (ModuleManager 4.2.3) Real Fuels (RealFuels 1:v15.6.2.0) RealFuels-Stock (RealFuels-Stock v5.1.0) Rover Science Continued (RoverScienceCont 2.3.5.7) Solver Engines plugin (SolverEngines v3.14.0) SpaceTux Library (SpaceTuxLibrary 0.0.8.5) Toolbar Controller (ToolbarController 1:0.1.9.11) Start / Open a game, and then enter the VAB or SPH. After this, the following NRE will begin repeating endlessly until you exit out to the main menu and has resulted in 300MB+ log files before I realized what was going on: [LOG 02:16:41.719] [RealFuelsFilters] Updated info boxes [EXC 02:16:41.720] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <f43ec557c13d4aa9907800f6eb365ca2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) The bug requires all three mods to be installed and any two of them can coexist without issue. Here are the logs from the minimal install: Logs EDIT: Not going to cross-post this to both of your mod threads since I don't think you need to be double notified EDIT2: For the time being I've just uninstalled EISE since it doesn't seem to work on most non-squad experiments, so if this isn't really high on your list, don't feel like I'm adding any pressure to fix it, just wanted you to know the issue existed.

@Starwaster Sorry for the ping, but 1: IDK who else to ping about this for RF these days, and 2: this one is sorta nasty and now that I've got it figured out I wanted to make sure someone actually looks at it. Will also be pinging LGG on his thread because the three-way issue involves two of his mods and this one. In regards to the above issue, it turns out that its a 3-way interaction between Real Fuels, Extended information about scientific experiments in VAB & SPH, and Rover Science Continued, or potentially their associated dependencies. To replicate, have the following installed (also to be clear, except for BG, everything on this list is a dependency for at least one of the three primary mods): Breaking Ground (BreakingGround-DLC 1.7.1) ClickThrough Blocker (ClickThroughBlocker 1:2.1.10.21) Community Resource Pack (CommunityResourcePack v112.0.1) Extended information about scientific experiments in VAB (ScienceSituationInfo 1:1.3.5) Module Manager (ModuleManager 4.2.3) Real Fuels (RealFuels 1:v15.6.2.0) RealFuels-Stock (RealFuels-Stock v5.1.0) Rover Science Continued (RoverScienceCont 2.3.5.7) Solver Engines plugin (SolverEngines v3.14.0) SpaceTux Library (SpaceTuxLibrary 0.0.8.5) Toolbar Controller (ToolbarController 1:0.1.9.11) Start / Open a game, and then enter the VAB or SPH. After this, the following NRE will begin repeating endlessly until you exit out to the main menu and has resulted in 300MB+ log files before I realized what was going on: [LOG 02:16:41.719] [RealFuelsFilters] Updated info boxes [EXC 02:16:41.720] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <f43ec557c13d4aa9907800f6eb365ca2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) The bug requires all three mods to be installed and any two of them can coexist without issue. Here are the logs from the minimal install: Logs

Recently I've been getting literally hundreds of thousands of the following in my KSP.log after entering either the VAB or SPH: [LOG 02:34:26.917] [RealFuelsFilters] Updated info boxes [EXC 02:34:26.969] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <c6afe99770794e0f8e6d2c11be87d511>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) And then this in the Player.log: [RealFuelsFilters] Updated info boxes (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at RealFuels.ModuleShowInfoUpdater.Update () [0x00068] in <c6afe99770794e0f8e6d2c11be87d511>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) (Filename: <c6afe99770794e0f8e6d2c11be87d511> Line: 0) This does not happen in a minimal install, so there's clearly a mod conflict going on. I am currently trying to zero in on the culprit, but its going to take me a while as I've got 250ish mods and that means a lot of time sitting on the game loading screen. In the meantime, I'm hoping someone here will be able to clue me in to what this function does and why it might be getting called hundreds of thousands of times as that might help me narrow down the source of the issue more quickly. I'm also going to include my KSP / Player log files (zipped because even with just a quick pop-in and out, they are 40Mb each) from the full install until I can narrow it down. I know its not optimal, but if anyone is willing to have a look at them in the meantime they might be able to find the offender where I could not. Some things to note about the issue in case anyone has any ideas: - It starts as soon as I enter either the VAB or the SPH without requiring a part to be selected. - Once it starts, it does not stop (at least for the several minutes I waited here) whether I move to the flight scene or exit out to the space center. - Searching for the error returned exactly one result reported in the RealFuels-Stock thread about a year ago, but that never saw any resolution. Hoping someone has an idea of what might be going on and in the meantime, I'll be reloading the game a whole lot of times trying to narrow down the possible list of culprits. EDIT: Not much luck so far... Its looking like a combination of mods (or at least one that wasn't in the install at the same time as some needed dependency while I was testing) as I've gone through the entire folder pulling mods and restarting and can only replicate it when everything is installed still. Still hoping someone familiar with RF's inner workings can give me some guidance on what the NRE means and what could be causing it to run into the hundreds of thousands like that. EDIT2: Still working on narrowing the issue down. Have found that at least one component of the problem is related to the mod Extended information about scientific experiments in VAB & SPH, but there is still another component to the issue as a minimal install with only Real Fuels, its dependencies, and the extended info mod still does not produce the endless NREs.

Ok, thanks for the quick reply!

Was this option ever added, and if so, how can I access it? Have been looking through the buttons and config file, but can't seem to find any way to switch from the main toolbar to Blizzy's where I keep all of my "mission critical" buttons.

Is there a guide (preferably video) or wiki on how to use these parts correctly? I've been fiddling around with them for about 3 hours now trying to make an aircraft and, while I feel like I'm making progress, it also feels like I'm beating my head against a wall trying to make things work because I don't really know what I'm doing. I've spent some time searching through this thread and online for some sort of guide and come up with nothing, so I'm hoping that my google-fu is just failing me and there is some sort of guide or reference that I'm just not finding. EDIT: To clarify, I get how to manipulate the various parts to make shapes, but am having trouble with details like getting control surfaces to fit properly with the wings etc. EDIT: Nevermind, have since brute forced my way through figuring it out.

Worked like a charm... Am able to basically stuff the supports all the way up into the cowling if I want to with no ill effects, thanks for the quick update.

Have both Space Dust and Cacteye installed and was wanting to have access to the original Space Dust telescope model which gets overwritten by this mod, so I wrote up a patch to split the versions so that they can coexist. Thought I'd post it here in case anyone else wanted to use it. Also, I was having issues with the Cacteye telescope tubes duplicating endlessly in the tech tree and this might fix that issue (my guess is that this was the result of two parts with the same name getting created at every game load), but I can't be sure until I test it for a while on my main save.

I'll give this a try, can think of some other areas where this could be pretty useful, thanks. This seems like it would fix the problem with pretty much all engines and allow for an easier time fitting the bolts in, especially for multi-engine setups.

I think this is likely what's been going on for me. I use mostly modded / ReStock engines so I'm guessing they might not all have tightly conforming collision meshes. Here's an example of my most recent attempt to use them: That lip seemed like a good place to put them, but caused the issue. I also tried it on the lower cowling and it still gave me issues. Would this be an example of an engine that just isn't going to work with the bolts, or would maybe another one of the options work instead?

Could someone give me some guidance on how to use the bolt style hold downs properly? I don't know exactly where to situate them and every time I try to use them, the vehicle catches on them and immediately skews a little to one side before straightening out. I'm sure its because I'm placing them in the wrong place since this doesn't happen at all with the fall away arm style, but it seems that no matter where I put them, if they are even close to touching the rocket, it'll cause things to go sideways, literally.

I know its been almost a year, but were you ever able to find a solution for this? All of the SAS modules from this mod are just grey models without textures for me even though it appears the textures are loading properly and without errors. So I've resolved the issue. It turns out there was the following error showing up in the log: [ERR 02:15:21.828] PartCompiler: Cannot replace texture as cannot find texture 'SAS_PrimaryMat_high_BaseColor' to replace Upon inspecting the part config and the assets folder, it looks like its calling what's supposed to be a base texture of some sort and then replacing it with the PNG texture in that folder, but the base texture is apparently missing so the game was erroring out and failing to replace the texture as requested. To resolve this, I just copied a DDS file at random from the same folder and renamed it to 'SAS_PrimaryMat_high_BaseColor.dds' which gave the part a texture for the game to replace and now I have properly textured SAS wheels. As far as I can tell, there doesn't seem to be any issue from using just a random DDS for this, but just in case, if you're still watching this thread at all RoverDude (don't want to ping as its not really a huge issue and I've found an apparent solution that anyone can do), you may want to release a hotfix with the "proper" 'SAS_PrimaryMat_high_BaseColor.dds' file included.

I know its been a year, but this solved the issue for me and wanted to say thanks. Seems like KSP doesn't like the way the seat texture was supposed to be loaded and wouldn't accept the non-standard name for it.

Makes sense then why my attempt at a patch failed miserably... Kopernicus does the KSP equivalent of rewriting the laws of physics to make itself work, which is a lot more involved than I'd originally thought. It also makes sense that this would necessarily be a companion mod rather than trying to put the compatibility into the main branch. I'll keep an eye on the github issue in the hopes that you'll figure out a way to make it work, and in the meantime I guess I need to go looking for some more solar panel options. Thanks for the reply.

What I ended up doing was setting it to false for the engines (RFSettings) and true for the the tanks (MFSSettings) as the latter led to some truly ridiculous values (~30 tons dry for a 20mx1.25m procedural tank). That said, I'm starting to have some second thoughts about even setting the engines to false as I've noticed some of what you've mentioned already as I've progressed through the tech tree in my career save with various engines being poor performing outliers because of their mass. Knowing that there are more issues to be had further down the line makes me think it might be better to start over and just deal with the fact that my rockets aren't going to be very big. I guess the worst case scenario is that I could add some structural segments to make things look better...

I'm curious if this patch ever made it into TweakScale? I'm getting this same behavior (up-scaled solar panels do not produce up-scaled power) in my test install with just TweakScale (2.4.7.1 installed manually from Github along with Recall 0.4.0.1 and UberPaket 2023.3.28.4 just for good measure) and Other Worlds + Kopernicus (installed through CKAN). After looking through the MM config cache, it appears to be the same issue described by Tonas1997 where TS is targeting the vanilla module, but OW/Kopernicus have replaced it with "KopernicusSolarPanel", so TS doesn't actually update the power module. Including logs + MM cache: Logs EDIT: Doing a sanity search for "KopernicusSolarPanel" in CFG files within the test install's GameData folder shows that TweakScale makes no reference to this module, so I'm guessing the answer to my question is "no". This prompts me to ask, would a custom CFG file with this fix this issue? TWEAKSCALEEXPONENTS { name = KopernicusSolarPanel chargeRate = 2 temperatureEfficCurve = 2 } Thanks EDIT2: So I've tried to use the above code both in a custom config file, and by inserting it into 020_ScaleExponents.cfg immediately below the same block targeted at "ModuleDeployableSolarPanel" and neither has had any effect on the issue. I have deleted the MM config cache for good measure on both attempts as I recall seeing that being needed somewhere else in this thread, but apparently has no effect in this case. Something I find interesting is that the up-scaled power production seems to work correctly while the panels are on the surface of Kerbin, but placing them in orbit removes the effect. Going to keep playing around with it in the hopes that I'll figure out how to insert my own patch, but still hoping for some sort of "official" response. EDIT3: Further testing shows that this is specifically related to Other Worlds because it patches "KopernicusSolarPanel" into the solar panels to get the second star to work. With just Kopernicus installed, the behavior of scaled solar panels is correct as well as when Kopernicus and OPM are installed. It's only when Other Worlds is introduced that the scaled behavior fails to work as expected. Still blindly poking around in the configs for myself, but it still looks like the issue is the "KopernicusSolarPanel" module as that is specifically invoked for Kopernicus configs with multiple stars. EDIT4: Playing around with trying to get TweakScale to recognize that I want it to add the same exponents to the "KopernicusSolarPanel" module hasn't produced any results, so I'm back to hoping for a better answer from someone who knows how to make this work correctly.

Curious how System Heat interacts with Real Fuels with regards to boiloff. I have both installed and both have boiloff as a feature, but that has me a little worried that they will end up double dipping and causing me issues. Searching through both threads hasn't returned any sort of relevant results, so I'm wondering if there is any information about whether or not they are compatible or will cause each other issues. Thanks

So I know its been a couple of years since any of the mod creators for this have replied, so I'm not too hopeful for an answer, but I am curious if we're supposed to be using "useRealisticMass=false" or not for this? I've tried multiple combinations and it feels like leaving the settings on "true" leads to fairly small rockets, while setting either of the options to false leads to comically oversized rockets (i.e. just to put a single Kerbal in orbit takes an absurdly large rocket and is nearly impossible with early tech). In searching through the thread I noticed at one point there was some talk about an update to rebalance things and remove the reliance on the setting, but looking at the patch notes there was only one update after that before it development stopped and its unclear if that rebalance happened in that update. So basically, I'm left with the following question: Have the configs been reworked such that we're just supposed to use the default RF settings, or are the current configs not rebalanced and we're supposed to set realistic mass to false and really work hard to engineer workable rockets? Thanks

Nevermind, was thinking of an entirely different mod...