Risks with compacting form ids.

[Quevik]

Two months ago (I really need to stop modding and actually play), i asked for assistance with ESL-ing mods. I received some excellent feedback and instructions (Thanks SMR and Danke) and used those instructions to ESL everything that could simply be flagged.

However, I'm now running out of room once again, and all future ESL-ed mods will need to be compacted first.

What are the risks involved with compacting form ids? It was mentioned in the other thread that i shouldn't do this with mods that contain NPCs as facegen is tied to ID number. But are there any other potential issues?

[HazakTheMad]

If it has scripts that target a form ID, you have to redo those IDs.
And maybe some other issues.
In general mods that need compacting can be as hard to eslify as to make them in the first place.

[HazakTheMad]

Here is a large excerpt from a guide on eslifying, specifically the section on compacting,

Compacting Form ID's ─ Hey! Yeah, you! *snaps fingers* Pay Attention, damnit:

In regards to compacting Form ID's, there are some things you need to consider first. When you compact the Form ID's of a mod, some patches or plugins that you install later that relies on that mod may no longer be able to recognize it due to its Form ID's having been changed. Any time you change the Form ID's of a mod, you need to have ALL plugins that call it master present and enabled in xEdit. Never use the CK to compact or renumber Form ID's, because the Creation Kit doesn't take into account the changes that also need to be made to said plugins patches. This is why, even when the SCRIPT that we will be using tells you to use the Creation Kit, ignore that.

To summarize, if you compact the Form ID's of a plugin, you need to have its patches enabled in xEdit as well. And, due to this, if you ever install a mod later on down the road that patches or relies on any mods that you've already compacted, you will need to reinstall the original uncompacted mod to bring it back to its original state (reinstating its original Form IDs) so that the new patches or plugins will function properly along with it. After you've enabled the new patches and plugins, then you can compact the Form ID's of the original once again, bringing all of the new patches and plugins into the fold, so to speak.

Compacting Form ID's will break mods that have assets that rely on the original uncompacted Form ID. Non-exhaustive Examples:

Facegen data (meshes & textures) for NPCs that have their formID changed will have to be renamed accordingly otherwise the dark face bug will occur.
.seq files need to be regenerated if the linked quest's formID was changed, otherwise the dialogue bug (dialogue missing until first reload) will appear again.
Scripts that use GetFormFromFile with a formID that was changed will have to be updated with the new formID and recompiled, otherwise they will break.


What this means is, do not compact the Form ID's of mods that have generated facegendata, scripts, or .seq (dialogue) files. This would be mods like followers, DLC's, quests, animation mods, NPC overhaul mods, etc. Just use your brain and delve into your mods to see what they consist of before compacting.

In some cases, the "Number of Records" field you can see in xEdit includes override records which do not count towards the 2048 limit since they use the overridden record's FormID and not a new one from the ESL's limited FExxx800 to FExxxFFF range (you can see this in xEdit). The script we're running intentionally ignores overrides as you can see from the comment // override doesn't affect ESL where it skips them before counting new records.

So, what this means, is that generally if the script denotes what we've gone over already as okay to flag as an ESL, then it's generally okay to do it. That being said, we mostly want to stick to ESLifying small plugins, like patches and what not.

Also, when the script says “requires FormID renumbering” then that doesn't mean you need to use the xEdit renumbering option in the right-click menu. No, in the case of the script asking for renumbering, we will be doing compacting. That being said, you shouldn't be compacting very many plugins. It should only come to that if you've already exhausted the option of "Can be turned into ESL by adding ESL flag in TES4 header" and still need more room to grow.

So, for now, we’re just doing the simple ones that say, "Can be turned into ESL by adding ESL flag in TES4 header and changing extension to *.ESL" but we will NOT be changing the file extension. You don’t want to do that. Afterward, and at your own discretion, you can begin compacting Form ID's.

[smr1957]

When you run the script in xEdit that tells you which mods can be turned into .esls, it should tell you what needs to be done: some can just be flagged, some need to be compacted, and some will have the following warning - "Warning: Plugin has new CELL(s) which won't work when turned into ESL and overridden by other mods due to the game bug". Those with the warning should not be turned into .esls.

As for any other mod, if it does not appear on the list of potential .esls, you should not attempt to do so, as they will not work and the mod will break.

Otherwise, as long as the mod appears on the list and has no warning regarding the cell, it should be completely safe to make it an .esl.

[Quevik]

The issue SMR is that i already flagged everything that can be flagged without compacting. And the next set of mods i want to add are a bunch of custom dungeons, so i CAN'T flag them.

Which means i either need to merge the assorted custom dungeons (Which i am considering), or i need to compact and flag whichever other mods i can.

And thanks hazak. Sounds like i should stick to only compacting smaller mods like, say, stuff that adds armor and whatnot.

Or maybe i should go back to merging.

Appreciate the info!

[smr1957]

Yeah, merging has its place - if only for the mods that you can't convert to .esls. A combination of the two is probably needed for really large builds.

[Quevik]

Originally posted by smr1957:

Yeah, merging has it's place - if only for the mods that you can't convert to .esls. A combination of the two is probably needed for really large builds

Probably the way i should go then. I want to add an assortment of "life of the guildmaster" self-made quests for the various guilds. (Basically just gonna consist of a small chest with a chance every three days to contain one of several notes triggering a new mapmarker). Obviously i need some custom dungeons for the quests.

Is this still the go-to merge option? (It's been awhile since i merged)

https://www.nexusmods.com/skyrim/mods/37981

[smr1957]

Yup, that's the one.

[smr1957]

And there is this from Helpful Links and References, Section 4, Modding the Game:

Merging Plugins
https://steamcommunity.com/app/489830/discussions/0/2264691750486479016/

[Quevik]

Originally posted by smr1957:

And there is this from Helpful Links and References, Section 4, Modding the Game:

Merging Plugins
https://steamcommunity.com/app/489830/discussions/0/2264691750486479016/

Thanks. It's been a bit since i merged stuff so a small reminder about it is probibly a good idea...lol

Regarding your paragraph about "mods need to be adjacent". I don't remember doing that in previous merges myself. Is that more of a recommendation "For maximum safety" in the sense of double-checking compatibility. (Advanced users can ignore if you know how to ensure compatibility) Or is there a behind the scenes reason for it that i may not be aware of?

Like, if i merge anything it will probably be a bunch of custom dungeons in which case i will delete all overworld changes first (Leaving only the new cells), merge them, and then hand place the new entrances in locations that fit my desires / conflict-free locations. (In the merged file) So conflicts should not be an issue at all.

But if there's something behind the scenes i'm not aware of, like a scripting reason, that changes things.

[smr1957]

sorry for the late reply, Quevik. They really should be adjacent when you merge them - all grouped together in the load order - BUT, the bottom line is if it works. If it works as intended then nothing else really matters.

[Quevik]

Originally posted by smr1957:

sorry for the late reply, Quevik. They really should be adjacent when you merge them - all grouped together in the load order - BUT, the bottom line is if it works. If it works as intended then nothing else really matters.

Fair enough.

Thanks again for all the info, really helps!