pStyl3

Looks great. An up-to-date, working procedure to get TES4LL working under MO. Let's see what gruftikus might come up with in the future, but for now that's the way to go.

It appears that I "accidently ignored" that aspect of MO (updating known files in mods, instead of placing those known files once again into the Overwrite mod) while trying to figure out, why on earth .. I actually still don't know why that happens - I mean, the folder is correctly predefined and all - but that isn't really important anyway. All that said above in the quotebox is what happens if I run the batch files the first time. I then drag&drop the .log files into the TES4LL mod (and delete the mentioned empty folders in the Overwrite mod). The second time I then run the batch files, everything will be corretly updated within the TES4LL mod, just as it is supposed to be. So no problems regarding that! Regarding your change .. TES4LL\Textures\landscapelod\generated --> TES4LL\Textures\LandscapeLOD\Generated If that happens to help on your system then I would agree that this change should be carried over to the "install instructions" we are setting up here for MO users. Note though, that I personally can't seem to replicate your issue with "TES4LL\Textures\landscapelod\generated" .. with this "original path", no files will be placed in my Overwrite mod on the batch files' second run. MO's warning triangle always stays grey here. But as said, if it helps you to adjust that (--> LandscapeLOD\Generated) aswell, I'm all on your side. Regarding your instructions: I find them very well written and on the point. Maybe two or three additions. Maybe mention at this point, that MO's warning about a to-be-happen false installation can be safely ignored (in this case)? Also, maybe you could add gruftikus' note, that a particular order in which the three batch files need to be run, isn't really necessary. Last but not least, a reminding note that both "Landscape LOD generator" as well as our "TES4LL" mod need to be activated in the left pane, would be good.

LaTeX is a "type setting system" .. well better read this to get the idea. It is mostly used for scientific reports or papers, as you have nearly unlimited possibilities to design a document (starting with math & physics .. or even creating images, like you can see here). You basically write a "textdocument", which then get's compiled, for example into a .pdf. Honestly, it is not the easiest thing to learn, but the results can be great. So yeah, in case you would have known LaTeX and would have used it to create your .pdf, it would have meant that you are quite familiar with the whole background. In that case I would have been really interested to see those kinds of files, just for the sake of it. Anyway .. I would suggest to keep using your original method to create a .pdf version, LaTeX is not something that you can simply switch to and immediately start using it happily, that needs weeks and weeks to get into. Thanks for the answer nonetheless! In case you are (generally) interested in this sort of stuff though, you would need two programs to start the adventure, e.g. "MikTeX 2.9" and an editor like "TeXnicCenter 2.0" (be aware though, there are dozens of other, available tools which could be used instead of those two). And now .. // OT end. Back to your FNV guide.

May I ask, through which method was the .pdf version of the guide created? Was that simply saving the guide from the step site into .pdf "directly", or did you possibly use something like LaTeX to write that?

Updated to 1.2.17, so far I'm having no problems. LOOT, Wrye Bash, xEdit and PatchusMaximus are correctly working, the game starts normally. Thanks Tannin!

