steve_v

@StubbornJebStop crossposting this in unrelated threads, it's obnoxious and in breach of rule 2.2 (m & o). I will not hesitate to report such activity if it continues. If you want help, do what has been asked of you and provide the required information.

It's been done before. It caused side-effects, was a pain in the ass to maintain, and is now seemingly abandoned. These problems would go away if it was done by the game engine... But Unity. It's MIT licensed though so feel free to revive it.

The mod you mention is almost entirely graphics optimisation, there's not much to be done here for KSP as its graphics and textures are already terrible. If you want it even more terrible, there are settings for that both in-game and in the config file. If your GPU really is struggling with KSP, turn down terrain quality and /or lower maxSubdivision for Kerbin and its ocean in the config. Turn off aero effects too, they're an appalling frame-hog (at least in <1.4). If you're running out of memory (main or GPU) and swapping, reduce texture resolution. But if your GPU was made this decade, it's probably not the graphics that are slowing things down... KSP isn't graphics-heavy, it's CPU bound by its physics engine. You can't reduce the resolution of the physics simulation (much) without nasty things happening and core game mechanics not working properly. The only thing one can do is run the physics at less than realtime, and the game does this automatically as far as is practical already. Hence, not much in the way of performance improving mods. Memgraph trades a short frequent freeze for a longer less frequent one, by using more memory. Not quite as annoying, but not really a fix either. It's more of a diagnostic tool. KSP boneheadedly loads every texture it finds in GameData into RAM on startup, so even parts you never use are consuming memory. This is why KSPs memory requirements are so insane, and only get worse with part mods. My current modded game uses ~10GB of RAM, which is patently ridiculous.

Huh. Seems @StubbornJeb lives up to his name. Speculate all you like, but without the information requested, that's all it will ever be.

And there is the culprit. CKAN installed the 1.4.x version into my 1.3.1 game, because broken metadata, like every other update.

Here. The errors from Hyperedit can safely be ignored, that was only installed to try and figure out where this is coming from. FWIW, I suspect I have a rover near the pyramid, but it's been along time so I'm not sure. Happens with other vessels in orbit too though.

As the topic says, somewhere around reaching orbit of duna and starting my deorbit burn, this horrific SSTV noise started up, only when I'm in mapview, and I can't turn it off. I assume this is from one of the mods I have installed (or it's somebody's terrible idea an easter egg), I recall the sound from chatter, but that's not one of them. I'm putting it here in tech support as this sound is driving me insane, please move it if it belongs elsewhere. Mod list: Any ideas?

Obligatory link to: On that, I hear that the logfile location has changed with 1.4.x (though the OP doesn't say what release we're talking about here), Is that thread still correct? The "method" is to a) post system details, list of mods and logfile, and b) try to isolate the problem by starting from an unmodified game and adding one mod in at a time until the problem reappears. Asking if anyone has any "ways to fix it" is pointless if you don't provide enough information to figure out what is wrong. Nobody can fix what they can't diagnose.

Wait, #9557 is fixed in 1.4.2? You mean stuff (by which I mean not landing gear) doesn't slide around all the time? Ground friction actually works properly? Finally.

0.53.2.0 is the last version for KSP 1.3.1 (and that's what I'm running), so this is no use to me whatsoever. I'm aware of what the changelog says, that's why I mentioned backporting the fix. But I can't find squat in the repo.

I am getting this too, on 1.3.1. And no, I'm not remotely interested in updating KSP to 1.4.anything. Not until the bugs in the base game are sorted out and the rest of the mods I use are updated. This is an in-progress save, and I would loose most of my vessels, not to mention the use of my joystick. Are any of the previous 1.3.1 compatible releases not broken in some way? I'd backport the fix myself, but I can't make heads or tails out of the github commits, I see a binary diff against USITools.dll, where's the source diff at?

Github. Old releases are always on github.

Hmm, I thought it was "Away with QA MK2"

The effects themselves, meh. Okay I guess. Kinda ugly. Part geometry becoming transparent though, that's got to be (another) bug. I really don't know how this passed even a cursory playtest, but then the same goes for all the other brand new bugs in 1.4.x.

