Tannin

Please check if you have a SkyUI_4_1-3863-4-1.7z file in c:userslocalappdatatemp and delete it for please try your regular account name as well as Administrator. When installing scripted fomod installers (like SkyUI) MO has to copy the installation file to the temp directory and install from there. Usually it will overwrite an existing file in the temp directory, but if for some reason MO isn't allowed to do that (insufficient rights or the file is open by another process or something like that) that might cause an error like the one you're seeing. Please note: If you have changed the location of the temp directory on your system you have to adjust the above path accordingly of course.

The ModOrganizer.exe you see in the process list is really the UI of MO. If that is still around without a visible window that could have a few reasons. a) the window is on a different screen (maybe not even connected). Don't fret, this happens b) MO hangs at startup. One possible reason might be you had MO running and tried to start a download from nexus. This will start a second MO instance that should connect to the first, transmit the download url and then close again without a window (for that process) ever popping up. If, for unknown reasons, that second process fails to connect or something, it might remain alive. c) MO hangs at shutdown. When you close MO it does a couple of things before it's actually gone, like ensuring all data files are saved. If any of that causes a hang (again: unkown reasons) MO might stay around without a window. With the available information there is no way I could find the problem but if you can narrow down the situation under which this happens, please report that to the issue tracker.

How many other .net applications are you running? And why do you think that is a peculiar piece of MO? There is nothing peculiar about it. NCC copies the file to a system-defined temporary directory (probably something like C:UsersAppDataLocalTemp but could be modified in your system) and then installs to the newly created mod directory

This is false Information, MO DOES have an installer plugin for C# scripted fomods. That's what NCC is for! Since the problem affects all scripted installers, it's probably a permission problem or you (or your antivirus) broke the NCC installation or your .net installation is broken. This same error was a known problem for FOMM (on which NMM is based on which NCC is based): https://sourceforge.net/p/fomm/discussion/999686/thread/35b4171a/ so maybe the reply from karbuke there can help you.

An alternative to the following instructions you can try the papyrus wrapper here: https://forums.bethsoft.com/topic/1513065-rel-advanced-papyrus/ As you might know, running the CreationKit from MO works like with any other executable and MO should discover the CK automatically if it's installed. But since the Papyrus Script Compiler is a 64bit executable and MO doesn't support those, you can't compile scripts from the CK. Except you can, because as it turns out, the PapyrusCompiler is in fact a "Any CPU" executable, which means it contains binaries for 32bit as well as 64bit. So if we could convince the compiler to run in 32-bit mode even on a 64-bit windows we win. And here is how you can to that: a) Download the "windows sdk with .net" package from the microsoft page. There are multiple versions of the package, it doesn't really matter which one you get but here is a very current one: https://msdn.microsoft.com/en-us/windows/desktop/bg162891 b) Start the downloaded installer. Take note of the install location (I'll assume "C:program files (x86)Microsoft Kitswindows8.1a"). During the installation you can select the features you want to install. You only need ".NET Framework 4.5.1 Software Development Kit" (or similar if you downloaded a different package). c) open a command prompt (in the search field of the start menu type cmd then click on cmd.exe) d) type in the following: "C:/program files (x86)/Microsoft Kits8.1a/bin/NETFX 4.5.1 Tools/corflags.exe" /32bit+ "c:/Program Files (x86)/steam/steamApps/common/skyrim/papyrus compiler/papyruscompiler.exe" (This makes the papyruscompiler always run in 32-bit mode. If you ever want to undo that, run the same command with /32bit- instead of /32bit+) Now with the current version of MO (1.2.14 and earlier) there is one more step because currently MO has a workaround for the papyruscompiler that doesn't work 100% and won't be needed with this solution e) Download this hxxp://no_longer_needed and drop it into your MO directory. This is the same hook.dll as MO 1.2.14 but with the workaround removed. From now on you should be able to run CK from MO and compile scripts without a problem. Please let me know if this works for you.

Do not try the downgrade, it's for an older version of MO. "errorcode 5" means "permission denied". My guess is the user account you use to run MO does not have write access to your mod directory.

could you please post a screenshot of the 403 page, including the address bar? I have tried on various PCs with different accounts and can't reproduce it.

