jenden

FYI there was another thread where similar issues were reported and the fix did the trick for me. Specifically starting KSP with -force-glcore42 has completely eliminated my crashes (though now I've got some memory leak which limits my sessions to a few launches).

Ok, new launch, no KRASH (still installed but not used), uninstalled RSSVE, EVE, Scatterer, or Distant Object Enhancements (basically all the optional mods in the graphics section). I added RealPlume back in as it was still crashing without (though maybe slightly less frequenty). And it still crashes fairly frequently on ignition. This time the last entry in Player.log is a stack trace, though doesn't seem to be super useful: Edit: While I am still crashing occasionally, removing the various graphics mods does seem to reduce the frequency considerably. Definitely seems to be video related, will try changing graphics driver versions and see if that helps. Currently on nVidia driver version 440.82-r3.

In my case it was actually during the KRASH simulations that it was crashing. I didn't think to try the launch without simulating first, but will do so.

To partially narrow down my issue, I tried removing Real Plume (since the issue seemed to be most common at engine ignition) and sure enough my rocket was able to launch successfully. However, when launching via KRASH simulation terminating the simulation (going back to the VAB) caused the game to crash again. Flying the rocket normally (outside of simulation) and going back to space station after explosion did not crash the game. It also looks like the OpenGL Error: Invalid texture unit! errors may be a red hearing as I still see those in the logs for a session that doesn't crash.

I'm also seeing this. I just started a new game on 1.8.1 (linux) and initially saw a few crashes that seemed to be related either to scene changes or explosions, but after creating my first rocket using an XLR43 the game crashes on engine ignition almost every time (probably something like 5/6 so far). Mod List Player.log

I've been having some contract related problems with my recent game. Every couple times I start up the game my progress and contact history gets reset. Contract archives are empty, I get contracts for first flight and similar again, and any outstanding contracts are gone. As far as I can tell it happens both after crashes and after normal normal exits, so I'm assuming that whatever is removing all my contracts is happening in the process of loading a game. I'm not positive its RP-0 causing the problems, but most of my mods are either dependencies/recommendations of RP-0 so it seems to be a good place to start. Here are logs from the most recent load where my progress got reset: Player.log KSP.log Edit: Here's a list of my GameData directory as well: 000_Toolbar AJE B9_Aerospace_ProceduralWings BetterBurnTime Chatterer CommunityResourcePack CommunityTechTree ConnectedLivingSpace ContractConfigurator CustomBarnKit DMagicOrbitalScience DMagicUtilities DeadlyReentry Diazo EasyVesselSwitch EditorExtensionsRedux EngineGroupController EngineLight FerramAerospaceResearch Firespitter ForgottenRealEngines KAS KIS KRASH KSCSwitcher KSP-AVC KerbalConstructionTime KerbalEngineer KerbalJointReinforcement KerbalRenamer Kopernicus MagiCore MagicSmokeIndustries MechJeb2 ModularFlightIntegrator ModuleManager.2.6.25.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree NoNonRp0 Olympic1ARPIcons PersistentRotation PreciseNode ProceduralFairings ProceduralFairings-ForEverything ProceduralParts QuickStart RCSBuildAid RP-0 RSS-Textures RSSDateTime RealChute RealFuels RealHeat RealPlume RealSolarSystem RealismOverhaul RemoteTech SCANsat SSTU SXT ShipManifest SmokeScreen SolverEngines Sovietengines Squad StockBugFixControllerPlus Strategia Taerobee TestFlight TextureReplacer ThunderAerospace TimeControl TriggerTech TweakScale UniversalStorage VenStockRevamp WaypointManager [x] Science! kOS toolbar-settings.dat

I think I ran in to a bug with the mini drill. Its not getting the WBIDrillSwitcher module added. Looking at the MM_DrillSSwitcher.cfg file it looks like the syntax is incorrect. It should probably be @PART[*]:HAS[@MODULE[ModuleResourceHarvester],!MODULE[WBIDrillSwitcher]] Relatedly my drill had an extend and core sample option (and option to change resource after the above change), but no option to start harvesting. I was able to modify the save file to force the option to show up in the UI, after which everything seems to work as expected. Unfortunately I didn't think to keep a copy of my save from before editing.

There was an update to the stock bug fix mod that mentioned fixing a heating issue, and it looks like that might have fixed things for me. I haven't had a chance to do much testing, but a very simple test of putting something into a very deep descent showed promising results (pod didn't explode until after engine and fuel tank).

