Mousetick

If you're going to try out my simple test plugin and accompanying test cases, I forgot to mention that I was using a vanilla configuration generated by Skyrim SE Launcher, particularly uLargeRefLODGridSize=9, which might be important to reproduce the bugs exactly as the tests intend to. I've been doing some more tests on my side and I've given up on finding a pattern, trying to define a general rule. With some old/new cells combinations, I can't seem to be able to trigger the bug. There are too many factors involved, many unknown, so, short of reverse-engineering the whole caboodle, it seems impossible to predict the behavior. The position of old and new cells relative to each other, the position of the cells on the worldspace grid, the position of the cells in the RNAM table, the algorithm used to scan cells to load, the algorithm to load near references around the player, the algorithm to load large references around the player, the phase of the moon, etc. each may be a factor. What's really interesting though about this bug is it shows the engine remembers the original position/scale/other properties of the large reference, as defined in its parent ESM (the one with the RNAM table). It must be keeping it around in memory somehow, otherwise it wouldn't be able to (incorrectly) load the reference at its original position/scale in the old cell. No problem. Glad to help a bit and return the favor, for once

Yes I know what you mean. So here is attached the simplest test cases I could come up with in a relatively short time. Using a tiny ESP plugin that moves one large reference from one cell to another. The test cases demonstrate the bugs and behavior I previously described, once the ESP is ESM-flagged, and should be quite easy to reproduce. Requirements: USSEP + ASLAL + SKSE. Please see steps to reproduce the issue and other details in the included Readme. Edit: uploaded new version, much improved and more comprehensive. LR Cell Move Test.7z

I had one a while ago. But it was with a large reference to a PlaneMarker STAT, so "full model" doesn't really apply there. I believe it's the same or very similar problem though. @Blackread describes a better example in details with a boat in Solitude in this topic.

I'm pretty sure that's the case, based on my conversation with the OP elsewhere, and this information was omitted. The OP is attempting to fix the large reference bugs by ESMifying plugins. But of course it's not for me to say. I'll let the OP confirm whether they've ESM-flagged the plugin or not.

Not if the plugin(s) overwriting the reference are ESM or ESM-flagged ESP. In that case, DynDOLOD doesn't consider the overwrite buggy and doesn't warn about it. An ESM moving a large reference to a different cell than where it is initially defined appears to trigger a different kind of bug than those described in https://dyndolod.info/Help/Large-References. Consider for example: Skyrim.esm: adds REFR abc to Cell x1,y1 in Tamriel worldspace, includes it in Tamriel's RNAM table, so it's a large reference. Plugin.esm: overwrites REFR abc and moves it to Cell x2,y2. From DynDOLOD's validation point of view, it's all good. What happens in-game however is something like this: Player approaches Cell x2,y2 by entering one of the near cells inside the uGrid encompassing Cell x2,y2: full model is loaded in Cell x2,y2, as expected. Player approaches Cell x2,y2 by entering one of the far cells inside the uLargeRefLODGridSize encompassing Cell x1,y1: full model is loaded in Cell x1,y1, which is the wrong one. Basically the engine is given inconsistent information about the location of the large reference, the RNAM table being out of sync with the actual cell location of the REFR. Hope my description is relatively clear and makes sense. Thanks. Addendum: I should add that this 'RNAM out-of-sync with moved large reference issue' seems to arise from ESMifying ESP plugins, which don't have their own RNAM tables, or by creating an ESM plugin entirely in xEdit without manually generating the RNAM tables. If I'm not mistaken, such a situation would never normally arise in an ESM 'natively' constructed by CK, because CK is supposed to automatically generate the RNAM table? In that case, the CK-generated RNAM table for that ESM would reflect the move of the large reference to a different cell.

