steve_v

Yeah, I7-4960X on an ASUS X79 board, essentially an unlocked Ivybridge-E Xeon. They overclock like a champ too, I could actually get more out of this one if I was willing to deal with the heat. Real shame the Xeons are locked, innit? Lucky sod. I've been thinking about upgrading, but TBH I can't justify it since the only workloads that show it's age are KSP and X4, and an upgrade that would be satisfyingly noticeable would also be pretty expensive. It's been on the "soon" list for a while now. The graphics usually isn't the problem, the CPU is. If KSP2 has a similar physics system to KSP1, that won't change and no amount of low-spec friendly graphics settings will have it run properly on a crappy laptop CPU. Most laptops are not remotely designed for gaming anyway, so trying to game on one is going to be suboptimal whatever you do. The only way to fix that would be to remove the signature rigidbody physics simulation, and at that point you might as well be playing SimpleRockets. Gimping the game and removing features for potato-compatibility is a big fat No.

[Snip] As this clearly concerns the SSTU (WIP) mod, perhaps you should consider asking in the SSTU thread?

Nope.

Quite possibly. MiniAVC has thread safety issues and is known for crashing KSP >= 1.8.0. Usually it's early in loading rather than at random, but it's best to be rid of it in any case. It does. As for KAC, I've been running it in 1.10.1 (GNU/Linux) for some time now, and I've not had a single crash, nor any problems with it.

Again? How are so many turning up with MiniAVC still installed?

You have MiniAVC, kill it with fire. Do this first. Either something has a lock on the file, or there are permission problems in the KSP root. Move KSP install out of Program Files (or any other system protected directory), disable virus scanners etc, see if this goes away. If it doesn't, do a clean reinstall of KSP and try again. Back up your existing install first OFC. That there is a failure to load a standard .NET library. Odd. Could be a corrupt install, could be a dodgy .NET environment. Never seen that one before.

KSP >1.9.1, right? They're all indexed, but the windows version has its max KSP version set to 1.9.1, where the others have no max version set at all. The topic title lists AFBW as 1.9.x, so I assume it's the latter that is in error.

That's... Proper dastardly. Find another host level of dastardly even. I have personally have a seething hatred of automatic "helpers/fixers" in software in general. I don't mind being informed about potential mistakes, but any and all fixing must be confirmed by the user, especially if it has the potential to touch many files. "MSDOS linefeeds detected in the following files: [], proceed anyway?" would be fine. "Hi there, we fixed up some files for you" would most definitely not. Mangling file encoding silently is cause for tarring and feathering the developer responsible. Off topic, the same goes for the "friendly helpful computer" approach many large software developers seem to be taking with user interaction in general (and error messages in particular) - I expect a message from an application or OS to contain enough information that I can act on it, not treat me like a bumpkin and offer nothing beyond a meaningless spinning graphic or a sad face emoji and a "send report to <some ******* company>" button. I installed Winblows 10 in a VM the other day, and the vacuous, unctuous, meaningless "We're just setting up a few things", "Leave everything to us", "Would you like to talk to Cortana" and the like had me trying real hard not to throw up in my mouth the whole time... Oh, and the installer will merrily "fix" your bootloader configuration for you too, without a word. :rage:

So would I. I hit up KerbalX and sorted by part count for this, since I didn't set out to bench KJR specifically and just went for "things that will thrash the physics sim". Finding KJRn as the biggest perf hog was a surprise. It's entirely possible that my results are skewed by this indiscriminate test-craft selection, as they are all pretty heavy on surface attachment. If you have a craft file more representative of normal (i.e. not building ships) gameplay I'm happy to try it.

