Tannin

Please create an issue with that log on the issue tracker.

For a user it is often hard to determine what is a bug and what isn't. To me it seems the "bug isn't reported because user doesn't recognize it as such" is almost as frequent as the "non-bug is reported". Closing a report when it isn't one takes me only a moment (although I do realize it may be annoying to the reporter that the time to write it down was wasted). But finding out that there is a bug which was known to users but never reported is annoying as hell. It may take considerably longer to find because the "context" in which the bug appeared (the first version it showed up or maybe changes on nexus) is harder to narrow down and I may be forced to change my release-plans because I want the bugfix out asap. That could then lead to features being released that haven't been tested enough and more bugs in the wild then necessary. In short: I'd rather have too many bugfixes than too few. If experienced users were to visit the issue tracker and see if they can clear up some of the reports that would of course be very helpful too. Your (and DoubleYous and others) efforts on the issue tracker (i.e. confirming fixes) are highly appreciated. If anyone is interested in taking a bit more responsibility on the issue tracker I can of course also give you some additional rights, so you can confirm or reject issues directly. The issue tracker can be moderated just like a forum, it's merely a better way of gathering and presenting the current state of an issue. The problem with tracking "issues" on a forum is that it's very hard to communicate when the issue is gone. I frequently get messages saying "I heard there is a bug in MO so I applied this workaround and now things are broken" when in reality the bug has been fixed a long time ago and the workaround is obsolete. People will go to this forum, read about an issue and follow the guide to fix it without verifying the problem even exists any more. Happens. All. The. Time.

I just locked the comments section on Nexus because again, bugs are reported there but very few bother to post them on the issue tracker. Consistently I ask that you don't report bugs HERE except to warn other users about consequences but even then, of course, the bug also needs to be posted on the issue tracker. If a bug isn't on the issue tracker I do not know about it.

It's perfectly safe to ignore the message.

You didn't enter the command correctly, probably you entered "corflags papyruscompiler.exe" instead of "corflags /32bit+ papyruscompiler.exe" The whole point of the tutorial is to set the 32bitreq flag to 1

No, how would it? MO lists all servers Nexus transmitted in the last download in that instance of MO If there is only one (which is it? CDN?) then that's what Nexus tells me, I highly doubt NMM has any faster mirrors available (unless you are premium user and didn't enter your account info in MO). Problems with CDN are a matter for Nexus.

Go to settings->nexus and change the preferred download mirror to one that is faster for you.

Unless Bitdefender has an option somewhere to disable this protection this can't be fixed except by uninstalling it. What happens here is very simple actually: Bitdefender protects the whole process against modification by foreign software. This makes sense in a way since the technique used by MO isn't very different from what rootkits do. Rootkits use api hooks to hide their files, MO uses api hooks to have files show up that are actually somewhere else. Bitdefender tries to protect you from rootkits, MO is collateral damage.

I'll reply to this once more because wth. a) MO decides which version is older so that it can tell you "Your version is outdated", "your version is NEWER than that on Nexus" or "Your version is current." b) Yes, this makes things complicated in the presence of completely borked version numbers but please let me assure you: MOs version numbering scheme is pretty good in comparison and it adheres to standards, it's the mod authors that don't. c) You don't believe that MOs version parsing is good or that it's useful to have an order of version numbers? Then check out the changelog on Nexus and see it break for the most basic and established versioning scheme. d) You may not like or want this functionality but I do and since I had to do the implementation I get to make the choice. You may not like it and you're welcome to argument against it but please also respect that I had my reasons and that I simply came to a different conclusion than you. A simple text field that can be compared for difference only would have been far far easier for me to implement but I was not satisfied with it. e) version numbers that look like these: a.b.c.d indicate a specific versioning scheme which is one of the (or even the) most established versioning scheme there is. Companies like Microsoft, Adobe, Bethesda, ... use them (often internally). They are interpreted as four individual integral numbers. 2.04.4 means major version = 2 minor version = 04 = 4 subminor version = 4 the minor version is NOT the decimal part of anything it is a separate integral number and therefore 04 is the same as 4. If someone writes 2.04.4 and expects it to be interpreted as a single number with 2 decimal dots then he's obviously being silly. f) a in a version number stands for alpha, b in a version number stands for beta. This is convention not my invention.

