Tannin

The list is always updated when you download a file. Due to that the list may be missing servers that didn't host the most-recently downloaded file.

Someone please report this as a bug on the issue tracker. And please include the name and link to at least one affected mod and where a valid description isn't being shown.

As you may remember a while ago Nexus decoupled the website from the interface for tools because NMM was responsible for a lot of lag on nexus. It's important to realize that this wasn't a fix, it only means that NMM will not bogs down reachability for the web page any longer, it now "only" hurts to tool interface. This does affect MO as well. Therefore the fact that you can still download via the web page means nothing, it's most probably still a Nexus problem.

- Well, the screenshot you posted is 1565px wide, that's about twice the default window size of MO. And you have streched the left pane a lot compared to the right, which forces the right pane to truncate filenames. This does render your first point a bit moot. MO is not designed as a widescreen fullscreen application, it's designed as a window application that leaves a bit of screen estate on a 1024x768 screen. - Coloring is not sufficient, some of the MO users are color blind and have specifically asked for icons instead of (or at least in addition to) coloring for highlighting. Please don't mistake me, I'm not dismissing the proposal per se, I just don't know yet how without breaking other design decisions I made earlier.

My proposed modifications to your naming: * Game INIs: - Default INIs: the _default inis located in the game directory - Base INIs: The standard game INIs located in %USERPROFILE%/My Games/Skyrim - MO Profile INIs: The MO-profile-specific Skyrim INIs * INI Tweaks: Mod-specific INIs that exist in an INI Tweaks folder at the top level of the mod package * INI Tweak Composite: The temporary combined ini tweaks generated from combining the ini tweaks * Plugin INIs: presence should be indicated by the paperclip on the mod in MO (left pane) ... Plugin INIs should have the paperclip within the plugins list (right pane) as is now the practice. Rationale: a) MO isn't Skyrim only so I can't talk of "Skyrim INIs". Base INIs is reasonable imho insofar as all profile inis are based on those inis ... b) ... unless the user chooses to base them on the default inis c) Mods are bundles of plugins, assets and ini tweaks (in MO: left pane). One mod can have zero, one or many plugins. Therefore we also have to clearly distinguish mod and plugin d) a mod can have zero, one or many ini tweaks, whereas a plugin can have only zero or one plugin inis e) Ini tweaks can be disabled, plugin inis can not.

If this were numbers in a math test in one of the few countries where dot is a decimal separator: yes, you would be right. But it's not, it's a version number and there 1.11 is (usually) considered larger than 1.2. Maybe it help if you mentally replace the dot with some other symbol: 1#2 doesn't necessarily seem larger than 1#11, right? MO can't track patch version separately from the main file, Nexus simply doesn't provide the needed information to do that. When a new version of a patch is released, MO has no way to figure out that file is even related to the patch you downloaded before. Therefore MO can only track files correctly if the mod author keeps his mod version and all file versions in sync. Otherwise you have to manually modify file versions. This can't be fixed unless Nexus how secondary files are handled.

the only thing you could do about it is rename the file and remove the version number MO stumbles over (i.e. rename to XPMS_NMM-BAIN Installer...)

MO supports multiple incompatible versioning schemes, i.e. one where 1.2 is newer than 1.11 and the correct one. The button you clicked basically tells MO "The versioning scheme you assume for this mod is wrong, the version I have installed is older than the one on nexus". MO will then try it's supported versioning schemes to find one where that is true and apply that to the mod. The way you describe it the version of the mod was already marked as outdated so the "change versioning scheme" option shouldn't even have been displayed.

tbh I consider solution b) unacceptable. It would mean for example that you can't change your audio volume in game. Or graphic settings. Or controls. You would have to go through MO tools for everything. Even if we improve this solution to "only settings provided in initweaks are written back to initweaks, everything else goes to the regular inis", the same could still happen: Every setting provided by an ini tweak would effectively break the corresponding control in all configuration tools except MO. This would appear to users like a bug. I'm currently working on solution d: If a settings provided by an initweak is set and the value is the same as in the tweak, nothing happens. If a setting provided by an initweak is set and the value is different then it is written to a new ini file located in the profiles directory. This ini file will also be applied like an ini tweak and will thus become active in future sessions. There will also be a warning notification if this file exists advising to integrate those settings into a "regular" ini file or a regular ini tweak.

Right now a mod may have up to 5 different flags at a time and there is a good chance this number will increase in future versions. If I were to align the flags this way I would have to reserve a lot of space for the flags in a section of the screen that suffers information overkill and where screen space is valuable.

