steve_v

That's really not how it works. GNU/Linux players getting banned is a simple case of the anti-cheat generating false-positives because it's poking about in system files that are none of it's business. Most anti-cheat systems check the integrity of a bunch of Windows .dlls, and as wine ships it's own reverse-engineered .dlls to provide Windows-compatible APIs, it triggers the anticheat. No actual cheating is involved anywhere. They should get a grip, and stop silently auditing your OS in the name of anti-cheating/piracy. Checking game file integrity is one thing, banning someone because they're running a not-microsoft-supplied dx11.dll is entirely another. Installing a TSR trojan (Denuvo) or hijacking system device drivers (StarForce) is of course equally unacceptable, and equally destructive to the efforts of the WINE/DXVK/Proton developers and the enjoyment of non-Windows players. The answer isn't a nice error message and an auto-kick, it's not grubbing about in or tampering with the users system to begin with. Ideally it's also officially supporting non-Windows users, either with a native port or through collaboration with WINE/Proton/SteamPlay/cider/crossover etc. Likewise. My purchasing decision process goes much like this: #1: GNU/Linux native. #2: Subject matter. (in this case: Spaaace) #3: Developer not owned by slimy "big gaming" publishing house. #4: Impressions from (preferably) playable demo or extensive reviews. KSP ticked all those boxes, but so far KSP2 is only scoring 1/4... Again, likewise. Security, reliability, flexibility, and not being nagged, advertised at, spied on, or generally treated like a brain-damaged child by my operating system. Also I'm not about to reinvent my workflow and go back to an OS I can't stand using for more than a few minutes just for a game. It's been demonstrated repeatedly that GNU/Linux runs games just as well as Windows, and that it doesn't take a huge team or vast amounts of investment to port a game to it - assuming of course the engine was sensibly designed with portability in mind. Unity3D is effectively the poster-child for portable cross-platform game engines, so there's precious little excuse for KSP2 not releasing GNU/Linux and MacOS builds.

I really tried to love E:D, and I'll probably try again, but for me the gameplay just isn't as engaging as it should be. The mechanics are mostly there but balance and difficulty are all over the place, and what should be fun loops turn out to be far shallower than they first seem. As far as I can tell there's really very little to do in that huge universe besides grind for bigger ships, which don't really gate any gameplay or open any possibilities, explore a universe that rapidly reveals itself to be all procedurally generated sameness, or grind engineering and meta for PvP, which is mostly full of adolescent griefers and scrubs anyway.

Assuming that mouse has adjustable polling rate, and a quick poke about suggests it does, lower it from the default 1000Hz to 500 or 250. I can't tell you whether ckb-next supports changing this as I don't have any compatible hardware, looks like there are instructions in the ckb-daemon manual. Like I said, it's just something to try. It might have nothing to do with it, but it doesn't hurt to try and it sounds exactly like what I was seeing when I switched from a classic intellimouse to a SteelSeries Sensei. Reducing polling rate to 250Hz solved the problem here. Reports of high polling rates causing issues are not without precedent on the 'net at large either. If you have one laying around, another quick test would be to switch to a generic non-gaming mouse and see if it improves the situation. Other than that, yeah, your machine should run KSP fine. Testing without mods is of course also worthwhile.

Well, since nobody else has stated the obvious, from your log: Could not allocate memory: System out of memory! Trying to allocate: 178956976B with 16 alignment. MemoryLabel: Texture

I've encountered similar issues in the past, and it came down to Unity not liking the 1000Hz reporting rate of my mouse. Might be worth a look. The relevant info for generic input devices can be found in the usual places (i.e. ArchWiki), if you have a fancy gaming mouse you'll want something like piper/libratbag or an appropriate model specific configuration tool. Also worth noting that scatterer performance on GNU/Linux (or OpenGL in general) sucks monkey-balls. So much so that I've given up running it, it's not worth the performance hit. Scatterer is a 50% framerate tax here, on a 1070 and a 4.3Ghz I7. AFAIK TUFX doesn't work on OpenGL at all. At least it didn't the last time I looked, and the thread still states DX11 only. I'll be pleasantly surprised if you have evidence to the contrary though. Now pull the other one, it's got bells on No hardware is perfectly suited to play KSP, the mostly-single-threaded cpu-crippling physics engine sees to that. Your CPU ain't bad mind, so long as it's not throttling under load... being a mobile chip and all.