A couple more tips. 1. You can quickly determine if a reference is a large reference by looking at the 'Referenced by' tab in xEdit. If it's present, it will show 'Referenced by (1)' and when displayed it will show that it's referenced by its parent worldspace (that is the RNAM table of the worldspace) in the plugin that creates the reference - meaning it's a large reference. If it's not present, it's not a large reference. 2. While xEdit doesn't parse nor display the RNAM tables of Skyrim.esm, the method above can be used with xLODGen beta in Edit mode, which doesn't have this restriction. The xLODGen tool is built on top of xEdit. Start xLODGen from your mod manager with these command-line options: -SSE -edit You'll then get the same UI as xEdit. This confirms that the reference that's giving you troubles is indeed defined as a large reference in Skyrim.esm: I wouldn't recommend using xLODGen in Edit mode for anything else than this specific usage.

The RNAM tables are merged. For example, Update.esm contains RNAM tables that complement Skyrim.esm's own tables. The xEdit script operates on one worldspace at a time, selected from a specific, single ESM. If this is your ESM patch for example, only the references added or modified by this patch will be considered, and if they are determined to be large references, either because they are new and they are big enough based on their dimensions, or because they override an existing large reference, they will be added to that ESM's worldspace's RNAM table. Wow, that was a long sentence. In effect, the script does the right thing and you don't need to worry about the other plugins. Refer to the comments at the top of the xEdit script's source code for usage instructions. To view RNAM tables in xEdit, go to Options > General and uncheck the 'Hide "never shown"' option. As a side effect, xEdit will take more time to parse the worldspace records and it will take longer to open them for viewing/editing. Here is the large references table of the Tamriel worldspace from Dragonborn.esm, for example: You'll need to disable this Hide option if you want to remove an existing RNAM table, which the xEdit script requires as it only generates the table from scratch and skips existing tables. xEdit never displays the RNAM tables of Skyrim.esm because they're huge and would slow it down too much.

The jury is still out on whether that SPID for Footprints fix mod actually fixes anything. The MA has yet to answer the simple question that was asked in the comments section: "What in-game issue(s) does this fix?" I've looked at the changes in xEdit, and I don't see any actual functional fix. It does correct some script property bindings which in turn eliminates Papyrus warnings spam, that is always good. It's nice to have, and it certainly doesn't hurt to use it, but it's not a must-have IMHO. I agree Footprints is long in the tooth and has become an ugly maintenance mess due to closed permissions.

Past discussion about the issue I encountered and solution: https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/?do=findComment&comment=257701 https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/?do=findComment&comment=257704

Yes, being a large reference moved to a different cell is very likely the cause of the issue you're experiencing, even if it's moved by an ESM. I encountered the same issue some time ago with another large reference that was moved to a different cell by an ESM. It would load/unload incorrectly depending on from where I entered the cell in which it was placed. Large references are defined in the static RNAM table of their parent worldspace (typically in Skyrim.esm). This table is indexed by their parent cell: Cell ID A Large reference ID 1a Large reference ID 2a ... Cell ID B Large reference ID 1b Large reference ID 2b ... Cell ID C ... It seems that if, for example, large reference 2b is moved to another cell X, the engine gets (understandably) confused since it's declared to be in cell B. This can be fixed by splitting the changes in an ESM patch in xEdit. 1. Bury the original reference underground so it becomes invisible: Select the record from Skyrim.esm to ensure it's in the right, original cell. "Copy as override into..." the ESM patch. Set its Z position to -30000. Don't change anything else. 2. Re-create the reference in its new cell: Select the record from the last winning plugin (which should have it in the new cell). "Copy as new record into..." the ESM patch. The ESM patch can be an .esl file or an ESL-flagged .esm file or an ESL-and-ESM-flagged .esp file. Make sure it's sorted late in your load order, after any plugin that edits the reference. Note: the new reference in the new cell won't be a large reference any more. If that's a really big problem for you, you need to generate the RNAM table in your ESM patch with this xEdit script: https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/Build/Edit Scripts/Skyrim SE - Generate Large References.pas. If you're using DynDOLOD, you may need to run the tool to re-generate the DynDOLOD plugins. If they don't currently touch/forward the current reference, it's probably not necessary. See also: https://dyndolod.info/Help/Large-References.

