Mousetick

DynDOLOD 3a148 / Resources 3a45 Beware I have no idea of what I'm technically talking about so I'm using vague and inappropriate terms. I'm using a treepineforestbranchcomp texture which has very thin features and is 95% transparent: In-game shots of (vanilla) full models with this texture and Ultra Tree LODs: The textures make the full model trees look very "skinny". The tree LODs look less detailed of course though somewhat ok when viewed up close (using free camera), but they look very "blocky" and "lusher" when viewed from normal distance. I would like to make the HD Tree billboards more "skinny" and less "blocky". There are 2 settings that I searched for on https://dyndolod.info/ but couldn't find information about: TreeMSAlphaThreshold in TexGen_[GAMEMODE].ini ; threshold to convert alpha channel to binary transparency - default is 128 TreeMSAlphaThreshold=96 TreeLODCreateAverageColor in DynDOLOD_[GAMEMODE].ini ; set to 1 to set transparent background of billboards to their average color, requires TreeLODDiffuseFormat with alpha channel like BC2 (DXT3), BC3 (DXT5) or A8R8G8B8 TreeLODCreateAverageColor=1 Would one of these two possibly help yield the results I'm looking for? Am I trying to fit a square peg into a round hole? Thanks in advance for your input. Full logs: https://drive.google.com/file/d/1wy5jtgkpjTasYoID4hqTj30oxta0J1w0/view

None that I know of. I've been using the ESL-flagged version.

Yes the former LITE version (now renamed 2K) of Embers XD is just lower res textures. All versions of Embers XD use the same plugin. The Embers XD variant of this mod is compatible with Embers XD's plugin. It doesn't care about its textures. Correct.

Discussion topic: Fires and Embers Clipping Fix by Diego2891 Wiki Link Improves the placement of fires, campfires and embers in their respective supports. Also fixed the correct positioning of all cooking items, like stations, pots and the various types of stands. Comes in 3 variants: Vanilla, Embers HD, Embers XD. Covers all SE content but not any CC content. Many patches available, one is relevant for STEP Guide: for Relighting Skyrim SE. I've been using this mod since the Embers XD variant became available last spring. As a side-effect of the improvements and fixes listed above, it makes Fire Hurts NG a lot more bearable and predictable: what you see is what you get - you don't unexpectedly catch fire by standing near a fire due to incorrect bounds, you only catch fire if you step on it.

Sorry for the late reply but it looks like there is a solution allowing you to keep your Windows' scaling. The trick is to downscale Skyrim inversely: Keep your monitor native resolution (2560 x 1440) in BethINI. Uncomment and set ResolutionScale in [..]\SKSE\Plugins\SSEDisplayTweaks.ini (found inside SSE Display Tweaks mod) to 100 / Your-Windows-Scale-Value (e.g. 0.8 for 125% Windows' scaling). I don't use Windows' scaling feature so I haven't tried this solution and can't confirm it works. But it makes a lot of sense. Credit goes to the player who found it: Resolution Issues - FIX (reddit)

Ok, thanks for following up. Would you mind describing what was the actual problem with Interesting NPCs and how you resolved it so that the game would start "without hiccups"? Greg, Z and I have made some efforts to help you with your issue. I spent some time reading and analyzing your crash log, which pointed to 3NPC.bsa. Please be considerate and respond. Not just for us, but for the benefit of others, who may run into the same issue. Interesting NPCs is a pretty good (IMHO) and popular mod.

Thoughts about Parent > Child feature. In addition to warning about potentially noticeable performance impact, it may be advisable to warn about impact on the reference handle count. This can become a problem for users using "urban sprawl" mods (example 1, example 2, example 3) or dense tree mods (example 1, example 2) for instance, from which child copies would be defined in DynDOLOD.esp rather than DynDOLOD.esm. In regards to the "covered area": At the risk of repeating myself, I cannot think of a tangible reason to copy non-large references beyond cells with navmeshes +/- (uGridsToLoad/2)+1. Their full model is not visible from the city cells - their LOD is visible instead, so I don't understand what purpose they might have or under which circumstances. But I'd be very happy to be proven wrong with specific examples or scenarios. If the area covered could be "optimized" depending on whether the parent reference is a large reference or not, this would partially alleviate the reference handle count issue. Or expressed more correctly: the area covered remaining what it currently is, if the copy process could be optimized to selectively copy all large references, and to selectively not copy non-large references placed farther than cells with navmeshes +/- (uGridsToLoad/2)+1. This is not a complaint or criticism. Simply some what-if food for thought. I'm actually not concerned or affected at all by the issue myself: due to my load order setup, the overwhelming majority of child copies are defined in DynDOLOD.esm. Thanks for reading.

