IggyHitokage

They were running Ryzen 7900X + RTX 4080. That's a $2000+ configuration. The bottleneck is not the hardware.

Absolutely not. If nothing has drastically changed since the preview build that just got shown off by YouTubers... It couldn't hold more than 20 FPS on a 4080 with a moderately sized craft (150 parts).

I tried to do it myself and nothing ever changed, so I said screw it and moved on. Strangely enough, when I couldn't research other bodies, I just forced it to unlock a new body and the entire bug... resolved itself. I'm not sure if this is what caused it, but if you research an unrelated body via changing the research state to 100%, maybe it'll fix the bug.

This does work temporarily for me, but it may be that I still have vessels in the SOI that causes the bug to just simply start again the minute I enter the tracking station. I accidentally discovered Lua (Beyond Home, first home planet's moon) and it triggered the bug. Hopefully deleting all existing craft around it will fix the issue. Edit: After extensive testing, no. Still only a temporary fix until the scene changes and then back to bugged.

Yeah, that's why I'm assuming this is just a stupid false positive, apologies if I raised an alarm about it.

Not trying to raise an alarm and I honestly think this is a false positive, but Malwarebytes recently alerted me that every single file for KSS that I downloaded was a trojan, specifically Trojan Siredef.C. Anyone else had this odd occurrence? I downloaded them from the GitHub only a few days ago. Edit: It looks like it was the Extended Kerbol System pack specifically.

Ah, that's my inexperience talking then. I saw the configs and just assumed that that was what was going on! Edit: Rereading over the config, yeah, they're using Sun as the main celestial lightsource, so no, no multiple lightsources. Note to self: don't assume while half awake!

Well, Extrasolar is its own planet pack, but its scatterer configs include settings for not only its own system, but for the stock system as well. I assume this is due to the light cast from the planet pack's star on the stock system. After some fiddling I've managed to make them both function together, but I think the functionality of using Valentine's light on the After Kerbin system wouldn't work without someone with much more experience editing the config files. Oh well, Archangel is definitely red enough.

Just a warning, do not use Extrasolar's "EVO" configs in conjunction with After Kerbin, I made that mistake and it caused a horrific memory leak due to Scatterer looking for bodies that don't exist anymore. Been fiddling with it for the last half hour or so to see if I can get them working together.

Thanks, I just wasn't sure about it. I'm running over a hundred mods, so I would understand entirely if it were some kind of conflict somewhere.

I recently started using BARIS on a new save file and I've noticed something that seems a bit off. Even after doing a full integration, it's pretty much guaranteed my craft explodes before it gets back to Kerbin. Using the USI Sounding Rockets seems complete out of the question and I had multiple antenna fail only minutes after a launch. I haven't changed any difficulty settings beyond enabling parts breaking. Is this normal?

So I've been working to create a self-sustaining colony on Laythe along with Extraplanetary launchpads and I've noticed just how absolutely pitiful the output is with the ISRU for LF/O production. To fill my SSTO with 3 dedicated Convert-o-Tron 250s with essentially unlimited supplies, it will take 400 Kerbal days to create the 24000 LF necessary. Would it be possible to later unlock either more efficient or more productive versions of the ISRU refinement? Even if it uses double, quadruple the resources to increase the output? I don't particularly want to spam ISRUs all over the base to make up for it, since part count = lag. I know I could edit the config files, but I'd rather have a genuine unlockable mechanism to increase productivity.

When I have the time, I'll test it with a near-vanilla installation (just Kerbalism/DeepFreeze), I'm pretty sure it's probably another mod interacting incorrectly with it. Edit: After some testing, it looks like it is a mod interacting with Kerbalism/DeepFreeze oddly. They do not reset radiation/stress upon waking, but they do not accumulate stress or radiation while frozen. Sorry for the false alarm, didn't think any of my other mods might do that.

Just a quick question since I noticed this behavior this morning. I used DeepFreeze to freeze some Kerbals in orbit of Duna for about 2 years, they had originally accrued about 12% radiation and 5% stress. After sending a vessel to retrieve them, I woke them up and noticed that all factors had been reset, stress and radiation were at 0%. Is this intended? Certainly helpful for long-term colonies without needing to ship Kerbals around endlessly after 5-10 years. Also, I had searched the thread and found a reply explaining that the exact opposite would happen (radiation would still affect frozen Kerbals), but that was almost a year ago.

Apologies! Will try and figure it out there, thanks for your time.

Having a minor incompatibility issue between M.O.L.E.'s "Solar Battery Module" and Kerbalism's background processing. It seems that Kerbalism looks for "ModuleDeployableSolarPanel" as the go-to for background processing and the part has two modules to facilitate the rotation of the part and the rotation of the panels. I've attached both a screenshot of the part and how it interacts with Kerbalism and the modules of the configuration file for the part. I've found a temporary fix by renaming the modules to each other, but it causes the part to rotate even when the panels are closed. Deployable Solar Panel produces 0.0 charge, but the panels themselves do produce 24/s with the other module. //Y-axis of SARJ is the pivot //Z-axis of suncatcher2 points to the sun. MODULE { name = ModuleDeployableSolarPanel animationName = empty resourceName = ElectricCharge chargeRate = 0 isBreakable = false pivotName = SARJ raycastTransformName = suncatcher2 windResistance = 5 trackingSpeed = 0.25 } //Y-axis of SolarArrayPivot is the pivot //Z-axis of suncatcher points to the sun. MODULE { name = WBIDualAxisSolarArray rotationModuleIndex = 0 animationName = Deploy resourceName = ElectricCharge chargeRate = 24.0 retractable = true isBreakable = true pivotName = SolarArrayPivot raycastTransformName = suncatcher windResistance = 5 trackingSpeed = 0.25 } My assumption is that I'll probably need to get Kerbalism to read the "WBIDualAxisSolarArray" module instead of "ModuleDeployableSolarPanel" for this to work without the sloppy quick-fix that I've done.

Having a minor issue and I'm not sure whether to chock this up to Kerbalism or MOLE, but the Solar Battery Module does not produce Electric Charge in the background for Kerbalism's purposes. I've been fiddling with it and noticed that the config itself shows 0 for it, but since this solar panel setup is unique, messing with it just causes it to generate electricity even when closed/no sun. Unfortunately, I'm not super sure if this is Kerbalism's fault or the part itself. I attached both a screenshot and the part's config modules. "Deployable Solar Panel" produces 0.0 electric charge, so Kerbalism sees it as producing none in the background. //Y-axis of SARJ is the pivot //Z-axis of suncatcher2 points to the sun. MODULE { name = ModuleDeployableSolarPanel animationName = empty resourceName = ElectricCharge chargeRate = 0 isBreakable = false pivotName = SARJ raycastTransformName = suncatcher2 windResistance = 5 trackingSpeed = 0.25 } //Y-axis of SolarArrayPivot is the pivot //Z-axis of suncatcher points to the sun. MODULE { name = WBIDualAxisSolarArray rotationModuleIndex = 0 animationName = Deploy resourceName = ElectricCharge chargeRate = 24.0 retractable = true isBreakable = true pivotName = SolarArrayPivot raycastTransformName = suncatcher windResistance = 5 trackingSpeed = 0.25 } Edit: I did find a temporary solution in renaming the "WBIDualAxisSolarArray" module to "ModuleDeployableSolarPanel" and vice versa, but it does cause the part to rotate even when the panel is not deployed. Doesn't seem to be a massive issue as long as I don't have any other undocked craft in the vicinity and there's no massive amount of time warping or rotation involved.

Can confirm opengl works just fine on a GTX 970, even using RSS, it works great. Love how it looks!

Oh please tell me you just added that to the OP, because otherwise I feel stupid.

Just for starters, loving Kerbalism, in stock, Kopernicus planet packs and recently, trying to use it with RSS/RO. Downside is, when used in conjunction with Real Fuels, the Kerbal doesn't take any MonoPropellant out with them for EVA fuel even though I've specifically put some on board. Is there a way to fix this, or barring that, a way to disable the need for propellant to fill the Kerbal's EVA pack? EDIT: So, with some testing, looks like Hydrazine is the winner. Loaded up the pod with every single fuel and that's the one the Kerbal took, good enough!

Much thanks! Finally, I can expand beyond Mun.

Sorry! Didn't know, I edited the post to remove the log, will use a fileshare in the future. Thanks for the quick look though, much appreciated!

Uh, it's in the spoiler in my previous post. Also, full reinstall with a fresh download from Steam yielded the same results, camera loss at 6000m.

Found the nullref in the log, it's in the spoiler there, I just replaced my username in Windows with username. Copy/pasted the nullref here too. NullReferenceException: Object reference not set to an instance of an object at RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction) [0x00000] in <filename unknown>:0 at ResearchBodies.ModuleTrackBodies.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 I'll also do a full reinstall and see if that helps. This was a previously modded install copy/pasted into a fresh folder for testing individual mods. Edit: Apologies, log deleted.

Still having this issue even with it not as the first part. Removed all mods and still same issue with the camera getting stuck suddenly and the rocket flies away. Changed root parts, even mounted them sideways and upside down, with or without fairings. KSP's debug doesn't say anything and nor does the flight log. I've had it consistently do this when the altitude hits about 6000m. Stops happening as soon as I pull the telescope off. Not that it matters, also checked in both 32-bit and 64-bit, same issue. Will upload the output_log in a bit.