When was the last time it worked fine and what has changed since then? Go back in time and retrace your steps. I don't know what has changed so I can't tell you how/what to fix. Check the SKSE log(s) for clues. If it was working fine before you downgraded, and works no more afterwards, beware you need to downgrade SKSE, Address Library, but also any SKSE plugins you might be using that have separate versions for Skyrim 1.5.97 "SE" vs. 1.6.x "AE".

You're on the right track. Fix your setup so that the game starts normally and runs successfully without NGIO. There is no point in trying to precache grass if the game fails to run on its own.

How are you starting the game to run the precaching? Are you using the 'Precache Grass' plugin in MO2? MO2 > Tools > Tools Plugins > Precache Grass? How are you 'manually closing' the game? It's possible the game is crashing always at the same spot during the precaching and not making any more progress. If you're using the MO2 plugin, this will cause an infinite run/crash loop until you abort the precaching, by using the 'Abort' button in the dialog box that appears after the crash and before the MO2 plugin automatically restarts it. You have 8 seconds to click on the button. If you're not familiar with the whole grass precaching process, do it at least once with a vanilla-like load order. Disable your town overhauls and new worldspaces mods like Gray Cowl and Projet AHO. Run the precaching to successful completion. Observe how it works, open the console while it runs in-game to watch its progress. Notice the *.cgid files it creates in MO2's overwrite folder. Notice the PrecacheGrass.txt file in the game's folder, you can look at its contents to track progress. Notice how the game may crash from time to time and the MO2 precaching plugin automatically restarts it, giving you an option to abort during 8 seconds. To completely stop precaching and return the game to normal operation, remove the PrecacheGrass.txt file from the game's folder. Do this only if the precaching is stuck, or was interrupted previously and you want to restart from scratch. Otherwise leave it alone and let it finish properly - NGIO removes it automatically upon successful precaching completion. Look at .Net Script Framework crash logs to troubleshoot repeating crashes that prevent any progress.

Discussion topic: IcyCollisions - accurate snow and ice object collisions by RokHel Wiki Link Icy-Collisions fixes major issues with player/NPCs clipping extremely into snow/ice objects when walking on it especially the bigger the object is. Covered: Solstheim, Tamriel and Forgotten Vale. Installation: easy, it's just a bunch of meshes. Pick the 'IcyCollisionsVanilla' main file. Overwrite ELFX, Fixed Mesh Lighting and Unofficial Material Fix. Note: I just installed it, I can't tell how good it is yet. It looks good on paper, and I like that it includes FML changes.

This can also be useful if you want to pick up skill books without reading them because you want to save them for later in your game. This becomes a non-issue with Reading is Good. Yep. Here is a shot showing the Read action with Convenient Reading. It also shows the Read icon glitch which is not caused by Convenient Reading but by a bug in either this mod or moreHUD:

There is no problem in the vanilla interactions, AFAIK. This is not a fix. This is merely a QoL UI improvement. Its purpose is to give you a choice of interaction and streamline it. To clarify, the vanilla behavior when you activate a book, if I'm remembering correctly, is: The reading UI comes up, with the book open for reading, and an option to take/steal the book. This always happens, whether you have already read the same book before or not. You can either exit the reading UI, putting the book back in place, or press a key or button to take/steal it, in which case it goes to your inventory. This mod changes the interaction like so: The Read action opens the reading UI, same as vanilla. The Take action picks up the book and puts it directly in your inventory, skipping the reading UI entirely. Same as picking up a weapon or a food item off a shelf. It becomes a Steal action if the book is owned. You have a choice via configuration: automatic, that is Read if book is unread or Take if book is already read; always Read; or always Take. Or you can toggle the action, when you activate a particular book, with the shortcut key. You prefer reading all books you find. I prefer taking them and reading them later, at home or in an inn before bedtime (in the game). It doesn't make sense to me from an immersion and RP perspective to take a break in the middle of dungeon delving to read a book I just found. I also don't want them to be marked as read when I take them, otherwise the read marker becomes useless and I don't know which ones I've read or not when comes the time to read them later, I want them to go straight to my inventory. Hope this helps.