The following time-saving procedure allows for adding new worldspaces to an existing grass cache, or for updating the current grass cache of specific worldspaces, without re-generating the cache of all worldspaces from scratch, which as we all know can be a very time-consuming process. This is not a guide about precaching grass from scratch with NGIO. It is assumed you have already precached grass with NGIO successfully at least once, and know how to repeat the operation. The procedure assumes Mod Organizer 2 is used as the mod manager. IMPORTANT: Grass Cache Helper NG is required for Skyrim SE/AE 1.6.x players. The existing grass cache must have been generated with Grass Cache Helper NG activated, and it must remain activated at all times for incremental precaching, and for playing. Step 1: Note the Editor ID of the worldspace(s) you want to add or update. Figuring out which worldspace(s) and their Editor ID is a task left up to the reader. See some suggestions at the end about finding out this information. Step 2: EXTREMELY IMPORTANT. Disable your existing grass cache mod[1] on the left side of MO2. Failure to do so will wipe out the entire grass cache during the later steps, which will then need to be exhaustively re-generated from scratch, which would make this tip completely pointless. Step 3: Edit NGIO configuration and specify the list of worldspaces to add or update. The NGIO configuration file is [..]\NetScriptFramework\Plugins\GrassControl.config.txt. Edit it with a text editor. You may want to make a backup copy of that file before editing it. Search for 'OnlyPregenerateWorldSpaces' or scroll down until you see it. Then comment out the line by prepending it with a # character. Add a new line like this, containing the Editor IDs you gathered in Step 1: OnlyPregenerateWorldSpaces = "Worldspace1EditorID;Worldspace2EditorID;Worldspace3EditorID" The list of worldspace(s) to add or update must be enclosed in double quotes, multiple Editor IDs separated by semicolon. Example showing the result of editing and specifying only one worldspace: Step 4: Launch the NGIO precaching process from MO2 as usual. You may need to make preparations[2] specific to your mod setup before launching the process. The process should only take a few minutes[3], more or less depending on the number and size of specified worldspaces. Wait until it completes successfully. Step 5: Move the grass folder from MO2's Overwrite folder to your existing grass cache mod. If you are updating the grass cache of worldspace(s), you will be prompted to confirm replacing the existing cache files with the new ones. Step 6: Undo the NGIO configuration changes you made in Step 3. If you made a backup copy of GrassControl.config.txt as suggested, simply restore it. If you added new worldspace(s), don't forget to edit GrassControl.config.txt and append their Editor ID to the existing OnlyPregenerateWorldSpaces line. Otherwise they'll be missing the next time you re-generate the entire grass cache from scratch. Step 7: Re-enable your grass cache mod on the left side of MO2. That's it. Enjoy[4] your updated or added grass. Notes [1] Your existing grass cache mod is the mod containing the grass folder, not the mod containing NGIO (inside a NetScriptFramework folder). If you have merged both mods, then you're doing it wrong. Split them into two separate mods. [2] Preparations such as reducing Skyrim's display resolution, disabling mods that may interfere with the precaching process, switching environments/profiles... Anything that had to be done when generating from scratch. [3] If you're updating Tamriel (Skyrim's main worldspace), the largest of all worldspaces, it will take quite a while, but it will still be faster to process it individually than processing all worldspaces in the entire load order. [4] You're not yet completely done if you use the grass cache for grass LODs. You'll need to (re-)generate LODs with DynDOLOD for the specific worldspace(s) you added or updated. Refer to the official DynDOLOD documentation for details: Updating or Updating. How to find out the Editor ID of worldspace(s) with grass Method 1: Recommended when adding new worldspace(s) for its accuracy. Requires xEdit, basic knowledge of its operation, and Worldspaces with Grass SSEEdit Script for No Grass In Objects. Install 'Worldspaces with Grass SSEEdit Script for No Grass In Objects' as instructed on its mod page. Load up in xEdit the plugins of the mods adding new lands, as well as any grass/landscape mod plugins. Omit other plugins. Run the 'List worldspaces with grass' script. When it's done, copy the resulting list and paste it to some place where you can edit it. Remove all vanilla worldspaces from the list. The remaining worldspaces are the new ones with grass. Example with Wyrmstooth: AlftandWorld;Blackreach;BloatedMansGrottoWorld;BluePalaceWingWorld;DarkwaterWorld;DeepwoodRedoubtWorld;Dimfrost;EastEmpireWarehouse;FallowstoneCaveWorldEnd;FallowstoneCaveWorldStart;FrostmereCryptWorld;JaphetsFollyWorld;KarthspireRedoubtWorld;KatariahWorld;LabyrinthianWorld03;LabyrinthianWorld04;MarkarthWorld;RedEagleRedoubtWorld;RiftenWorld;ShadowgreenCavernWorld;SkuldafnWorld;SolitudeWorld;Sovngarde;Tamriel;WhiterunDragonsreachWorld;WhiterunWorld;WindhelmPitWorldspace;WindhelmWorld;WyrmstoothWorld Method 2: Suitable when adding or updating worldspace(s). Physically go to the place in-game where there is already grass to be updated or where there should be grass to be added. Use fast-travel, coc or cow console commands, whatever works to get there. Open the (More Informative) Console and press the Tab key until the Worldspace & Cell information card is displayed. Ctrl+Click the 'World Space' field in the information card, to display more details. Note the Editor ID. See following screenshot for illustration: Method 3: When adding new worldspace(s), less accurate than Method 1. Requires xEdit and basic knowledge of its operation. Load up the plugin of the mod adding new lands in xEdit. Expand the Worldspace node. Select a new worldspace entry (i.e. not vanilla), and check the 'DATA - Flags (sorted)' section on the right panel. If it contains 'No Grass' then skip it, go to step 6. Otherwise note its Editor ID. Repeat from step 3 for each new worldspace entry. Illustrated example showing the first two worldspaces from Beyond Reach:

