Tannin

Please note: When python is installed properly, a python27.dll will be placed in a system directory (C:\windows\system32 on 32bit windows or c:\windows\syswow64 on 64bit windows). MO should find this dll if it's there. This is completely automatic through the official python library I use and can NOT be influenced by me (user can influence it by placing the dll somewhere else in the dll search path but I'd advice against that UNLESS you lack the rights to install python system-wide). python_dir influences only where python libraries are taken from. This should be automatic and MUST match the python version that is discovered automatically. If the python plugin doesn't work at all, you most likely have NOT installed python correctly and thus the python27.dll is missing in the expected directory. If you get cryptic error messages with backtraces that say "python" repeatedly OR if MO crashes and on next start claims that the pythonproxy plugin caused a crash then your python_dir is probably set incorrectly. Thus far I'm not aware of any problems with the python plugin that are not caused by one of these issues: - python 2.7 (32-bit) not installed (correctly) - python_dir set incorrectly

I realised how old I am when I was writing that bat file and missed vi. ;)

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.

First things last: Mod Organizer should deal with "false esms" correctly in the current version (since a few versions actually). With MO, assuming all archives are "checked", the BSAs are treated exactly as if they were loose files. That means the priority depends solely on the mod order (that's the left pane in MO!) and NOT on the esp order. This is imho a neat feature because it lets you ignore BSA ordering completely. To understand BSA ordering under MO all you have to do is FORGET that they are supposed to be special. You sort your mods on the left pane so you get the assets you want, you sort the right pane according to boss for maximum compatibility. End of story, it doesn't matter how they are packaged. The difficulty with some mods (Unofficial Patches in particular) arises because the mod has dependencies that the author fails to document properly. USKP introduces an incompatibility with other mods (in particularly dragon soul related) and claims it has to be fixed by others. Basically when USKP/UDBP description says "Check for: dragonactorscript.pex and/or mqkilldragonscript.pex. Remove them if present. They are from dragon mods that came as loose files." What they mean to say is this:

Mod Organizer doesn't create start menu entries for itself. It never has.

The crash problem when bsas are extracted should be fixed in the current version. If you have the goty version of FO3 you probably have to change the steam app id in settings->workarounds to 22370

Yeah, that's normal. The debug messages are usually meaningless but in case of a bug they may help tremendously in finding the problem because they tell me (approximately) what the program was doing internally when it crashed. They may even provide pointers in identifying problems with mods. If the log size presents a problem you can lower the log level in the settings dialog so that debug messages aren't displayed.

Weeeell, no, this is actually a bug. Fix will be in the next release. ;)

I'd advice against renaming the files on disk because as long as you keep the original name MO can warn you if you re-download the same file again. One thing I could do is add a toggle to show mod names instead of file names (where available) but of course the mod name could still be too long. But this would lose information (i.e. 1k version vs. 2k version) Another option would be to trim the name to the first n characters and the last n characters. I.e. instead of "Skyrim realistic text..." you would see "Skyrim rea ... erhaul 1k" I guess in most cases this would provide more information. Finally, I could add the full name to the tooltip

As has been mentioned, fomods are themselves archives. Occasionally a mod author will distribute a .7z that contains a .fomod so the content is compressed twice. MO, both the integrated and the external installer (NCC), handle fomods from fallout BUT the fomod format has gone through a few iterations and while NMM seems to support all old archives, NCC bundled with MO seems to have problems with some old-style fomods (i.e. at least one of the popular hud mods). And I hate working on NCC :( I hope that with NMM 0.5 the code becomes more "compatible" with separate directories for mods and thus easier to adapt to MO, but for now everytime I touch it something else breaks...

If Texture Optimizer (which I have only ever touched once half a year ago) works like this (recursing through all mod folders), then this is the way to go. The only thing that speaks against that is that you have no control over which mods get optimized, even mods that aren't active would be optimized but I guess that makes little difference..

Not really an issue with MO, BSAs checked under "Archives" are loaded, independent of the esp.Thanks for that info. So MO will always load a BSA that is checked under "Archives" regardless of the presence or absence of an esp. That's very useful.There is one restriction:Users who get the "failed to remove limit on archive list!" error message can only load around 80 BSAs this way. Those users may have to unpack after all OR load the corresponding esp. I don't know under which circumstances this error occurs and how many users are affected, since I haven't heard much in this regard I assume it's only very few. May be related to a exe modification *cough*crack*cough*.

The strain on the CPU is only at the times the game loads from disk. Unless you're playing on a Pentium 90 packed BSA are almost guaranteed to perform better. Still, the effect is probably hard to notice. Not really an issue with MO, BSAs checked under "Archives" are loaded, independent of the esp. The game loads in the background, there is constant HD access which may cause stuttering/delays when a lot of assets are required at once (i.e. opening the inventory, the character creation dialog, ...) To rephrase my earlier post: I think it's a matter of taste, all arguments for or against unpacking are a bit *meh*. Personally, I leave my BSAs packed and never had any trouble with that.

It depends on several factors. BSAs can be compressed. In this case loading files from bsas increases the cpu load while reducing HD load (during startup time). In most cases load times are HD bound so (compressed) BSAs load faster. Also a BSA is only one file on disk so the directory structure (which MO needs to hold in memory to provide the fs virtualisation) is smaller. As a consequence MOs memory footprint is smaller if BSAs remain packed. The primary reason to unpack BSAs is because (without MO) it's not possible to customize the order of loose files between bsas and loose files. This is why wrye bash afaik unpacks BSAs. !BUT! MO more or less fixes that: asset files are always prioritized the way they are sorted on the left pane no matter if they are stored as BSAs or loose. Long story short: No, I wouldn't unpack BSAs unless you have a good reason to.

As a rule of thumb: If you install a new version of the main file "replace". If you install a "patch" for the main file "merge". If you install an option (as in: mod works correctly with or without it), "rename". "rename" is probably the cleanest solution, since it allows you to update the main mod and options separately. You can select "Nexus ID" in the grouping drop down (below the mod list), this will put main mod and options into a hierarchy so there is less clutter. You can currently not use drag&drop while a grouping is active. Unfortunately since MO has no way of tracking updates for individual files from a mod this still requires manual bookkeeping. Say you have I. "mod A main" - version 1.0 II. "mod A option A" - version 1.0 Now the author updates "option A". One of two things happens: a) The author imcrements the mod version. BOTH mods I. and II. will show an update notice although only one can be updated. Afterwards you can increment the version of I. manually to get rid of the update notice but if the mod author later decides to make an actual update to "main" with the exact same version number you get no notice. This should be rather rare though. b) The author does not increment the mod version. You get no update notice and have to find out about the update yourself. After installation there is no sign that II. has been update. In both cases, during installation MO will offer you to install it to "mod A main". You have to manually select the correct mod (II.) and select "replace".