steve_v

I forgot all about that. The specification on many common connectors is surprising to say the least. Last I looked, for a common SATA connector the mechanical durability spec is 50 cycles. And I missed that too. Oops. I argued because running KSP_linux on a Linux guest VM on a Linux host is a bizarre thing to do, and I had already covered games. As for the crashing, Unity's "Screenmanager" is dodgy as all get out, and it's been known to interact rather badly with certain window-managers in the past. I see you never tried another WM and just reinstalled the OS. Why? You'll never know what the problem was, "it was my GPU driver" is likely but hardly definitive given your lack of troubleshooting.

"That's how it should be" was in response to "And, no, I don't dual-boot Windows." I don't see any point in dual booting these days and not doing so is, IMO, how it should be unless you have special requirements, which I later covered. You started it. It doesn't include Slackware either, one of the oldest and most reliable distributions, nor Gentoo, one of the most flexible. I'm not complaining, it's slanted like all Linux polls because there are too many to list. It should probably have included Fedora, but Redhat itself wasn't particularly common as a home desktop OS last time I checked. Common on servers and business workstations due to the commercial support, but you don't generally play KSP on those. A native application doesn't need a VM, and PCI-passthrough isn't magic. You not knowing how to do it doesn't make it bs either. Why the hell would I do that? I run KSP_linux on my Linux desktop. For KSP_win, see my comment on windows games and high-end CAD above. The only time you'll mess up a working GNU/Linux installation (without gross user-error) is installing Windows for dual-boot, in which case definitely unplug the other drive if you use one. In other news, one of the main reasons for using VMs is that the guest OS can't mess up the host.

That game looks pretty cool, I hadn't seen it before. Unfortunately I will not be buying any more games built on Unity3D, after the disappointment of all the ongoing and unfixed unity related problems with this one.

There is (or was) exactly such a part module in the game. Pretty sure the thread was lost in the great forum crash and I'm too lazy to go hunt for it now, but AFAIK it was never used because it was too buggy. People have been asking for this functionality (and robotics) for years and it's on the "do not suggest" list, presumably because Squad thinks it's too hard.

Right. So not having Windows installed makes me a fanboy? Or running Gentoo? Either way your definition is rather different from mine. I'd say the user name "Linuxgurugamer" is more an indicator of a fanboy than anything I have said here. I might be considered an evangelist at times, but it's not for GNU/Linux, it's for free software and end-user empowerment. That's an ethical stance, not fanboyism. I have tried many 'tools' in my ~25 years of using, building, administering and tinkering with PCs, from DOS and OS/2 to Windows 7, Solaris, BSD, and various GNU/Linux distributions. I haven't used Windows willingly in years, because that hammer is currently incompatible with my nails. Gentoo GNU/Linux is, so that's what I use. If what you have does what you want and you like the way it does it, why waste disk space with dual-boot? Why would anyone want to dual-boot these days anyway? VMs are a thing. The only exception I can think of is Windows games. Fair enough perhaps, but everything I want to play runs natively or perfectly well in wine. High-end CAD might be better on Windows too, but that's a niche application and calls for (what is to me) a niche OS. As far as I know nothing at all works better on Red Hat except commercial support, so I'm not sure what that tool is for at all. Maybe it got better since I last used it. Each to their own I guess.

I can neither confirm nor deny that I have contributed to Nertea's caffeine addiction...

Indeed. Nertea makes incredible mods, extending KSP yet looking like they were meant to be there from the beginning. I have serious doubts that any stock centrifuge would match the quality of the ones in SSPXR.