All LOOT version mentioned here refer to the dropbox list of the latest loot snapshot builds. --- Rather than that something is strange with his/her personel setup, I would say that this indeed is a particular problem of MO. Additionaly, there haven't been found reliable steps to reproduce the issue until now. As far as I know, there are 2-3 documented roots for this issue (depending how you look at it). First, this issue was noticed while using LOOT with MO 1.2.10 and reported here - Bug report #779. Tannin fixed this one with MO 1.2.11. Quote by Tannin: But the problem continued to showup, even in MO 1.2.14 - for some people all the time, for some people very rarely and at "random" times; e.g. in my case, LOOT works 99% of the time like it should .. but then again, I had the blank screen 5-6 times aswell .. and I can't tell what it triggered really. In my case, LOOT will be blank, if it fails to launch "child processes" while being run through MO. This one was reported here - Bug report #901 - the issue is still open on Tannin's issue tracking site. The information that the "--single-process" flag helps in this case, or better said sidesteps the issue, was conceived by wrinklyninja and tested by myself here (see also the following posts). The "--single-process" flag fixed the issue for me 100% reliably (once I have the blank screen it continues to appear for me all the time, until I have restarted MO .. using the --single-process flag "fixed" the issue). The question that remains is, why do child processes fail in the first place? For example, I have installed Steam/Skyrim/Mod Organizer/LOOT in my custom folder C:\Games\.., so not in C:\Program Files.., a folder that can be restricted by UAC - User Account Control. One would think, that a somehow restricted MO would be out of the equation .. since I do not use that folder and still got the problem a few times. Note 1: The last time I had the blank screen was with "0.7.0 Beta 1", until now I did not have the issue with any version of LOOT Beta 2 or Beta 3 (which doesn't need to mean anything (as it could reoccur anytime), but, that is how it is, for now). Edit on 13th of January: blank screen bug confirmed with LOOT 0.7.0 Beta 3-66 and MO 1.2.17 Note 2: The --single-process flag doesn't work on all versions of LOOT. It was reported to definitely crash LOOT 0.7.0 Alpha 4-58 .. then wrinklyninja adjusted something within LOOT .. and then it was reported to work with LOOT 0.7.0 Alpha 4-229. So if you want to try to use the --single-process flag to "fix" the issue that LOOT is blank if run through MO, you need to use at least version 0.7.0 Alpha 4-229, or better the latest Beta snapshot build. Anyway, all that said , there were also cases, where simply moving MO out of the C:\Program Files.. folder solved the problem of LOOT being blank (also on MO 1.2.14). That actually stands in contrast to what my experience is (as said, for me the blank screen occured even though I don't touch the Program Files folder), but that's how it is, as weird as it seems. Examples of these cases are .. Seireitou (most likely) Chryma I believe there was also a third documented case, but I can't find it right now .. So yeah, in some cases the --single-process flag helps (that's when MO fails to launch child process, for whatever reason that is) .. and in some others moving MO out of the C:\Program Files.. folder helps. There also might be a possibility, that simply installing the very latest beta snapshot of LOOT helps to sidestep the issue, but that is only current speculation on my part. In any case, what I'm now interested in, regarding people which have the blank screen bug, are two things: In case MO is not installed in the "C:\Program Files.." folder .. can someone provide reliable steps to reproduce the issue?In case MO is indeed installed in the "C:\Program Files.." folder .. which UAC security setting is set on that PC?Edit on 13th of January: blank screen bug confirmed with LOOT 0.7.0 Beta 3-66 and MO 1.2.17

Using the --single-process argument on LOOT (within MO's "Modify Executables"-tab) sitesteps the issue in the latest beta build of LOOT 0.7.0 (using that flag on your build of LOOT will probably only crash the application). There is a second step you can try, which is to move MO out of the C:\Program Files\.. folder (as it is advised anyway), so to a folder that isn't affected by the UAC settings. That should fix the problem. On another note, please open the UAC options through opening the windows command line, and then writing simply uac and then pressing enter. Which security option is set on your pc (there are 4 available settings)?

Thanks for the note! Do I understand you correctly? You changed the two filepaths "TES4LL\Textures\landscapelod\generated" inside of "tes4ll_all.mpb" to "TES4LL\Textures\LandscapeLOD\Generated"? Whether or not that is correct, could you please also clarify of which files you were talking exactly (inside the overwrite), so which files were previously in the overwrite, and after the adjustment not anymore? My observation is: using "tes4ll_ultimate.bat" puts "tes4ll.log" into the overwrite - the actual meshes will be correctly in the defined modfolder "TES4LL"using "tes4ll_tes4qlod.bat" puts "tes4qlod.log" + the three empty folders "Textures\LandscapeLOD\Generated\" into the overwrite (those empty folders can be deleted) - the actual textures will be correctly in the defined modfolder "TES4LL"using "tes4ll_normalmaps.bat" puts "tes4ll_normalmaps.log" into the overwrite - the actual textures will be correctly in the defined modfolder "TES4LL".So "tes4ll_ultimate.bat" and "tes4ll_normalmaps.bat" put their files correctly into "TES4LL", only the .log files will be in overwrite, and "tes4ll_tes4qlod.bat" is basically the same, only that using this one puts also the mentioned three empty folders into the overwrite. I tried adapting the "tes4ll_all.mpb" file, but that didn't change anything for me .. the three .log files and the 3 empty folders (through tes4qlod) were still be in the overwrite mod. No problem and great to hear. Don't forget to thank especially gruftikus aswell! :) Just to clarify this aswell and to be absolutely sure .. you plan to this all for the next version and this is not already possible, is that correct? In any case, that sounds great. So that means, that I have to run "tes4ll_tes4qlod_cache.bat" everytime before I want to run "tes4ll_tes4qlod.bat"?

@ GrantSP I will take a look regarding this. @ koreador What I was looking for was actually the filesize of those meshes. It seems, that you too have overwritten your UOP's meshes by TES4LL, just like I experienced it aswell - see here. This means two things. 1. You need to reinstall the Unofficial Oblivion Patch. 2. The path for those meshes seems to be borked, so they did not "find" your corresponding TES4LL mod. Looking at your posted "tes4ll_all.mpb" file, I currently cannot see any real mistakes .. three things come to mind, though. a) Please make sure that the TES4LL-mod from "Step 1" is identical to mine. b) Please make also sure, that the TES4LL-mod was activated in MO's left pane, before you attempted to run "tes4ll_ultimate.bat". c) If those two things were alright, you could also try to rename: D:\Steam\steamapps\common\Oblivion\Mod Organizer\ to .. D:\Steam\steamapps\common\Oblivion\Mod_Organizer\ So renaming the actual mod folder of your "Oblivion Mod Organizer", so that there is no "space" .. and then of course replace that "space" through that "underscore" in the "tes4ll_all.mpb" file, as well as make sure that in MO's "Modify Executables" everything is adapted. No, I didn't thought that the folder would actually be there, but I just wanted to be absolutely sure.

