steve_v

I'm seeing this too, and it's not a new thing. It's been there at least 2 versions, and it appears that the UI gets progressively less responsive as more changes are marked. When I first installed 1.3 and tried to install my usual ~60 mods, I got to about 20 selected before the UI became so slow as to be unusable - 5-10 seconds between clicking and a mark appearing in the checkbox. The entire UI appears to freeze for the duration. Please, whoever wrote this UI, if you've got background work to do at least provide some visual feedback that you're working on it. Video Also, any chance we can have a UI that doesn't look completely out of place on a GNU/Linux desktop? Like, follows the system widget and colour themes properly? I don't know what UI toolkit mono uses, but it sure is ugly...

Again, this is not the same thing. Mods compatible with 1.3 may not be compatible with 1.3.1. There is no "either". Install only 1.3.1 compatible mods on 1.3.1. Do all your mods specifically state that they are for 1.3.1? Most that include a .dll require a recompile against the new version (or they crash the game), and anything that touches the settings window (and possibly part categories) requires code changes.

"Should be" /= "Are". Many mods released for 1.3 will crash the game with 1.3.1. There have been a large number of similar reports recently, almost all due to Steam auto-updating the game from 1.3 to 1.3.1. If your mods haven't changed, the game version is the other likely variable.

Being snarky does not encourage people to spend their time trying to fix your problems... The reason the support sticky exists is to avoid having to go through this information-extraction process with every support thread. Unity starts writing output_log.txt as soon as the player loads, so if you see the loading bar (and haven't started with the -nolog argument), there's a log. However, this one will do. Mod DLLs found: KSPModFileLocalizer v0.2.1.10 ModuleManager.2.8.1 v2.8.1.0 000_AT_Utils v1.4.4.0 FilterExtensions v3.1.0.0 / v1.0.0.0 KerbetrotterTools v1.0.4.0 USITools v1.0.0.0 B9PartSwitch v1.9.0.0 B9_Aerospace_WingStuff v1.0.0.0 BDAnimationModules v0.6.4.8 RNModules v1.1.5.1 CCK v2.0.1.0 / v2.0.1.0 for KSP 1.3 SimpleBoiloff v0.2.1.0 DeployableEngines v2.2.0.0 DynamicBatteryStorage v1.0.0.0 EditorExtensionsRedux v3.3.14.0 Launchpad v5.8.2.0 / v5.8.2 FarFutureTechnologies v1.0.0.0 Firespitter v7.3.6354.39102 FShangarExtender v3.5.2.0 / v3.5.0.0 GroundConstruction v1.2.0.0 HangarGrid v0.4.0.0 HideEmptyTechTreeNodes v1.0.0.0 InterstellarFuelSwitch v2.10.0.0 / v2.10.0 Scale_Redist v1.0.0.0 KAS v0.6.3.0 / v0.6.3 for KSP 1.3 KerbalEngineer v1.1.3.0 KerbalEngineer.Unity v1.0.0.0 KerbalJointReinforcement v3.3.3.0 KerbetrotterTools v1.0.4.0 KIS v1.7.6468.41490 / v1.7 for KSP 1.3 KSPDev_Utils.0.28 v0.28.6465.41979 / v0.28 for KSP v1.3 KSPWheel v0.0.0.0 AnimatedIntakes v1.0.0.0 TweakableAnimator v1.0.0.0 MechJeb2 v2.5.1.0 / v / v2.6.1.0 ModularFlightIntegrator v1.0.0.0 / v1.2.4.0 modularFuelTanks v5.9.1.0 / v5.9.1 NearFutureElectrical v1.0.0.0 NearFuturePropulsion v0.9.0.0 NearFutureSolar v0.4.0.0 PatchManager v0.0.9.0 / v1.0.0.0 PersistentRotation v1.0.0.0 ProceduralParts v1.2.12.0 QuickGoTo v1.3.3.31560 RemoteTech v1.8.0.0 / v1.8.8 DeepFreeze v0.23.7.0 RetractableLiftingSurface v0.1.4.0 / v1.0.0.0 SmokeScreen v2.7.5.0 ModuleBounce v1.0.0.2 / v1.0.0.0 Scale v2.3.6.0 Scale_Redist v1.0.0.0 DynamicTanks v1.0.0.0 Konstruction v0.0.0.0 USILifeSupport v1.0.0.0 KolonyTools v1.0.0.0 WarpEngine v1.0.0.0 Interstellar v1.15.2.1 Interstellar_Redist v1.0.0.0 Scale_Redist v1.0.0.0 Are _all_ these mods compatible with 1.3.1? I'm not going through your list for you, but at a cursory glance there are some in there that do not have a 1.3.1 release... And this looks a lot like a "mod dll not compiled against right KSP version" cash to me.

Wrong log, as usual. Please read the support sticky and post the suggested info. Crash probably due to incompatible mods, in turn probably due to steam updating KSP to 1.3.1.

Use the x64 executable on x64 systems. Running the 32bit build with mods is asking for OOM crashes. Wrong log anyway. output_log.txt is the one that is actually useful. Are you sure they are all compatible with the KSP version you are running? Mods that have not been recompiled for 1.3.1 will often crash the game. Logs?? Why does nobody post the (right) logs? Also, thread-jacking much? Speak for yourself, I'm not "nice" at all.

Sure. Looks fine to me. In order of difficulty: Ensure fans are working and exhaust vents are not obstructed. Clean all the dust out of the fans / heatsinks. Remove heatsink assembly(s) and replace thermal grease / pads. 2 & 3 will require dismantling the machine to some extent. See if google has any instructions / videos for your model, or be prepared to play "find the silly plastic clip" for a while. Laptops are a PITA.

Reproduce the bug in an unmodded game. Post a bug report. (what you have here is pretty good already, providing a save file would be even better). Wait.

Everyone should know about Alt+F4, and there's nothing particularly wrong with using it if you ask me. I use Ctrl+Alt+Esc (GNU/Linux xkill), and I do love my little mouse cursor for offending-window selection. Just save first, no harm done.

Why, in the name of Dog, are you running CKAN as administrator? I hope this is not your usual user account, I thought that kind of foolery died with Win'98, when M$ stopped encouraging it. Running as admin by default means anything you run has the ability to compromise your entire system, and will almost certainly lead to permissions issues at some point. People doing this is half the reason Windoze is such a juicy target for malware and viruses. Don't do this. Bad Idea doesn't even begin to cover it. This ^. x900. Gah. This is not CKANs problem. It's a permissions problem caused by running as admin. I'd suggest inspecting (and fixing) the offending file permissions, possibly from safe mode. Ask google for details. Then again, if it were me I'd probably just nuke the whole OS install from orbit...

Haven't tested extensively with 1.3.x, but it worked a treat in 1.2.2. So far no performance issues to report with KSP 1.3.1 / Trajectories 1.7.1 / FAR 0.15.9 either, but again, not used in anger. Flying with it now. No problems.

Because the OP said so: 8GB installed, ~3.5GB usable. Sure sounds like a 32bit non-PAE OS to me. Why anyone would install a 32bit OS on an I5 with 8GB of RAM I don't know, it's madness. But unless the stated numbers are incorrect, there we are. Granted onboard Intel graphics are sub-optimal (though the chip in an I5 should be a bit better), but a slow GPU won't cause the game to crash, and that's the main problem here as far as I can see. At a guess, I'd say that's the old "terrain shaders run like ass on intel graphics" chestnut... There's a "fix" for this floating about somewhere IIRC, but yeah, for KSP Intel graphics == poor performance.

One does wonder if the "source code available" requirement for addons also applies to such things as executable installers... Aside from that, I have no problem with this idea, provided that: The system works on all supported platforms (Win/Mac/Linux) without additional shagging around (no, running the installer in wine is not an acceptable solution). There are no hardcoded Windows-centric paths involved (e.g. the antiquated notion of "drive letters".) The files can be obtained with standard tools (zip etc.) if the installer fails for some reason.

There's no linking of any kind involved here, just redistribution. So long as the redistributed copy of AVC meets the licence requirements, no problem. This whole conversation is a pointless distraction. Back to the topic at hand: This appears to work just fine with a plain old recompile. I'm sure Alshain will get onto it shortly, or if you're super impatient it's easy to do yourself.

It's an i5, and very much 64bit. Somebody just installed the wrong OS on it. Do yourself a favour and install a 64bit operating system. With your current configuration, over half of your memory is unusable. As a bonus you'll be able to run KSP properly, with mods even.

I have a special love for those modders who release their work under the GPL, as it prevents this kind of obnoxious behaviour.

Steam. Steams idiotic auto-update. Oh, and Squad for updates that crash with once-working mods and no useful debug output. Roll back to 1.3.0, or go through all your mods checking for compatibility with the latest KSP version.

1) This install is modded, and therefore this doesn't belong in the unmodded section. 2) You are running the 32bit KSP executable, never a good idea with mods. 3) You have mods installed that are not compatible with 1.3.1, and several are throwing exceptions. My money is on #3 for the cause of your crash. Steam probably did that super helpful "auto update and break all my stuff" thing that it does. Downgrade back to 1.3.0 (IIRC Steam can do this, but I wouldn't touch Steam with a 40' pole, so YMMV), or remove the mods and install 1.3.1 compatible versions.

