steve_v

For any concerned, the contract pack itself appears to work just fine in 1.8.1. However... I recompiled it [snip], it loads, It doesn't throw any exceptions. YMMV, use at own risk, don't bug nightingale, may contain considerable bees, etc. etc. Guess the first one to Jool gets to find out if it still works properly.

I'll add GNU/linux as an affected platform, and frankly I expect this will be the case for MacOS as well. Looks like someone failed to adequately test the new shiny in this release... Again. As usual. This is why we can't have nice things.

I presume what I'm seeing here is the same: nothing in the log, nothing on stdout/stderr, just a sudden crash entering the VAB/SPH. I wouldn't call it frequent (~every couple of hours), but it sure is annoying. Mods etc. (nothing I wasn't running in 1.7.3, with no crashes at all):

I'm not sure if it's FAR or MechJeb, but something is freaking out and spamming the log constantly when a vessel crashes. This tanks framerate to ~0.5FPS for the duration of the RUD. [EXC 18:18:33.833] NullReferenceException FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0) FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0) MuMech.VesselState.AnalyzeParts (Vessel vessel, MuMech.VesselState+EngineInfo einfo, MuMech.VesselState+IntakeInfo iinfo) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.VesselState.Update (Vessel vessel) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebCore.Drive (FlightCtrlState s) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebCore.OnFlyByWire (FlightCtrlState s) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) Vessel.FeedInputFeed () (at <2c9e31d65a604d1980fb0cb89728fc1e>:0) FlightInputHandler.FixedUpdate () (at <2c9e31d65a604d1980fb0cb89728fc1e>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Any idea who I should be punting this one to? ----Updated---- FAR, Mechjeb, MM and MFI alone reproduce this reliably now. Without MechJeb installed FAR produces no exceptions at all, so the theory that FAR is borking and the exceptions from MechJeb are caused entirely by this doesn't seem likely. MechJeb is likewise quite happy without FAR installed. It's only the two together that cause a problem. KSP.log Player.log Test craft used (also reproduced with the FAR "E42" example craft). Save file Repro: Take off from the runway and immediately bank hard to have the port wingtip hit the ground. Expected result: RUD. Actual result: RUD at 0.5FPS, exceptions logged. Halp?

KAS has winches, winches have ropes... As for how well this might work, you'll have to try it and find out. Given KSPs physics idiosyncrasies I have my reservations.

Gimped, Console-ised controls/UI in a PC release is an instant no-buy for me, just sayin'.

@UomoCapra What exactly is this ugliness, new for GNU/Linux users with 1.8.x? A new ice-age? A borked shader? A complete failure to test on GNU/Linux? What?

Images speak louder than words. 1.8.1: 1.7.3 for comparison: Present in all scenes where Kerbin is visible, other bodies untested. New to me as of 1.8.1, 1.8.0 not played or tested due to being an unmitigated dumpster fire. Not present in 1.7.3. Unmodded. KSP.log Player.log Bug report. Gentoo GNU/Linux amd64 stable, Nvidia 440.44. Anyone know if this is mitigated with settings / driver changes / some workaround? It's ugly, it's distracting, and it's properly disappointing to see yet another borked, untested GNU/Linux release right after the last SNAFU. How do I make it go away? Ed. This: WARNING: Shader Unsupported: 'Hidden/Nature/Terrain/Utilities' - All passes removed WARNING: Shader Did you use #pragma only_renderers and omit this platform? ERROR: Shader Shader is not supported on this GPU (none of subshaders/fallbacks are suitable)WARNING: Shader Unsupported: 'Hidden/Nature/Terrain/Utilities' - Setting to default shader. Appears in my Player.log right before kerbin loads the first time (loading -> mainmenu) with 1.8.1, but not 1.7.3. I know SFA about shaders, but I assume they are in some unity blob I can't get at anyway...

Unless you've installed it incorrectly, no. It does make water drag somewhat higher than stock, because that's what fluid dynamics says it should be. If you feel it needs balancing (and it quite possibly does TBF), the source code is freely available here. I look forward to your contribution.

More content (covers 4/7 poll options): Meh, add it (or mod it) in later. Better graphics: I still play DooM (1). Graphics are overrated. Multiplayer: Maybe. I probably won't use it though. You know what I do want from KSP2? I want a game engine that allows me to build moderately large craft without slowing to a crawl, add a handful of mods without immersion eviscerating garbage collection freezes, and interact with planetary surfaces without encountering ragequit-inducing physics jank.

Get the part name from the error message / log file, and search for that string in the backup you sensibly made before you started deleting things. Alternatively, if it was part of a common mod, you might try entering it in the search box here.

Ublock Origin -> element picker -> click offending popup -> profit. Why complain, when one can simply make it go away?

As there hasn't been an official CLS release since 1.4.x and @Papa_Joe hasn't logged in since December, I guess I'll do that. .dlls only, compiled from https://github.com/taniwha/ConnectedLivingSpace/tree/cls-fixes. No warranty, no support, there until it isn't, get the assets from the usual places.

Only because I find it rather irritating when people post screenshots instead of log files or text listings, thus using 100X the bandwidth to convey 1/10th as much useful information and signifying that they haven't read the self-help stickies. Perhaps I was a little harsh, for that I apologise. Been away a while, sorry it's so late. Recompiling Mapview Mono Sound against the current unity shipped assemblies will probably fix it.

For the record, I just recompiled @taniwhas fork against 1.8.1 / .NET 4.7.1 (I think ), and added some obvious missing references. It appears to work just fine. Not difficult, should hold the impatient over while @Papa_Joe gets an official update together.

You might try setting 'UNSUPPORTED_LEGACY_SHADER_TERRAIN = True' in your settings.cfg. I've never owned anything with intel HD graphics so I'm just poking about in the dark, but it can't hurt to try.

"HP" and "71B" are ringing bells for me, It should be around here somewhere... A bit more than a calculator, and a bit newer too, so that might be fitting as an age-clue. I've never seen any core memory in person, but I was working on a machine with 4k bubble memory modules not a month ago. That stuff is like rockinghorse s* these days, and just as expensive.

It was a suggestion on where to copy your install to. C: is a disk, KSP.bak is a directory.... you know, simple entry-level "how to use a computer" stuff. So am I, this is painful and my patience is at an end. Still no logs either... It's this kind of thread that makes me question responding to support requests at all. They always end up making me want to punch myself.

You can help yourself, by not running outdated mods. I'd point out which of your mods are not built for 1.7.x (let alone 1.8.0), but since you've posted a lazy screenshot rather than a logfile and so I can't see version numbers or what is generating errors, that's a proper chore. Mapview Mono Sound in particular hasn't been updated since 1.3.1, and if not compiled against the correct KSP version is quite likely to cause this kind of problem. Ditto for anything else that messes with sounds. If that's not it, and you insist on running mods not built for the game version you're running, you'll just have to work out which is causing your problem by removing them one by one until it goes away.

I was referring to when Activision and Blizzard were separate entities, I've never played an Activision-Blizzard game either. They seemed okay in the late '90s/early 00's, but I only played a couple of the games they published.

The sad part is that all of those companies used to be pretty awesome, back when games were mail-ordered on physical media. Seems like all the big game studios are hell bent on behaving badly these days, I don't know if it's just a symptom of success or what. I truly do not understand this aversion to DLC that keeps springing up around here. What's wrong with charging for additional content beyond the base-game? Content costs something to make, right? Would you really prefer that cost was added to the initial price of the game instead? With KSP as an example, I haven't bought the DLCs because I don't really want what they bring (and mods bring it better anyway). You don't have to buy DLC either. It's a different story if the core game is intentionally crippled without it, or it gives a competitive edge in multiplayer, that's screwing the customer. We'll just have to wait and see.

Sounds straightforward enough to me, make a copy of your KSP install directory somewhere outside steam, then launch the game from there. Presto, non-steam KSP install to test with. The point of this is to stop steam from a) updating the game when you least expect it, b) putting files you remove back in again and thwarting your troubleshooting attempts, and c) loading a bunch of other stuff like steam libraries and overlays that muddy the waters when trying to locate a problem. To be fair, it's unlikely to solve this, but it's a good idea anyway and it won't hurt to try it.

Read the support sticky I linked and follow the instructions, then report back with the information you collected. This is what I mean by not listening: You you clearly didn't read the thing I linked for you to read, or we'd be seeing some logs here and maybe even be making some progress. We're all volunteers, most of us are patient, but please try not to make us repeat things ad-nauseam. Also try VoidSquad's suggestion, as it will stop steam from trolling you as it as it likes to do from time to time. Even if it doesn't solve the problem, It can't hurt.

Read it, then do what it suggests re. uploading and linking logs and system info. LGG informs me that the logfile name has changed to Player.log on all platforms as of 1.8.0, the location remains the same.