One thing to note is that the plugin only adds the animated grinder inside and some crates and barrels, you could simply disable the plugin and it will still look good.
Cleaning a plugin's masters is extremely simple and takes up mere moments of your time, @BrotherShamus (or any other user regularly facing this issue). Compared to cleaning unintended ITMs, scanning for errors, disabling deleted references, or any of the other small house cleaning steps you should be learning or already know how to perform as a mod user, doing this is just as easy, if not easier.
How to:
If you don't have the missing CC on hand for lack of updating or backups, create some dummy plugin files with the names of "the four" (ccQDRSSE001-SurvivalMode.esl, ccBGSSSE037-Curios.esl, ccBGSSSE025-AdvDSGS.esm, and ccBGSSSE001-Fish.esm). You could do this in xEdit the same way you would make a new plugin for a patch, or you can copy-paste some other plugin in your load order and rename it. In MO2, dummy plugins are distinguished in your (right side) list by a strikethrough. If you really need to, you can download a dummy plugin from this Nexus page.
With the dummy plugins you have created (or the actual CC if you have them sitting around) activated, boot up any mods you have with dirty masters in xEdit.
Once xEdit finishes loading, simply right-click any mod plugins with dirty masters and select the option "Clean Masters" (takes only a second or two). This will clean "dirty"/unused masters only; any master that is actually required by the plugin's content will not be cleaned.
Save your changes and close xEdit.
Deactivate your dummy plugins (or the unused CC).
You should then be free to use any cleaned mod without issue. Getting the hang of little things like this is more worthwhile and less time consuming than badgering the author (who has already shared something freely with you) over such a minor detail.
Note: Only the navmeshed plugin option originally shared by Blackread has dirty masters. RedBag's standard plugin is already clean as of this posting.
I'm a little confused about the installation of the Dyndolod patch. Does 'load after Dyndolod' mean to run Dyndolod and then install the patch or does it mean to load the patch below Dyndolod.esp after running Dyndolod with the patch enabled?
Install this mod and the patch, then run dyndolod, then load the patch in load order after dyndolod. Although maybe it doesn't even matter, the issue is really complicated, Blackread explained it to me but it still makes my head spin.
It doesn't matter whether the patch is active during LOD generation (and does not require regenerating the LOD to work), it just replaces the rotor used by DynDOLOD with one that doesn't stick out through the building. The rotor isn't a LOD model, just a regular (animated) object, so replacing the mesh is just like using any other model replacer. However, the mod in general may require rerunning of DynDOLOD, depending on what mods you had in your list affecting the swindmill.nif before. This is because during LOD generation DynDOLOD determines the indices of the rotor in swindmill.nif and then creates an override in its plugin, applying NULL texture sets to those parts of the mesh to make the rotor in swindmill.nif invisible. It then replaces it with its own rotor. If the mesh is changed to one with different indices after LOD generation, the texture sets are applied to wrong blocks and wrong parts of the building turn invisible.
By the way RedBag, the SMIM rotor patch should replace meshes/architecture/solitude/swindmillrotor.nif instead, which is a file from SMIM that DynDOLOD uses for the rotor instead of the one in DynDOLOD Resources if it's present. This is my fault really, I initially gave you wrong information regarding this, and sheson explained to me how it actually works afterwards.
New Dyndolod compatible version still won't work properly for me. Either missing floor but one rotor (dyndolod reassigns texture layers or something in esp) or visible floor with two rotors. This is after regenerating full object lod anew.
Nope, pretty sure versions matched. Old mod (1.2?) had this issue as well, 1.3 too, 1.4 is not tested yet, going to try SMIM+SMIM dyndolod later, but if those were not changed now, results are going to be the same. Texture layer assignments (or whatever Dyndolod edits)... how they correspond to actual mesh?
IDK what happens here :) First mesh with this kind of issue
Can this be changed? The stones outside and inside the building are the same stones (the walls are not so thick). If we compare the texture sizes of the stones outside and inside the building, can this improve the situation? https://ibb.co/hLMCnPH
84 comments
How to:
- If you don't have the missing CC on hand for lack of updating or backups, create some dummy plugin files with the names of "the four" (ccQDRSSE001-SurvivalMode.esl, ccBGSSSE037-Curios.esl, ccBGSSSE025-AdvDSGS.esm, and ccBGSSSE001-Fish.esm). You could do this in xEdit the same way you would make a new plugin for a patch, or you can copy-paste some other plugin in your load order and rename it. In MO2, dummy plugins are distinguished in your (right side) list by a
- With the dummy plugins you have created (or the actual CC if you have them sitting around) activated, boot up any mods you have with dirty masters in xEdit.
- Once xEdit finishes loading, simply right-click any mod plugins with dirty masters and select the option "Clean Masters" (takes only a second or two). This will clean "dirty"/unused masters only; any master that is actually required by the plugin's content will not be cleaned.
- Save your changes and close xEdit.
- Deactivate your dummy plugins (or the unused CC).
You should then be free to use any cleaned mod without issue. Getting the hang of little things like this is more worthwhile and less time consuming than badgering the author (who has already shared something freely with you) over such a minor detail.strikethrough. If you really need to, you can download a dummy plugin from this Nexus page.Note: Only the navmeshed plugin option originally shared by Blackread has dirty masters. RedBag's standard plugin is already clean as of this posting.
However, the mod in general may require rerunning of DynDOLOD, depending on what mods you had in your list affecting the swindmill.nif before. This is because during LOD generation DynDOLOD determines the indices of the rotor in swindmill.nif and then creates an override in its plugin, applying NULL texture sets to those parts of the mesh to make the rotor in swindmill.nif invisible. It then replaces it with its own rotor. If the mesh is changed to one with different indices after LOD generation, the texture sets are applied to wrong blocks and wrong parts of the building turn invisible.
By the way RedBag, the SMIM rotor patch should replace meshes/architecture/solitude/swindmillrotor.nif instead, which is a file from SMIM that DynDOLOD uses for the rotor instead of the one in DynDOLOD Resources if it's present. This is my fault really, I initially gave you wrong information regarding this, and sheson explained to me how it actually works afterwards.
IDK what happens here :) First mesh with this kind of issue
https://ibb.co/hLMCnPH