Search the Community
Showing results for tags 'runtime'.
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. It can be a bit of a tricky subject. 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. A more centralized list if you will. If you DO NOT see the records listed here, assume they CANNOT be ignored and that conflict resolution will be necessary. Yes, this can get very specific inside various record types. If there is a subrecord you think should be listed here, let me know. It will need to be verified that data will merge or otherwise be collected properly at runtime before adding it to this list. Default Object Manager DOBJ - DNAM [Objects]: 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. Dialogue Subrecords DIAL - TIFC [info Count]: These will appear as conflicts whenever the counts don't match. So far as I have been able to determine, the game will keep track of the highest count and will run with that. 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. INFO - PNAM [Previous INFO]: These will be sorted at runtime based on the actual order of the final list of INFOs attached to a DIAL record. Story Manager Records SMQN - SNAM [Child] subrecord: The children specified in these subrecords will process correctly even if the display appears to indicate they won't. This can be pretty clearly demonstrated by the vanilla game and the Dawnguard DLC. There are SNAM conflicts there suggesting that Dawnguard would block the connections but the game operates them properly anyway. SMQN - QNAM [Quest Count, Quests] 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. SMBN - SNAM [Child] subrecord: As with the equivalent in the SMQN subrecord, these also sort themselves out at runtime. Location Records LCTN - Location record: As displayed in TES5Edit, everything from ACPR all the way down to LCEP will merge with each other at runtime. Conflict resolution for these subrecords is not necessary. All LCTN Subrecords from FULL [Name] to the bottom of the list DO require conflict resolition, as well as everything from EDID [Editor ID] up to the top of the record. Idle Animation Records IDLE - ANAM [Related Idle Animations] subrecord: This data is sorted out at runtime. ALL OTHER DATA in the IDLE record must be conflict resolved. Worldspace Records NAM0, NAM9 subrecords: Used to determine the in-game cell dimension of a worldspace. These have been confirmed to be exempt from the Rule of One. *ANY* mod making changes to these sets of values will have those changes propagated into the game WITHOUT conflict management. Be aware of this if you are running two mods together which intentionally change these values for a worldspace. The outcome will not be predictable and you may end up with a worldspace size much larger than you're expecting. This can lead to huge amounts of stuttering in the game that have no other identifiable cause. 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. They can appear in a mod unintentionally and the author may not be aware it has happened. Navigation Mesh Info Map NAVI - This is a special case record that will exist in any mod which has navmesh edits. Each mod will have this record listed as form ID 00012FB4. All of the data in each mod that has a NAVI entry will be merged at runtime. Conflict management is therefore not necessary, and likely wouldn't be possible anyway due to the complexity of the record.