How? What did you do to resolve the issue and start the game without hiccups? Your first LOOT screenshot shows you have 1 dirty plugin. This indicates you're apparently ignoring suggestions and advice we've given you, such as cleaning all newly added plugins with xEdit. Your second LOOT screenshot shows you've used the 'Sort' button in MO2. Don't do that. Never do that. Only sort with the external LOOT tool, via MO2's 'Run' button. Use the STEP Guide as a "best practice" reference and as a template for installing new mods. If you keep doing things "your way" and disregarding the guide methodology, then you have learned nothing from the guide and you'll keep making mistakes, running into issues. Only after you have accumulated enough experience and are comfortable troubleshooting issues on your own, then you can start doing things "your way".

Illustrated practical demonstration of the engine's handling of temporary references in ESM vs. ESP plugins For mod authors and advanced mod users. TLDR: Skip to the Summary section further down. Part 1: The initial (vanilla) state We're in Markarth, in front of the stables. Let's look at a few objects: the door, a handcart, and a hay bale: Notice the console shows a Textures field for all the references. This indicates the textures are loaded and the object is rendered. The door is a persistent reference because it's used with navmeshes for NPCs, among other things. The other objects are temporary references. The door is only interesting as a point of temporary/persistent comparison later on. Part 2: The demonstration plugin Now let's make a simple plugin for an hypothetical mod. We're going to permanently disable the handcart, make the hay bale bigger, and place a new small hay bale: So the plugin overrides two vanilla references and adds a new reference. We've also given each reference an Editor ID to more easily look them up. Let's go take a look at the changes in-game with our new plugin enabled. The handcart is disabled and no longer visible, the existing hay bale has grown in size, and there is a new small hay bale not far from it: For the next tests, we'll be moving to Winterhold, far, far away at the opposite end of the map. In Winterhold, the cells we were in in Markarth (i.e. the active grid) won't be active any more. Part 3: Engine handling with an ESM plugin The demonstration plugin is ESM-flagged. This is how Bethesda intended things to be based on how the engine is designed and behaves in Skyrim SE. Let's look at our references from Winterhold. First the door. The door is still there, despite it being in Markarth and us in Wintherhold, as expected since it's a persistent reference. But note the Textures field is no longer present, meaning the door while still being loaded in the game, is no longer rendered. It all makes sense. As for all the other references, they can't be found. They're no longer loaded in the game at all. It all makes sense again, since they're temporary in a cell outside Markarth and we're in Winterhold: Part 4: Engine handling with an ESP plugin We remove the ESM flag from the demonstration plugin. This is how 99% of all mods made and released by mod authors are. Let's again look at our references from Winterhold: Surprise! They're all found. They're all loaded (but not rendered, as they have no Textures field). They're essentially treated like persistent references by the engine. Note that even though the handcart is permanently disabled, it's still loaded. An object that will never ever seen in-game is wasting engine resources. Also note that the hay bale originally defined in Skyrim.esm, but has been overridden by our plugin, is now always loaded. The hay bale is now wasting engine resources. We can even go into the Jar's Longhouse, an interior cell, and they're still there: Summary The Skyrim SE engine is designed to handle (object or actor) references in ESM plugins, not in ESP plugins. References in ESP plugins still "work" but not as intended by Bethesda. Temporary references in ESP plugins essentially behave like persistent references: always loaded in the game, available and reachable globally from anywhere. All temporary references in ESP plugins, whether they are overriding existing temporary references, or newly added references, are affected. Temporary references in ESP plugins contribute to the total amount of loaded references, which has a hard limit. Even though temporary references in ESP plugins don't waste rendering resources, they still consume engine resources, mainly memory. Miscellaneous Notes ESP plugins are bad not only because they're wasteful, but they also hide all the bugs in mods. Since all the references, temporary or persistent, are always loaded, there is no longer a meaningful distinction between persistent and temporary. A temporary reference may be used in the wrong context, it's all fine, it doesn't matter as it's always loaded, it always can be found. The same plugin would be a CTD crashfest if it were ESM, or some things wouldn't work correctly. All Creation Club modules, from the simplest gimmick to the largest content, are released by Bethesda as ESM plugins (.esl is the "light" version of .esm), for a simple reason: it's how plugins are expected to be in Skyrim SE. People can be confused by the term ESM which is commonly associated with game masters, i.e. the core game files (Skyrim.esm, Update.esm, etc.). And so they think it doesn't make sense for a mod or a patch to be ESM, to be a master. The two concepts must be disassociated. Game masters are the core game files, yes. But ESM is something else, it's just a small flag that has no relation with the nature or purpose of the plugin, but has big implications for the engine. Again, Creation Club modules are not core game files, they're Bethesda-approved mods, and yet they are all ESM. There is no downside to plugins being ESM, while ESP plugins exhibit proven disadvantages and deficiencies. Technically, ESM vs. ESP only matters for plugins that add new references or modify existing references. Those that don't can be ESP. Large references are not related to temporary or persistent references. They're a separate feature that is only available, and that is no coincidence, in ESM plugins. ESP plugins that override large references cause visual bugs, which is another reason ESP plugins are a bad idea. In our demonstration above, we only used static object references. The increased resource usage and waste caused by ESP plugins is worse with temporary NPC references (ACHR), because the engine must periodically evaluate and process their AI packages in case they might need to travel somewhere, or do something on a schedule. The engine is optimized to prioritize and refresh the most often the NPCs closest to the player, but it still must check all loaded NPCs from time to time. It's too late now to do anything about it. There's too much legacy with 99% of all existing mods using ESP plugins. Making existing ESP plugins into ESM can be trivial or extremely difficult. Even if some ESP plugins can be made ESM, there is the issue of sort orders and dependencies, particularly with automated sorting tools such as LOOT. This may require that other plugins be made ESM in order to satisfy the dependencies or sorting metarules. Nevertheless, certain kinds of mods which only deal with static (STAT/TREE/FLORA) or moveable static objects (MSTT) - such as tree mods; or landscape clutter mods - can and should be made ESM as they typically add or touch thousands of temporary references. Persistent Location There exists a sparely documented reference attribute named 'Persistent Location' which is extensively used by Bethesda in the vanilla plugins, but is apparently ignored or unknown by mod authors. It seems to be used exclusively with NPC references, so may only be intended to be used with them. It allows a temporary ACHR to become "temporarily" persistent as long as the player is in the specified location. As a reminder, a location (LCTN record) is a "tag" that is applied to specific cells, which together belong to, and form, a geographic location. The Persistent Location is an optimization feature: it avoids making an NPC reference persistent, which creates some overhead for the engine as discussed above, and instead keeps it as a temporary reference while allowing for some advanced NPC behavior across multiple cells, even across interior/exterior cells, while the player is in the geographic location. For example, Adisla, a farmer working at the Hlaalu farm near Windhelm: This minor NPC has advanced AI packages to make her sleep and eat inside, work and wander outside, on a specific schedule. She also has dialogue scenes with other NPCs on the farm. These features require her to be persistent. However her reference is temporary. But the Persistent Location attribute makes her persistent only when the player is in the Hlaalu Farm. Once the player exits the location the reference becomes temporary again, and completely unloads when the player moves further away. Obviously this is only meaningful in ESM plugins. It's completely useless in ESP plugins, since all temporary references are always and everywhere pseudo-persistent.

