z929669

As I understand it, VR supports ESPFE due to it's file extension even though it doesn't support the ESL flag itself, so it's a good compromise for plugins supporting SSE and SSE-VR. Also, I did qualify my assertion. From my post: ... that's precicely why I qualified my statements. I wanted to double check if it really should be ESM. I got no issues with that, but what you're saying does imply that most mods should be ESM if they touch any outdoor landscapes ... most of them don't use ESM but rather ESP. Reason to prefer ESP over ESM? Freedom to prioritize via plugins.txt rather than restricting to early in the LO. That's all. That said, I'll modify my post accordingly.

I can't say for sure, as I have never noticed this in my games (but I test rather than play mostly these days). I would check MCM for Storm Lightening. I think it has some realism stuff. Otherwise, this may just be a game limitation, IDK.

As explained in the DynDOLOD MA documentation, I think the most efficient way to tell DynDOLOD to assign LOD to a given base object for this mod, what I think is needed is ... Base record with path to model - Exist in IcyFixes*.es* for this mod LOD model with name prefix corresponding to base record model (preferably in /meshes/DynDOLOD/ for highest priority [or include CRC32 for absolute 1:1 specificity]) - These are provided by the mod under /meshes/lod/ and LOD model shape names match full model shape names on spot check of one example Rules for base objects undefined in vanilla or DynDOLOD - for this mod, presumably the following Editor IDs referenced in IceLODFull.esl: GlacierEndLg01BackLight IcebergLargeBackLight IcebergLedge01BackLight IcebergSmall01BackLight IcebergSmall02BackLight GlacierPillarLg01BackLight Rules File - The mod could use use IcyFixes.esm|l - ESL-flagged and/or .esl extension for all users except those upgrading from previous versions due to renumbered Form IDs and .esm extension but NOT ESL-flagged for users upgrading from previous non-ESL-flagged version <-- Changed due to Mousetick's input in post following: File Name(s): /DynDOLOD/DynDOLOD_SSE_icyfixesesp_[high|medium|low].ini - Following is 'high'. Rules would differ slightly for med/low [Skyrim LODGen] LODGen1=IcyFixes.esp;0000AA0C,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high LODGen2=IcyFixes.esp;0000AA0D,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high LODGen3=IcyFixes.esp;0000AA0E,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high LODGen4=IcyFixes.esp;0000AA0F,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high LODGen5=IcyFixes.esp;0000AA10,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high LODGen6=IcyFixes.esp;0000AA11,Level0,Level0,Level1,none,FarLOD,Unchanged,1,Icy Mesh Remaster - high Since the textures used by this mod can be from any number of supported mods (e.g., GlacierSlab.dds), the LOD should conform to these. DynDOLOD can create the LOD textures from the full ones per standards, thereby obviating any need for the MA to provide the LOD variants and the user the error-prone task of selecting the correct ones in the FOMOD for their build. <-- Again as pointed out by Mousetick in a subsequent post, not all users will use DynDOLOD, so it's not so simple; however, the LOD models could all use a SINGLE texture rather than multiples of the same texture under different texture names, which does cause uneeded texture bloat and maintenance overhead. For just one LOD patch there's lots of redundancy. Given there are several LOD patches, most of the textures can be scrapped if LOD models are updated to use a single path: File Name: /DynDOLOD/DynDOLOD_SSE_TexGen_noalpha_icyfixesesp.txt -3 1 1 1 textures\landscape\glacierslab.dds 2 2 0 0 textures\lod\glacierslablod.dds 2 2 ... there's probably other textures used by meshes in the other 5 records, but I haven't checked them all, and it's this piece that I'm less certain about in terms of the 'ideal' values and whether all should be 'noalpha'. Aside from all that^, I think ... IcyFixes.esm can be changed to IcyFixes.esp (ESPFE) - should work for SSE and SSE-VR Confirmed ESM is best for this mod. Likewise IcyFixesLite.es* all seem valid (but FOMOD could provide context for ESL-flagged .esm or .esl extension vs not flagged .esm extension). IceLODFull.es* can be removed IceShaderDisabled.esl, ProjectedGlacierSnow.esl, and Partitioned snow meshes.esl could be merged into IcyFixes.esp (MA's discretion, but it seems like these should apply to all users ... if not, then different versions of IcyFixes.esp could be used) Result = drastically simplified FOMOD and asset management for both MA and user + fewer installation mistakes + lower support/maintenance overhead (no need to update this mod when supported mods are updated) @sheson Do I have this right? See previous posts for context and OP for URL to mod in question. The more we can help MAs proficient in graphic art but lacking in knowledge of plugins and DynDOLOD, the better for everyone.