They are, but there's a handy mitigations=off kernel command line switch. Fascinating I'm sure, but you're talking abut the performance of KSP across versions and hardware generations. I'm talking about the performance of KJR forks on the same KSP version and hardware. 1.10.1, which means Unity 2019.2.2f1 IIRC. No excrement. I've been running Gentoo since 2003, and LFS before that, so I'm quite familiar with compiler optimisations (and the pitfalls of such). What do GCC optimisations have to do with KJR? Both of these are in my initial post on the subject: I can flick you the craft file if you want, as well as any logs or whatever else. You didn't ask. I7 4960X @ 4.3GHz all cores, no turbo limits, HT on. 32GB DDR3-1600CL9. X79. Quad channel. GTX 1070 8GB discrete. Starwaster's KJRc build from the KSP-RO repo (the only 3.5.1 I am aware of) works fine with stock robotics. I haven't used IR in years. Which is... Why I posted my results in the first place. It is entirely reasonable to call them no longer valid if benchmarks in the current game version indicate so. Like I said, it works for me with stock robotics. I haven't specifically tested for robotic joints being wobbly, but if they are it's a fair trade for the performance differential. I doubt robotics has anything to do with it anyway, as none of the craft I benched performance on have any robotic parts at all. No. Tests with KJRc and KJRn are with identical unmolested craft from KerbalX. They may have autostruts, but given the wet-noodle behaviour without KJR (either fork) I doubt it. I guess autostruts could be causing problems, but then they'd be causing problems for both KJR forks.

Eh? It's a 7 year old CPU... Is the "average gamer" running KSP on a z80 or something? Well... I guess I do have mitigations disabled on this box, and it has slightly nuts memory bandwidth for it's age... But still, 7 year old CPU. Is KJRn using some fandangled new CPU instructions KJRc isn't? AVX2 math all over the place? Custom asm86 core? Magic code that runs slower with retpoline off?.. I thought not. So why the discrepancy between the forks, on the same not particularly unusual commodity hardware? I'm not really interested in numbers to show to the general public TBH, otherwise I would have done more extensive benchmarking. What I am interested in is why, in the specific scenario I tested with, KJRn performs significantly worse than KJRc. FWIW I actually see similar results in lower part-count general gameplay as well (and have for several KSP versions at that), but I didn't mention it, because uncontrolled benchmarks with a bunch of other mods installed are kinda useless. Telling me that all benchmarks are invalid unless they cover every possible configuration is pretty darn unhelpful TBH. If that was the case, any and all claims to improved performance (as in the OP) would be equally invalid, and we'd have to just throw our hands up and abandon testing as an impossibly time-consuming task. Indeed. If that's the case, it might be time to revisit the supposed performance improvements in KJRn... Which is kinda why I posted those numbers to begin with. If the cost of dynamically detecting robotics parts is ~9FPS, I'll take the ugly old manual blacklist method any day. That's all well and good, and I'm sure it was faster for you at that time. My question was: Why is it not faster for me, at this time? Is it broken on KSP1.10.1? Does it need some work for game engine changes? What? The OP claims general performance improvements, not "May be faster on particular hardware when the wind is blowing north-east, for a limited time only", or "Designed to perform better with KSP 1.7.x on Macbooks"... Yet as of right now, on my rig, it imposes double the performance penalty of the old version. Something is clearly up. If I'm just going to be brushed of with "stuff changes" or the old favourite "It must be your PC", then I'm bound to assume KJRn is now broken as far as it's stated goals, and go back to Ferram's demonstrably better performing implementation. I don't want to, but the numbers don't lie, and an extra 9FPS at 550 parts is not something I'm going to turn down. Ed. On a completely unrelated topic, I finally got around to properly exploring your website... It's quite interesting.

Pretty much anything that has a high heat-flux will get nonsense numbers on physics load sooner or later. KA/NF reactors are a prime culprit, but enough stock heat sources or, as you say just being close to the sun will do it too. Kerbal. Jank. Program. I guess one low-mass part not making your entire craft explode randomly any more is progress though, or as much progress as we can expect in this never-fix-anything-properly game. Kinda telling that you still have to use the debug menu regularly after 9 years of development...

Integration into CKAN would work either way. Where to put it isn't really the problem as I see it, more: Bags not going anywhere near coding a log analyser intelligent enough to be properly useful, they've been tried before, and they always suck. A simple "X plugin is barfing some NREs" might be marginally useful, but then we already have ExceptionDetector. For more complicated cases, sooner or later you're going to run into one that requires you to backtrack way up the log to that tiny innocuous looking warning that made everything explode... How ya gonna reliably automate it? How much context do you include? What about unholy interactions where your first clue is a perfectly normal looking info line? If I'm looking for a problem I'd rather get the whole file any day. IME nothing really beats grep, awk, a mk1 eyeball and a well caffeinated brain. You're going to want the whole log file eventually, why not just ask for it to begin with?

