steve_v

FTFY.

Because @sarbiancelebrates cat day, and so should you :P

My desktop is running two SATA SSDs in a striped vdev (roughly equivalent to RAID0), and pretty much everything else is on a hybrid pool (24TB mechanical RAIDZ2 + 240GB SSD adaptive read cache) over NFS... Including regular snapshots of that fast-but-fragile RAID0. I've just about completely transitioned to ZFS as far as filesystems go TBH, nothing else comes close to the featureset or flexibility. One day I'll upgrade the desktop to something that actually has M.2 support, and no doubt that'll be ZFS as well. As for boot times... Err, what boot times? I think the last time I rebooted anything was well over a month ago. :P

Voxels are recalculated by geometry changes that FAR is aware of... Which doesn't include the BG robotics, because Squad didn't include an event that FAR can use to detect that something has moved. IIRC the current workaround is to toggle the lights after moving robotic parts.

I see. We're lust talking about asset compression and the like, not actual block-level optimisation. Sounds like a fairly trivial change to me, though frankly I could do without the storage bloat uncompressed assets will cause. Recon I'll take slightly slower loading over twice the footprint anyday, and just keep the filesystem-level LZ4 compression I'm already running.

There are 2 machines on this desk right now, standard ATX and E-ATX respectively. Well if you want a tiny board, compromises are going to be made. I really don't get why anyone would care how "neat" the inside of a PC case is, once the covers are on nobody sees it. As for cooling, if a couple of dinky little SATA cables create an airflow problem there's something seriously wrong with your cooling solution. This old thing (since upgraded) has 2 CPUs, a non-modular PSU, no fancy cable-hiding compartments, 13 SATA cables... And zero cooling problems. I've also upgraded the appallingly horrible camera that took that.

Yeah, I still spend hours reading manuals, trawling forums and poking the thing with a stick before I'll admit defeat and post a question. I just kinda assume that's the way it's done, the whole learning something in the process bit and all that. Kinda makes me wonder just how screwed the google/social media generation would be if the internet went away for a while...

I should probably clarify that: What I'd really prefer is an additional PCIE slot or two on the mobo rather than a dedicated NVME slot. If the majority of NVME drives were PCIE cards that's what we would have got. It's less about the NVME form factor itself, more about the continual erosion of the original role of a motherboard as a dumb backplane and incessant addition of extra (and rapidly obsolete) crap to it. I don't want motherboard audio, video, wifi, or idiotic RGB lighting either TBH, just give me standard expansion slots so I can add the things I actually do want... Like a nice SAS or FC HBA and a DAC that doesn't sound like a rat in a cake tin. I remember when a motherboard didn't have any storage interfaces built-in at all, and you added the IDE/FDD controller as an ISA card. Hell, I've owned machines where the CPU(s) are on expansion cards. One or two NVME slots on the board gets me one or two drives, in a ridiculously difficult to get to location. One PCIEx16 slot gets me somewhere to put an HBA that can serve 8 or 16 drives that I can then mount in a hotswap cage where they belong. Guess which one I'd prefer. Enough off-topic though, back to the scheduled broadcast.

As @jimmymcgoochiementioned, the log file(s) are far, far more interesting than the in-game debug console. A screenshot of your GameData doesn't list mod versions either, and those are important. ReflectionTypeLoadException(s) are indicative of missing or incompatible mod DLLs, but we'll need the log to tell which. My bet goes to incompatible mods installed, possibly due to a braindead steam "auto update"... I.e. the usual. How does everyone keep missing that big fat sticky "we need logs and list of mods with versions" thread anyways?

Because marketing, and because it looks way cooler? Of course it can. my machine runs it's 100Mhz CPU at 33MHz with turbo off, and it most certainly is slower. The implementation varied, but the majority of 486 and early pentium machines just cut the clock multiplier as you say. Many ISA-only 286 and 386 machines actually ran at 4.7 or 8MHz (the original purpose being 8086 performance) with turbo off, but to get that low on a 486 you'd need to change the bus speed, and that louses up VLB and PCI cards. Also, most (ISA) 486 boards could do a 16 and 25MHz bus as well, hence the availability of SX-16, SX-25 and DX-50 CPUs. When PCI came along, it's 33MHz bus became the de-facto minimum.