Apparently it crashes when opening or reading the file 3DNPC.bsa. Mine looks like this: and its CRC32 checksum is 1132B384. Yours should have exactly the same size in bytes (i.e. 2,117,416,854), modified date (i.e. 2022-08-18 4:04:58) and CRC32 (1132B384). To get the CRC32 checksum of a file, open 7-Zip File Manager, navigate to the folder containing that file, right-click on the file, select CRC > CRC-32:

DynDOLOD 3a146 / Resources SE 3a44 Not a problem report. Just a Parent > Child appreciation post. The Legacy of the Dragonborn airship, when parked inside Markarth, Riften or Whiterun, provides an immersive way to get a bird's eye view on parts of the city's exterior while being in the city's child worldspace. Riften Docks, very nice | Details of a copy with Enable Parent 👍 Whiterun Stables (terrain is ugly because I need to regenerate grass cache with grass in WhiterunWorld) I noticed you made a new model for the wrhousewind01 in Resources (wrhousewind01_DynDOLOD_CHILD.nif) specially for Parent > Child copies. This fixes the issue with the missing door: Very nice. I happen to have another mod that uses the same house further down the road, but is orientated such that the door is on the other side: Thank you for all these improvements, much appreciated.

How does it stop loading? Does it quit, and control is returned to MO2? Or does it hang indefinitely? In the former case, check whether a crash log is generated. Could be caused by missing masters, errors in plugins, uncleaned plugins, or using LE plugins with SE.