Discussion topic: Im Talking to You by RedxYeti Wiki Link Addresses an issue where NPCs don't realistically react to your activating them to initiate dialogue, and continue to walk off on their merry way. This results in a surreal dialogue where you find yourself conversing with thin air while the NPC has walked off screen. I'm sure you've encountered this situation before. This is more disturbing in first person, and exacerbated by using mods that give NPCs more elaborate AI packages, such as AI Overhaul. With this mod, the NPCs will promptly stop, and attempt to get close to you if they can find a path, if not they'll stay where they are. They'll also turn to face you. It's script-based. There is a single, very simple script that kicks in when the dialogue menu opens and stops when the dialogue menu closes. Most of the scripting is done efficiently via SKSE scripting functions, although the mod itself is not an SKSE plugin. Previous versions used several Papyrus scripts and had an issue where NPCs would perform a 360 degrees spin when turning to face you. This was funny but weird. The new simplified and optimized version fixes those issues so I can recommend it without reservation.

Discussion topic: Read Or Take SKSE by powerofthree Wiki Link A simple SKSE plugin that allows you to take or read books or notes placed in the world, when you activate them. There are 3 possible modes, configurable in an INI file: Automatic: read unread books and take already read books. Always read. Always take. The default read/take action depending on mode can be reversed by pressing a key while activating the book. Also configurable in the INI file (left Shift by default). As it's an SKSE plugin, you can install/uninstall at any time. Beware the following issues as of this writing (refer to the bugs and comments sections on Nexus for more details): There is a minor cosmetic glitch when used in conjunction with moreHUD, where the Read eye icon floats over the book in read mode. This only occurs when activating to read, it's fine if reading from the inventory. This mod's and moreHUD's MAs are currently arguing over which mod's fault it is. Hopefully they will come up with a solution at some point. Apparently the modifier key feature doesn't work with a gamepad. Has yet to be confirmed/acknowledged by the MA. The description of Default action values in the INI file is reversed. It should be: 0 - Automatic, 1 - Take, 2 - Read.

Perhaps you may want to clarify that users need to run TexGen with whatever glacier textures they're using, beforehand. I know it's kind of obvious as the instructions are referring to 'TexGen Output', but just in case

Unlike, let's say, SPID for Footprints or SPID for XMPSSE, for example, this one is nice to have but it's not going to make a big difference. ACE only affects a few named NPCs (about 100). Without SPID there is an invisible quest and associated script that runs at the start of a new game to change their default outfit. The changes are then baked into the save file. This part only runs once at the start of a new game and shuts down, but remains dormant and available in case you toggle the changes in ACE's MCM, in which case it runs again (once each time). SPID replaces the above by static changes that are no longer togglable (no more MCM, which arguably nobody probably ever uses, so not a big loss). It saves you a few milliseconds at the start of a new game. Big whoop. SPID doesn't completely eliminate ACE's quest and script however, because ACE changes the outfit of certain NPCs dynamically and conditionally depending on their statuses. For example NCPs who become jarls during the civil war will have their outfit changed by ACE to reflect their new status. SPID can't handle this kind of dynamic change. So even with SPID, ACE's quest and script remain and are still used. So for me it's nice to have it, but I don't consider it a significant improvement over what ACE was doing without it. It's more a case of "SPID is cool tech so let's apply it to all the mods we can think of even if they don't really benefit from it, because I'm cool" by a user (Kinok) who is not officially maintaining ACE. One benefit of SPID however is that end-users can tweak the distribution files more "easily" than patching plugins in xEdit or editing in CK, to resolve conflicts between mods that change the outfits of the same NPCs for example.

Once you move it higher in the list (i.e. give it lower priority), you can then get rid of these hiding instructions which are no longer necessary because SLaWF will now be logically overwritten by all the respective mesh fix mods and other mods that are installed below it and have precedence/preference over SLaWF: It makes your life easier, and installation by users simpler. Nice, huh?