It's still a permission issue though. ;) On modern Windows administrator can not do everything so there is still the possibility of too restricted permissions. 1. Select the dlc files, right click on the selection than click Properties -> Security (tab) -> Advanced (button) 2. Go to Owner tab and check what the current owner is. If it's anything other than your user account, click "Edit..." and change the owner account to your user account. 3. No matter whether you changed anything on the owner tab, go to "Permissions", select your user account then click "Edit..." and give yourself "Full control". I had to translate the menu names from german so I hope I got them all right, otherwise please try searching around a bit. The short story is: It's possible that the acls (access permissions) on the files are borked, either referring to an owner that doesn't exist on your system or it simply doesn't allow access for the owner. Both is possible, you CAN strip the owner of a file of all access rights on windows.

I think most mods that don't provide options use this structure: A mod consisting only of an esp is the simplest case, like this: |-> someplugin.esp Or an esp and a bsa which should cover most mods out there: |-> someplugin.esp |-> someplugin.bsa Or assets |-> textures | Â -> sometex.dds |-> meshes | Â -> somemesh.nif MO will also "dig" any number of levels deep to find structure like this, as long is it's not "skipping" any files. i.e. this would be handled by the simple plugin |-> Sample Mod | Â -> data | Â Â Â -> someplugin.esp | Â Â Â -> textures | Â Â Â Â -> sometex.dds But this wouldn't: |-> data | Â -> someplugin.esp |-> readme.txt Mods can be incorrectly handled by the simple installer, i.e. if they have this structure: |-> someplugin.esp |-> hi-res variant | Â -> textures | Â Â Â -> sometex1024.dds |-> lo-res variant | Â -> textures | Â Â Â -> sometex2048.dds But to my knowledge none of the available mod managers handles this kind of mods correctly so they are reasonably rare.

Octopuss: Did you install with the integrated installer or the external? I wouldn't be surprised if the NCC installer fails for such a large file. The archiver has two mods of operation: In one it's ridiculously slow to display menus because it will extract files (i.e. images) individually so if the archive is solid it will extract the whole archive once for each file to display. In the other mode it creates a buffer in memory for the whole file, then extracts the file to another buffer. Thus it requires archive-size * 2 Bytes of memory (esp. address space). Since it's compiled as a 32-bit app that won't work for archives > 2GB. Please remember NCC is based on NMM code, I'm not touching that area of the code because then I will have to keep patching it every time I update.

The code is hosted here: https://sourceforge.net/projects/modorganizer/ The relevant code for the integrated fomod installer is under source/plugins/installerFomod The relevant code for NCC is under source/NCC

I don't have access to my development computer over the weekend so I'll look into the reported problems next week. There have been several crash reports though they all sound very similar. Probably they have the same cause. An email is ok, I'm used to getting emails regarding MO. tons of them. ;) As an alternative you can upload dumps on dropbox or similar and send me he link (by mail or PM)

Regarding the bugs: 1. This isn't a bug. With the integrated boss functionality MO can work without a separate BOSS or BUM installed. This means I can't make assumptions on certain BOSS directories even exist. Also I'm considering to eventually allow userlists to be modified from inside MO. basically the plugin list would be auto-sorted and manually moving a plugin there lets you create a userlist rule. This means MO will then need its own userlist anyway. 2. Yes, this can't currently be fixed. Actually, integrated boss in general will only be able to see files that are in the data directory because boss has these folders hard-coded. I can't fix this without rewriting boss completely. The informational messages from boss thus have limited use, boss integration is really only about sorting. 3. ? 4. MO doesn't parse the userlist, that's boss. If the content of the userlist causes trouble (although you're sure it's correct) I'll have to escalate that to the BOSS devs. Please send me the relevant userlist.txt 5. That's expected, MO doesn't save these (because as mentioned in 2. they have limited use anyway) 6. If you could reproduce the problem that leads to this, please let me know. Afaik MO doesn't apply the sorting at all if boss reports an error.

There is no limit on the number of mods you can install or activate. Only the number of active plugins is limited.

