Tannin

You wont find the symbols on the internet. Send the dmp my way (sherb at gmx.net) and i'll take a look. Its more likely mo using qt incorrectly than the bug actually being in qt

I'm not 100% sure because I can't check right now but I believe the name is probably the first alphabetically.

No need to delete everything, all you need to delete is the "installerBCF.py" file under "plugins".
Don't worry, you don't lose any functionality.

please delete the file ModOrganizer/plugins/installerbcf.py. That plugin does nothing and was never intended to be released.
I must have accidentally included it in one of the 1.2.x releases and now it doesn't load any more. But as I said: the plugin doesn't do anything anyway.

The sResourceArchiveList is turned into short-names and mapped back to regular file names for every application run through MO.
If an application sees something different than the game this may have two reasons:
a) it uses a different list of archives (i.e. hard-coded) in which case the application is inheritantly unreliable in this regard anyway.
b) the application reads the archive list in a different way than the game. I.e. an application could open the ini file as a txt file and parse it manually. There is no way MO could then "fix" the list. Again one could argue that if the application reads the archive list in a different way than the game it's the applications fault if it gets different results.
 
A little known fact: ini files can be placed in the registry and the regular windows ini-reads (which skyrim uses) would transparently fetch the values from registry instead of the ini files. Doing this for skyrim might even make sense to improve startup time. Of course tools that don't use windows ini-reads would not get the registry values.
This, combined with the fact that ini files are not a standardized file format and therefore every method of reading them might produce different results (i.e. because of different syntax for comments, different character encoding support, ... ) means that all tools that use different means of reading ini files than the game should also, technically at least, be considered unreliable.

Yes, your MO version can't communicate with Nexus anymore so an automatic update is out of the question.
Usually the following should always work: Download the full archive (not the installer) and extract the whole content to your existing MO installation such that the existing files are overwritten.
This doesn't overwrite your profiles or settings so everything should be good. This may leave some obsolete files in place but apart from taking up a little disk space that wouldn't hurt.
 
To be safe you might wan't to create a backup of the whole MO folder first.

I'm not sure those are "unimportant" log files, .json are usually data/configuration files, the "MovedFiles" file may be important as well. My advice is: create a mod from overwrite (right-click) and called it something like "_overwrite". This will move those files to that new mod and when they get changed/recreated they should remain in that mod.
 
Now the MO warning about "files in your overwrite folder" will alarm you of new files in overwrite and you can again make an educated decision about where to put them (in a mod? in your _overwrite? into the actual data directory? or delete them?)
 
This is the whole point of that warning: MO can't possibly know what the relevance of the files is and where they should be so the warning is MO asking you "please, use your mighty human brain and google-fu to figure out what to do with those files".

The warning shouldn't do anything.
the qaccessible stuff is for supporting accessibility for users with disabilities (i.e. high-contrast ui or special keyboard shortcuts)
This subsystem seems to be incompatible with certain input devices, most prominently wacom tablets and mice.
There appear to be some high-precision mice from other vendors that also don't play well with qt.
 
This is something I could fix on my side only by updating to qt 5 and that unfortunately brings along new problems.

Most likely you have MO running started as administrator but your browser is running as a regular user. This won't work.

The Warning (W) (Not to be confused with Error (E)) simply says that MO failed to monitor for changes in your skyrim-saves directory. Most likely you haven't started Skyrim yet so there is no such directory so this is a non-issue.
 
Regarding your browser I really can't say what the reason is. MO uses a very simple mechanism to display a website that says to windows: "Please windows, display this web page in whatever software you deem appropriate." So either Windows 8.1 broke this mechanism or you don't have a default browser (for whatever reason).
Those are the only reasons I can come up with.

No you shouldn't need it for any other version than 1.1.2. Please let me know what the error message is and what mods are affected.

Nexus changed the url through which the login happens (or at least it disabled the url I was using before). Therefore MO can't login (which it reports) and therefore downloads > 2MB don't work.
 
I'll release an update next week, until then I'm afraid there is little to be done except for manual downloading.

No, there is a best practice: Install MO in a location where you don't need administrative rights to write to! Very simple: If you can install MO without needing administrative rights then it's a good location.
 
MO is designed as a portable app, it stores and changes files in its own directory.
The "Program Files" directory otoh is designed to contain only "static" data of an application that is not changed post installation (except for updates) with "dynamic" data being stored in the user directory.
 
tl;dr: Don't install MO below "Program Files" and don't run MO with administrative rights.

The first message only tells you that MO doesn't have a Danish translation. I assume that's your system language hence MO tries to load it. No problem here, it uses English as a fallback. The second message probably has the same cause as the download problem, neither is the reason for the other.Both error messages tell you that MO can not open the directory C:/Users//Desktop/ModOrganizer/downloadsThat directory doesn't exist or MO isn't allowed to access it. Please double check that there isn't a typo in that path like a wrong letter in the user name or maybe your MO path on disk has a space between "Mod" and "Organizer"?
 
One more thing, though I doubt it would cause a problem: Does your username by any chance contain any funny letters not found in the english alphabet, like an Ã˜ ?

You're using the MO 1.2.0 beta version, which includes a broken version of ncc.
ece didn't install correctly and so wrye bash was correct in reporting an error.
Please apply the ncc downgrade from the MO page on nexus or wait for the update to 1.2.1.

It's basically a general limitation of character encoding.
It is simply not possible to reliably determine the encoding of a file unless it's unicode and contains a BOM (Byte Order Mark).
 
The internal viewer of MO tries to detect that BOM. If it's missing it assumes UTF-8 (which is another unicode encoding that is often produced without BOM).
It currently doesn't support the ancient notion of country specific character sets at all.
 
The best approach here would be: If you have a file that doesn't show correctly in the MO window, send the author a mail that the 21st century says hi and looks forward to meeting him.
 
Yeah, I know this isn't realistic, we're going to live with DOS tech for a couple more decades, so I'll look into it.