steve_v

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.

In case someone else runs into it: I just loaded up 1.1, after all this waiting... to be greeted by a wildly resizing black window leaping all around the screen and locking input until killed from the CLI. Logs show KSP switching between seemingly random window geometries. Doesn't crash the WM (KDM), but still freaks it out badly. Solved by setting fullscreen=true and native resolution in settings.cfg. Windowed mode is just all-around broken it seems. Haven't we just had a pre-release for these issues to be found and fixed? Debian 8.4 / KDE 4.14.2 / NVidia 364.12

I've been wondering if anything was going to come of that "new forum issues/suggestions" thread we had when this IPS thing first turned up. Has it been long enough now to conclude "suggestions made, bugs reported, no-one plans on fixing anything"? The eye-burning theme was mentioned repeatedly, along with the incredibly slow JS, glitchy & slow editor, half-arsed BBCode support... And the totally broken mobile interface (try quoting someone on FF/Android, it's "fun"). For the colours, this stylish theme works ok. For everything else, sounds like it's the usual story: "It's a Unity IPS problem, nothing we can do"... which makes me wonder who selected this as a replacement for VB.

The physics engine in 1.0.5 is old, slow and (mostly) single threaded. Your performance is about what I would expect with 1288 parts. 1.1 is reportedly better in this regard, and should use your other CPU cores.

Agreed on the new button. @Matuchkin: Eh what? You can't be serious. Do you not like free crayons?

Working patcher = minimal load. Working patcher = not doing full DLs. From the looks of things those update patches are generally <100MB. Working patcher = everyone on the same version, no fetching required. The distribution / bandwidth concerns are valid at the moment. However, I distinctly recall bringing up the broken patcher several times over the last year... and being largely ignored. This is frustrating, as fixing that would have avoided the whole situation.

Annoyed. I could just buy the game again on steam I guess, but paying ~2x the going rate for what steam users get included in the ticket price? No. On principle.

It's really not. Perhaps one should wait until 1.1 is actually released before starting 1.2 "new parts" hype?

If by "spreadsheet" you meant "Microsoft Excel", that's pretty much my definition of "weird unfamiliar program". Also, that spreadsheet needs a GUI... and several thousand times more CPU work than the original task, just to open it. Inefficient, most inefficient. But eh, use what you know, I guess.

Thanks. Though that is 180 (non whitespace) characters to to my 35, in bash. The day I need a spreadsheet to do a batch rename is the day I go looking for a better way.

I stand corrected. I was close. --- And just to be an ass, does that zero-pad the names, like 01, 02 etc.?

That batch file 'aint automation, it's just typing into a file rather than the prompt Been a long time since I did any scripting in Windows, if you have a method for consecutive renaming of files (and I bet it's more typing than bash brace expansion), would you not just replace the "copy file" bit with "recursive copy directory"? My vauge memories of DOS say that would be the 'xcopy' command? Is such a simple task really so hard in Windows? surely there's an equivalent to {01..99}... I know it has for loops. You could just install bash in cygwin. This looks like a lazy method, though I have not used it. Now I am so very glad I use a real shell. --- Google says it would be something like: for /l %x in (1, 1, 100) do xcopy [path]\texture00 [path]\texture%x where (1, 1, 100) is start, step size, end. But don't quote me on that.