I can't say for sure, but what I read once was to do these things in this order: 1. tes4ll_ultimate.bat 2. tes4ll_tes4qlod.bat 3. tes4ll_normalmaps.bat The first one is used to generate distant meshes for terrain, the second one is used to generate textures for distant land meshes and the third one to create normal maps. Given that, it makes sense to me how that order was presented. #2 and #3 might be switchable, but I am not sure of that.

Happy new year! A few things.. 1. Did you create the TES4LL mod prior to running the batch files, as I have wrote it in "Step 1"? 2. Do you use the "Unofficial Oblivion Patch"? If yes, please post a screenshot of it's ..\Meshes\Landscape\LOD\.. folder. 3. Please post a screenshot of the ..Steam\SteamApps\common\Oblivion\Data\Meshes\Landscape\LOD\.. folder, if their is such a folder. The tes4ll.log file that pops up in your Overwrite seems to be okay, as far as I can tell.

Wrinklyninja adjusted the sorting algorythm with LOOT 0.7.0 Alpha 4-58 (to be downloaded from this Dropbox link), so that the loadorder is more "human-readable", which means if a plugin stands in no direct relation to another plugin, it will be sorted alphabetically. The most recent version of LOOT is as of today, 0.7.0 Beta 2-67, so.

Landscape LOD generator tes4ll - 5.00 Content of the updated file: Data\Docs\.. - README-tes4ll-Oblivion.txt - Triangle_Copyright.txt Data\Ini\tes4ll\.. - CityPolygons.dat - FortEmpire_Aleswell.dat - FortUrasekToAleswell.dat - FortUrasekToBridge.dat - RumareCoastLine.dat - tes4ll_all.mpb - tes4ll_little_tamriel.mpb - UL_RollingHills.dat - WayToCheydinhal.dat - Weye_FortAsh.dat - WeyeNorth_FortEmpire.dat - WeyeWaynet.dat Data\tes4qlod_tex\Oblivion\.. - too many files to list here.. Data\.. - tes4ll.exe - tes4ll_DibellasWatch_ultimate.bat - tes4ll_highres.bat - tes4ll_midres.bat - tes4ll_normalmaps.bat - tes4ll_tes4qlod.bat - tes4ll_tes4qlod_cache.bat - tes4ll_ultimate.bat - tes4qlod_Oblivion_ltex.dat What I've tested in conjunction with MO: tes4ll_ultimate.bat tes4ll_tes4qlod.bat tes4ll_normalmaps.bat I tested these three files of TES4LL v5.00 under MO and found, that they are all working - if some additional editing is done. Installation and Initialization: First, TES4LL needs to be installed. The normal installation instructions are, that it needs to be installed directly into: ..\Oblivion\Data\.. Because we (the ones looking up this particular thread) use Mod Organizer, we can install TES4LL from within MO; MO's virtual file system will make sure, that TES4LL will see all relevant files. So I added "Landscape LOD generator" as a normal mod in MO - Screenshot - Installation. Click "OK", then "Ignore". It should work nonetheless (as this is "only" a tool, and not a mod that should work ingame). Once that is installed, I added the 3 files mentioned above as executables in MO, with these filespaths: C:\Spiele\Modding\0_Programme\Mod_Organizer_Oblivion\mods\Landscape LOD generator\tes4ll_ultimate.bat C:\Spiele\Modding\0_Programme\Mod_Organizer_Oblivion\mods\Landscape LOD generator\tes4ll_tes4qlod.bat C:\Spiele\Modding\0_Programme\Mod_Organizer_Oblivion\mods\Landscape LOD generator\tes4ll_normalmaps.bat So I used the .bat files from my just installed Landscape LOD generator-"Mod". So far so good, but that isn't everything that needs to be done. If I would now run these executables from within MO, the files wouldn't appear where I want them to be. For example, if I now would run "tes4ll_ultimate.bat" from within MO, the newly created meshes would be placed - if another mod already has such meshes with the same file names - inside that mod, replacing the mod's original files. In this case, that would happen with the "Unofficial Oblivion Patch". That is basically the problem I reported here aswell. That, of course, must be prevented. Step 1: - Go to your "Oblivion Mod Organizer"-folder and open the "mods" folder. - Create a new folder named "TES4LL". Open it and create the following (empty) folders: Meshes - Landscape -- LOD Textures - LandscapeLOD -- Generated So this should be the result (in MO). This first step is necessary (or better said, to me it seems to be), because if this "mod"-folder wouldn't be setup prior to running the batch files, the batch files would throw an error and thus wouldn't create the files they should. That said, if the instructions of "Step 1" are followed, everything is playing nice. Step 2: Open your "Landscape LOD generator"-mod in Windows Explorer, and goto: ..\Ini\tes4ll\.. Now open "tes4ll_all.mpb" with an Editor of your choice - I use Notepad++ Now change the path $_gamedir\Data\ in several places* to C:\Spiele\Modding\0_Programme\Mod_Organizer_Oblivion\mods\TES4LL\ .. well, actually do not copy that second path just like that, you must use your own correct path, that points to your "TES4LL"-mod, which you have just created in "Step 1". * here is my entire modified "tes4ll_all.mpb" file, where you can see what I have changed: Results and thoughts: If those two things from above are made, all three .bat files can be successfully run through MO and the files will be placed into the "TES4LL"-mod in MO. The three .log files.. tes4ll.log tes4ll_normalmaps.log tes4qlod.log .. that will be created during this process will showup in MO's "Overwrite" mod .. nothing to complain here, they easily can either be deleted or manually moved to the TES4LL-mod by drag&drop. Now .. speaking from MO's perspective .. it would be ideal, if these sorts of manual edits wouldn't be necessary, so that TES4LL can be used though MO. I think, that a command line to specify an output folder - like TES4LODGen.exe's -O: argument - could do the job. So that the user can specify, that files should be placed in a custom folder, and not into a static location like $_gamedir\Data\....... I can't really say if that is feasible - and if my conclusion is correct in the first place - and if yes, how much work that would require .. but that's how I currently see it. So, I would say .. TES4LL can be workarounded under MO now! Thanks a lot gruftikus.