That's, ah, not exactly how I remember it... And it seems wikipedia agrees with me. The turbo button is actually there to make the system slower. Disabling turbo was what we did to run properly old software that used a CPU dependent calibration loop, most commonly thwarting the dreaded borland pascal runtime error 200 or getting old games to run at a playable (i.e. not insanely fast) speed. Later came moslo for the same reasons. I still have a machine with a turbo button (486 DX4-100), and when it's enabled the system runs at the rated 100MHz clock, not overclocked. I guess you could set a system up so turbo-off is stock speed, but I've never seen it and frankly I doubt you'd find a 486-class CPU that overclocks that well. The LED display was kinda cool in any case, even if it was entirely fake and just set with jumpers behind the panel.

600MB/s (SATA 3) is fine for most tasks, since most tasks care about latency and IOPS far more than raw bandwidth. KSP with both expansions is ~4.8GB on disk (or 2.8GB in my case, thanks to ZFS/LZ4 transparent compression), so at SATA speeds loading should take less than 10 seconds if IO bandwidth is the bottleneck. That said, the PCIE bus is absolutely the way to go for local storage. It kinda annoys me that it's in the form of a special connector on the motherboard rather than an actual PCIE card, but whatever. I'm in no hurry to upgrade. I fail to see how one would go about optimising a game for SSDs anyway TBH, unless you're working at the block level and you're almost certainly not going to bother with that krakens for a game. On any mainstream OS almost all applications (the exceptions are largely specialised forensic or data recovery tools), including games, have no idea where or how their data is stored on the hardware. That's the kernel/IO scheduler/filesystems job.

[snip] Fan? sure. It's a good game. It's also full of bugs, janky as hell, and suffers from various performance problems - most of which I have commented on in this forum before [snip] Scene loading taking 45 second's just isn't one of them. Either you're exaggerating wildly, or there's something else going on. Neither is call for rewriting core game systems in such a complicated way, especially considering all the new bugs it will inevitably ship with.

Personally I think Lights Out, Editor Extensions, and RCS Build Aid should all be stock construction scene features. I'm not going to hold my breath though, considering how it took to get a stripped down KER into the game.

A good thing medical research and the actual processes behind vaccine production and testing are not under the direct supervision of the idiot politicians who let this get out of control then, innit? Seriously though, even if a vaccine is rushed into production before final trial results are known, the worst that's even remotely likely to happen is that you get something that doesn't work as well as hoped. Nobody is going to put anything completely ineffective or dangerous into production, no matter the political pressure. Especially not a for-profit corporation, the backlash would utterly bury them.

Ridiculous, illogical, and properly infuriating. Not particularly surprising though. Meanwhile, living on an island has it's perks. I imagine the arrival of a vaccine will be instructive as to just how many pig-headed wilfully-misinformed idiots live here too. Where there are people dumb enough to set fire to cell towers (because 5G mind control or some such nonsense), I'm sure there are considerably more who are dumb enough to refuse modern medicine for similarly moronic reasons.

You must be running the game on a mechanical drive from 1994, installing every single mod on CKAN, or there's something horribly wrong with your install. I have never seen scene loadingtake anywhere near 45 seconds, and that with 100+ mods and on hardware inferior to yours. Also, this ^

Yes. Multithreading is hard to begin with, and it doesn't work at all (or doesn't bring any benefit) for some applications. The physics engine KSP uses is one of those, and I expect KSP2 will be the same. Aside, shouting is obnoxious. Please stop.

With the instructions in the thread I just linked and your image manipulation software of choice. MS Paint for example.