Then I guess I've beaten the tech-tree Ran LFS for a while, even built an LFS install with rpm for package management... before I learned that rpm was the devil. The biggest problem with limited RAM (and 2GB is not much these days) isn't the OS, it's running a modern web-browser. I have a 486DX4-100 with 21MB of ram, and Linux (DSL) runs fine on it. Firefox not so much. That said, GNU/Linux isn't the primary OS on that box, OS/2 Warp is. Champion. My servers all run Devuan now, for the same reason. Same distro, late '90s for me. I switched from Redhat to Gentoo in '03 to get away from redhat in general. Then LFS for fun. Then Debian when compiling wasn't fun any more. Back to Gentoo again recently, to escape the systemd insanity. Likewise on the modelines, not so much the smoke. I remember kernel patches to get more than 16 colours on my GD5426 VLB GPU though. That's how it should be. As for my current desktop distro: -/oyddmdhs+:. steve@perdition -odNMMMMMMMMNNmhy+-` OS: Gentoo 2.6 -yNMMMMMMMMMMMNNNmmdhy+- Kernel: x86_64 Linux 4.14.83-gentoo `omMMMMMMMMMMMMNmdmmmmddhhy/` Uptime: 23d 9h 19m omMMMMMMMMMMMNhhyyyohmdddhhhdo` Packages: 1538 .ydMMMMMMMMMMdhs++so/smdddhhhhdm+` Shell: bash 4.4.12 oyhdmNMMMMMMMNdyooydmddddhhhhyhNd. Resolution: 1920x1080 :oyhhdNNMMMMMMMNNNmmdddhhhhhyymMh DE: KDE 5.52.0 / Plasma 5.14.3 .:+sydNMMMMMNNNmmmdddhhhhhhmMmy WM: KWin /mMMMMMMNNNmmmdddhhhhhmMNhs: GTK Theme: Breeze [GTK2/3] `oNMMMMMMMNNNmmmddddhhdmMNhs+` Icon Theme: breeze `sNMMMMMMMMNNNmmmdddddmNMmhs/. Font: Noto Sans Regular /NMMMMMMMMNNNNmmmdddmNMNdso:` CPU: Intel Core i7-4960X @ 12x 4.3GHz [43.0°C] +MMMMMMMNNNNNmmmmdmNMNdso/- GPU: GeForce GTX 1070 yMMNNNNNNNmmmmmNNMmhs+/-` RAM: 11347MiB / 32110MiB /hMMNNNNNNNNMNdhs++/-` `/ohdmmddhys+++/:.` `-//////:--. Gentoo is nice, it felt like coming home. .

Given that we have no life-support or health system in stock, what function would a centrifuge serve? On the poll, I vote "no", because we already have mods for this, and if history is anything to go by they're considerably better and prettier than anything Squad would implement. I vote that jank-removal, GC stutter improvements & joystick support on GNU/Linux be included in the next update. I don't give a rats ass about new parts or existing part retextures.

I find it irrational, so I run mods that fix it . Wait for it... There's a mod for that too.

Terrain collision detection has been janky as hell for forever. Spawning underground, clipping through terrain, sliding about, vibrating or sinking landed craft, none of it is new. The only new bit is that the last few major releases have been revealing the jank more than usual... On a related note, the new-ish "fix" for sliding wheels, namely to lock the craft in place when the brakes are on, is a particularly obvious and rather lame workaround. Can provide pics of aircraft pinned to the ground at weird angles by two wheels if needed, but I'm sure you've all seen it at some point.

It's an easy way to ensure that you forget to slide the shutter and wonder why your webcam isn't working, or an easy way to have to carry tape and to leave sticky crap on the lens. Not having your PC compromised is pretty easy, and something one should do regardless - at which point covering your webcam is redundant. I really don't get why people assume a PC is insecure... Unless of course they run windows, in which case they might as well give up any illusion of privacy right now. Suit yourself though, on the hat too.

I have 100's of these in my spam bin. Obvious phishing spam is obvious, still no need to cover webcams.

Yeah, but bad code with unity works, so it's too easy to not fix it. IMO, if unity builtins (e.g. the old ui) are a performance blackhole, they shouldn't be unity builtins. Sure, there are ways to write slow code in any system, but the garbage collector in unity is a ticking timebomb that only makes itself known when your code reaches a critical mass - by which point it's a bear to go back and fix it. Where I come from, you screw up memory-management, you crash. Frankly, I prefer to know up-front when I screw up.

Honestly, I don't get this paranoia. Don't want your webcam spying on you? Don't install malware. Easy. That these features exist kinda says the manufacturers have given up on the software not doing bad things, so are working around it in hardware. What the actual frack.

The runtime must stop the world though, due to the nature of the garbage collector, right? Granted these stops should be so short as to be unnoticeable, and the fact that they aren't is down to poor code. It does still seem a little bizarre to me that with a managed runtime one has to put so much work into memory management to get acceptable performance. I'm not going to argue with you though, I know that you know what you're talking about. That's just... really unnecessary. Good to know now the supposed "lots of work to reduce garbage generation" is over, squad is still working hard on the performance front. I have heard this many times, from many sources. I've never used it myself though, because screw spending effort on unity. I do know I don't have garbage collector problems in C or C++ though.