It's fixed.

The debug log I uploaded is from the exact same session that generated the DynDOLOD.esp I checked in xEdit. I was hoping the log would contain some hints. But if there are none, there isn't much more I can do Perhaps another way to trace these phantom references would be to search for the form ids of valid references that precede or follow them. For example: buvarpsereesp_001326_Tamriel_DynDOLOD_OBJECT [REFR:26271D9A] (places WalkwayStairs4_DynDOLOD_BASE [STAT:2409C83A] [REFR:26271D9B] (places NULL - Null Reference [00000000] [REFR:26271D9C] (places NULL - Null Reference [00000000] [REFR:26271D9D] (places NULL - Null Reference [00000000] [REFR:26271D9E] (places NULL - Null Reference [00000000] legacyofthedragonbornv5esm_13DC20_Tamriel_DynDOLOD_OBJECT [REFR:26271D9F] (places _DA_Dock_ScaffoldBase4Sided2_DynDOLOD_BASE [STAT:2409CA07]) [... and so on ...] Hope this helps.

I don't know what "game does not start" means exactly. I use Interesting NPCs. All patches mentioned by Greg above are good, except the correct patch for children faces is not TK Children but Simple Children. The patch for 3DNPCs is in Simple Children's FOMOD (patch plugin, meshes and textures are needed). Perhaps the failure are caused by your changes in xEdit. Try the mod and patches "as is" first, without fiddling with anything in xEdit. Also disable DynDOLOD while adding and testing new mods. Then re-enable, or re-generate. Clean any plugin or patch added to your load order with xEdit.

