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.