TommyH

Thank you Sheson, this is really super helpful! Yes, I am aware and understand the limitation that last .bto wins, same principle like normally with mods, no problem. But it seems there is still some demand for such simple LOD. I mean despite this limitation, nobody has yet complained that the LODs I provided do not work together with "xxx" mod. Fully understand that Dyndolod is the only good option for good results. In fact I am a long-time devoted user myself. Cheers and all the best!

TL; DR... When I generate object LOD's in xLODGen64 for the Tamriel worldspace it creates a lot of .bto's. How can I now determine which .bto's are actually required to be bundled with my mod in order to make the modded object visible from a distance? It should be only a handful, perhaps up to 10 or so, object meshes I think? *** So I have a simple mod that changes the shape of the Solitude Arch by adding and arranging more rocks. It now looks differently than it looks in the vanilla game. In order to make the new shape/appearence visible from afar, I want to include pre-generated LOD meshes to give the less demanding mod user a quick option to make the mod work when viewed from a distance. I generated only object lods in xLODGen using a mininal modlist of only vanilla .ESM's, Unofficial Patch and my mod. I only selected the Tamriel worldspace. Generation ran quick and smooth, and the visual result in-game is quite satisfactory. But I do not want to bundle the whole 120MB+ of generated LOD files together with my mod, and I don't expect this to be even necessary. In lack of better knowledge, I looked at some other mods that also include their own LOD meshes. Specifically, because they are in the area, I checked Drengin's Blue Palace Terrace and Solitude Docks Updated. These authors included only a few .bto's for their mod and that is apparently sufficient because in-game they look fine. So how can I narrow down the .bto's that are actually relevant to my mod? I would believe there is a more targeted way than just trial-and-error guessing and looking for the same .bto's names as other mods have in the area? This is what I did and it even almost works but this cannot be right, no? I would really appreciate some help or guidance or reference document on this. Many thanks for your great tools, sheson!

Hello Z, I think the OP referred to this link and settings which link to the v1 of the xLODGen Guide, as I understand: https://stepmodifications.org/wiki/SkyrimSE:1.0.0#xLODGen Me too I was struggling to find the STEP 2.0 recommended settings which you link in your above response. I did find and read the 5 pages long testing thread but thereafter was wondering if v2.0 settings were agreed upon. Apparently they were. Maybe I did something unsmart in searching for your linked page, in this case Sorry. And thank you for the new link! :-)

Disregard my post. It is now a couple of hours later, and the new version is available for download on Nexus. Apparently there was an issue with the initial upload.

Fantastic news, thank you for this Christmas present LePresidente and Team!

Cheers MO Team! MO 2.0.8.3. alerted me that there is a new version 2.1 available, but installing it from within MO itself, the installation hangs after installing the MS Visual C++ 2017 runtime module... I tried googling for any installer download but could not find any. Maybe the uploads of the new version are not yet completed at this time (early hours of Dec 25 in Europe)? Thanks for this update, the changelog contains most welcome changes and fixes.

Just warming up that older thread. This Discord Channel that is mentioned by LePresidente, is this at this website? https://discordapp.com Were there any test builds of MO2 uploaded in which the local savegame problem was addressed? If so I'll open an account there and gladly download a version. I really miss that functionality of MO2. This was one of my favourite thingies in MO for old Skyrim. Too bad that development seems to have stopped on MO2.

Aahhh, good one to know! I was wondering what these right-click options were about. Convenient, as quite many archives are packed in MO-unfit fashion.Â

Hm... yeah... on the first case in the quote, I had only one instance where I could observe this, as there was only one mod I "cleaned". So the sample is very small, and I do not insist that my observation was indeed so. In the second case I agree with your "most likely...not proper game data" which would imply that MO only takes up the new, correct file from the existing mod folder and the game will play correctly. In any case, this I think holds true (requoting myself): drag & drop cleaning out the overwrite folder is the safe way of avoiding ambiguity and issues. But yeah, would be nice if Tannin can settle this. But then again, for the moment I understand it sufficiently well. I came a long way since my opening post. :) Thanks again to All for your kind help!