I thought the custom cursor fit the 'warm' theme better, so I opted for the non-animated version in the FOMOD instructions I put out there. I also don't like bulky cursors and prever something slim and with a clear, sharp point. I would create a basic 'beige' cursor to accompany the DD theme. Also your point about the text color being potentially fuunwanted by some is valid, but I'd argue that anyone with old eyes will appreciate it. Those with younger eyes will have no readability issues either way. My 54-year-old eyes benefit greatly from the 'softer' look of the lower-contrast text, so I think this only presents an aesthetic rather than a functional drawback. For those users, there's INIs and options. We could provide advice for two FOMOD options and let users tweak away on their own from there. Your post will probably save me a good deal of time sorting all this out, so TY for that.

So I've done some initial exploration of the plugins in relation to LOD. First, I used my 'minimal' Step-vanilla profile (basically, only runtime mods and DynDOLOD Resources/DLL installed). Then I generated all LOD for that, renaming the DynDOLOD plugins to DynDOLOD_1.*. Next, I disabled all LODGen mods and repeated this whole process but with IMR installed basically as I described previously. I did not rename the DynDOLOD plugins this time, so I can see with and without IMR. Now I'm not at all certain how exactly to interpret the outcome, but a few facts can be gleaned from this comparison. Maybe you guys can glean more than me from this: Most records in IceLODFull.esl are not incorporated into the DynDOLOD patches, and this plugin only provides a small number of 'static' records. Lastly, based on my work with Enhanced Mountain Rocks, plugin records are not needed to define LOD. The NIF shape names are used by DynDOLOD to assign LOD, IIRC (so I don't think most of these LOD mesh assignments are really doing anything, but IDK for sure): This demonstrates that without IMR, DynDOLOD otherwise incorporates this record (remember that IMR plugins were not present when this DynDOLOD_1 plugin was constructed). Also, notice that IceLODFull.esl steps on IceFixes.esm, and the former forwards the USSEP record with it's own LOD assignments, while the latter has unique Object Bounds.: Here's an example of where the IceLODFull.esl record IS being incorporated into the DynDOLOD patch, but in all cases, they are Iceberg* Editor IDs sourced from IceFixes.esm being the 'master': Anything else I can share that anyone wants to see from this? My only take away is same as previous. I would eliminate all these plugins by merging them together into IceFixes.esP ESL-flagged variants (with the exception of the BDS/vanilla 'fix' plugin).

Yes, I'm probably making things more complicated than they are, but likely as a result of the assets themselves (and the installation) being tremendously overcomplicated. I'm just saying that the plugin extensions and flags seem arbitrary, and I agree that this mod likely only needs a single ESP (probably flagged ESL, which I think VR can also use). I haven't checked if the LOD-related plugin records are redundant, but if not, I can see no reason why their changes can't be merged into the at-this-point-theoretical single plugin to rule them all. I'm just going to install IcyFixes.esm and IceLODFull.esl and will experiment with IceShaderDisabled.esp and ProjectedGlacierSnow.esl to see what impact they have. I'll mess with the FOMOD to see what options give the final result, but I suspect it may soon become obsolete if others begin expressing similar problems with using the FOMOD. There's also the question of the Cathedral Landscapes optional file and why it's not also incorporated into the FOMOD (in fact, since the FOMOD exists, there should be a single Main File rather than 2 Main and 2 Optional Files)

The ESLs I checked so far from this mod are straight up light masters using ESL extension (obviously) and ESL flag. No ESM flag. Likewise, the ESMs are just that, and the ESPs are just regular old ESPs so no ESPFEs (light plugins) so far. (I prefer ESPFE where possible so LO behaves as expected for standard plugins) I asked about it on the Nexus page and got back some useful info. I'll be opting for the ESL probably.

Actually, I do agree it's something about your save game, but probably not due to updating CL, as there is nothing in the updated version that changes landscapes. AYOP seems unlikely as well. We've seen plenty of weird things even in a new game that just went away with another new game and no other changes. Sometimes the game can be buggy is all.

Installing the FOMOD is quite confusing, especially in terms of LOD with references to enigmatic 'full'/'lite' plugins, and Nexus Description doesn't help. The only way to see what it's doing is to look at the FOMOD XML ... what a PITA. Even then, I need to install each option just to check it in xEdit to decode this enigma. The plugin names referenced in the FOMOD don't correspond to what I'm seeing in the XML, and I've no clue if 'ESL' is ESPFE or actually ESL. It's also clear that the MA doesn't entirely understand what sorts of plugins to use or how to explain them to the user. My guess is that you guys installed an earlier version before all of this confusion. Actually, I've run out of patience. I just don't have the time to go down this rabbit hole right now. I'll just wait for the update, as there's no way the current state of the FOMOD or mod Description can last, IMO.

Discussion topic: Extended UI by MrJack Wiki Link This is a LE mod supported by Dear Diary, which itself is in testing now as a companion mod to Completionist - Skyrim Completion Tracker (NG), which is also in testing. The one downside is that this mod comes with a BSA that must be extracted, since it's not compatible with SSE AE. The plugin is also incompatible, but that is remedied with use of Extended UI - Settings Loader Nevertheless, this mod offers some significant UI enhancements, including allowing more information to be exposed on the Skills/Perks UI (see mod description for details). Installation Install the Main File. Click [Yes] to extract the BSA when prompted. NOTE: The prompt appears because this is an LE mod with an LE BSA, which MO knows isn't supported in SSE. This assortment of interface mods will require a lot of testing against our current interface mods. I expect that if we adopt one or more of these new solutions, some of our current guide solutions will become obsolete/redundant.

This mod has a great many FOMOD options for compatibility, so I will need input from others testing this against several other interface mods we are using, since it will take a long time to test otherwise. See OP.

Please read the OP. It's explained there. Nothing at all has changed besides being prompted for the game mod if not set. The file must be renamed or the command line argument added per the game that applies to avoid the prompt.

As I mentioned previously, I'm not a fan of mods that dynamically adjust settings that impact visuals. While good for those that cannot run at a particular performance level, it itself obviates settings we recommend per the guide (mainly BethINI and Performance Tuning recommendations). If a person's box cannot handle specific settings, they should make the necessary adjustments to compensate rather than everyone installing mods that obviate our efforts.

Discussion topic: Dwemer Pipework Reworked by CALEB2 Wiki Link Testing: Install the Main File and merge the two Hotfix files. Merge the optional Textures without Decorations Optional File This is being tested in compilation with other mods. See, Optional companion to Real Dwemer Pipes

Discussion topic: Simple Dual Sheath by slavicpotato1 Wiki Link Companion to Immersive Equipment Displays

Might want to check the USSEP docket for this one. They should address vanilla inconsistencies like this.

Just delete that output, delete all logs from the ./DynDOLOD/logs/ folder and re-run DynDOLOD. If it happens again, click the link and troubleshoot.

I updated the Grass LOD guide with some draft GCF instructions.

Guide updated with some draft GCF instructions.

Thos instructions are redundant. I will fix it

If you installed MO in instanced mode as explained in the System Setup Guide, then your mod install priority and enablement is stored in \%LOCALAPPDATA%\ModOrganizer\{instanceName}\profiles\{profileName} (lowest priority at bottom of file) This is a directory path under the user's ownership, so user changes to these files should are honored. If you open this file and drag/drop a vanilla mod in the left pane to the priority wanted, it will update this file. Vanilla 'mods' cannot be disabled. If this is not the case for you, then you have ownership problems in the OS, or you have not installed MO in instanced mode as instructed (because your profile path is not under your user ownership). Ultimately, MO install priority doesn't matter for vanilla 'mods' in the left pane, because none of these have loose assets but rather BSA archives that are loaded with their respective plugins and determined by load order of plugins that are in turn determined by LOOT sorting.

Yeah, we had discussed this early on for 2.1.0 I think and we decided to keep the grass cache separate, due to it's original large size. The rationale was that only those generating grass LOD would need it. Obviously, that changed when GCF became available, but we never acknowledged the relevance for loaded cells without NGIO. I honestly just never thought of it ... robotically updating the guide and plugin minutia without thinking of it (because I always use it).

The Step Grass file had been close to a Gb previously until we decided to compress into BSA. We just never got around to thinking about it again since. I agree with you. I'm pretty sure the pregen is GPU and not CPU limited, but I honestly forget. This is definitely true for DynDOLOD-related processes. Example with Step build: If I have my Radeon Adrenaline and related processes running, grass pregen requires at least two hours on my quite-powerful AMD rig (see sig). Killing these unnecessary processes cuts tht time down to 30 min. Similarly, TexGen requires about 20 min and DynDOLOD takes over 2 hours with AMD 'bloat' processes running on my system. Killing them cuts the time to 2 minutes and ~30 minutes, respectively for those. I think Adrenaline is beneficial for gameplay, but it just gets in the way of generating grass and LOD. I suspect something analogous to this phenomenon may be at play with your setup. More so than hardware, I'm guessing. You definitely want all mods that touch landscape enabled ... keep in mind that this applies to any new locations and some mods that wouldn't seem to impact landscape, so I recommend getting your 1.5.97 setup as close as possible to your 1.6.xxx setup.

This is a misinformed, assumptive, and incorrect statement. DynDOLOD 3 Alpha produces the exact same 'ultra' LOD trees as DynDOLOD 2.xx but has many more features to impact the output and is far more comprehensive in aiding the user and in the LOD it can produce. It's arguably a bit more work to configure, but far simpler to use once configured. There's no reason at all to use 2.xx for SSE. If your LOD is not right, it's because you aren't using it properly or because you don't have your prerequisites and/or your configuration is faulty. So called "2D trees" are only 'billboards' in that they display the entire tree on a simple flat mesh. It's still a simple "3D tree" in object LOD and NOT a 'tradidional' Skyrim billboard tree. This is probably why the 'Ultra' tree nomenclature evolved. The tree images used for the 3D billboard trees are rendered 2D images of the 3D LOD trees and look exactly like the full trees (with obvious 2D limitations of such a projected image on a flat mesh) if LODs are made properly. Ultra with Level0 used for LOD4 trees adds the 3D LOD tree models to the *.bto 'supermesh' (just like DynDOLOD 2.xx). Ultra with Billboard used for LOD4 trees adds the flat LOD tree models to the *.bto 'supermesh' with projected images of the 3D LOD tree (just like DynDOLOD 2.xx). DynDOLOD 2.xx cannot render these billboard images from the 3D LOD trees. They must be made manually (or by using TexGen 3 Alpha, which is how most authors are making their texture tree billboards now ) EDIT: have a look at the Step Guide as an example of how we use DynDOLOD 3 Alpha. I suggest running a simple vanilla setup in a new MO profile (or Vortex) with DynDOLOD 3 Alpha and prerequisites to get your config nailed (DynDOLOD config is ideal for vanilla by default). It takes less than 15 minutes to generate vanilla LOD with DynDOLOD 3.

Hmm ... I had thought Grass Cache Fixes was recommended in Grass LOD guide, but alas, it is not. @DoubleYou originally constructed that guide, and I contributed, but it seems we ignored GCF ... I assume because that guide was itself the basis for DY's ideas about GCF. We need to add this piece to the Grass LOD guide, IMO. We don't mention the relevance of the grass cache files for loaded cells, because it's not all that relevant but for not having grass growing in objects or having grass grown in certain small areas where it's missing ... plus it's a huge file, so it arguably doesn't make much sense for most people to download that unless they are using grass LOD. Perhaps we should. I'll let DY chime in to decide. We could probably mention it's uses, but we tend to avoid providing context where it isn't needed in the Step guides just to reduce maintenance burden for us. Again, maybe that context would be welcome.