dll injection between obse and skse works differently. I just checked out the code of both.MO injects by starting the process (the game in this case) paused, inserts its own initialization before the actual game code and continues the process:a) init vfsb) start gameObse does exactly the same, except that, since MO goes first, obse inserts its initialization before MO so the sequence becomes1) init obse2) init vfs3) start gameThis means obse loads its plugin before MO can start up its virtual filesystem.Now skse creates a so-called remote thread which will run in parallel with the game.1) init vfs2) start game + init skseThis means the vfs is already there when initializes.WHY skse uses a different init mechanism I do not know, in my experience remote threads cause more antivirus tools to throw a fit.Still, that's the situation, there is no obvious way to fix it. The best I can come up with is replace the obse_loader altogether and have MO inject obse directly. This is true only for the steam version of oblivion.

I just downloaded version 1.2.12 but since I won't be able to fix bugs until next week I'm not yet marking it as the latest version. This update should fix the 202 download problems among other things. Also: I had to re-install my server hosting the issue manager. It seems to be running again but If you have trouble please let me know.

yes, initweaks is a collection of all your initweaks. This file is read before skyrim.ini or skyrimprefs.ini meaning that if a setting exists in initweaks its value in skyrim.ini is ignored. The problem profile_tweaks.ini solves is: What is MO supposed to do if you have a setting set in a initweak and then the application (i.e. the in-game settings) changes such a value? Setting the value in skyrim.ini/skyrimprefs.ini like the game would usually do would achive nothing because the ini tweak overwrites it. setting it in initweaks.ini would be temporary because the file is re-generated every start. Setting it in the appropriate individual ini tweak (inside the mod) could be unintended because ini tweaks will usually set parameters required to properly run the mod so modifying wouldn't really make sense. This is why MO stores the setting in a separate file and requires you to manually judge how to deal with it.

Nope, it is run as long as fnis reports it failed to generate its data correctly. The actual problem is that fnis reports minor problems as errors so MO can't tell one from the other which means you have to fix ALL warnings in FNIS or disable the checker plugin. The issue you linked to is about MO not unlocking after it ran fnis.

Well, the answer is the same: You have some software or virus that actively prevents MO from working, there is nothing anyone can do from our end. You have to find out which software is responsibe and maybe then I can provide a solution.

Why on earth would you go through the trouble of installing a mod if you can't tell if it's working? Hoping for a placebo effect? The only real way to know if a mod is really really working is to know what it should do and verify in-game. MO will highlight a mod (by having the name appear in light grey and italics) if it contains no files at all that would affect the game but there is no way for MO to know if ALL necessary files are there.

splwow64.exe is somehow connected to the printing subsystem of windows. In the log file you printed you're NOT running the game, you're running BOSS and for some reason it's trying to run that printing-related binary which is 64-bit and can thus can't be hooked. This is not necessarily a problem, the only thing that happens is that this printing-related program won't see the virtual filesystem.

You have to quit chrome before changing the file. Du musst auch erstmal Chrome schließen bevor du die Datei ändern kannst. ;)

I verified that this is not a problem in MO, the Nexus fails to return any download links for the file. This affects NMM as well as MO.

Neither, you should do what it says. Look. if your order is A B C And it suggests to "move A after C" and "move B after A" IN THAT ORDER, that does make sense, no? To my knowledge that tool works fine except for a few cases where it will suggest moving an update before the base mod when the base mod contains mulitple esps and the update doesn't replace them all. Placing unofficial patches late in the installation order isn't a problem as long as the script-conflicting mods are correclty sorted. the PMOP suggestion cares only for that, not for anything else.

Issue tracker. always.

Tbh. I have no clue how it could work if you don't have a cookie from an earlier attempt. MO currently identifies itself with "Mozilla xyz" as the user-agent because originally the login went through the regular website-login-script (in contrast to the other request which go to separate scripts for applications) so it seemed prudent to identify as a web browser. When the last login problems occured I changed (on request of nexus staff) the login to be the same url NMM used but I didn't change the useragent (because Mozilla continued to work so I didn't think to change it). Now nexus checks the user-agent too. They have not locked out MO specifically, if I log-in with the same user-agent I use for all other requests ("Mod Organizer vX.Y (compatible with Nexus Client vA.B)") login works again, so there is no ill intend here.

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.

It's completely possible the dotNet-check isn't up-to-date with what NCC requires. NCC has been updated more frequently than that test, so... It's also rather crude, checking for the presence of a specific registry key, but I haven't found a clean way to check for the dotNet version from a native application.

that check tests for dotNet 3.5. I'm not sure why the link leads to a dotNet 4.0 installer but this is the first (in well over a year) I hear this is wrong. :(

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

Teamspeak (3) and MO both use the Qt library for their interface. If the same problem has ben reported with TS, it's very likely an incompatibility between Qt and the drivers of your mouse. Bad news is that I can do very little in such a case.

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.