Probably the same people who decided laptop webcams need a physical shutter. And a free tinfoil hat OFC.

Yup, the garbage collection "stutters" are very much still there. Almost unnoticeable with the stock game on powerful hardware, but still there. I've given up asking about this as fixing it properly would entail major changes to the game engine, and that is in the too-hard basket. It's pretty horrific that anyone thinks freezing the world every 10 seconds is a fair price to pay for a free .net runtime, but that's craptastic bargain-basement game engines for you. At least they are using a modern version... Oh wait, it's based on a 7 year old mono release.

There is a lesson here: Every KSP release (especially .0 releases) is broken in some way, and almost every KSP release will break mods. If you play with mods do not allow steam to auto-update KSP. Wait for all the obvious-yet-slipped-QA bugs to be complained about and the 3 or more hotfixes to be released before upgrading to any new major version. 1.6.0 is borked like every other .0 release, so it won't be kept. As expected. New release, new bugs. The cycle continues. Hey @SQUAD, where's the fooking joystick support you broke in 1.4? Is this going to be fixed or what? Likewise, as my peripherals don't work at all in KSP >1.3.1 and Squad doesn't appear interested in fixing this regression. Guess it'll be 1.3.1 forever, since these recent "updates" seem to be introducing more bugs than they fix. Shiny part retextures, yay. Game still doesn't work properly. I fired up 1.5.1 and 1.6.0 to test, and wheel friction is indeed bung. Thanks for confirming it's still not fixed... As for shock-absorbers being "treated"... I'm still seeing mighty screwey perpetual motion machine behaviour from this perpetual-mess of a wheel system.

steve@perdition ~/Games/KSP_linux/GameData $ grep -R HG-55 ./ ./Squad/Parts/Misc/AsteroidDay/HighGainAntenna.cfg:title = #autoLOC_500637 //#autoLOC_500637 = Communotron HG-55 That took about 2 seconds...

As a landy owner, I can identify with this. My ignition switch once underwent rapid unplanned disassembly (Thanks Lucas, prince of darkness) at an intersection. Random junk wire and large screwdriver (across starter terminals to crank) to the rescue... And some pushing, and many irate motorists. Then I got to drive it home with no electrics at all, hand out the window signalling style. What fun. This was perhaps topped by the 2 days I drove it to work and back with no clutch, thanks to the failure of a tiny spring in the master cylinder... And for an unrelated complaint, the screen on my phone died completely the other day, so I now have semi-phone which I can only use by screenscraping over ADB to my PC. Chaos ensues when it rings. Yay for consumer electronics.

Field research doesn't disable rescue contracts, but this does: One can presumably re-enable them in CC settings.

FWIW (as I have little time for debugging KSP ATM), I tried 1.9.5.2 on KSP 1.5.1, and I'm seeing a consistent 20FPS+ performance hit (vsync @60 -> ~40) while in flight. Nothing interesting is being logged, and the mod appears to otherwise work fine.

Yay, stock ΔV readout. Not-yay, 7 months and joystick support still not fixed. No fix joystick support == no purchase DLC or future product. [snip]

Because any competent engineer fixes what he breaks. This isn't a "never worked", it's a regression introduced in 1.4. Likewise. For me it's actually "No GNU/Linux port, no purchase." At a guess: You're running KSP <1.4, you're running some super-obscure distro I've never heard of, or you're one of the unicorns who have managed to get something out of this supposed "steam controller" support. I have 2 joysticks & 3 gamepads that mysteriously don't work in any KSP (and only KSP) version from 1.4 up. These same devices operated perfectly in 1.3.1. It's been more than three, as there have been more than three broken releases since 1.4. You might get some peace from it if that's your thing, this is probably the last time I'll be around here, at least for a long while. I don't support game developers that only port to my OS because it's easy, and I don't support game developers that butcher such ports at the first opportunity to make a quick buck on another platform. If you say you support a platform, support it. Also, I haven't forgotten the missing analytics switch, that liquides me off too.