Uhh, get a machine that's actually designed for gaming? An I5 is fine, a low-power laptop I5 is not. Age isn't the problem, the fact that it's a low power mobile CPU is. The integrated graphics won't be helping either. I'm still running a processor from 2013, and KSP(1) runs pretty well, all things considered... But it's a 130W hex-core clocked to 4.3GHz, not a 35W dual-core with ultra-conservative turbo limits and rubbish cooling. Expecting KSP(any) to run well on a laptop is a stretch. Expecting it to run well on an old, decidedly-low-performance, definitely-not-gaming laptop is futile. Ed. Going from ivy bridge to comet lake at comparable clock is probably going to be somewhere around 20% single-threaded performance improvement. Nice, but not exactly astonishing, and I'm sure a decent ivy bridge CPU will run KSP2 just fine.

I'm pretty sure it's just because you're playing Kerbal Jank Program. With a stock install the thermal system is (now, finally) mostly stable, most of the time... But as soon as you add anything that stresses it, the cracks reappear. A solution is coming. All hail Nertea.

Right now it's looking like the usual development decisions driven by a big "AAA" publisher. Independent studios sometimes design with Mac/Linux support in mind from early in development, but from what I've seen everything controlled by a big publisher seems to take the "Promise nothing, get a Windows/DX build out as fast as possible, consider porting later" approach... Usually meaning a half-arsed effort or no port at all. That said, it's another Unity game, and that makes cross-platform pretty easy. We'll see, but given TTI is calling the shots I'm not optimistic.

Well, xz is just LZMA and so is 7zip, so results should be similar. Converting people to 7zip is pretty much a public service anyway, is it not? I'm not convinced that "download and run this tool, post results" is that much easier for the unwashed than "download and install 7zip, compress log", and it's sure more work for whoever gets to write the (cross-platform) preprocessor in the first place. Off topic: Here's some benchmarks on lrzip, a tool specifically designed for compressing source code. Results are impressive to say the least.

Less so with a halfway-decent compression format. xz and zstd both consistently hit 5-6% on KSP logfiles for me, and I'd expect even better if that 600MB log is mostly spamming the same NRE (and even better again if using lrzip). Repeated short text fragments are basically decompression bombs anyway. 35-40MB compressed is still annoying, but it's quite suitable for any old filesharing site. ED. Yeah, just grabbed a 120MB KSP.log I had laying around and fed it to lrzip... 3.19MB compressed.

Uhh, erm, well, ahh, that's not quite what I'm seeing in game... KSP 1.10.1, 553 part random "battleship" from KerbalX (lots of surface attached wing & structural parts) sitting (half) on the launchpad. Stock: 49FPS + KJRc 3.5.1: 41FPS + KJRn 4.1.15: 32FPS I thought you were making fewer joints, and that should improve performance, no? Any idea what's going on?

Citation required. Vulkan (spelt with a 'k' BTW) works swimmingly over here on an Nvidia GPU, and unlike DirectX[whatever] it's an open, manufacturer and platform agnostic API. It's also faster (in terms of CPU overhead) than DirectX or OpenGL, at least when implemented properly. Vulkan sure would be nice, but It doesn't sound like KSP2 will support it, at least not at launch. Then again It probably wont have GNU/Linux or MacOS support either... In which case I really don't care since I won't be buying it.

Why yes, yes it did First things first, Atmospheric Sound Enhancement is borking badly: Probably because it hasn't been updated since... 2015. Why on earth do you have such an ancient mod installed? You also appear to have MiniAVC, I'm not sure if it's problems have been solved or not, but it was standard advice to remove all traces of it for a while. Other than that though, I don't see a smoking gun for an out of memory situation (as is the topic of this thread). A bunch of NREs to be sure, but no allocation failure. Is that log from a run that crashed or what?

Something strange is going on here. ¯\_(ツ)_/¯

2 words, 200 bytes, sure doesn't look like a log file to me.

Finally, someone else reporting this. HerbalHealth has been sporadically freaking out like this when entering physics range for rather a long time now, at least since 1.3.6 / KSP 1.7.3, but I've never managed to grab a clean-ish a log with debug enabled, or reproduce it in a minimal modset. I've mentioned it here before, but since nobody else has I had assumed it was some unholy interaction. Here's a probably-not-very-useful log without KH debug anyway, I'll enable debug in hopes of catching it again next time I'm doing some landings.