steve_v

Ooh lookie, it doesn't merge posts anymore, how irritating.

After hitting those links, agreed. The "Q&A" style forum sections are horrible, adding nothing but hiding a lot of useful information.

Ya, this. I'd rep you, but like I will most certainly not. In other news, I find myself agreeing wholeheartedly with all the complaints on this page. My personal top two gripes are the eye-burning lack of contrast and the faceborg-like "like" thing.

One word: "dislike". I have always, and always will, avoid any button with the word "like" on it.

'tis not the point, I know it's still there. Oh yeah, and I want my BBCode back.

What filesystem and mount options does that drive have? (see output of 'mount' command) If it's NTFS, it's possible to make permissions play nice, but not straightforward, best put KSP on a Linux-native filesystem. Check that your "different HD" isn't mounted with "noexec" - Ubuntu does this by default for some reason. On another note, why the bleep do we have an "answer this question" button on this thread now? which question? What if it's an informational post - i.e. the top of this thread?

Questions: *How Do I delete forum-lag induced double-posts? *How do I prevent "steve_v likes this" from appearing on posts when giving rep? (I will give no rep if this persists) *Does "rep" actually mean anything now? "likes" (whatever they are) are cheap. *Why are line breaks so ridiculously huge? *Why does the colour scheme hurt my eyes? *Why does every post I make hang on "saving" forever/until I refresh? (see deleting double posts) *When are you going to sort out the 502 errors? And most importantly, why does this "upgrade" feel like a gargantuan step backwards, in appearance, performance, and functionality?

Ok, I just noticed the "<user> likes this" appearing on posts... I will therefore be giving ZERO likes, (whatever this "like" thing is), sorry 'bout that. Missing the old rep system already.

Good to know I'm not the only one. The double posting will continue until forum performance improves

Good to know I'm not the only one. The double posting will continue until forum performance improves

It'd be significantly better if it actually worked most of the time, HTTP/1.1 502 is pretty boring to look at. Speaking of look, the longer I look at it (when it actually loads), the more I want to gouge out my eyes. It's either the colour or the contrast, IDK exactly but it's extremely unpleasant.

So slow, in fact, that that took ~3 minutes to "submit". And we remove forum-lag induced double-posts how?

All of the above.

All of the above.

[quote name='damerell']... a situation which would be enormously exacerbated if CKAN were to provide a convenient way to install supposedly-incompatible versions. Hey, how about a --force-win64-hack argument, too? Indeed, I think the annoyance it would cause mod authors is the primary argument against a way to install mis-versioned mods.[/QUOTE] And we're back to this: [quote name='steve_v']...are we operating under the assumption that Users Are Stupid and making life difficult on purpose? ... Every package manager I have ever encountered (with one obvious exception) has a non-frustrating, documented way to override such sanity checks... Why is it such a big deal to include this in ckan? [/QUOTE] It's pretty easy to identify that a user has intentionally broken things (as ckan knows the installed mod is marked incompatible), but all the "outdated/broken mod version installed by ckan" issues I have seen are not this at all, rather that your metadata was wrong and ckan installed it without complaining. I doubt we're going to agree on this, but I'm done repeating myself, and I'm done with ckan. It's more aggravation than it's worth.

[quote name='politas']Well, I would counter that the best thing for clever users like you is for this sequence to happen: ... You doing a --force option to avoid the metadata update is the selfish alternative.[/QUOTE] My point is, if I have to do manual installs to test compatibility I might as well just do manual installs. How about: * Note that mod is marked as incompatible. * --force install * Test. * Dump .ckan | grep <incompatible flag> to generate list of working "incompatible" mods. * Post said list and/or update metadata. Once the metadata is updated, mod becomes marked as compatible with no further work, and no manual uninstall/reinstall cycle. ? Easier, no? Yes, I'd like it to work "right now" precious metadata or no, and I'd like to be able to e.g. roll back mods or install specific versions on request without digging through the registry for version numbers. I might even be inclined to help out maintaining the metadata if ckan didn't make the testing process unnecessarily difficult. Initially I thought this system a great idea, but with the angering of mod authors (e.g. the recent argument with Ferram4), the "maybe sometime next year" response to a "breaks unrelated software" bug and the "nevermind UE, metadata never lies" attitude I'm not so sure any more. Anyway, feel free to spend your time on something else, it's a moot point anyway. As it stands ckan screws up my desktop and makes testing mod compatibility difficult, so I'll take the third option, install manually and quit fighting an application that apparently knows what I want better than I do.

True, but if you mean modifying the release file, it's not a fix, it's a dirty hack to work around an obvious issue with CKAN. If you muck with the games release file to say '1.0.4' What happens to mods that are compatible with 1.0.5 only? How about other things that may expect that file to be correct? So you're saying that I should screw with the rest of my install to accommodate CKANs bugs, like I have to work around it borking my desktop mime cache?