Extra trivia: The cats have... migrated. They now replace the waypoint icons in-game too. Either this is new, or I'm blind...

Yes. And you could have done what I just did, and asked one of the many "is it down" type web services.

Provide more living space, add parts that provide entertainment (habitation multiplier), or turn the feature off.

When... I like When, it's way better than "If"

See if there is a >=5.0 mono-runtime package available in the repos. If there is, install it and try again. If Mint has the new version of apt, you can have it try to resolve dependencies automatically by using apt install <file.deb> rather than dpkg -i. Otherwise, it's off to mono-project.com for an unofficial update. As the package on your system is from Ubuntu, you're probably best using the packages for that distro. Add the repo as described there, apt update, and apt install mono-complete. Beware random outdated blogs... Take care what you add to sources.list, especially if apt wants to remove anything when you install from an unofficial repo. You can make a right mess, and on FDN we call the result a FrankenDebian. That one is not too far off the mark (though it references ancient packages for an unsupported Debian release), but you'd be better following the instructions on the mono-project download page I linked. ----------------- Looks like you have the mono-project repo in your sources already (-xamarin versions are from there), it probably has a lower priority than the official mint repos, which is why it didn't get pulled in automatically. IIRC, synaptic (I just use apt at the console) sets priorities in it's own special way...

Gentoo GNU/Linux. It's been that way for a while. Remember the "double free or corruption" debacle? Or crashing peoples window managers? Or crashing if pulseaudio wasn't available? You'll be excited to learn that joystick support is also broken on Linux...

The only suggestion you have offered is to "autostrut the legs", which is on by default anyway. Then you offered a vague "It's probably complicated" explanation as to why this bug is still around, which I attempted to clarify as I had investigated the new wheels / landing legs in some detail around the 1.1 release. Why this then needs to become a big angry argument, I don't know. And I claimed you said something more, perchance? I'm not telling anyone what to do, I simply explained what they have done and why wheels / legs still suck. As this topic is about yet another bug relating to landing gear, I don't think that is at all off topic. So don't. You're the only one shouting in here. If you want to defend against these perceived "SQUAD bashers", that's your prerogative, but don't yell at me.

Yes. Ditto. I guess we wait some more.

You shouldn't need to, no. Just make sure mono is installed and run the binary as 'mono ./ckan.exe'. You don't need to install with the .deb, all that does is pull in mono-complete for convenience. If you don't use the .deb, install mono yourself. You'll need to find instructions for your distro. Mint doesn't appear to ship mono at all (though there are references to it on the community site?), so you'll have try the Debian or Ubuntu packages. I can't tell you which, as apparently Mint is based on both. Personally, I'd try Debian. Explaining the the incredibly informative "World Of Pain" console output you got when you tried to install the .deb so we can see what's going on might be helpful too... I don't use mint, but I do have some Debian-foo.

a) By discussing it with one of said (former) devs. b) By mucking with the thing myself. c) In the course of looking for alternatives, of which none are are available as a ready-to-use plugin, hence the "not inconsiderable work" comment. If you have some credible evidence to the contrary, I'm listening. Do you have an alternative explanation for the forced autostruts on wheels, or why kerbals can walk through landing struts? Perhaps it's just space aliens messing with a perfectly engineered codebase, rather than a set of imperfect patches on top of an imperfect system? My implications are that SQUAD has built a thing on top of a system that, frankly, sucks. And this is why the bugs keep coming back. If you want a second opinion, go check out all the complaints on the Unity forums about just how hard the wheel system sucks. Or you could just keep on being angry, suit yourself.

Indeed. If I come across as particularly salty at the moment, here's why^. We're not in beta any more, and the prerelease idea seems to have fallen by the wayside. I expect more testing and fewer regressions for a release at this point, especially when Take Two has just purchased the game and the first DLC has arrived. Problems with the DLC itself, fine, but the core game should be relatively stable. 2 year old bugs resurfacing now is ridiculous.