I don't think you can add a patch to an existing suit in game, but there's no reason you couldn't make it part of a custom (or modified stock) suit texture.

It's exactly as simple as building for any other platform. The difference is that bugs in the binary that the "build for Windows" button produces actually get attention, both from the game developers and upstream at Unity. The GNU/Linux and MacOS output, not so much. The vast majority of bugs in KSP affect all platforms anyway, the only reason there are a number of outstanding GNU/Linux specific items on the tracker is because nobody is doing anything about them. To be fair, at least half of them are Unity bugs anyway. Absolutely. The best (code) modders tend to be hobbyist hackers*, and those tend to gravitate towards open-source hacker-friendly platforms, for fairly obvious reasons. Without them we wouldn't have such influential projects as ModuleManager, MechJeb or CKAN, among countless other mods. Mods that directly add value to the game at no cost to the company. Hopefully there are some beancounters at Take Two who can see that, but TBH (experience breeds pessimism) I expect the corporate mentality (for a game publisher apparently synonymous with "buy out the competition, work the devs to burnout, and squeeze the customers for every cent you can") is too ingrained to see beyond short-term profit predictions and franchise potential. *Because mass-media and general stupidity, I guess I should link the definition to avoid the inevitable outrage. Sigh.

Another barely-tested .0 KSP release, more buggy new features (which were already available as established mods, sans bugs), more regressions in existing systems. Game settings still not working properly, orbits still flickering, stuff still sliding around, wheels still horrible. Obligatory .0 release gamebreaking bug present. Yawn. Wake me when we get a proper bugfix release. At this point I'm not even going to bother with a list of all the borkage I found in my ~1 hour with 1.11, let alone file reports. I'm over it, it's utterly futile, nothing gets fixed properly and every new release comes with new regressions.

I don't own (and never will due to stupidity exactly like this) a Mac, but that sounds very much like the new "gatekeeper" features in Catalina blocking the app because it's not from the app store or signed by an "apple verified" developer. Whether there is a way to get it signed is probably a question for the Squad support channel (email from the KSP store etc. etc.), but if it were me I'd just flat out disable the intrusive security. Whether you are comfortable with neutering gatekeeper to allow installation from "unidentified" sources is up to you, but even if you try it and put it back again after at least it'll definitively identify the problem. Someone with more MacOS experience may have a less drastic solution.

Indeed. I've seen long-running KSP instances at ~28GB just before the OOM killer nukes them. IME it also starts to get flaky and slow down noticeably at around the 10-12GB mark regardless of whether the system has free memory or not. I suspect Unity / mono wasn't really designed with such memory usage in mind.

Sure. I simply don't care. The anti-cheat system is garbage if it cannot do it's job without interfering with the rest of the system, and no software vendor has any right to go poking about in my stuff or screwing up my system for their own purposes. Most anti-cheat systems are kissing-cousins to DRM, and use the same strategies and technologies. Such technologies are defective by design, and the strategies are just another example of the ever-encroaching corporate control over end-user devices. Cheating, like piracy, will always exist. No technological measure less than hermetically sealing all PCs and encrypting and signing all software will prevent it (and even then it's debatable), and anti-cheat DRM, like anti-piracy DRM, hurts innocent users as much as cheaters and pirates. I doubt anyone has counted, but I can say with confidence that several of the oldest and most cherished KSP1 mods were and still are developed on GNU/Linux systems. Of course it does. Take Two has an army of furniture-absorbingly poophole-retentive beancounters, and if you look at things with that attitude a GNU/Linux port doesn't make sense. I mean, that's just another example of the catch-22 @Geonovastmentioned earlier, and if it's ever going to change someone has to actually release games for the platform. A shame that those in the best financial position to do so (did I hear mention of ridiculous profit margins somewhere?) are also the least willing. Well, since Micro$oft bought monodevelop (embrace, extend) and turned it into Visual Studio for Mac (extinguish) we don't really have a .net IDE any more, but other than that...