Tannin

The confusion stems from the fact people are very inprecise when talking about mods. A mod is a bundle of things that change the game, including textures, meshes, audio and plugins. Plugins (in this context) are changes to the game world. Plugins have the file extension esp (elder scrolls plugin) or esm (elder scrolls master) but let's not go into that detail. LOOT orders plugins NOT mods. It's very possible for a mod to consist only of - say - textures. In this case LOOT doesn't do anything for that mod and it doesn't have to. You have three mods installed but none of them contain plugins so nothing new shows up in LOOT. There is no problem there, everything is good (unless one of the mods was supposed to contain a plugin which I can't say from over here)

It shouldn't be necessary to download the update! I downloaded the full archives from Nexus yesterday and all of them contain the hook.dll in version 2.7.5. Everyone who didn't download 1.3.6 in the first 2 hours or so shouldn't be affected. Regarding version numbers: I can't increase the version number when the main application doesn't change! As you notice, ModOrganizer.exe and hook.dll have separete version numbers (1.3.6 vs. 2.7.5). I can't version them together because then I'd have to increase the version number on both, even if one of the files didn't actually change.

please delete the file ModOrganizer/plugins/installerbcf.py. That plugin does nothing and was never intended to be released. I must have accidentally included it in one of the 1.2.x releases and now it doesn't load any more. But as I said: the plugin doesn't do anything anyway.

Don't worry, both are used to it by now. ;)

bloody hell. Please check if this patch fixes the c# fomod problem: https://www.dropbox.com/s/uz3oj0miedl2mon/NCC_hotfix.7z?dl=0

What I described was only my thoughts what could be done having the information as "data" inside MO instead of text being displayed to the user. But none of that has priority to me. Right now I work on three "fronts": 1.3.x: I want to get this version to a point where it's stable. I think we're almost there 1.4.x: This version will have only one new feature which is better integration with steam. It will discover steam-subscribed mods (done), display them in MO selectable/deselectable (done) with a bit of integration (i.e. displaying the description from steam where MO would otherwise display the nexus description) and insert files from steam workshop "cache" directly into the vfs so that those mods don't actually have to be installed into the data directory. 2.0: Support for 64-bit, game independent, support for multiple games managed by one instance. Progress on each is slow already, as you might imagine, so while I have a lot of ideas how MO could be improved, the above are the only things I actively work on.

The primary reason to have sort integrated is that its - well - integrated. I can display the warnings and hints inside MO. Technically it may eventually be possible to further use that information. Say: You right-click on a "dirty" esp and the context menu contains an option "clean with xedit" which then opens xedit with the correct esp open. Or a way to help user resolve conflicts between esps. I can also imagine a "beginner" mode for MO where all you have to do is download mods through MO, it automatically enables them, picks one of multiple conflicting plugins and sorts the plugins, thereby providing you with a UI similar to Steam workshop but with working load ordering. This depends on MO being able to correctly order plugins.

thosrtanner did the fixes regarding fomod installer and he seems to be working on further improving compatibility.

right now no userlist is loaded though that is easy enough to fix. If nobody disagrees that this is a good idea I'll put this into 1.3.6

Will be fixed in the next release. Basically for reasons I don't understand, setting "min-width" causes this problem, basically minimizing the button size to barely fit the test and then deducing space for the down-arrow. The fix (the only one I found) was to remove all "min-width" statements and use padding to keep icon-only button from becoming tiny.

@GrantSP: No, C# fomods all have to go through the external installer because I can't run C# code from MO (unmanaged native application) directly.

I'm not sure why this is tbh. It may be a bug in the newer qt version (1.3.5 now comes with qt 5.4.1) because the dark.qss hasn't changed at all nor has the ui code (afaik). I also haven't found a way to fix this in the qss. I can increase the margin of course but the text still remains cropped.

1.3.5 is out, please let me know if you need further features exposed through the plugin interface.

No, these functionalities really don't exist right now as the need never arose. I'll add these functions to 1.3.5 for you except for suggesting a version as I don't see a need for that. You can change the version after the installation without much trouble.

Unless you installed 3rd party MO plugins I don't know about there is only one plugin that will cancel the start of an executable and that is the fnis checker. that plugin will determine if your setup has changed in such a way that fnis needs to be re-run and, if so, starts fnis before running the application. If you cancel there or fnis signals a serious problem, MO will cancel the application start. You should have received some form of error message from fnis before the log message you mentioned. If everything else fails, you can just disable the plugin.

MO doesn't parse the nexus website because the structure of the page might change at any time. It uses a separate API intended for applications (primarily NMM). I'll see if that api provides a way to take users to the donate page.

The functionality doesn't depend on the payment stuff, it will work with free mods as well. I'll still add it. And I agree, the way this played out was not great. People have no problem paying 5 bucks for colored water with flavor at starbucks but when someone asks for a few dollars for a project that is the result of hundreds of hours of work they go ballistic because for some reason the work you put into a digital project isn't worth anything? And I'm saying this as someone who refused to have MO as a "service provider" or payed mod for the workshop. Yes, Valve did offer.

rant The sh*tstorm Valve is receiving is unfounded imho. Some mods are a lot of work and should be worth something. (MOs worth - applying business metrics - is well in the 6 digits (dollars)). Paid mods may be bad for modding, they could also lead to better maintained and higher quality mods. Look at nwn premium modules for a success story. People are ranting against the 25% share for mod authors but ignore the fact that nexus has been making money publishing mods without sharing 0% with the content producers? I'm not saying nexus bad steam good - I like both - I'm just saying we should apply the same standards here. /rant Regarding a future MO integration with Steam: Steam changed the way mods are installed recently. In the current Steam version, mods are downloaded vanilla (not packed) to a steam workshop directory (one directory per mod) by steam. The Skyrim launcher then copies the files to the game data folder. With MO, the mods will still be downloaded by steam. MO will then map the files from the workshop folder to the game folder using its virtual file mechanism just like mods installed through MO itself. This means you can continue using the steam subscription to install and update mods and you can use MO to activate/deactivate those mods in profiles. MO will also use steams api to retrieve meta information about mods like descriptions, screenshots, ... This means a very neat integration is possible, the only "trouble" is the skyrim launcher because I can't keep it from copying the files to the data directory, but then you don't run the launcher anyway when using MO. right?

You're wrong and misinformed. Just because your human brain can do something doesn't mean a computer program can. Humans are far better at pattern recognition than computers. You can recognize that an encoding is wrong because you speak the language and the symbols don't make sense. Do you expect me to write a program that knows all languages, tests texts for syntactic and semantic correctness, account for typos, ascii art and the like to determine which encoding is most likely? This is an unsolved problem, NO software known to me can do this reliably. Also, you mention unprintable symbols but most 8-bit encodings have the unprintable symbols in the same byte-range and therefore they are NOT a reliable way to recognize character encoding. If you're so smart YOU write code to auto-discover character encoding reliably. I'd advice you to file a patent.

Current version of MO is 1.3.4

It's in the works. Steam has the upload date which can be used as the version

That button would simply open the nexusmods.com/ page in your default browser. A possible reason is that you run MO as administrator and your browser refuses to run with those permissions for safety reasons (I think IE may do that)

It simply doesn't work that way. The amount of code says nothing about the "desirability", it could simply be more obsolete code was removed than new, desirable improvements made. The size of the code doesn't need to change at all, changing a "x y" can make all the difference and that's not even a difference in file size. When I do a bugfix in MO that is as likely to reduce the amount of code as it is to increase it. The same would be true for scripts so all we can determine is if one script is different from the other, we can't determine which is better unless mod authors introduce and all adhere to a versioning system. How likely do you think this is? But even determining if two scripts are different is a problem because one version of the script may be loose, one unpacked in a bsa and one packed in a bsa. The only way to determine the difference is to extract the scripts and compare but that would cause an inacceptable performance hit. Also, the PMOP advice doesn't really need to order scripts, the point of the feature is to order mods after esps because we already have a plugin ordering system in loot and there is very little reason to order assets separate from plugins. Remember: If it weren't for MO BSA-based mods couldn't have a separate asset order at all and loose files would be ordered by installation order so following the PMOP advice really only takes a slight amount of the freedom away you wouldn't have had without MO in the first place. The mod authors can't plan with separate asset and load order because they have to plan for NMM and manual installs. It's solely STEP that is imposing a specific, artificial asset order. How necessary is this order really? But 99% positive I already have! What we're talking here is already the missing 1% that needs to be fixed. A half-assed may-work-may-not-work won't suffice. Well, STEP is a community project, MO is pretty much a one man show so if we're in a contest who has less time I can almost guarantee I'll win. That's ok then, as long as users are made aware that the advice is only for a step-only installation I have no objections. Well, coding is not the only way to help, giving detailed bug reports is an enormous help. The quality of bug reports can make the difference between 15 minutes of work and hours. If the PMOP suggestion indeed doesn't work like intended (like cyclic fix instructions) a report containing a minimal set of mods to replicate the problem would go a long way towards solving it. If this is an unsolvable problem for STEP maybe I can add a quick&dirty blacklisting mechanism where when you hit "Fix" you can select to either execute the mentioned moves or ignore them forever. What's important to me is that you talk to me about these problems and we try to find a common ground that can work for all users (of Step and MO both) instead of giving advice - stuff people might find via google without knowing the context - that is simply bad for a large part of my user base.

Sorry Tech but this is a load of bull. You can not determine if one script is newer or better than the other automatically by checking which has more code, that's not how programming works. Let me rephrase that: You can not automatically determine if one script is newer or better than another. period. Which is why the current implementation of PMOP (baring bugs of which there are no reports right now) is the best that can be done without a manually curated list of mods which is completely impractical. While the changes suggested by PMOP may very well be unnecessary I have no reports of cases where it is producing an order that works worse. The practical approach would therefore be to adjust step (which is already a curated list but infinitely shorter than what MO would require) to not produce a PMOP warning in the first place. Since the STEP Guide only covers those mods covered by STEP and not the other 50000+ mods users might end up using, disabling this feature is not a good idea. If the step wiki continues to make suggestions like this I'm not sure I can continue using this as the official MO wiki because I don't stand behind it. At the very least mention that this suggestion is controversial. Mention that this advice is only sound if users install nothing but STEP. If you feel an MO feature is not good enough then help improve it instead of disabling it altogether because that only ensures the feature will probably never get to a point where you like it.

I didnt consider 1.3.2 as beta because i had been doing betas (1.3.0 and 1.3.1) on this forum. It was only after release it turned out there were many issues left. But if only 2 or 3 ppl test things stay unnoticed so i dont have another choice but to make releases public at some point