No, you need to have all mod plugins that edit the terrain enabled in your load order before generating the grass cache. Helgen Reborn should be enabled for example. As well as CRF, Wyrmstooth, and all the others. To simplify things and ensure everything matches correctly, the grass cache should be generated with the same load order as that used for playing, i.e. a complete, not minimal, set up. Same principle as generating LODs with DynDOLOD. Can't help you with the crash. Need to provide more info. If you disable plugins that are masters for other plugins, things will break. Does the game even start normally, not in NGIO cache generation mode?

This is very confusing. Why do you want to overwrite MM meshes with SLaW meshes? They're not at all alike. The additional triangles are for improved collision compared to vanilla. The SLaW version is based on vanilla. The additional mesh node comes from the vanilla mesh, which has it too. It's not a fix or an improvement at all. Quote from SLaWF comments section (currently at bottom of page 3): Quote from SLaWF compatibility section on main page (emphasis added), and confirmed in the comments section: The MM meshes are based on vanilla, but largely rebuilt, and most of all, they use a different texture set than vanilla, so they look different and are consistent with the rest of the MM aesthetic. Comparison shots of mountaincliff02: Vanilla > SLaW > MM (Double-sided) If you want MM meshes with MM texture sets + Double-Sided + Improved collision, there is this mod: Majestic Mountains - More Accurate Collision (by Korodic). I was suggesting (and showing) the complete opposite. SLaWF currently has highest priority for assets because it's in the 'Fixes' category of the STEP guide, causing unwarranted conflicts that need to be resolved by hiding stuff. It should have lowest priority. Considering these points: SLaWF is a hodge-podge of various fixes (and gameplay changes). The fixes are "better than nothing" on top of vanilla, they're vanilla-based and not essential. The gameplay changes should not be included in this mod, but that's beside the point. The SLaWF plugin is sorted very high by LOOT, meaning it's considered very low priority and should be overridden/overwritten by most other mods. Like USSEP. Consequently its assets should be treated the same: they should have very low priority too and be overwritten by most other mods which provide actual specific improvements and features over, or deviations from, vanilla. Because its assets are loose files (they should really be in a BSA to make things easier), they need to be sorted very high on the left pane to have very low priority. If you move SLaWF to 'Foundation' for example, there will be no hiding necessary. Imagine USSEP came with loose assets instead of a BSA, where you would put it in the guide: in 'Foundation', or in 'Fixes'? And how much hiding would you have to apply?

Not sure if this was a rhetorical question or you were asking me, but I can't answer. Like I said previously, my modded game deviates too much from vanilla levelling mechanics and formulae, for my particular gameplay experience with this mod to be meaningful to others. What is almost certain is that the longer you play and the more skill books you read, the faster your skills (and thereby your character) will level, at the same time potentially giving access to more perks faster. If multiple skills grow faster, and therefore level faster, in parallel, mechanically the character levels faster. Keep in mind the cap is 5 skill books (up to +20% bonus) per skill. Not 5 books total. It's relatively easy to find 2 skill books for a skill, giving +8% bonus - not too shabby. Combined with a standing stone bonus, this can be a huge boost. Please take my opinion with a large pinch of salt - it's very biased in this regard, and it's unsubstantiated. If you want to do all the math, and predict the skill and level progression with/out the bonus(es), there are some formulae available on UESP. Rough approximation with a +8% bonus, rounded to 10% to simplify: every 10 skill levels increase relative to any given starting skill level, the player with this mod will be one more skill level ahead of a player without this mod. Since reading the skill book in vanilla grants one skill level, the first 10 skill levels increase is a draw. The difference will become apparent starting at the 20th skill level increase: +1 level ahead compared to vanilla. Then at the 30th skill level increase: +2 levels ahead. And so on. I hope this looks about right, if not please correct me.

Don't get me wrong, I like this mod quite a bit too. Otherwise I wouldn't be playing with it It's an SKSE plugin + some magic effects + some scripts, easy to uninstall if desired. I just like it better nerfed a bit. I agree with DY that this is probably not a big issue for most players. I'm not sure it can be tested during a playthrough, though: how would you characterize and reproduce an average or typical playthrough? Edit: not simply an SKSE plugin.