Tannin

This may be a fixed issue or a broken update. Please see if a clean 1.3.4 Installation fixes it

MO 1.2.x won't be updated, sorry. If you're stuck with windows xp you're also stuck with MO 1.2.18 and loot 0.5 as the integrated sort option. Although I am a bit confused why it's a problem to run a one year old version of a gaming tool but no problem to run a 13 year old insecure OS which you entrust with a lot of sensitive information.

Well, the error indicates MO fails to parse Dawnguard.bsa, have you modified it? could you check if other tools like bsaopt can read it?

No, MO does nothing with .ghost files, that's a WB-specific feature.

The warning tells you to put mods with scripts in the same order as the plugins and I have yet to see confirmation about a single case where this isn't the safer variant. If you are certain that CRF should be loaded before LAL then you should probably also put the CRF esp before LAL esp. And btw.: Arthmoor is the very reason this feature exists because HEs the maintainer (?) of the only mod that's actually known to cause trouble when mod order and plugin order don't align.

What DanimalTwo said. MO stores the path to mods and downloads as absolute paths so if you move MO those paths become invalid. This is easy to fix though: Go to Settings->check advanced and adjust the paths there.

It's continues to confuse me why this is so hard to understand. The mod list is always sorted by one of the properties of the mod: i.e. Name, version, installation date, priority. When you drag&drop a mod while the list is sorted by name, what do you expect happens? Should MO invent a new name so that the mod goes where you dropped it? When sorting by version, should MO change the version number of the mod so that it fits where to dropped it? How should drag&drop work when not sorting by priority?

@Octopuss: I doubt it. Actually, I'm fairly certain Skyrim starts faster when run from MO than without because the current virtualisation library has a hack that optimizes away a lot/most of the expensive .ini file queries Skyrim does. The new library won't do that because it's intended to be more generic. otoh it will hopefully only generate its file mappings once whereas the old library did that every time a process was started so my expectation is that the performance will be closer to the performance you would get without MO, be that positiv or negative.

Please read the lower half of the announcement post, I think it states very clearly what I intend to do with minor stuff like this. ;)

That makes sense, yes. quick fix for this is: open the file stylesheets/dark.qss and change "opacity: 100;" to "opacity: 255;" That is intentionally actually. When you have a mod list that spans multiple pages, this will let you see where in the list the conflict is even when it's off-screen. Oh, yes, that plugin is from the old version of MO and is no longer required. previewBase.dll now handles dds as well. Was previewDDS.dll actually included in the 1.3 archive? (i can't check right now) I'll look into the other bug reports, keep them coming. ;)

For this beta either post to the issue tracker as usual or post in this thread, both is fine. Just don't send issue reports by PM or create a new thread for a single issue, those might get overlooked. Regarding loot: yes, the dll included in MO is 0.7.0 beta 4

UPDATE New beta version 1.3.1 available on Sourceforge. This should fix all reported problems. The only thing I couldn't make any sense of is the report of load order being reverted, could someone please work out reliable steps to reproduce it? I just uploaded a beta of MO Version 1.3 to sourceforge: https://sourceforge.net/projects/modorganizer/files/? Before I go into the changes, let me first advice against using this version as your primary installation. While it seems to be relatively stable and I've been using it on my own system for a few weeks now I will refuse to even feel bad if this ruins your setup. Still, I would appreciate any feedback. Right, features. Integration of loot 0.7 betathe integrated loot can now be updated without a new release of MO. (1)the mod list now has a new column that displays icons based on the content of the mod so you can quickly see if a mod contains, say, esps or textures or skse plugins or ...the mod list can be filtered by their contentWhen you click a mod that has conflicts, the conflicting mods now get a colored highlight in the list.Apart from this there have been a couple of changes under the hood: MO is now based on the current version of Qt (5.4 instead of 4.8). Unfortunately this also leads to a 4MB bigger archive.Windows XP is no longer supported.more game-specific functionality has been factored out into plugins. While this won't suffice to support non-gamebryo games right now it may be possible for someone (not me) to write a Morrowind plugin. (1) To update loot, get the "loot api" download from the loot github page at https://github.com/loot/loot/releases/ and copy the loot32.dll contained within to the loot directory of MO. Since I already have your attention I'd like to also announce that this is probably going to be the last feature-release of MO, at lease for a while. This is not saying that I'll stop working on MO but the project has become too large for a single person to work on effectively in their very limit spare time and since it doesn't look like an active development community is forming around MO I decided to focus my time on very specific topics. This will allow me to work on those things more effectively while allowing me to keep a shred of sanity. So what I'll continue to do is: Fix bugs in the core applicationFix severe bugs in the virtualisation library and pluginsAdd plugin interfaces on demandWork on a new virtualisation library that is more flexible and supports 64 bitAnything that I deem enjoyable. ;)What I will no longer do is: Add any features (unless I deem the implementation fun)Answer any requests for help (be it PM, mail or on the forums) unless it's "I want to help out with MO but I need advice" or something like thatDo the german translationFix "minor" problems or "medium" problems in the vfs system and pluginsMaintain "lists" like the categories mappings, configurator settings file,...Work on the tutorials in any way The reason I will only fix severe bugs in the vfs library is that this lib will hopefully be replaced anyway when the new one is working. The reason I will only fix severe bugs in the plugins is that I believe those plugins are sufficiently simple that others could easily work on those. If you don't know, the features implemented in plugins is: all the installers, the tools below the "tools" menu, the diagnostic messages (exclamation mark) and now parts of the functionality specific to gamebryo games. Known issues with MO 1.3 beta: right now filtering by the mod list by "checked, unchecked, update, ..." doesn't work.

This is unlikely to happen I'm afraid to say. I'm very opposed to the idea of providing multiple ways to do the same things. Colors wouldn't allow you to do anything you can't do with categories. I'm also not a fan of making MO look like candyland. ;)