That shouldn't be the case. The suggestions should only list mods that have conflicting scripts and the moves should simply put the mods in the same order as the corresponding esp. This is because mods with bsas would (if the bsas weren't extracted and you weren't using MOs archive order handling) load in the same order as the esps no matter what your "installation" order is and some mod authors may rely on that.

I'm not sure we (Spock, GrantSP and me) are on the same page here. Are you refering to "Some mods require to be re-initialized if their index changes "? This is absolutely not a new problem or something related to MO, this has been true at least since Oblivion and with or without MO. If a esp has mod idx 1f then all id (for example for items) have the ids starting with 1f, so the new armor added by the mod might have the id "1fbaddad" Now obviously if you reorder mod and the mod idx becomes 1a then the armor id becomes "1abaddad". The game can usually cope with that keeping your inventory intact but the custom scripts in many mods can not and have to be reinitialized.

Not sure what's wrong in detail, but as others have pointed out the error means: What you have entered in the "Binary" field is not an executable (.exe). It doesn't matter what's in your "Starts in" or "Arguments" field, that won't cause this error, only the "Binary" field is relevant. You can only have 32-bit .exe files in that field, not .jar, not .bat not .cmd or .py or ...

No worries, I didn't intend to flame you, I just wanted to make it very clear that your suggestion (overwrite loot order manually using lock mechanism) is not a universally accepted technique. It's difficult for users to see which suggestions are established "community knowledge" and which are preferences of individuals. LOOT is about relative ordering of plugins (this goes before that, this requires that, ...) to provide the best compatibility. The lock mechanism in MO is about absolute positioning of plugins. It tries to keep a plugin at a specific index in the load order while the other plugins may be re-ordered around it. This also means that locking may break the correct relative order and should therefore be used carefully and selectively. Some mods require to be re-initialized if their index changes and locking in MO is intended to "freeze" a plugin in place so the mod doesn't get re-initialized whenever another plugin gets added before it. That's the only reason the locking feature exists.

This is WRONG LOOT sorts according to an automated algorithm that can be overwritten by a masterlist and then a userlist. The algorithm is right most of the time. If it isn't the masterlist will have a rule unless the mod is very new. If the mod is very new and you disagree with the ordering then you should contribute the corrected order. If the mod is not very new and you disagree with the ordering then you are almost certainly wrong! And finally, if you absolutely cannot believe you are wrong and you absolutely cannot contribute to a community project then you make the changes in the userlist so that loot will always apply the order you (mistakenly) want for that mod. Do NOT use the lock mechanism to fight the loot ordering, that's not what it's there for! But all of this has nothing to do with the topic because GrantSP already gave the correct answer and there isn't anything else to say on that.

MO gives no message whatsoever (also not in the log window at the bottom) when it fails to create the shortcut? The icon of the "create shortcut" opton doesn't change?

You solved the problem for exactly one person: yourself. That's not how a community works.