In theory, yes. In practice, it screws up peoples installs pretty much every game update.

That log is incomplete and, as you have discovered, this POS forum software can't handle such a large amount of text. Upload the whole file somewhere and post a link.

Does nobody read this thing any more or what? Where are the KSP logs? Can we have an autoreply bot or something here? It'd save a lot of time wasting.

Thank you. Still no patches though, I see. What is so bloody difficult about providing incremental patches? You do for Windows, so you can damn well do the same for the other supported platforms. Slack.

Developers are damned if they don't, at some point post-beta, establish a stable API. That way mods require at most a recompile to function with a new version. If one must change the API mods are using, save it for major releases. From what I see, pretty much every major release has been followed by a couple of minor releases to fix new bugs... which shouldn't have been in the release in the first place. This is annoying enough, without breaking mods (again) as well. I'm fine with 1.2.x -> 1.3.x requiring code changes in mods. The same circus for 1.3.0 -> 1.3.1 is just a pain in the ass.

Metal. Loud, melodic, preferably from Finland. Works for me

Not sure how you got "one persons mod" from "community database". This is not a mod, it's a collection of ModuleManager snippets from a great many contributors - much like the community mods and plugins library thread. That one is pinned, so why shouldn't this get the same treatment? If you're talking about not favouring ModuleManager itself, it's used in most mods anyway, and it has it's own thread to not favour.