steve_v

And joystick support on GNU/Linux is still not fixed. Bye @SQUAD, I'm done with this game.

This is my biggest gripe with the wheel system. Other jankiness aside, the ease with which one can accidentally build a perpetual motion machine is ludicrous, particularly when taken with the "realistic physics model" claim on the box. If systems gain energy from nowhere your "realistic physics model" is broken, period. This is quite possibly the case, though I have not tested it. However, space exploration is pretty heavy on light vehicles, if you get my drift.

To wit: Not fixing the root cause. The root cause, as with all the other unfixed problems in this game, is the game engine. If Unity won't sort it out, you either code around it or you buy a source-code licence and fix the existing systems. KSPWheel is much better than Squads implementation, or it was the last time I tried it with the stock patch. Even if it's not perfect, it's yet another example of free community code being seriously superior to what Squad has developed. So why doesn't Squad do what Shadowmage & co. did to provide the best possible user experience within the limitations of Unity? Is it the same reason they haven't taken a cue from AFBW and fixed the input stack? Perhaps it's because it's easier and cheaper to blame Unity?

Norton is nowhere near as bad as it used to be, and Kaspersky is one of the best antivirus products available, at least as far as detection rates go. You should help yourself first, by reading this and posting the information it suggests. As you appear convinced that this is a Windows upgrade issue, some system information might also be useful.

Welcome to post-1.1 KSP. Landing legs and gear have been borked in a variety of ways ever since the U5 "upgrade". Since Squad seems to have no interest in fixing them properly, the only options I am aware of are to avoid using them entirely or spend considerable time tweaking the spring and damper settings... Which will trade slinky or pogo-stick for mound of jell-o if you are lucky.

It won't make any difference, KSP is as CPU bound as it gets. It's both. KSP uses a lot of rigid-body physics, and Unity doesn't support GPU acceleration or threading of the same. As it has always been, single-threaded CPU performance is king. I'm running ye old i7-4960X @ 4.2GHz and a Nvidia 1070. KSP still runs like crap, my GPU is essentially idle, and the performance degradation is almost exponential with single-vessel with part count.

I was running Slackware at that point, I moved to Gentoo around 2003 (after a brief flirtation with LFS) and ran it without issues for ~5 years before switching to Debian for "just works" and no lengthy compile time. Installing stuff with Gentoo on a P166 was slow. Then Systemd became inescapable on Debian, so I escaped Debian. I look to Gentoo as one of the few remaining distros with a choice of init systems, and discover that it's now considered "old guard". But it's got choice and freedom, and that's what matters. Kinda felt like coming home TBH. Yeah, I was dual-booting until a few years ago, for this very reason.

Short answer: Uses 2 modules simultaneously for the same operation (by splitting data into blocks and sending one to each module alternately), much like RAID0 does for disks. Theoretically this provides twice the performance of a single module. Memory interleaving is just the technical term for what manufacturers call "dual channel". You should use slots 1&2 or 3&4 (i.e. slots the same colour), for double the memory bandwidth. Ed. This is totally in the manual for your board... You did read the manual, right? Red or blue. Clearer?

You were right to begin with, I was just moaning about the "ease of use" vs "logical layout" colour coding on most motherboards. The other way to tell is that slots on the same channel are usually adjacent, this is the case on your board as the physical layout is 1,3 (channel 1) 2,4 (channel 2). You want slots 1&2 or 3&4 for 2 modules... Or to put it another way, a module in every second slot WRT the physical layout. Mine was easier, 8 slots, 8 identical modules.

If your motherboard follows the usual convention, yes. Confusingly (to me at any rate) each memory channel serves one slot of each colour, so to use both channels in interleave mode you use matching modules in matching colour slots. Frankly I'd find one channel = one colour to be more logical, but whatever.

Unless your chipset has 4 memory channels (mine does) there's no reason to go with 4x8 over 2x16.

Fair enough. I tend to go with "I have backups, so breaking stuff is kinda fun." My Gentoo box just got nvidia 410.57 and firefox 62.0.2 with link time optimisation.

AFAIK, Synaptic doesn't respect /etc/apt/preferences and keeps it's own priority settings. Other than that I can't say I've had any issues in ~10 years running apt-get, aptitude, synaptic and packagekit frontends on the same system. One should use man pages (and info pages, and apropos to find both) as a primary source of information, preferably well before resorting to internet searches.

Last I heard Mint had a GUI "driver manager" for this... Failing that, you'll need to figure out why libnvidia-cfg1-396 can't be installed. You might also try out aptitude, it has a different solver algorithm and a handy "aptitude why-not <package>" command for such situations.

Right, crashing on loading then. Are all your mods compatible with the game version you're running? Mods compiled against the wrong game version can and often do crash mono.

I was trying to suggest that you do something about your free memory situation before digging any further, to eliminate the obvious. This is almost certainly not causing crashes. MM rejected some patches is all. Is this crash occurring on startup, scene change, or randomly? Where's output.log.txt?

You are absolutely sure this is not the cause of the problem? If so, we're going to need logs 'n stuff.

A properly designed lifter likely won't have the TWR in the final stage to circularise in time anyway. which leads to: A bad launch profile will probably cause design problems.

Then why bother suggesting it? Unless you have zero control authority in atmosphere, it's just a stupid thing to do. If you must use an all-SRB first stage, steerable fins are cheap and unlocked early in the tech tree.

To cover the blindingly obvious first, you do have ModuleManager installed, right? Also this, as usual:

This is a rhetorical question, right?

Regardless, you have just motivated me to replace that horrific font. All further attempts at communication via crayon will be rendered (more) unintelligible... wingdings unintelligible. Hooray for userContent.css

Unless there's a way to enforce it, it won't happen. Nobody reads the support stickies. How about a form to fill out when posting a topic in the support subs, with a menu for OS, mandatory log upload, etc? The number of variations I've seen on "Halp it donst work" is depressing, and the first reply is almost always a request for information. While we're at it, a remote shock delivery system for people who don't use capitalisation or linebreaks would be nice too... With a lethal variant for users of comic sans of course. As for GNU/Linux specifically, I don't really see a need to segregate support requests by OS. You can spot a support request from a Linux user by the presence of useful information.

Frankly, both those bug reports suck. They read like personal anecdotes rather than technical reports, and if there is a set of reproduction steps buried somewhere in there it's not exactly obvious. #19511 is especially appalling - If you want people to read your stuff, at least use linebreaks and proper capitalisation. The return key exists for a reason. There is a heap of information on the 'net WRT writing useful bug reports, and duplication is the least of concerns here... But I don't have a console, so I'm not about to clean them up.

Huh. Your definition of "working" must be different to mine, I don't see any developer commentary on there at all. None on the other report either, but that's about what I've come to expect.