steve_v

Don't hold your breath. Others, myself included, have spent considerable time tracking down the cause of this (there's even a mod just for the purpose - kinda indicates it's a widespread issue, no?) and all we've heard from Squad so far is head-in-sand. I guess nobody on the dev team tests with large saves, or surely someone would have encountered it by now. As it stands, I consider late-game (still) effectively unplayable due to this, mods or not. The overall improved physics performance in 1.1 just serves to make the GC pauses more obvious.

Yup, I see the stutter here clear as day - I wouldn't want to play that save TBH. Here's a little vid, even at the low framerate of that capture the gameplay impact is obvious. I'm pretty sure this has gotten worse since 1.0.5, it certainly hasn't got any better. No mods bar GCMonitor, BTW. Debian GNU/Linux 8.4, I7-3820, 16GB, GTX680.

It's not a "plugin", It's (part of) the Windows kernel, and it's not "causing" anything. It shows up in stack traces because whatever Unity bug is crashing the game is doing so while interacting with Windows code inside that .dll.

Yeah, the most official word I've heard, essentially: "minor issue, better things to spend the time on." Indeed, some plugins appear to make much garbage. I suspect this may improve if/as mods move to the new UI system. Solutions: a: Make less garbage, both Squad and modders. b: fix the GC, or prod Unity to do so. Don't really see a third here.

I've just been testing exactly that. Looks like the patcher is back. Only one trivial bug detected so far (wrong archive format on GNU/Linux), it's certainly worth a shot for the 286.99x smaller download.

Your save should auto-upgrade to 1.1, assuming it doesn't require any unavailable mods. if it does depend on broken/outdated mods, you will have to wait for those to be updated to match the current game version, or ditch the save when the mods disappear. That's just how it is, it's the risk you take playing a modded game. The 1.1 Squad update is not save-breaking, stock saves from 1.0.5 work just fine. Check the threads for your mods too, nobody likes doing it but sometimes mod updates are save breaking. Aside, you're still missing all of the required information to make this a real support thread - any useful investigation is going to need a mod-list with versions and log file, minimum. Fair warning: If this info confirms my suspicions regarding the state of your GameData the response will probably be something like "You have incompatible versions of mods [foo,bar] installed, remove them." FWIW, I like mods too - I probably spent 3+ hours testing the mods I want to use before starting a new career game for 1.1. The alternative to starting fresh was to wait for mod updates that might never happen, or spend even more time debugging all the broken things... and probably end up removing all the mods in the process anyway.

Seriously, don't do this. You need to make sure your installed mods are compatible. All of them. Any mod that includes code (and some part mods too) that hasn't been updated for 1.1 will fail to work correctly... if you are lucky. If you are not they will break the game in horrible ways. Get rid of anything not explicitly compatible with 1.1 and try again. If issues persist follow the instructions in this post.

Somebody is bugging Unity about this, right? Do I take this as a "no" for 1.1.1 then? Any ETA on an upstream fix?

Are we getting a fix for the "double free() or corruption" crashes on GNU/Linux in this patch? It's been reported multiple times, and even made it as a "known issue" (no fix) in the "Linux thread". This needs to be fixed, release software that crashes randomly is not a good look. Very similar crashes are being reported regularly on other platforms too, though I can't test myself. Wheels and other issues I can wait for, stable client first please, on all supported platforms. For comparison: 1.0.5 x64 on GNU/Linux, 60+ mods = zero crashes. Seriously, I don't recall ever seeing a crash with native code trace before 1.1.