Once everything is ironed out for MO users, the information can of course be passed over to that thread hishutup, but as of now the discussion is very well related to the topic title .. making TES4LL compatible to MO is the goal of this thread. "Only" because a new version of tes4ll or MO has been released, does not automatically mean that the problem for MO users has been fixed. That needs to be tested and documented. That said .. I believe I just got everything working (including TES4qLOD), BUT with some additional, manual editing inside of "tes4ll_all.mpb" + some initial work directly in MO - I still need to test a bit more .. and then write down what I did so that TES4LL can be used with MO .. and what possibly, if anything, could be improved on TES4LL's side. Bottom line, if I'm correct the signs are looking good!

Awesome news. I will take a look and comment on the new version this evening.

Seems like you're working hard on the project over the last few days. Great!

I may be able to help out with this, just not yet. My timetable is full of stuff for at least 3 months .. maybe after that I could help a bit out with the MO side. Regarding LOOT. Technically - afaik - there shouldn't be any problems with it, as it uses algorythms to sort the loadorder. Furthermore, the sort function was even more fine-tuned in the latest Alpha builds of version 0.7.0 (actually, yesterday Beta 1 of 0.7.0 was released), to make it more "human-readable" .. that means, if a plugin doesn't fall into any specific criteria options (has no master, is no master to another plugin, or something like that) it get's sorted alphabetically. The only problem there could be potentially, is that LOOTs masterlist for Oblivion is missing some stuff; which ideally people that know about mods for Oblivion should report to wrinklyninja, LOOTs developer. Oh and just to makre sure: LOOT masterlist =/= BOSS masterlist .. the masterlist of LOOT is way smaller, as it only contains some stuff for very specific mods.

