steve_v

Poked him some (long) time back, but never really got a quantifiable answer. Without an easy/reliable way to stick it to any particular mod I'm disinclined to hassle more, Sarbian can be a little, er... irritable at times.

Without seeing your log file, I'd guess the game was running up against the 32bit address space limit trying to load the additional textures -> out of memory -> crash. This used to be the #1 cause of all crashes before 64bit builds were available, and the #1 reason for switching to GNU/Linux, which had stable 64bit first . Agreed, though it would kinda require dropping 32bit support. The game is pushing it as it is.

Overall run time / time per operation against object allocation rate. Yes, I have managed to break GC entirely by enabling parallel mark. This working with Sgen would be one of the requirements for "dramatic improvement". I know. But what are we going to do, line all the devs up and flog them? But it isn't...

If you mean 32bit vs 64bit, they're separate binaries: $ file KSP.x86 KSP.x86_64 KSP.x86: ELF 32-bit LSB executable KSP.x86_64: ELF 64-bit LSB executable Just ensure you start the right one. Or set that steam thingamajig to start the right one, if you use steam. If you mean release number, game version / build number is in BuildID.txt, and in-game on the lower right corner of the menu screen. Now that you know where the issue lies, (and once you are sure you're not running 32bit and simply out of memory address space) It might be worth a shot to ask (and post logs / mod list etc.) in the relevant mod release thread.

or

In the log, for a start. It may be obvious. Also make sure you are running the 64bit executable. Better to do a binary search, remove half your mods and test, half again etc... until you can identify the culprit.

As it's not available in Unity, I clearly cannot benchmark it to provide hard numbers - hence "liable to" rather than "will". Every benchmark or comparison I can find (for reasonably complex workloads) shows monos sgen significantly outperforming the old boehm implementation, and coming pretty close the performance of .NETs GC. What makes you think that this won't apply to KSP as well? Surely there is something to be gained with a generational, multithreaded GC - even a minor improvement in the time taken for a collection run is worthwhile here. If you can keep the allocation rate low enough (and the nursery size large enough), you might get away with very few full collections between scene changes. If mod code is generating 200MB/s, I doubt any GC will deal with it without a significant performance overhead... But I'm not seeing anything like that rate, and I would be surprised if this was the norm. What I am seeing is noticeable stalls starting at 1/10th of that allocation rate - and it's the time these last that makes it a problem.

3 things: 1) You're redistributing copyrighted Squad assets. 2) Part descriptions are full of gratuitous profanity. 3) This could all be better done with a simple ModuleManager patch, which would avoid (1). Other than that, cheat engines? Yawn.

This is true, however my point is that in Unity it is obtrusive. The Boehm-Demers-Weiser algorithm, while simple to implement, is absolutely terrible for real-time performance-critical applications... like games. Unitys runtime sucks because it's ancient, and its simple GC algorithm is not suitable for games. It's not even multi-threaded, something mainline mono has had for years. Writing better code is only part of the solution, we also need a better GC... like Sgen, included in any recent version of mono (and experimental in the version Unity uses, before unity messed with it). It's not perfect, but it's a whole lot better than what we have now, and it's liable to dramatically improve this situation.

IIRC, ContractConfigurator can disable stock contracts by category, in the difficulty settings. Not as fine grained as this, but it's something.

I once did a binary delta between releases, just to show how much pain time a decent patcher would save (and refute SQUADs claim that non-steam prerelease builds would chew too much bandwidth), the results were impressive to say the least. I have here a patch I just whipped up, with minimal effort and a free cross-platform tool, for ksp 1.2.1 -> 1.2.2. It's 113MB. Does a 113MB download sound better than 1.9GB or what? C'mon SQUAD, if I can do it, so can you. Why windows only binaries?

I'm sure there are, and when they are advertised as such and I can filter by this criteria, I might consider using it.

I really would not have. I simply do not buy games that are steam-only, and I will not have steam (or any other DRM) on my system. This includes (in the case of KSP) using it only as a distribution method. AFAICT, the patcher itself isn't actually broken (and it's code is totally unchanged since initial release), the issue is that nobody is maintaining the (r)sync server. At this point I'm just going to call it oughtright laziness. Removing the button from the launcher would take less than 5 minutes, yet neither the launcher nor patcher have been touched for several releases. I have filed two bug reports relating to the patcher myself, care to guess how old they are?

I would certainly prefer it was fixed. As it stands, non-steam, non-windows users have no update mechanism besides a complete re-download. Some people have limited bandwidth or data-caps. For some reason, the devs appear to be either allergic to, or incompetent with, native code - especially cross-platform native code. The launcher is built in Unity (which is a properly queer decision in itself), and the only native code ever shipped with the game (the patcher) has been an ongoing disaster. If I (or any other semi-competent schmuck) can replicate a running webserver with rsync, I really don't see how fixing this thing can be so hard - especially as the only custom code is the Qt GUI, and cross-platform UIs in Qt are about as hard as falling off a log. There are executable patches on the download page... if you run Windoze. Otherwise you are SOL.