GSDF Fan, thank you very much for the most detailed post! Well, let me say to all who heve helped me here that MO and me have come a long way together over the weekend and by now we already make a pretty effective team. As an eternal and happy WB user, I of course was somewhat sceptical and hesitant to switch to MO. But now I'm rather WOWed!!! The whole idea of virtual directories and mod list building on the fly is a strike of genius! The convenience and speed is incredible. And the program itself is a joy to use. There is a little bit of black box behaviour here and there, but this is at least partly due to my inexperience. After a couple of days of practice and experience gained, the overwrite folder is really not so difficult to understand as I initially thought it was. Looking back at my the initial struggles, I think the information in the STEP could be improved upon. Maybe it simply lacks a practical step-by-step example of how to build a Bashed Patch and handling the new output appropriately. I think building the BP is the most typical case that most players run into sooner or later when modding their games. Let me post a summary with the hope that it will provide additional insight. I am using 3 tools only: WB, TES5Edit and BOSS. I can't speak for FNIS or SkyRe proc, simply do not use any mods that require me to use these tools. BOSS BOSS is the easiest in relation to overwrite folder because it never writes anything there ever, but (by design) just changes the date/time stamps on all the mods in the right hand pane. Wrye Bash (WB) WB and Bashed Patch is also quite easy to understand with a bit of practice. After building the (new) BP, it is dumped into overwrite where it "rightfully" belongs because the whole purpose of the new BP is to overwrite/replace whatever old or pre-existing BP there was previously. Here comes one of the few quirks I find with MO: The content of the left hand pane is not updated automatically upon exiting WB (or any other tool), but the user has to press the little silver-colored directory refresh button manually (located where the profile selection list is). Why does the program not refresh the structure automatically? This would avoid any confusion of the "Why is the overwrite folder not showing red color despite something new written to it?" kind. Small detail, but I was confused a few times initially. Just saying, I know and appreciate that there is also the warning triangle in the right hand upper corner that shows red then, alerting you to something has "happened". But simple auto-refreshing of the structure would still make sense, IMO. I agree that building a differently named BP for each profile and making a different "BP Mod" containing nothing but the newest "Bashed-Patch-named-specifically-for-this-profile.esp" makes sense, IMO. I understand that this is technically not required (neither is one BP each for each profile as we have seen, and some users handle it that way), but I also like a clean and organized mod structure. TES5Edit Let me write about the simple scenario when using T5E for "cleaning" mods. (DoubleYou writes about merging mods) The "cleaning case" is different from the WB/BP case. Whereas WB/BP dumps the newly created file into overwrite folder, TES5Edit dumps it's new output into the mod's already existing folder that is physically located in the .../Mod Organizer/mods/ folder. And - if you choose the Backup option when exiting TES5Edit - writes a renamed copy of the pre-existing, "old" .esp/.esm into the overwrite folder. So in this case, the content of the overwrite folder is not what you want to use in the game. So what I'm doing is create a new mod folder "TES5Edit Backups" and put all T5E backups into it (the recommended way). And of course do not check this folder (because you don't want to use its content in-game). Interestingly, when TES5Edit dumps its backup into an otherwise empty overwrite folder, the color will not switch to red even after manual refreshing the structure. Which makes sense I guess, because the new file already resides in the correct, existing mod folder. There is one scenario about which I am not certain. Suppose you leave the T5E backup in the overwrite folder, and start the game: Will it pick up the new, correct file from the mod's existing folder, or will it pick up the backup from overwrite folder? I think it only picks up the new file. But just not sure. In any case, drag & drop cleaning out the overwrite folder is the safe way of avoiding ambiguity and issues. Ok, these are my practical insights to this date. Mods and experts, please correct me on any of my scribblings. I hope this thread can serve as an additional reference on overwrite folder. Thank you!

OK... in principle I agree with Double You. But just leaving the overwrite folder "dirty" in a controlled way seems very convenient. Thank you Guys. I will see how it goes. At least I have a better understanding now what's going on with the overwrite folder. Certainly, many points of my original post I had dead wrong. So thanks again for your help.

OK..... I was thinking the same. At least then you know that the BP is correct for the selected profile. And rebuilding the patch is a quick affair on a good PC. However, this method will always result in MO "complaining" that the Overwrite folder is not empty and will show you the warn triangle in the upper right of the GUI, no? But as long as there is only the BP in Overwrite, you just ignore it, right? Thanks so much for your help.

I'm new to MO but am well versed in modding TES. Before modding SK, I also modded Oblivion extensively. I am very familiar with WB (using it for OB and SK) and made the change to MO for the convenience of maintaining different profiles for different playthroughs. I'm struggling with the Overwrite folder. After reading this thread and the "Sticky for Creating Mods out of Overwrite folder" thread and the Overwrite chapter in the STEP guide, I think I have a certain understanding, but not really sure if it is the correct one. I use several Profiles, and I build Bashed Patches (BP) for each of them. Say now I work with "Profile 1". I start WB (from within of MO), build the BP, close WB. Back in MO, I now have the BP twice so to say: One BP is in the right hand pane (actual current load list for this profile). This is the BP I just build and this is the correct one to use for this profile now, right? Let's call this the "correct BP" (CBP).And I get a BP inside the Overwrite folder in left hand pane. This one I understand is some "old" BP that I built before, for some other profile? Or is it the old version of the BP for the current Profile 1? Or could it be both? Regardless, this is DEFINITELY NOT the correct one for the CURRENT profile and load list. Let's call this "Overwrite BP" (OBP).This is probably crucial: If I do NOTHING with the OBP and I start the game, the OBP will override the CBP during game load, right? I will end up playing the Profile 1 game with the wrong BP?If 3.) was true (not sure), then you ALWAYS HAVE TO deal with the OBP in SOME fashion, right?And this would be my most important question for now: If I don't mind the inconvenience of rebuilding the BP every time when switching to a different MO profile, I could just as well DELETE the BP in the Overwrite folder and be done with it, correct?The alternative to 5.) is to create a "BP Mod" for each profile and select the corresponding "BP Mod" when switching profiles, yes? (create a folder, name it e.g. "BP-Profile 1", "BP-Profile 2"... and move a BP into each of them).Thanks a ton for some help. Make it easy on yourself, just recite the number and say Yes/No if my points allow for that.