- Skyrim sseedit start processing mod#
- Skyrim sseedit start processing full#
- Skyrim sseedit start processing mods#
Skyrim sseedit start processing mod#
All of the data in each mod that has a NAVI entry will be merged at runtime. Each mod will have this record listed as form ID 00012FB4. NAVI - This is a special case record that will exist in any mod which has navmesh edits. They can appear in a mod unintentionally and the author may not be aware it has happened.
Skyrim sseedit start processing mods#
If you have mods which are altering vanilla worldspaces, chances are these edits were NOT intentional unless the author specifically states they have done so. This can lead to huge amounts of stuttering in the game that have no other identifiable cause. The outcome will not be predictable and you may end up with a worldspace size much larger than you're expecting. Be aware of this if you are running two mods together which intentionally change these values for a worldspace. *ANY* mod making changes to these sets of values will have those changes propagated into the game WITHOUT conflict management. These have been confirmed to be exempt from the Rule of One. NAM0, NAM9 subrecords: Used to determine the in-game cell dimension of a worldspace.
ALL OTHER DATA in the IDLE record must be conflict resolved. IDLE - ANAM subrecord: This data is sorted out at runtime.
Skyrim sseedit start processing full#
Conflict resolution for these subrecords is not necessary.Īll LCTN Subrecords from FULL to the bottom of the list DO require conflict resolition, as well as everything from EDID up to the top of the record. LCTN - Location record: As displayed in TES5Edit, everything from ACPR all the way down to LCEP will merge with each other at runtime. SMBN - SNAM subrecord: As with the equivalent in the SMQN subrecord, these also sort themselves out at runtime. SMQN - QNAM subrecord: Data contained within the QNAM subrecord will merge at runtime as demonstrated by numerous mods which share these nodes to add quests to the lists which all function together properly. There are SNAM conflicts there suggesting that Dawnguard would block the connections but the game operates them properly anyway. This can be pretty clearly demonstrated by the vanilla game and the Dawnguard DLC. SMQN - SNAM subrecord: The children specified in these subrecords will process correctly even if the display appears to indicate they won't. INFO - PNAM : These will be sorted at runtime based on the actual order of the final list of INFOs attached to a DIAL record. It's also possible this subrecord doesn't matter in the end and is only for internal information purposes as this count value is never seen in the CK. So far as I have been able to determine, the game will keep track of the highest count and will run with that. It will need to be verified that data will merge or otherwise be collected properly at runtime before adding it to this list.ĭOBJ - DNAM : ElminsterAU has confirmed that this record merges its data at runtime, therefore conflict management on this record if it exists in a mod is unnecessary.ĭIAL - TIFC : These will appear as conflicts whenever the counts don't match. If there is a subrecord you think should be listed here, let me know.
Yes, this can get very specific inside various record types. If you DO NOT see the records listed here, assume they CANNOT be ignored and that conflict resolution will be necessary. So I figured it's about time to start documenting this in a more proper way than scattering it about on various mod threads on Nexus and elsewhere. I've seen a few scattered questions about which records in the game will conflict with each other and which won't and what should be done about it if they do or don't.
0 kommentar(er)