It did run through and completed successfully. However checking DynDOLOD.esp for errors in xEdit finds a bunch (77 to be precise) of [00:01] [REFR:26271D9B] (places NULL - Null Reference [00000000] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at 0,0) [00:01] REFR \ NAME - Base -> Found a NULL reference, expected: ACTI,ADDN,ALCH,AMMO,APPA,ARMA,ARMO,ARTO,ASPC,BOOK,CONT,DOOR,FLOR,FURN,GRAS,IDLM,INGR,KEYM,LIGH,LVLC,LVLN,MISC,MSTT,SCRL,SLGM,SNDR,SOUN,SPEL,STAT,TACT,TREE,TXST,WEAP errors. They're all persistent references. There is no EDID. They all look like this: Full list: Full logs: https://drive.google.com/file/d/17CqYSy56n5oUqpsKd6W0XWxh4BlsjLxJ/view Thanks. I went back and checked DynDOLOD.esp I kept from previous versions: Alpha 134: No errors. Alpha 140: Same errors.

There you go: https://drive.google.com/file/d/14g8e9YT-hcJlXphcjWU8J3rBJv9m03z0/view I'm going to be away from keyboard for a while. Won't be back until late afternoon tomorrow UTC.

DynDOLOD 3a145 / Resources SE 3a43 Error: Load order FileID [7C] can not be mapped to file FileID for file "DynDOLOD.esm" [7C] is actually DynDOLOD.esp. Full logs: https://drive.google.com/file/d/1usLPb4uTHAx3a8qvFif9zq0O5j5jHmwP/view Thanks.

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD I'm done testing copies of references toggled by script. No issues were found with vanilla or modded stuff. I don't know if there were Parent > Child related changes in released Alpha 143 since the last test version that would need checking. Side note: Wow, Riften with NoCellsWithNAVM=0 is such a big improvement. Wonderful. That sounds like a simple and effective solution. It would need to be done to any base record, used by copied references, that has a non-empty VMAD section. Not just ACTI. Thanks.

Survival Control Panel allows you to view or change the warmth rating of worn apparel, or add warmth rating to items lacking it (such as mod-added apparel). It uses an MCM for its UI so it's not as convenient as this mod to see the warmth rating of items in inventory. Dear Diary Dark Mode includes this mod, so it's redundant when using DDDM.

Exactly! I was basically saying the same thing, and I completely agree with you but I'm very confused at the same time Earlier you said: But now you're saying it did contribute to light armor perks... Which is correct. Don't you think it's wrong/strange that a Heavy Armor mask influenced your Light Armor perks? This is a bad bug because, due to the Amor Type / Armor Keywords discrepancy, a Heavy Armor player wearing the mask would have Heavy Armor skills applied, but not some Heavy Armor perks. Or in your case, a Light Armor player would have Heavy Armor skills wastefully applied, and Light Amor perks applied, even though it's a piece of Heavy Armor. It's very confusing. It's pretty bad, but not too bad, since it's a unique item obtained from a big boss that not many players would encounter.

Thanks, that's useful info. No. Armor perks are based on keywords. Take a look in xEdit at Unhindered [PERK:00051B1C] (renamed 'Light Armor Training' in Vokrii), or Custom Fit [PERK:00051B1B] ('Light Armor Fit' in Vokrii) for example. All the conditions are based on armor keywords, not armor type. Warmth rating is added for specific armor/clothing pieces in Update.esm for Survival Mode. WACCF forwards them. If there is no warmth keyword, then it's done on purpose by Bethesda, and WACCF didn't think it needed fixing. I don't know what the default warmth rating is when none is specified.

I don't know what the vanilla game does, but SkyUI (and derivatives) use keywords for many things. For example, the Amulet of Articulation has Armor Type = Clothing but is displayed in inventory as Type = Amulet, Class = Jewelry, with an Amulet icon. I don't know what information SkyUI uses for Light vs. Heavy armor in inventory and item card. You should try with the CR Patch bug and see how it looks The fact that the Armor Type is wrong and inconsistent with the keywords is pretty bad. This should be fixed. Then you won't have to worry about whether it's displayed incorrectly in the UI

On second thought, I think it's better not to carry it over. First, it wouldn't work: parent and child references being separate references in separate cells, each with their own reset timer, they wouldn't be in sync. Second, the No Respawn flag is useful with "smart" stateful references such as those using ACTI, and therefore would not be needed with dumb stateless static copies.