Jump to content

Recommended Posts

Posted

I'm posting this in multiple places in the hopes it catches the eye of someone more knowledgeable, because I've never encountered an issue like this before and I'm completely stumped by it.

If I make a new game from the main menu, run to Whiterun and take the carriage to Solitude, Skyrim somehow does not recognize all the plugins that edit the large ship, the Red Wave, at the docks, but only uses the data from the second plugin of a total four: Realistic Boat Bobbing.esp. But if I instead coc straight to the docks (solitudedocks01), the data is read properly and the ship is at the right place. It seems that if I approach the docks from from an angle where the cell where Realistic Boat Bobbing places the boat (i.e., vanilla location) loads first, the boat ends up at the wrong place. But if I instead coc straight to the location where both cells are loaded or come from the direction of the Dainty Sload/Lighthouse, so that the cell of the new location is loaded first, the boat is at the right place.

Here's what it looks like if I take the carriage and run down to the docks: https://i.imgur.com/jtmnQi9.png

However, the door of the Red Wave does end up in the right position at all times: https://i.imgur.com/eiGXI12.png

Here's what the record for the Red Wave looks like in xEdit with my load order: https://i.imgur.com/mJYSWZQ.png

Here's what it looks like if I coc straight to solitudedocks01: https://i.imgur.com/YymhcTG.png

One thing that occured to me is that I believe the ship is a large reference. All the plugins editing the ship are ESM flagged, but is there some limitation to moving large references between cells? Would I need to update the RNAM record somehow, and if yes, how would I go about doing it? xEdit does not seem to display the RNAM at all, or at least I haven't been able to find it.

Posted

Update: As a workaround it seems that saving the game, exiting to main menu and loading the save does put the boat back in the right spot, but I would rather fully resolve this issue if possible.

Posted
4 hours ago, Blackread said:

One thing that occured to me is that I believe the ship is a large reference. All the plugins editing the ship are ESM flagged, but is there some limitation to moving large references between cells?

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.

4 hours ago, Blackread said:

I would rather fully resolve this issue if possible.

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.

Posted (edited)

Yeah, I guess the duplication workaround is the best solution here. Thanks for the input. I was familiar with the DynDOLOD Large References manual page, but it doesn't mention moving large refs to another cell if I'm not mistaken.

Thanks for the discussion link. I will probably have to fix that same occlusion related large ref bug myself too in the future.

Edited by Blackread
Posted (edited)
8 hours ago, Mousetick said:

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.

Regarding this, do you happen to know what would happen if I were to generate the RNAM table with multiple plugins that make edits to the Tamriel worldspace? Would the tables be merged together with all the new additions, or would only the last override carry its changes over? Would I need to create a patch where I merge these edits together?

Edited by Blackread
Posted
2 hours ago, Blackread said:

do you happen to know what would happen if I were to generate the RNAM table with multiple plugins that make edits to the Tamriel worldspace? Would the tables be merged together with all the new additions, or would only the last override carry its changes over? Would I need to create a patch where I merge these edits together?

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:

image.png

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.

Posted

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:

image.png

I wouldn't recommend using xLODGen in Edit mode for anything else than this specific usage.

Posted (edited)
2 hours ago, Mousetick said:

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:

image.png

I wouldn't recommend using xLODGen in Edit mode for anything else than this specific usage.

Thank you for the tips. To update on this, I found another mod that suffered from the same issue, our old aquaintance RedBag's Rorikstead. Although, it doesn't seem like every instance of a large ref being moved to another cell triggers this. E.g., COTN Falkreath moves the Jarl's Longhouse ref from its original position up the hill towards the nordic ruin, but there weren't any issues in Falkreath prior to me turning the large ref system on. After I did turn it on however the longhouse stood smack bang in the middle of the town square. xD It seems that if you have the large ref system on, any large refs being moved out of their origin cell is a quaranteed way of triggering the bug, but if the system is not on it will only happen rarely on some unknown condition. But since I am planning to be using large refs, I guess I have some patching work ahead of me...

By the way, if you remember the crashes I had with RB's Rorikstead a couple weeks ago, turns out they were still happening after I moved my navmesh edits to a separate plugin. Only after going back to separating the large refs into their own plugin and removing ESM flag from the main plugin did the crashing stop.

Edited by Blackread

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.