The updater has been horribly broken for ages, AFAIK the person who wrote it no longer works for SQUAD, and those who currently do appear to be either unwilling or unable to fix it (which I find rather ludicrous, it's just an rsync frontend). This has been pointed out over and over, caused a minor riot on the forums when a beta was released to steam users only (excuse, no patcher ), was supposed to be fixed for the next update and wasn't. Now we have binary "patches" for windows only, while the official update method built into the game launcher remains broken. What a shambles. @SQUAD: If you really can't fix the patcher please remove the damn thing, save people this confusing hassle, and save yourselves the egg-on-face of shipping broken software with every release.

Yeah, not much has changed. I'm sure SQUADs "garbage reduction" efforts are nice and all, but this BS performance is what has killed my career saves over and over. The best bit is that it gets progressively worse as you have more craft in flight, effectively killing any chance for an enjoyable end-game. Blaming mods (e.g. mechjeb) is all well and good, and often it is indeed mods creating garbage... but the simple fact is that the runtime sucks. What is the point of a fancy memory-managed modding language if using it as intended (without jumping through hoops, and avoiding half the features) murders performance? We will remember you, KSP: A beautiful concept, crippled by it's shoddy game engine. Such has been the state of things since day one.

Run your own, on your home connection. That's what I do. Just make sure you lock it down. I have pretty much zero trust in "free" proxies, but setting one up yourself isn't that hard. Though if your system is as locked down as it sounds, I'm surprised you have access to proxy settings on your work machine at all.

Much the same way you are going at it - with a light plane. With a sufficiently low stall speed, one can land on top of a mountain in this game. Not saying it's easy, but it can be done. 'chutes help, the small landing gear being rubbish since 1.1 doesn't. Make the lightest aircraft you can, and taxi with care. Once you get the small deployable gear this becomes much less frustrating. I've never really figured out how these contracts were intended to be done, accurate landings are one of the most difficult things to do in game, decent wheels are way up the tree, maybe you're supposed to do it with rockets... but then not much in career mode makes sense, so ¯\_(ツ)_/¯.

My "Hybrid" storage setup is 2 SSDs (OS/home + games), backed by a 24TB ZFS pool over dual gigabit ethernet. Windows on the other hand gets an ancient mechanical drive, as I boot it about once a year. Maybe... depends how fast a drive you're talking about. I've never encountered a mechanical drive that can saturate a SATA link. More likely it's going to be the drives R/W throughput or IOPS that is the limiting factor. You might saturate a SATA link with a decent SSD, but do you really need more than 6Gbps on a desktop? Indeed, and on a mechanical drive it's the seek contention that's the killer. Not such a big deal on an SSD though. Depends on what kind of RAID you're talking about. RAID0 will give you double the performance of a single drive at no added cost over using two separate drives... but with half the reliability. If you want a wickedly fast scratch disk (or have a good backup system) RAID0 a pair of SSDs. RAID1/10 can double read throughput & IOPS (but typically not write), and provides redundancy, but it is more expensive as you sacrifice half the storage capacity. Other RAID layouts (and advanced filesystems like ZFS & BTRFS) provide different price/performance/redundancy compromises. In practice, most RAID setups are for redundancy, not performance.

Nope. Eh? Why would I use that horrible platform?

Nothing in that log looks like an OOM to me. There are, however, a whole lot of mod-related errors, so I'd guess it's a mod-related crash. Best bet is to do the standard "remove some mods, try again" procedure to narrow down the culprit, starting with those throwing errors.

Craft shape based, rather than part based drag/lift/occlusion model. e.g. FAR. Parts lift based on shape, not arbitrary "lift rating", adds ability to make ad-hoc cargo bays, removes all issues with simplified stupid cargo bay occlusion model (no more "cannot deploy while stowed" BS), makes things that look aerodynamic behave as you would expect, removes all wierd drag behaviour of open stack nodes & surface-mounted parts (e.g parts angled to follow contour produce excessive drag), fixes unexpected drag of clipped parts (e.g. parts inside hollow adapters). Probably more advantages I can't put my finger on right now. Why does it need to be simpler? FARs approach works great, and I dont see a significant performance impact.

32GB RAM, 8GB VRAM. Not installed. I7-3820 @ 4.2GHz, 32GB RAM (Quad channel), Nvidia 1070 8GB, Debian GNU/Linux. 65 mods, ~60FPS. Add KK/K-S to that and I get ~25FPS. Kerbinside = ~35FPS hit, regardless of what else is installed. This is a bigger performance hog than SVE+Scatterer. Unacceptable performance in 1.0, unacceptable performance now. What I don't get is why, a few more models in scene shouldn't tank framerate this hard.

First up, run the 64bit version, assuming your OS is 64bit.

It does: It's moved to the stock difficulty settings page, and there's also a debug interface at Mod+F10.