To my knowledge there is no cache or something in the engine between runs, I don't think you need the esp active at any time. My guess is that either the engine failed to load the texture due to a glitch (insufficient memory or something) which isn't actually related to how the bsa is loaded or (and I'm afraid this is more likely) MO failed to write/update its archives list before starting the game. In this case the bsa isn't loaded, but not because the mechanism is inherently broken but because of a bug in the implementation. If you still have the ModOrganizer_.log from the time the texture was missing you could look into it and see if the bsa in question appears in the list of "aaa maps to soandso.bsa"

The "Fix" button is marked as beta because I was worried it could cause more changes to the mod order than it's supposed to, but so far I've had no reports that that's the case. The PMOP reporting itself is imperfect and there's little that can be done about it as it's an automated system. We'd need something comparable to loot's masterlist&userlist system to define per-mod overwrites of the pmop suggestions and that's far, far beyond the scope of what I can do for a single feature. Especially because this would probably be even more complicated than loot considering mods are named by the user whereas loot can rely on plugins having a certain name. There is a bug remaining that will hopefully be fixed in the next release and maybe I will add a way to have it ignore specific mod-pairings but beyond that this feature is "done". Not because I'm happy with it but because it serves its purpose (alerting user of potential problems) and perfecting it is impractical.

Well then, have fun...

The way you go ballistic because people disagree with you makes it very hard to take you seriously. I'm done with the topic as well, just one general question I'd really like answered: Why, if this is so damn important, are you not working on a solution? Why didn't you even ask if/how you could integrate a solution into MO? The answer - I have to conclude - is that this is important enough for you to rant on a forum but not important enough for you to actually invest time on a solution. In your opinion it's worth my time but not yours. That is a bit insulting you know?

I gave you my opinion on your proposal, I explained why I'm not doing it, I could have just said "no" and be done with it. Look, your suggestion involves me pushing out other projects, investing a lot of my free time I could invest on other things. If you're going to take it personally when I question your suggestions critically you may want to stop making them. Honestly, I appreciate proposals but please don't expect you can order stuff and I'll invest hundreds of hours of my time just because you claim it's useful or because you asked nicely. If I were to implement everything anyone has ever said they'd find useful I'd already have enough work on my plate for the next 20 years. It's not enough that you think this is useful. It's not even enough if you convince me that it's useful. You'd have to convince me that it's more useful than all the other proposals that will keep me busy for years. Be more convincing, be less miffed. ;) Or be helping. Maybe if I didn't have to develop everything myself I'd have time for less pressing issues.

Debatable. a) In all your examples the mods did conflict, it's just that they conflict in fewer cases. But since you usually resolve conflicts on a per-mod basis (especially when using bsas) and not per-file, that doesn't really matter. The information "mod a conflicts with mod b" is what's useful as it tells you there is a conflict to resolve. Which individual files differ is mostly relevant to make up your mind. b) if two mods contain the same file that probably means one of two things: Either the mod author is a moron and packaged files that are already part of a dependency and thus inflated the file size without need or he's copying files from a "modders resource", which is also available to others. In this case his copy represents a certain state of that resource which, in your case, happens to be the same state as the one in some other mods. However, the next time you update either mod, that shared resource may be different versions of that file. In short: The fact two files in two mods are the same at one point doesn't mean they will be the same after the next update. Unless you plan to go through all conflicts after every update you're going to make a decision "I want to use files from this mod over files from that mod independent of the version" and be done with it. In this case the information "the two files are the same right now" is not very relevant. MO is almost stateless in that it has no caches or databases apart from profiles and ini files to ensure those don't degenerate/break and to ensure you can work with foreign tools outside MO without breaking MOs stored data. I've always avoided storing any sort of complex data that users can't read/interpret manually, MO is complex enough. Your proposal would break this: Use a foreign tool to change/update a mod and MO will not know it needs to update its index. I don't intend to add a new dimension of user problems "MO doesn't display conflict information correctly because it's index is corrupted" or "MO didn't tell me about this conflict because I forgot to manually re-build the index" Apart from that: I won't implement such a feature if it works only for people who extract BSAs because I don't want people to extract their bsas!

I doubt this would be practical. Right now MOs bsa parsing is fast because it reads only the "file records" of bsas to figure out the names and sizes of files, it doesn't read the data. Calculating hashes for all the files could add minutes to the startup time of MO.

You can use categories for this obviously. Or, if your mod pools are (almost) completely disjoint you could just have multiple installations of MO instead of using profiles.

It should always be safe to clean temp directories. Are there many MO installed mods in there? Because MO should delete them after use. Hmm.