If there is no more feedback I'll assume none of the remaining settings has an effect. Thanks to those that did help.

This is very simple probably. The file extension doesnt decide if a plugin is a master, there is a flag inside the file for that. What you have there is most likely a regular plugin incorrectly named .esm

Please verify that f3PBoltTiltUpAngle actually has an effect. I can see in my logs that the game accesses the other 3 settings but f3PBoltTiltUpAngle is never touched. I attempted to set f1PBoltTiltUpAngle and f3PBoltTiltUpAngle to 45 and sure enough, from first person the bolt shoots upward in a 45° tilt (very visible). in 3rd person the bolt still goes straight. So while it would make sense to have f3PBoltTiltUpAngle I'm almost certain the Bethesda guys forgot to implement it.

Thanks, this is good information. What would you guys say: Should the configurator list settings that are only relevant to the CK or Launcher? Maybe I should add another "group" in addition to "Basic" and "Advanced"... re Mouse Acceleration: The point is: according to my logs the game never accesses that value so unless there is something I'm missing that setting won't activate mouse acceleration. sD3DDevice is also only accessed by the launcher, presumably to estimate the best settings, it's not read by the game.

There has been a bit of discussion recently about the Configurator missing settings or incorrectly reporting settings to be placed in the wrong file. madduma on Nexus has created and released a modified settings.json that adds missing parameters. A few I could verify were missing, some were relevant only to the launcher but not used by the game (which imho makes it pointless having them in the configurator) but many I couldn't see any effect. But since there are a lot of settings in question and since it's possible some settings are only used under certain circumstanced I'd like to ask for the help of the community. At the bottom of this post is a list of settings in question. If you can verify that one of these settings has any effect (or not) please post here, preferrably with a short description what effect the setting has, I will update the list occasionally as feedback comes in. When I say "verify" I truly mean: make sure. Saying "when I enable that setting i think the game may feel smoother perhaps" is not very reliable. "I ran through the intro sequence with setting on and off and my minimum FPS went up by 5%" would be better. In Skyrim.ini: [Camera] fOverShoulderAddY [Combat] f3PBoltTiltUpAngle [VATS] uVATSRangedPercentSneak uVATSRangedPercentGlobal In SkyrimPrefs.ini: [Controls] bMouseAcceleration [Decals] uMaxSkinDecalsPerActor [Display] iShadowSplitCount sD3DDevice - Launcher only? [General] fBrightLightColorB - Creation Kit only? fBrightLightColorG - Creation Kit only? fBrightLightColorR - Creation Kit only? [NavMesh] fObstacleAlpha fCoverSideHighAlpha fCoverSideLowAlpha fEdgeFullAlpha fEdgeHighAlpha fEdgeLowAlpha fTriangleFullAlpha fTriangleHighAlpha fTriangleLowAlpha fLedgeBoxHalfHeight fEdgeDistFromVert fEdgeThickness fPointSize EDIT [blurShader] bUseBlurShader [blurShaderHDR] bDoHighDynamicRange bUseBlurShader and bDoHighDynamicRange are used by Oblivion and are read by the SkyrimLauncher but appear to be never read by Skyrim. More legacy settings?

You seem to be missing the complete plugins folder OR you have the plugins from an older version of MO.

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 fairly certain those messages are correct as the right location for ini settings has been determined directly from skyrims behaviour. Please note that there is a lot of wrong information being spread in the community about settings. Someone will say that if you change setting xyz the performance will be better, many will believe its true (https://en.wikipedia.org/wiki/Placebo) and spread that wrong information and boom, everyone believes setting xyz will do something when in reality it means nothing to the game. I've found claims about settings improving performance, quality or stability in almost all "optimization"-guides which I can verify are never ever read by the game. Even the ini files auto-generated by the game itself contain settings in the wrong file or settings that have been abolished after oblivion. Believe it or not, right now the Configurator is probably the most reliably information about what settings actually do something in Skyrim and where they belong we have. Still, if you have concrete cases where you can verify that a setting works set in a specific ini file and MO still reports a warning then please contact me but in the general case I'll assume the configurator is right.

MOs behaviour is to be expected, it picks up all directories in its "mods" directory as its pool of mods. DimmDrive simply copies each directory to its ramdrive then creates symlinks in the original directory after renaming the original folder to xyz.dd.presync this means each dimmdrive'd directory exists twice from MOs pov. It's a very specific problem, especially since DD isn't all that useful (ramdrives have been available since the times of dos and have never seen much use because they're usually not worth it. Especially in times of SSDs) Otoh this should be very easy to fix, I could introduce a workaround to let you set patterns that MO should ignore in the mods directory. You could then set an ignore pattern "*.dd.presync" and MO would ignore those. Might be useful in other situations as well.

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".

Good catch with the event viewer, it would be interesting to know what the error message was. apphelp.dll is connected to windows application compatibility system I believe. One part of this system is the manual compatibility mode you can set up for applications but Windows has some automatic hacks it will apply. Say an application has a bug and frequently crashes with an error indicating heap corruption, Windows will activate its "Fault Tolerant Heap" (https://msdn.microsoft.com/en-us/library/windows/desktop/dd744764%28v=vs.85%29.aspx) for that application and bam, crash disappears (although the bug is still there waiting to hit again. A nightmare on development systems). So a possible explanation for your problem is that something made windows flag MO's hook.dll as "bugged" and activated some form of automatic workaround which in turn broke it completely. By reinstalling MO you might have reset Windows' compatibility info for MO and thus allowed it to run again. Because from my end, there are no "hidden" settings for MO. There's the settings in ModOrganizer.ini and the files and that's that. There should be no difference between an updated version and a fresh install.