Yeah, and it's not only the Windows player that randomly crashes either. KSP on GNU/Linux went from zero crashes, even heavily modded, to random CTDs every 1-2hrs (native heap corruption / mono issues AFAICT) and a bunch of graphical glitches, with no mods at all. Going through the extensive list of "known issues" and disabling some GPU driver optimisations improved this from a CTD every 3rd scene change. Hell, I've even seen 1.1 go zombie and trigger the kernel SMP lockup detection code. (BUG: soft lockup - CPU#[x] stuck for [xx]s! [KSP.x86_64]) This is slightly disturbing. While performance has improved (though I'm not seeing the "huge" performance boost claimed TBH) stability has gone seriously downhill, add to this the several "CTD on startup" issues, windowed mode freaking out so badly it's actually crashing certain window managers, and the dodgy transparency and other graphics issues... KSP feels far more "beta" than the beta releases ever did. As for wheels... Borked. Just don't get me started on how borked... They're still a minor issue next to the crashing though, IMO. The more I play, the more I see this is a buggy, crashy mess. Unity issues (the cost of using a cheap lousy game engine) perhaps, but nevertheless "Release quality" this is not.

I see this thread is still alive... and so is this performance issue. 1.1 appears niether better nor worse to me, general performance improved but stutter remains pretty much unchanged.

Nicked these from somewhere, sometime. Not sure exactly what you mean by all containers, but either one works for me with any LFO tankage. IFS: Firespitter:

Windowed mode is thoroughly borked ATM. Some things to try: Remove ~/.config/unity3d/Squad/Kerbal Space Program/prefs, restart game. Possibly remove settings.cfg too. Do above, then set resolution to actual screen size & fullscreen = true in settings.cfg, live with fullscreen. Manually enter one pixel less than required / screen resolution in the above prefs file, then chmod -w to keep it from being overwritten (anecdotal evidence). Likely because prefs is in your home directory, but it's looking in roots home directory when run as root. P.S. don't run games as root, ever. Now that you have, check ownership on any files it may have written in the KSP directory.

Mediafire links are disabled here, pick another host.

On the off chance that it's the same issue I was seeing (trace looks familiar, comparable hardware / OS): That message is a warning from glibc malloc, could indeed be a double free() but it'll also catch other heap corruption.

FWIW, crashes on scene change (esp. with TextureReplacer, dumps pthread trace into head of log file) cured by setting __GL_THREADED_OPTIMIZATIONS=0, so far anyway. Debian GNU/Linux 8.4 x86_64, Nvidia 364.12.

Known. Irritating, but known. I've already compensated for caster at takeoff / landing attitude. Besides, it's a taildragger - it can't have zero caster in all situations, otherwise it won't take off. Wheels are by definition round, right? Assuming the cowling doesn't clip the ground (yes, I checked) if caster is what's going on here then this behaviour is clearly a bug. I also tried a tricycle setup with single nosewheel, wheels placed dead straight and level. Nosewheel exploded @ 30 m/s. Non starter. I really don't know how much slower and flatter I can come in - as I said, ~0.5 m/s vertical velocity @ 50-55m/s. Extremely sedate by 1.0.5 standards. Adding more static AoA might get me down to real cessna speeds, maybe, but having to go that slow is ridiculous - especially considering we don't really have the parts to build aircraft that light, or piston engines for that matter. --- I see they break other things too: Just converted my ~40t VTOL to the new gear, go for a quick hover and land a touch hard at ~1.5 m/s vertical. The gear survive... And the runway explodes. I smell a rat somewhere in the ground collision detection, or the forces generated.

Last time, about 5°. The aircraft in question is a taildragger, as light as I can build with the mk1 cockpit and fixed gear, so it's always coming down on the main wheels first anyway. On the odd occasion I get it on the deck without the gear exploding (<1m/s vertical seems to do it), it goes into a drunken sway and rolls over (suspension enabled) or bounces, then rocks, then spins out (suspension disabled). Using the Lvl 1 runway with the apropriate (early) tech unlocked is suicide. Hell, even takeoff is a 50/50 as to whether the gear explodes from "overstress", and if you surive that it's 50/50 whether you get off the ground before the suspension sway takes the wings off. This shouldn't have been let out of prerelease. Landing gear are totally broken, wheels and landing legs almost as much. Sounds like a case of "this bug too hard, screw it" to me.

No kidding, I've yet to land any aircraft without explosions (even at ~55m/s 0.5m/s vert.) Landing gear are pretty much unusable for the advertised purpose, so much so that it aborted my attempt at a "planes first" career.

Most excellent. Issue detected: ArgumentException: No PartModules found for type 'Wheel'. at ContractConfigurator.Validation.ValidatePartModuleType (System.String name) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.All[String] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at ContractConfigurator.PartModuleTypeUnlockedRequirement.RequirementMet (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.CheckRequirement (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.RequirementsMet (ContractConfigurator.ConfiguredContract contract, ContractConfigurator.ContractType contractType, IEnumerable`1 contractRequirements) [0x00000] in <filename unknown>:0 Rethrow as Exception: ContractConfigurator: Exception checking requirements! UnityEngine.Debug:Internal_LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) ContractConfigurator.LoggingUtil:LogException(Exception) ContractConfigurator.ContractRequirement:RequirementsMet(ConfiguredContract, ContractType, IEnumerable`1) ContractConfigurator.ContractType:MeetExtendedRequirements(ConfiguredContract, ContractType) ContractConfigurator.<ContractGenerator>d__27:MoveNext() ContractConfigurator.<ContractGenerator>d__26:MoveNext() ContractConfigurator.ContractPreLoader:GetNextContract(ContractPrestige, Boolean) ContractConfigurator.ContractPreLoader:GenerateContract(ConfiguredContract) ContractConfigurator.ConfiguredContract:MeetRequirements() Contracts.Contract:Generate(Type, ContractPrestige, Int32, State) Contracts.ContractSystem:GenerateContract(Int32, ContractPrestige, Type) Contracts.ContractSystem:GenerateContract(Int32&, ContractPrestige) Contracts.ContractSystem:GenerateContracts(Int32&, ContractPrestige, Int32) Contracts.ContractSystem:RefreshContracts() Contracts. :MoveNext() I haven't actually checked to see if the wheel-dependent contracts spawn when you unlock wheels, but seeing this in the log makes me think they won't. I know ModuleWheel went away for 1.1, but not sure whether this one is yours or a CC thing. FWIW, this is not the only contract-pack that causes these, RoverMissions is the same. GAP - 1.2.3 ContractConfigurator - 1.10.3, 1.10.4 Kerbal Space Program - 1.1.0.1230 (LinuxPlayer) Much other mod installed, can test with minimal mods etc. if needed.

Already reported I'm sure, here's the log snippets anyway. NoOffsetLimits: EditorExtensions: Start (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) Exception: No such field: EditorLogic#st_offset_tweak at EditorExtensionsRedux.Refl.GetField (System.Object obj, System.String name) [0x00000] in <filename unknown>:0 at EditorExtensionsRedux.Refl.GetValue (System.Object obj, System.String name) [0x00000] in <filename unknown>:0 at EditorExtensionsRedux.NoOffsetBehaviour.FreeOffsetBehaviour.Start () [0x00000] in <filename unknown>:0 (Filename: Line: -1) EditorExtensions: Start SelectRoot2: EditorExtensions: Start (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) Exception: No such field: EditorLogic#st_root_select at EditorExtensionsRedux.Refl.GetField (System.Object obj, System.String name) [0x00000] in <filename unknown>:0 at EditorExtensionsRedux.Refl.GetValue (System.Object obj, System.String name) [0x00000] in <filename unknown>:0 at EditorExtensionsRedux.SelectRoot2.SelectRoot2Behaviour.Start () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Neither of these components are working for me, though the rest of the plugin does. EEX 3.2.1.9 Kerbal Space Program - 1.1.0.1230 (LinuxPlayer) Debian GNU/Linux 8.4

Sounds plausible, stdout: displaymanager : xrandr version warning. 1.4 client has 4 screens displaymanager screen (0)(HDMI-0): 1920 x 1080 Looks like it is getting the display size ok, though the xrandr warning may be relevant. Dunno what the "4 screens" bit is about though, I have exactly one monitor / xorg screen. I tend to run KSP fullscreen anyway, so no big deal. Might try this if I ever feel a need to run windowed. -force-glcore[XX] actually makes certain graphics invisible here, the loading bar and mod UI elements (e.g. AVC) are fine but the loading screen picture & the main menus are missing, so I can't start the game to see what else is affected. Without any arguments I have no graphical issues, AFAICT.

IMO, any "fails to start"/"crashes to desktop" issue should be a release blocker. I was expecting these problems, because I know KSP, and there are always problems. If I wasn't used to hacking binaries and dealing with graphics SNAFUs from all the other buggy releases, I'd be yowling for help with a game that doesn't start right about now. Some warning about the known issues and Unity bugs in the release notes / readme would have saved me some time too. Dunno 'bout you, but to me one crash is one crash too many. Software should not crash, it should throw a scary error if something horrible happens, but not just CTD with "aborted". If yours was the GPU drivers, cool (though the above still stands), but I've had at least one completely unexplained CTD so far, and seen some reports from others too.

Very close to my own experience, though in my case the number of fails-to-start issues was (2). Workarounds employed and all is mostly well, but issues like these make for a less than optimal first impression, especially for such an anticipated release. Largely positive reception, excepting the usual game-engine bugs.

Surprised it's out so soon TBH. Good: Performance, working AA (finally) on Linux, UI overhaul is awesome. Bad: Wheels appear to have the structural integrity of a sugar sculpture, bunch of game engine bugs still unfixed (pulseaudio, windowed mode broken / unable to run at non-native resolution without various graphical/UI glitches, GC stutter still present, seemingly random crashes - e.g. double free() -> aborted ctd.) That's just the few I encountered in a ~1hr first-play on GNU/Linux. Some of these have workarounds, but a working workaround is not an excuse to release with serious bugs - particularly crashes. My very first startup of 1.1 was a crash-to-desktop, fixing that resulted in the game starting, but going spastic with random window geometries, locking input and forcing me to kill it from the CLI. Fixable, but not exactly a shiny first-impression. Overall much pleased with the engine upgrade, though enough issues remain that I feel it could have done with a little more time.