That's why I wrote to use "..\Generated_DistantLOD" . Anyway, glad to hear that it worked for you.

Naa, there are lots of people who know way more than I do. I just happen to be interested in modding Oblivion with MO during the last couple of months (although that is currently on hold for me, because I'm researching a very nasty, randomly occuring BlackScreen problem on my pc, which occurs in some games, in others not... ). But I agree that an official STEP section regarding Oblivion+MO should be created to gather the latest workarounds, may it be standalone or as an seperate tab on hishutup's link. Here is what I am aware of. OBSE https://forum.step-project.com/topic/3560-obse-will-not-load-when-launching-with-mo/?p=59014 TES4LODGen https://forum.step-project.com/topic/3481-mo-for-oblivion-tes4lodgen-memory-use-issues/page-2?do=findComment&comment=98868 TES4ll / MPGUI MPGUI doesn't work, don't try itTES4ll --> For creating Distant Meshes & Normal Maps a workaround exists, TES4qLod does not work at this point (same issue like with TES4LODGen, we would need a newly defined output folder, which is not possible with TES4qLod as of now)The author gruftikus is working on a new version of TES4ll, see here and here, which should fix the remaining problems with TES4ll, once released that is.Thread: LinkSolution for TES4ll (to create Distant Meshes & Normal Maps): Link1 - Link2 Skyrim Performance Monitor In case you want to know, how to use SPM on Oblivion, while the combo MO-OBSE-ENBoost is already used (with the specific workaround for OBSE) - yeah, I did go a little bit crazy on this one - check this out: Link The important trick here is, to activate SPM's "Safe Mode". That is what I am aware of, if I haven't forgot something. What I don't know, or do not have any knowledge with, is for example how to use the Construction Set with MO.

This is the workaround you are searching for. In short, get the latest xEdit version, rename TES5Edit.exe to TES4LODGen.exe and use the -O: argument to define a new output folder, that is not in MO's folder. The problem here seems to be the actual number of files TES4LODGen attempts to create. Assuming that m4DnZ installed RAEVWD and thus wants to run TES4LODGen afterwards, approximately 10000 files will be created. While doing so, MO hiccups .. and thus we need the mentioned workaround with a newly defined folder outside of MO's filepath.

I have restored my posts in this topic, for some reason many BBCodes weren't working anymore. Hopefully everything should be back to it's prior state now. As hishutup, I'm also very happy to see the ongoing development. Once you think that your new version is ready to be tested (whenever that may be .. no need to rush things), just tell us about it and we will provide you with as much feedback as possible! Looking forward to this.

No problem. ----- I have now reinstalled TES4LL and MPGUI completely, to see whether or not that could reactivate my ability to use MPGUI through MO .. it didn't. As of now MPGUI doesn't work for me, and I still don't know why or how it worked two days ago. Very strange. @ sirenAri Wow, thanks a lot! I have gone through your post and can basically confirm everything of it. So, while I also use Notepad++, I changed the content of tes4ll_all.mpb as you said: Original: Modified: Once that was done and saved, I re-added TES4LL (now, in contrary to before, without the "makemeshes" argument) .. I can now use TES4LL to create distant meshes as well as normal maps! Superb. Screenshot of TES4LL "mod" in MO The remaining problem child - TES4qLod And here you are correct aswell. If "tes4ll_tes4qlod.bat" from TES4LL is added as executable in MO and then run, the application runs into memory blocks and can't finish the job. The files it created until then can indeed be found in the Overwrite mod: Image That (and this aswell, if I'm correct) points out, as you said, that the output folder of TES4qLod is still not correctly configured, if TES4qLod should run with MO. Now .. while I don't have any real programming skills (yet), I do have "Visual Studio 2013 Express" (I actually want to try to learn the basics of C# some day) .. so I made the same as you, I downloaded the standalone TES4qLod tool and looked at the "tes4qlod.c" file. I recognize these lines that are probably the ones we are looking for: Source1 Maybe this one aswell: Source2 The thing now is, that I can't compile that project too, for some reason I don't know .. there should probably be more source files of the project, to be able to recompile the standalone TES4qLod tool, am I correct? Anyway, if I could recompile the project, I would probably try something like this: Idea And even if I could recompile the file, I still wouldn't really know, how that could help us with the inbuild TES4qLod function of TES4LL. ----- Yeah, we are getting there. TES4LL works mostly, only the inbuild TES4qLod function doesn't work. Possible solutions would probably be either Tannin fixing the "memory issue", or Gruftikus implementing a proper command so that we can specify an output folder (that is then outside of MO). MPGUI still crashes aswell, but if we get TES4LL to work that shouldn't matter.

Updated MO to version 1.2.14. Updated xEdit to version 3.0.33 svn1839 (Link, so TES4Edit.exe as well as TES4LODGen.exe are up2date) ----- TES4LL Besides the mentioned circumstance - that, while the meshes ARE created (in contrary to the initial statement in this thread), these meshes are falsely placed inside the "Unofficial Oblivion Patch" mod folder Comparison - nothing has changed. DOS Output - TES4LL (Pastebin) So TES4LL seems to work under MO, though the meshes are still not placed inside Overwrite .. they still replace the "original" files inside the Unofficial Oblivion Patch .. and that is not good. ----- MPGUI Well .. I have good and bad news. Good one is, it worked two hours ago when I tried the mentioned process of Post #1. Bad news is, while changing absolutely NOTHING .. it stopped working for me once again. I changed nothing and is doesn't work anymore, I really don't know what suddely went wrong. Even restarting my PC now does not fix the problem. Anyway, step by step now. All that is still the way I do things. - First deactivate the Bashed Patch - then open MPGUI from MO 1.2.14 - select "tes4ll_all.mpb" - select all my plugins - read the worldspaces - goto "Start Process" and select "Click me if you are ready" Plugins - Worldspace - LOD Meshes - Normal Maps - Color Maps - Start Process The process worked when I tried it first two hours ago: MPGUI - Output (Pastebin) MPGUI crashed on exit, but that wasn't a problem .. the new files were placed in Overwrite .. great! The folder structure ..Meshes\LandscapeLOD.. wasn't there by default, but that can be made manually with the now newly created meshes inside Overwrite. So I now changed the "Mid Resolution" inside MPGUI to "Ultimate Resolution", once again the process finished, (MPGUI crashes on exit, again no real problem), the files showed up in Overwrite .. and now I have a correct "mod" in MO containing the new meshes, Link. -- So far so good .. but from now on MPGUI always crashes with the same message as before: Image 10 once I click on "Click me if you are ready", regardless what I do (and again, I don't know what I could possibly have changed ....). It's now all the same once again, if I try to create meshes, use the inbuild TES4qLod function or try to create Normal Maps .. it always crashes. So yeah .. hurray that a solution comes within reach .. unfortunately we aren't really there yet.

I'm wondering .. would it be recomendable to manually delete certain files from e.g. "Vanilla Optimized", if the same file is provided from another Optimized mod that has a higher priority number? So as an example .. ../textures/weapons/torch/torch_n.dds This file is provided by both Vanilla Optimized and HRDLC1 Optimized .. wouldn't it make sense to manually delete the file from Vanilla Optimized? Doing that with all the conflicts between the optimized mods should in theory enhance MOs startup speed, shouldn't it (as MO would have to manage fewer files)?

I made a few comments on the issue #813 that I've opened on Tannins bugtracking site. Then gruftikus wrote me via PM the following answer: "I took a quick look over it [this thread]. In general you should be able to run everything, that can be run with MPGUI, with a direct call from tes4ll aswell. MPGUI is only a shell that calls tes4ll. One could easily copy the command line that MPGUI produces. MPGUI also puts together the list of mods, I believe I made the path to the plugin.txt choosable. tes4ll does not do this, if I remember correctly. If the modlist is empty, it opens the windows registry, searches the app-path and there the plugin-data. I myself use MOM, which exchanges the files actively. Unfortunately I don't really have the possibility to test the "old" version anymore, as I work on a new version since 2 years, where I have rewritten practially everything. I know, way to long already.. Once the new version is ready (the performance isn't that good as of now), I can surely build in some options.." ------ Tannin also made this change with MO 1.2.12: I am not 100% sure that he refers to TES4LL and MPGUI (I didn't ask) .. but I think that's most likely the case. All that said, I haven't come around to test the changes yet .. but I surely will do that within the next days and will then post my findings here!