Kendeshel Playthrough,  Modding,  Skyrim

Making my first patch in xEdit

Here’s a post documenting a new adventure in modding for me: creating my first local patch in xEdit!

Turns out I triggered a problem known to folks on the Legacy of the Dragonborn Discord–where dragon attacks inside Solitude are astonishingly common. For the session I played with Kendeshel on 10/7, the post for which will be going up soon, I had three.

I’ve had dragon attacks in previous playthroughs in Solitude, sure! But three in one session? Definitely a bit much. 😆

More about this behind the fold.

The root cause

From what the LotD Discord had to say about this, the probable root cause of the problem is that Legacy makes significant changes in the Skyrim worldspace–especially in Solitude. Since it is, after all, adding an entire museum there, as well as the additional zone that serves as the access to the Dev Aveza once you get it.

In particular, in my case, Legacy had a couple of patches that were setting different cell height data for Solitude zones than what Skyrim sets itself.

(Mind you, I am still very much a newbie to this level of Skyrim modding work, and it is not clear to me yet why “cell height data conflict” equals “a dragon strafes Solitude every time I step outside the museum”. But LotD Discord devs have the experience to know what they’re talking about! For now, for purposes of this post, I’ll just run with that. Though if I learn more about this issue and get a better understanding, I’ll do a followup post.)

The recommended solutions

The LotD Discord mentioned a few options to solve this problem:

  1. Try not to fast travel directly into cities
  2. Copy vanilla Skyrim’s cell height data for the impacted museum exterior cell over onto any mods that might be breaking that data
  3. Save out a patch specifically containing the vanilla cell height and add that to my load order

Minimizing fast travel will probably help some, but…

For option 1, that strikes me as kind of a good idea anyway. This is very much in line with observations I made way the hell back in Alarrah’s playthrough, when I realized that dragons were a fuckton more likely when I fast traveled anywhere. Which is exactly why I started making the Western Watchtower my chosen fast travel location for coming into Whiterun.

I’ll try to minimize my fast traveling, but for purposes of this playthrough I don’t know how practical that’ll be. Especially given that the vast majority of this dragon strafing has not been triggered by fast travel–it’s just been triggered by zone changes, and specifically by coming out of the museum. There are three different ways I’ve done this, at this point:

  1. Walking out through the main entrance
  2. Coming out on the balcony around the Safehouse
  3. Coming around the corner from the porch by the Explorer’s Society Guildhall, where the airship docks–because this does trigger a zone change

Scenario 1 is the most common here, though 2 and 3 have both now triggered the problem for me. And it’s not like I can avoid doing any of these. It’s literally impossible to get out of the museum without triggering a zone change.

Which means that it can’t be the only solution to my problem here.

… what I really need to do is use xEdit

The real actual solution to this, according to the LotD Discord, was to get xEdit looking at my load order, find the bits of conflicting info about cell height, and fix those.

And while I do most of my playing on the Deck, I do semi-regularly also play in my VM on the computer. So I needed to make a solution that I could apply in both places. Which meant, doing a patch in xEdit.

So what’s xEdit?

xEdit is a tool for doing advanced digging into a load order, especially for conflict resolution. The tool has other interchangeable names, depending on what game you’re actually modding for. In the case of Skyrim’s Special Edition and/or Anniversary Edition, it’s also called SSEEdit. But since the LotD folks generally call it xEdit, I’ll stick with that for consistency.

I followed this wiki page to get it installed on my VM on my MacBook. I wanted to try a fix in xEdit first, because as I’ve written about before, doing extensive modding work directly on the Steam Deck is a bit of a pain in the ass, even if I’m remoting in on the device. So I figured, if I got an apparently working fix going on the VM, I would also then port that fix over to the Steam Deck.

What I specifically had to fix

As per input from LotD Discord users icecreamassassin (LotD’s creator!) and Benven, I had to look for cell height data. I spent some time reading up on what the various colors of things in xEdit mean, and what I can get out of the HUGE FIREHOSE of information in the tool.

Then I found a couple of relevant options to turn on, which were:

  1. Apply filter to show conflicts, on the left hand pane
  2. Hide no conflict and empty rows, on the right hand pane