MO can't reliably determine if an application is still accessing its virtual file system. You may have noticed that if you run - say - boss from MO, the UI gets locked and unlocked after boss quits (refreshing all data files that outside applications might have changed like the plugin list). However, when you start skse from MO and skse starts skyrim then MO unlocks the UI almost immediately because the application it started has finished (skse), while skyrim still accesses the vfs. Any changes the game might make to the vfs (i.e. skse plugins writing logs) MO will not know about. The other way around, changes you make in (enable/disable mods) will not affect the game (while changes on hdd, like deleting files will, obviously). To avoid confusion (esp. for new users) I opted for MO shutting down by default so you either run MO or the game, thus you don't have to know how the two might interact. It's fairly safe to toggle MO closing as long as you are aware of what I wrote in the first paragraph (which is why I wrote it before answering the question :P )

RRR_3DNPC-Patch-25029-1-8.7z.unfinished is an unfinished download that should usually be resumable. Since in this list you already have the finished download (probably you started a second download?) you can safely delete the unfinished file. If you have "RRR_3DNPC-Patch-25029-1-8.7z.unfinished.meta" but no "RRR_3DNPC-Patch-25029-1-8.7z.unfinished" then that means MO failed to remove the meta file created during download. Again, it's safe to delete. The next version of MO will do that automatically.

If you download manually and then "Query Info", MO has less information to go on. It has to "guess" the mod id from the file name, then retrieve a list of downloads from Nexus and match the downloaded file name against those files to determine the file id and version. Both can go wrong. The file name can be so obscure that MOs guessing fails and it then continues with a wrong mod id. Also, the list of files MO can retrieve from Nexus is limited to 30 (Nexus limit, not MO limit), so if your download is not within those 30 files, query info fails. When you use "Download with Manager" links, all necessary information is passed along with the link. Also, MO tracks downloads speeds for download mirrors (available in the settings menu) so it can prioritize the fastest server automatically (i admit, the algorithm leaves room for improvement) whereas with manual downloads you have to know which server is fastest yourself.

Next version of MO will automatically delete these files.

It's only relevant if "external" is true and it influences how the ini file is opened. If the associated flag is true, the application associated with ini files is open. this is equivalent with double clicking an ini in a file manager. If false, the default text editor is started, this is equivalent to right-clicking the ini file in the file manager and selecting "edit". I believe in a default windows setup the same will happen in both cases, but if you change the file association for .ini files (say to wordpad), "associated=true" will use wordpad, "associated=false" will use notepad

The CBBE installer has the magical ability to pop up in the background and NOT show up in the task bar. You will only see it by alt-tabbing. I have no clue how it did that but it does. Previous versions of MO tried to bring the window to foreground by polling the window list for the installer process and bring the window to front as soon as it appears but there was still a bug with that. 1.0.12 fixes that. tl;dr: The installer has probably worked before but you probably didn't see the window.

It's also a good opportunity for a modding community to die. A more modern engine is almost guaranteed to be more complex thus harder to mod and harder to produce content on par with the base game. One good example for this is the Neverwinter Nights series: NWN had a simple engine an extremely easy editor and today there are almost 6000 quest mods. That is playable content, not nude mods or saturation-increased textures which is 90% of the skyrim mods. You could probably play 2 hours of nwn modules every day for the rest of your life. Or you could stick to the highly rated stuff and be done in ten years. NWN2 had a more complex engine (terrain) and thus a more difficult editor. But most of all the base game was fully voiced and so every user-made mod felt low-quality unless the mod author had a professional sound studio at home. The result: only around 450 user-made quest mods which on average are shorter and more buggy. And this is still more playable content than is available for skyrim (380 mods categorized as quests or adventure) or Dragon Age, which was touted by Bioware as the spiritual successor to NWN (53 quest mods) When NWN was current, Bioware was the unchallenged "moddable game company" (more than twice the number of quest mods than morrowind has mods in all categories combined), they gave that away by building more complex engines without improving their modding tools to the same degree. Probably lost their whole community to rpgmaker or something. If the next Bethesda game turns out to be harder to mod, the community MAY choose to rise to the challenge. Or they switch to a different game/engine. Or they stick with Skyrim for the next 10 years. More on topic: Nitpick seems to fix (or at least it has at some point fixed) 3 issues: 1) character limit on ini entries, particularly the limit on the archive list 2) fixed a limit of 508 esp/esms in the data folder (no matter whether they are active or inactive) 3) superfluous attempts to read from ini files that don't exist MO does 1 and 3 out of the box. 2 is not automatically fixed but Settings->Workarounds->Hide inactive ESPs/ESMs does exactly the same as nitpick (as far as I understood it). So there you have it: I claim Nitpick is not necessary if you have MO. ;)