You can add 99% of the semi-useless cruft that comes on most motherboards these days with expansion cards, and doing that you get to pick exactly what you add. I've been looking at upgrade options myself of late, and TBH I'm getting pretty irritated at the lack of low-cruft high-slot-count decent quality options available. I have zero use for onboard sound, onboard video, onboard wifi, multiple NVME slots, RGB lighting, or any of the other crap vendors like to use to differentiate their products. What I do have a use for is a full ATX board with plenty of PCI-E slots, plenty of SATA ports, support for more than 4 DIMMs, and ideally a legacy PCI slot as well. Apparently this doesn't exist outside the server market these days, despite my current (P9X79) desktop board checking all those boxes. IME it's often also a reliability thing (though personally I wouldn't touch MSI or Gigabyte with a very long stick on that count), better (read: more expensive) VRM designs tend to use better parts with more current/thermal headroom and come with better heatsinking. I've seen enough VRM failures over the years, overclocked or not, to make those power-delivery parts a factor for me in much the same way a PSU is.

The entire bulldozer "moar cores" (and lies WRT core count to boot) architecture was a blunder, not only for gamers but for 95% of desktop workloads as well... Not to mention AMD's credibility in the CPU market in general.

And a good thing too. Internet e-peen points systems are ridiculous. A simple "I agree" or "Useful post" button avoids the usual "+1" or "^^" reply for sure, but anything beyond that is totally superfluous.

Yes. Absolutely. There's also no logical reason for it. This could probably be made to work again without too much difficulty, assuming you have the patience and a .NET dev environment.

If you're referring to this "online reference", you're better off ignoring it. I don't know who wrote that wiki page, but frankly it's an embarrassment. The only thing it gets right is the unzipping part. All mods go in 'GameData' beside the 'Squad' directory, one subdirectory per mod (with the exception of ModuleManager, which goes directly in GameData). So your MechJeb install should look like this: KSP_[OS] └── GameData ├── MechJeb2 │ ├── Bundles │ ├── Icons │ ├── LandingSites.cfg │ ├── LICENSE.md │ ├── Localization │ ├── Parts │ └── Plugins └── Squad If you really need pictures, this tutorial isn't bad. Or just do yourself a favour and use CKAN.

Unsurprising, as KSP isn't particularly graphics intensive and SLI doesn't scale very well at the best of times anyway. It won't. KSP can't do anything with a compute card and the physics engine (AKA the reason KSP runs like crap with large part count vessels) runs entirely on the CPU.

Sounds a lot like the strain-relief on the new connector was not correctly used, or what you have is one intended to be injection moulded to the cable. Generally speaking (hard to know without actually seeing it) rewirable/user installable connectors have a metal "tongue" inside the connector housing that should be crimped over the outer sheath of the cable to take any mechanical loading away from the wires. Sometimes it's some other mechanism like a compression gland or the like, but a crimp is the most common. If your connector doesn't have a viable strain relief mechanism, glue (ideally silicone or epoxy) is indeed a reasonable if rather messy course of action. Most people don't have an injection moulding rig at home to replicate what the manufacturer did. Replacing the damaged plug is a perfectly good plan, and it reduces the number of otherwise perfectly good power supplies that go to landfill. If all else fails, using glue (amazing what one can do with a little epoxy) as mechanical strengthening isn't a bad idea either... So long as one watches the polarity and checks for fit so as not to damage the socket. I know you're just advising caution, but the sheer quantity of good gear that goes to the tip because "don't try to fix it, you might break something" boggles my mind, and manufacturers cultivate this learned-helplessness whenever they can (e.g. Apple and the "replacing batteries is too dangerous" argument). "Having a go" is also a valuable hands-on learning experience. On that danger note, there's a certain fairly entertaining video from Louis Rossmann floating around (too much profanity to link here) demonstrating iphone battery removal using nothing but a claw-hammer and a paint scraper. Guess what Apple, nothing explodes. This is actually the one single thing that Apple does right on their laptops, that magnetic power connector. The rest of the machine is usually garbage, but at least they don't tend to go through power cables as fast as everything else. Good advice (discharging the power supply), if possibly a little over-cautious. So long as it's unplugged from the wall and you're not opening the power supply itself, the voltages involved should be quite safe. That said, I have seen shoddy supplies that will give you a mild bite from the unplugged mains end if you don't leave them a while before touching it. The laptop end of the thing ought to be safe as houses at any time though, as it's likely not more than 30v. More and more companies are not only making it so you have to completely dismantle the machine to get at the battery, they're gluing it in as well. Because they'd prefer you bought a new machine than replace a consumable part. The same goes for soldered in SSDs and RAM. Repairability is right at the top of my checklist before I buy something these days.

Reactors have a couple of new stats (WRT stock converters), "core health" is exactly what it sounds like - i.e. how screwed up the reactor core is after those times you accidentally (or not) overheated it, and life (or something like that, I forget the exact wording), which is how long you can expect it to run at the current power setting before you have to take it offline for refueling.

Excellent, thanks. Think we could put this information somewhere visible, or better yet fix that one little niggle and officially mark it as compatible? Seconded.

Welcome to the weird world of KSP development, where serious bugs are randomly introduced and then studiously ignored for multiple releases. Since the 1.10 release notes mentioned a new caching system, I'm betting that this has something to do with it. My crystal ball says someone forgot to dirty the cache after resource transfer. Or it could be a race, no way to tell really. vOv That's my solution as well. With history as my guide, I have no faith whatsoever that this will be fixed in any kind of reasonable timeframe. Unfortunately the devs have been known to use "a mod addresses this issue" to excuse not fixing it for an even more unreasonable length of time, so the mod solution is really a double edged sword.

Good question. Link a log file. Off the top of my head, this sounds very much like file permissions or outside interference. I'd start by making sure KSP isn't installed in Program Files and checking that no antivirus or other unrelated program is meddling with it.

Ordinarily I'm pretty heavily against such "when update" questions, but in this case MKS is now over a year and two major game releases behind the times... I get that these things take time, especially if there's some major rework in progress, but this is getting pretty close to "dead mod" territory right now. That's a shame, because on the rare occasions it's compatible with the current state of the game, it's pure awesome. Could we not have some kind of interim compatibility update, or even just an official word on said compatibility? It's literally been years since I could start an MKS playthrough with any confidence it's going to work properly.

When it's good and ready, with any luck.

Is excellent advice regardless of what shady programs you do or do not run. Safe computing 101 even. It regularly astounds me the sheer number of people around who run without backups. The same people often extol the virtues of <insert favourite commercial antivirus> like it's some kind of magic shield. Every time someone posts something like "Sorry guys, there will be no more updates, my laptop died and all my mods are lost" or "Waah, all my saves are gone, help me fix my hard drive" (and it's even happened here), I have to bite my tongue quite hard... The answer to viruses, ransomware, disk failures, accidental deletion, cosmic rays, floods, fires, and windows update being windows update is... Having a tested backup on a different (and ideally remote) machine. Preferably a filesystem on said machine that is only accessible by tightly controlled backup scripts (e.g ssh as a dedicated no-shell user with 'forced-commands-only' set). I have personally had a machine compromised exactly once, (by a bot ) and entirely through my own stupidity (creating a user with an obvious password for guest access at a party, and forgetting to deny ssh login). Recovery was as simple as a ctrl-alt-sysrq-k; cat <restore_script>; sh <restore_script>, and I was back like nothing happened in under 10 minutes. The number of times I have restored backups for other reasons, be it hardware failures or simply me doing something destructive, is beyond counting. He could indeed, though it's a pretty convoluted solution to a simple problem. I prefer "you may install thing in your home directory, but if you abuse it I will noexec your mount", but that's a unix thing again. Guilty as charged . Had the run of the entire network and all the admin accounts at high school... Used it to play StarCraft mainly.