Once I had those options on, I drilled down into LegacyOfTheDragonborn.esm, which was the primary file for this particular mod in my load order. For that file in particular, I looked under “Worldspace”, then under “SolitudeWorld”, and lastly under “MuseumExterior”. This was the impacted cell as per info from the Discord.

This got me some data that looked like this, which showed me that yes, my load order was bitchy about conflicts in “Max Height Data”:

Screencap of xEdit showing in-depth data about the MuseumExterior cell in Legacy of the Dragonborn. The right hand pane indicates a problem with "Max Height Data".

In the right hand pane of this screenshot, you can see what the Max Height Data value gets reported as, according to various files. Skyrim.esm is the one relevant to the game itself. All the rest of the tabs are, I believe, for various mods I’m running.

So what I had to do next was check what was on the Skyrim.esm tab and compare it to everything else.

Here’s what I saw when I clicked into the Skyrim.esm tab, behold this gigantic hex string:

Screenshot of xEdit, where I'm looking at the huge hex value in Skyrim.esm that represents Max Height Data for the "MuseumExterior" cell in Solitude.

When I started looking at the other tabs, that same gigantic hex string was on most of them, except for two patch files at the end–which were specifically related to Legacy’s official patches. That different value is shown here:

xEdit screenshot, showing a hex value for Max Height Data in a Legacy of the Dragonborn patch. This value does NOT agree with the value provided in the official Skyrim.esm file. Oops.

So now my task was to resolve this conflict.

icecreamassassin and Benven advised me that the easiest thing to do would be to just copy the entire string out of Skyrim.esm and over into the impacted patches–though this would have the side effect of my having to fix it again if the patches got any updates to them.

However, since I knew I was going to have to deploy this same fix to the Deck after testing it on the VM, what I decided to do instead was generate an actual patch that I could add to my load order. As per icecreamassassin, as long as this patch contained Skyrim.esm’s value for Max Height Data and it showed up in my load order after the patches, its value would take priority over the patches.

In order to do this, I right-clicked on the left hand pane and got the popup menu shown here. On this menu, I selected the “Copy as override into” option:

xEdit screenshot showing the popup menu I got when right-clicking on the left hand pane, to try to create a patch file for my broken Max Height Data value.

And last but not least, once I chose “Copy as override into”, I got a dialog box that looked like this. I had to scroll all the way down to the bottom and choose the option for a new ESP file, with the ESL flag on. What this means in practical terms is that it was to create a file that wouldn’t count against my plugin limit in my load order, because Skyrim does apparently have a hard cap on that:

xEdit screenshot of my creation of a new ESP file, with the ESL flag on it, to contain my patch for the Max Height Data value.

I called my patch file “Vanilla Cell Height Patch”, and this is what it looks like if I drill down into it in xEdit now:

It’s got the same hex string value as the one in Skyrim.esm, which is what I want.

I added this patch file to my load order on the VM and did some play testing of it, and was able to walk around Solitude and have it behave apparently as normal. I then deployed that same patch file to the load order on the Deck for further testing.

The end result

Since deploying this patch to my load order, I’ve had just one dragon attack inside Solitude across a couple of sessions. So they clearly haven’t vanished entirely. But I’m actually fine with that, as long as I don’t get a ridiculously high number of dragon attacks. Previous playthroughs of mine have had Solitude dragon attacks before, as I’ve written about.

If this patch gets me back to the “low but not zero risk of dragons inside a city” situation I’ve had before, I’ll be happy. <3 I will continue to report on how this behaves as Kendeshel’s playthrough continues.

And now I know how to do a simple patch in xEdit! I’m feeling pretty happy about this and will refer back to this post as needed for anything else I might want to patch in the future.

Many thanks to icecreamassassin and Benven from the LotD Discord, for their assistance in helping me work this out!

As Angela Highland, Angela is the writer of the Rebels of Adalonia epic fantasy series with Carina Press. As Angela Korra'ti, she writes the Free Court of Seattle urban fantasy series. She's also an amateur musician and devoted fan of Newfoundland and Quebecois traditional music.