On second thought that shouldn't be the issue. The exact same vessel with the fuel tank (and everything attached to it) replaced with a heat shield worked OK. I'd assume that if the antenna or other parts sticking out caused a problem they would cause the same problem with just a heat shield underneath.

I believe so. Its a fairly basic 1.25m stick with parachute and MK1 capsule on top, some universal storage wedges, fuel tank, landing gear and engine. The one thing that I'm starting to get suspicious of is that I've got some non-physical parts attached to the capsule, including a (retracted) antenna. I'm not sure how physicsless parts interact with reentry heating... looking at the thermals they aren't heating up themselves, but if the parent part (the capsule in this case) is inheriting the expanded profile then that might explain things.

Ok, I guess DRE is just more deadly than I remember. Last time I was playing (around the 1.0 release) I seem to remember that even with DRE I could have a re-usable lander that cycle between LKO and Mun/Minmus. I would aerobreak in the upper Kerbin atmosphere (I think I was using ~50km or so at the time) then circularize to 100km or so after shedding some velocity. Hitting the atmosphere pointing directly retrograde usually concentrated the heat on the engine which had a sufficiently high max temp to handle it. The engine is still handling the heat OK, but as mentioned above the crew capsule is heating up and exploding before I hit 60km. With this kind of setup a heat shield isn't going to make much sense since I still want the engine after slowing down a bit. Is there a better/more correct method of doing this kind of aerobreak? The deepest I've managed to get in anything without a heat shield is about 65KM, which wasn't enough to shed a useful amount of velocity. I tried removing FAR entirely to make sure that wasn't conflicting, but no change in behavior.

I'm having a problem with sudden command pod explosion on what should be (as far as I can tell) a rather safe aerobreaking maneuver. I've got a small vessel coming transferring from Mun to Kerbin with a Kerbin PE of 53k. In my past experience it seems like this shouldn't be an issue (whether it's useful as an aerobreak or not is questionable, but it illustrates my issue well), but now on my way in at 63k altitude my command pod suddenly starts heating up at a rate of multiple hundreds of degrees per second and immediately explodes due to heat. Similar 40k reentry from LKO with a heat shield and around the 50-60km mark the pod just goes boom. In both cases I don't get any atmospheric heat effects before the explosion. Removing DRE seems to restore sane stock behavior, so I'm guessing its not another mod causing the issue in isolation (though it could always be a conflict somewhere). I read somewhere that removing the Physics.cfg file helps fix some things, so I tried that. This actually gave me the exact opposite behavior. I could come in with an extremely sharp reentry and see no heat increase on any parts. Using steam to verify files I get the original (pre-delete) Physics.cfg file back. Potentially useful information: Linux 64bit install Physics.cfg that causes immediate explosion (file that came with distribution) Physics.cfg that doesn't seem to heat up anything (generated if I delete the above file) My GameData folder (for mod list) Player.log

Yes, probably the issue earlier in the thread

Ok, I think I got it. You're calling UpdateSMcontroller in OnVesselLoaded which in turn sets SMAddon.vessel to the given parameter. This is also called though when new vessels are loaded into physics, so its not always going to be your current vessel. I put in a gated the call to UpdateSMcontroller with a if(data.Equals(FlightGlobals.ActiveVessel)) and that seems to have fixed my problems. Not sure if it broke anything else, but I could switch to other vessels in physics range and it updated the SM dialog accordingly so it seems to be working.

Ok, I may be closer to tracking it down. Removing PauseMenu.isOpen didn't help, but throwing in more random debug statements it looks like SMAddon.vessel is not the correct vessel. This also seems to be why SM initially things my Base is Debris. When loading the base UpdateSMcontroller gets called a couple times with different nearby vessels (I've got something of a littering problem) but none of them are the base in question. Then whenever it goes in to the Display function it falls in to step 0a because ActiveVessel != vessel.