[quote name='politas']From CKAN's perspective, installing incompatible mods is a Bad Thing.[/QUOTE] I get his, I really do. But as I understand it, CKAN exists to make life easier - in this scenario it's just getting in my way, and it happens with [i]every[/i] new KSP version. If I want to do a Bad Thing, I'll install the mod manually anyway - is it not better to have it handled by ckan, or are we operating under the assumption that Users Are Stupid and making life difficult on purpose? (something that I find [i]extremely[/i] aggravating). IMO it'd be far better to just provide a --force option with a Big Fat Warning, the number of times this has come up speaks for itself. Envisaged workflow: $ ckan versions <mod> <lists all tracked versions> $ ckan install <incompatible version> Not compatible, go away. $ ckan install --force <incompatible version> Are you sure you want to do this silly thing? [y/N] Every package manager I have ever encountered (with one obvious exception) has a non-frustrating, documented way to override such sanity checks - take an example from apt/dpkg (for a potentially system-brickingly stupid request): You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' Why is it such a big deal to include this in ckan? [QUOTE]why not post a list of such mods with links to evidence for each (just someone saying "I've tested it" would generally be enough) and do something helpful?[/QUOTE] Sure, but why not let the user override compatibility checks at own risk in the mean time? I see no logical reason not to, and that way we can test for compatibility without having do manual installs - if it wasn't such a pain I'd be far more likely to do such testing myself. Or are we coming back to the Users Are Stupid/CKAN Knows Best attitude? because it's been shown many times that it doesn't. :huh: As it stands, I'm very near the point of "screw CKAN, this is no easier for me than manual installs." Why should I use (or "do something helpful" for) a [I]tool[/I] that won't do what I tell it to?

So, what's the ETA on sorting out (or just getting rid of) the mime handler installation? it's broken at [URL="https://github.com/KSP-CKAN/CKAN/issues/1510"]least[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1509"]three[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1498"]ways[/URL], and much as I'd love to use CKAN for 1.0.5, up with an application that corrupts my desktop configuration every launch I will not put. Can't we just kill this already? It's not hard to add a file association through the provided desktop tools, for those few who will actually use this. Aside, I'm not overly excited about ckan tampering with files it does not own (and without prompting) in general. Please leave my desktop alone so that I can use this again. ---- As a workaround I'd like to use the command-line client, how do I change the filter from 'compatible' to 'all' on the CLI? CKAN will not show mods that haven't been updated for 1.0.5, or allow one to install them without guessing the exact version, despite said mods being known to work... and this issue is getting rather old.

You need an 'su' binary (such as SuperSU) to get root user permissions and allow apps to do the same. - same as using 'su' for system admin tasks on a *nix box. It's that simple, but there are various methods to overcome the "chicken & egg" puzzle -> you need to be root to install su, but you need su to become root... most of these require flashing su onto the rom via recovery mode or ADB. Some manufacturers make it harder by locking the NAND... (S-on) but the S3 should be ok in this regard. Search for your model on xda-developers, someone has most likely upped a flashable su installer & instructions. Most custom ROMs come with su, and are labelled as 'pre-rooted'. I recommend something Cyanogenmod based. :) Be aware of warranty issues, also some (mostly internet banking etc.) apps will refuse to run on a rooted device (though there are ways around this too). Most importantly, pay very close attention to which apps you grant root permissions to... it's exactly the same as the root account on a Unix/Linux/BSD etc. machine - i.e. full access to everything. Apps are usually sandboxed in the Android java VM, granting root allows tampering with the Linux OS underneath and direct modification of the filesystem. If you don't understand the implications, or your only purpose in rooting is to get some random app to work, don't. Do some reading first.

I'll take your word for it, but I have it on good authority that it did break FAR. If that's the only one, all good.

I bet you a cookie it's not actually random. Getting help without posting the "random code" or error messages is also somewhat unlikely. On a different note, how are you guys handling 1.0.5.silentpatch? time to switch to build numbers for versioning? Or maybe just pretend it didn't happen?

Not sure what's going on here, it's most definitely writing those files at every startup... and overwriting my changes. Using filesystem permissions to make the files un-writeable by ckan is a short-term solution at best - other things may need to write mimeapps.list, and it'll cause grief later on when I forget what I did. Excellent.

Well, it's writing to both ~/.local/share/applications/ckan-handler.desktop & ~/.local/share/applications/mimeapps.list every time I start it - so say both filesystem timestamps and strace. A cursory look at the code sees a remove & recreate in RegisterURLHandler_Linux but I don't see the conditional for the dialog check in Main... or know C# . Removing GUIConfig.xml gives me "allow autoupdates"(Y) and "update on startup"(N) confirmation dialogs, but that's all. - ckan-handler.desktop is simply written again without prompting. Given that no other .desktop file on my system has the formatting ckan-handler.desktop has, I'd say it's a good bet that ckan is wrong - which explains why its file doesn't work on KDE, Gnome, or Unity. It also explains why removing those spaces makes it work, but the irritating bonus is that ckan overwrites the file on startup.

I too have fixed the file for my own purposes, and set it immutable so ckan can't overwrite it with garbage every startup. It'd be real nice if this could be fixed in ckan though, it should be pretty easy to do. Whoever added that 'feature' clearly didn't test it very well, it can't have worked on day 1. - - - Updated - - - +1 Some '--force' command-line switch would be real nice. While on the topic, how about some '--verbose' too? and some history so I can see what (files) have been updated and when? ATM I'm relying on filesystem snapshots to see what ckan changed, but it's not ideal.