A bigger desk + a decent desktop will almost certainly still work out better value and gaming power/m3 than a laptop... Desks tend to be comparatively cheap and all.

I doubt it I will add, on the topic of framerate, that almost all console titles traditionally target 30FPS. I'm not sure if KSP/KSP2 are the same, but personally I consider that kind of FPS borderline unplayable. ed. Is that "than" meant to be there? (emphasis mine). It suggest the game runs better on console, which IME isn't the case at all.

Updates have always appeared for the PC release before they are ported to consoles, often to the tune of several months. Performance on PC is scalable by upgrading your hardware (and generally better than consoles provided you have the cash to make it so). Controls are completely flexible on PC, as you can plug in pretty much any controller you want (or build your own). Yes, you can use wireless keyboards with consoles now, but you're still limited as to compatibility. Mods are available on PC, and PCs have the hardware (memory primarily) to run them. That last one alone is a hands-down win for the PC release in my book, there is so much more you can do in KSP when you have access to mods it'd take me days to list it all.

Keeping the format around is fine, it's setting at as the default on every page load that I have problems with. Here we have a valid and useful use for cookies, and you're not using them. Please give me a way to not have to click that button on every singe support thread I visit, every time I visit it, just so the conversation makes sense.

FWIW (I assume you are signed in anonymously now), I don't see you on the list of active users. Nor does the profile hover give me any "currently viewing" or "last login" type data.

This is what happens when you spend decades allowing application vendors to provide their own executable installers, write whatever they want wherever they want, and store configuration data in whatever crazy directory structure they like... You form bad habits, and push "run it as administrator" to the top of every helldesk monkey's troubleshooting flowchart. Over here in the sane unix world, we've had a multi-user system with consistent separation between administrator-provided application files and user-modifiable configuration since day one, and a formal standard for such since 1994... A point in time when MS was still running on top of DOS and had no concept of access control or user privileges at all. So yeah, it's not Microsoft's fault any more, but it is Microsoft's fault that this situation developed in the first place. IMO, the "All these folders are yours, except Europa Program Files. Attempt no writing there." solution is still the wrong way to go about it, because then you get what we see here - namely bypassing access controls by simply putting the same nasty mix of executables and configuration in some other globally-writable place.