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.

I tested 4.1.3, no luck. It has the same behavior. I built a copy of the mod with some extra debugging in it to print the results of SMAddon.CanShowShipManifest() and that seems to indicate that CanShowShipManifest comes back true*. Not sure if its expected, but that function is called constantly via Update->UpdateHighlighting. The debug line I added with its results basically filled up the debug console instantly. Clearing the console fills it up again immediately, even when the game is paused. Disabling highlighting stopped the spam, but did not fix the issue. *It actually comes back false initially due to vessel.VesselType returning debris for some reason. However when using [] to switch to another vessel then switch back it starts acting properly and returning true.

*edit* Oops, double post. Post below has more info.

I said its a Colony Base, but the actual type in KSP is just the standard "Base". Not sure which settings file you wanted, so here's KSP global settings SM config.xml

Trying to emulate my previous success failed. I'm back in the broken state. I tried removing CLS since things started working after toggling last time, but no change. I can successfully move crew around via SM logic using the native movement UI.

I'm seeing this. Most vessels work fine, but my MKS colony base on minmus consistently refuses to show the SM control panel. The only logs in Player.log from ShipManifest area bunch of: [ShipManifest]: ShipManifestAddon.OnShowUINo messages appear in the SM debug console, verbose logging only adds some messages about finding CLS. This happens with both stock and blizzy toolbars. When focused on the problematic vessel and clicking the toolbar it seems to be correctly toggling state (stock toolbar gets the "pressed" look) and switching to another vessel shows that the state is correctly being changed, however when enabling on the problematic vessel the icon does not turn green. Disabling if I've enabled from another vessel does turn the icon back to yellow. I've got a lot of junk around the base, and oddly enough if I switch between it quickly with [] the SM interface will show up for a half second or so with the correct values for the base before disappearing. Switching to other ships in range generally show their SM panels ok, but undocking/redocking parts of the base don't seem to help. Fair warning I've got lots of mods, so I wouldn't be surprised if there were some kind of conflict at work. I tried rolling back as far as 4.1.4.1 and that didn't help. I have had success with almost this exact same vessel (if anything I think I destroyed some parts) a few days ago, but for the past couple days nothing. Going to try removing and/or reverting other mods to earlier versions when I've got some more time. For reference the mods updated in the past week or so and therefore are the most suspicious are: AdGroups Extended Waypoint Manager Kerbal Inventory System SETI Contract Configurator DMagic Orbital Science Happy to try any suggestions you may have. *edit* As with any good bug, after posting about it it seems to be fixed (maybe?) I disabled CLS and manually moved a kerbal around and all of a sudden the SM window popped open. Will do more testing tomorrow.

I'm not part of the development of either mod, but my experience is: Its probably a combination of how KAS creates new items when pulled out of storage and how realchutes initializes the parachute module. Likely neither is doing anything explicitly wrong, they just have a different set of assumptions for how new parts can be created/attached. Installing KIS will not fix any chutes you may already have in KAS storage. I was able to create a new rocket with radial chute and screwdriver in the pilot's inventory, attach the part in orbit, and use the chute to land successfully. Note that I couldn't find any way to control/tweak the realchute settings, so you get whatever the default sizes are (in my case a bit too small for my rocket unfortunately).

I hacked around with the code a bit but never did get this to work with KAS. However, the new KIS seems to be creating chutes just fine, so going forward once containers have switched over to KIS the problem should go away I assume.

Did this ever get figured out? I'm seeing the same issue.