Tannin

There is an almost infinite number of valid mod orders and an almost infinite number of invalid mod orders. STEP gives you one valid order and tells you to use that because they tested it. MO determins one valid order algorithmically and warns you if you deviate from that. Both are fine. As long as you use STEP and only STEP you can use the MO suggestion or follow the STEP guide to the dot, you get a valid order. The moment you install more mods than in the STEP guide, you only have the MO order to go by. It still gives you only one out of infinite valid mod orders but at least you know that it is valid.

Thank you all for your kind words. I have to admit I was a bit worried about how you'd take this. I'll try to answer a few questions to the best of my knowledge but please realize we're early in development and we have big goals. Man, your tutorials are invaluable for MO users and I'm immensely grateful for the work you put into them. :) I can't promise anything yet. As has been mentioned, the new mod manager will be modular and the mechanism putting files into the game directory is extensible. The default setting will probably work similar to what NMM is doing currently, using symlinks or hardlinks into the game directory because this is simply more robust and doesn't upset antivirus tools as much (can you imagine NMM being updated, a million users download it and 10% get warnings from their AV?) Plus we want to keep Linux and MacOS support an option and the MO vfs is impossible to port. But I can't see a reason, apart from the time investment, we can't providing an extension for the mechanism using the vfs library from MO. I have also played with the thought of using an actual virtual filesystem driver based around dokan (https://github.com/dokan-dev/dokany) which may be easier to implement and more reliable with the disadvantage of requiring an admin install and worse performance (at least theoretically). So I put effort into keeping the option available and DarkOne is open to the idea but we haven't committed to it yet. The new UI will be complete new and will take pointers from what was sh*t about either UI. I doubt everyone will like the new thing but that shouldn't be surprising. ;) Don't worry, I'll still come by and bring you my dirty laundry ;)

Dear MO users, As you may have already read on the Nexus news (https://www.nexusmods.com/skyrim/news/12905/?), I've recently joined their ranks. If you haven't read it yet: Yeah that happened. Over the coming weeks and months we will keep the community informed on what we're planning and working on for the future of NMM but right now many of you may be more concerned with what this means for MO. First I want to assure you that the primary reason of Robin hiring me was to take advantage of my experience with MO and to integrate it into the Nexus offering, not to kill off MO. And the primary reason for me to take the job was that it will allow me to invest serious time into creating a better modding experience when previously it was becoming increasingly difficult for me to find time and motivation to work on MO in my spare time alongside a demanding job. Obviously I won't be working on MO any more which unfortunately means that, unless someone else picks up where I left, MO v2 won't appear in a stable version. I know that will appear as a loss now and I apologize to everyone who was looking forward to a new release. I do hope however that you trust me, and everyone else at Nexus Mods, to understand what you liked about MO. I'm confident that with what we're planning you won't be missing MO for long.

Sorry for the late reply. What Ganda said so far is true: - Debugging the plugin is pretty nasty. What I did when I wrote the included plugins was write a mock for the mobase functionality I was using in MO, then run/debug the plugin as a regular python application for testing. - The Python code includes PyQt which is a complete separate build of Qt so you can add your own PyQt libraries if you need. The only connection between C++Qt and PyQt is the parent widget you get passed in "setParentWidget(self, widget)". This is a widget handle created in C++Qt but you need it in PyQt to display modal dialogs for example. I honestly have no clue what would happen if the PyQt version and the C++Qt version were too different because then the python part might be using that widget "wrong".

Just check if hook.dll (or usvfs_x64.dll for MO2) is loaded using the getmodulehandle api.

This file is used to exchange information between processes seeing the vfs. Nothing suspicious there.

Hehe. Well, this is another aspect: if you have an ini file that has the same name as an esp, that ini is automatically loaded by the game and "overrides" the other inis. MO doesn't touch those at all. However, to my knowledge not all settings can be made in those inis

I didn't know about fallout4custom.ini when i wrote the ini functionality in mo and didn't get around to updating it. The goal is for mo to "bake" an ini file that contains the content of the relevant ini files and tweaks, redirect all accesses to that file and once application completes, transfer changes that happened in that file back to the appropriate ini

MO cannot actively cause slowdowns! MO code only gets run during file lookup. During regular gaiming the overhead from MO is 0. The only thing that may make a performance difference is that MO may influence if/whilch files get opened (ini files, maybe shaders) and badly written libraries that do api hooking (potentially part of the driver) may fail to load. The first is the whole point of Mo, the latter I can't change because that would be a bug in that software, not mo

Could you try if mo2 behaves differently? You shouldn't replace your existing mo1 install, just test it.

You can manage your downloads through MO (delete them, hide them for the moment, ...) and MO will correctly remove the associated meta data. We can talk about improving the UI of the download tab (though I would prefer an issue) but I don't want people to feel the need to delete downloads by hand in explorer because THEN I have to consider "manual users" if I want to change anything in how I name or organize the download folder or how I store the meta data. Maybe it would help if i add small "open in file manager" to various tabs (saves, downloads, profiles) ? > It's just a change from what we've been used to for so long that it came as a bit of a surprise. I understand, but there were just too many users having trouble with file permissions. Next release won't even offer portable mode if the MO directory isn't writable. I think this will fix a considerable chunk of support requests which is why I think it's worth it. > I personally offload this from my C drive for space reasons, so I'm glad to here it can be customized. You actually have several options. You can use MO's own path settings to move the individual directories in each instance individually. Windows allows you to move the AppData/Local directory as a whole. Or you can have AppData/Local/Modorganizer as a link/reparse point/junction point/whatever you call it to a different drive.

That's pretty much what has been implemented. You can choose the location through settings, are even reminded to do so after creating the instance and if you fail to, data is stored in a location that I can rely on to work. No, sorry, but My Documents is just wrong. Skyrim/Fallout4 shouldn't be storing their ini files and save games there either. Microsoft has guidelines on where to store files, storing application settings in My Documents violates them. My Documents is for user managed documents like audio files, text files, pictures, ... User-Managed means: They don't change unless the user actively edits them (i.e. in word, photoshop, ...) My Documents is in a visible location so you can easily find files when you want to send them to friends or something. AppData is intended for application managed files which a user will usually not touch directly and may break the program if he does so. This applies to MOs ini files, its profiles, its mods, its cache. Unless you really know what you're doing you should not be touching any of those outside MO, hence a hidden location is a good thing. And if you do know what you're doing, finding appdata won't be a hurdle. And I'm fairly certain you will find on your own system that most applications that aren't from the win98 era agree with me...

What other folder would you suggest? I don't specify appdata directly, i call an api to retrieve a writable location. What other folder can i rely on to exist being writable with user permissions on windows?

You won't run into major problems, but it's strange. As GrantSP said: MO comes bundled with all the python it needs.

python plugins can be developed without compiling. Tool is free choice, I like pycharm a lot. Most plugins are C++ though. For that you need a compiler (only Visual C++ 2013 and up will work currently) and you'll want an ide. I personally prefer qt creator over the visual studio ide but most ides will work.

The plugin api is extensively documented in the headers. There are over 20 plugins as samples including simple hello world samples. This should be enough to get you started if you really want to contribute. The bsa extractor isn't even 150 lines of code, most of it boilerplate. I really doubt documentation in necessary for that...

The bsa extractor being missing isn't intentional nor final. As you know i moved my repository to github and split it up into smaller repos. The bsa extractor (like all plugins) is now its own repo which i probably forgot to include in the build. Btw.: if anyone feels like adopting this or any other plugin repo, just say the word ;)

Conflict display is still possible, I haven't implemented support for ba2 yet however.

The feature has been removed because it required a lot of complex game-specific and error-prone code inside the hooking lib and caused ton of confusion, bug reports and hatred from other modders. It made the whole PMOP business necessary which way too many people didn't understand. The bsa management was supposed to make things more intuitive by giving assets the "expected" order, but in practice it made everything more complicated. With MO2 my primary focus is Fallout 4 where I don't want to repeat the same mistake and non-gamebryo games where it's unnecessary. If you need this functionality for step then you should stick with MO1.

I added tags to bugs/Features/enhancements. I'm not aware of other means to organize the list.

Hi everyone, I'm currently in the process of restructuring the MO source code project and moving it to github. And since github has a decent issue tracker, I'll also stop hosting my own and instead use the one there. This means that the old issue tracker will be read-only for a while before I shut it down eventually. I will import all open tickets into the new tracker though we will lose notifications for those and they all appear as if I had posted them. The new issue tracker is at https://github.com/TanninOne/modorganizer/issues I will update this post once the import of exiting issues is done. I believe the import is now complete. If you notice any open issue missing from the github tracker, please let me know. If you're interested in the source code: MO is now split into many individual repositories (one for each plugin, tool, ...). Each is intended to be buildable individually (using cmake as the official build system) except where there are dependencies. There is also an "umbrella" repository which contains a python script that can retrieve and set-up all dependencies and mo projects. All this hopefully makes it easier for others to contribute. The project "TanninOne/modorganizer" is actually "only" the main MO UI, the umbrella project is at https://github.com/TanninOne/modorganizer-umbrella If you know which sub-project an issue belongs to, please post to the individual issue tracker but if in doubt, use the one in "TanninOne/modorganizer"

Well, for one thing I could re-introduce the file-list and download directly from inside MO. This would likely speed up updating mod considerably even when you still have to go through the installation routine manually. Also while I have doubts with profile sharing everyone everyone I think we could do half-automated curated batch-installations. Ie with the hash-based approach one could probably automate fomod installations just fine as long as someone ensures the referenced fomod is available and updates the batch-installer to keep up with updates. This means you could fully automate download and installation and installation order and load order of all mods in step. There are still steps that would require manual interaction (as discussed above) but as long as we clearly state what the automation process can do and what it doesn't.

The problem is not that updates could break things, the problem is that you can't just automatically update a mod. Many mods provide several files (i.e. variants of the same file). If you have a mod file like "Night_sky_redmoon_v1_0.zip" and "Night_sky_bluemoon_v1_0.zip" and they get updated to "Night_sky_redmoon_v1_1.zip" and "Night_sky_bluemoon_v1_1.zip" it's easy for you to see which is the update to which but that's only because of your wonderful human brain, no computer can reach its pattern matching ability. Things get even worse when actual update files are in play, like author has released v3.0 of his 2GB monster mod, noticed a single script problem and released a patch v3.01. The automated installer would probably pick 3.0 and say "done". User wouldn't even notice there is a problem until his save game is ruined because he wouldn't assume he has to verify the result of a fully automated process. That's the problem with automated processes: Unless they work as expected they suck. The other thing is: How does NMM replicate interactive fomod installers without user interactions? I can think of two ways: Either they store the menu choices with the shared profile or they store the hashes of all installed files and during profile "restore" they search for the hashes in the archive. Both break with an update. The former breaks if the menu choices change, the latter always breaks with any file update.

I'm not sure how NMM will implement profile sharing but if they can really implement this: "NMM will be able to download all the mods you had installed in your profile (...) and install them exactly how they were installed before, with no need for any further interaction." in the presence of skyproc tools and xedit I shall be impressed. It can be done of course, the easiest would be to include those files in the profile that don't exist (identically) in any of the archives but that still seems complex. And it will still break the moment one author removes the specific file version from nexus. But if NMM starts to allow automated downloads from their page that would still open some nice possibilities.

Mo's virtual filesystem is very platform dependend and probably wont work inside wine. Sorry