Hi again

As some of you know I've lost part of my work, so I'm starting over, but that's not the point, what I wanted to ask you guys is, is it even possible to avoid dirty editing?

I was thinking in doing everything in a new worldspace, I can say the player "please cow to....", but he has to go back to, should I say cow/coc again?

If one is to put a load door or whatever in default SKYRIM doesn't that redundantly result in a dirty edit? Since we have to put static stuff, edit navmesh, etc?


Although the "definition" says accidentaly, in the end its the same thing as not accidentaly, a change to vanilla is a change, accidentaly or not.

Or am I missing something here? Many thanks for answers.

The 'accidental' part is essential; it's the difference between a weed and a flower. A weed is growing somewhere you do not want it to grow. A flower is growing somewhere you appreciate it growing. The reason dirty edits are bad is because they can cause problems and have absolutely no benefit to the player. That's it.

Yes, there is reason to avoid editing the base game if possible, but that's a separate, more situational philosophy.

Thanks for the answer.

I see, but although I can look to my flower as a flower others may think it's a weed, but I totally see your point.

Problem in my case is "should I not edit the vanilla at all or add a load?"

That depends entirely on what you're building. The best part is that no mod that doesn't edit binaries is permanent (and thanks to Steam, even that can be undone.) I edits cells in the base game to insert the spellbooks for my mod, and I satisfy myself with editing cells that don't get changed very often (and my changes are themselves small, since it's just placing an item.)

That's what I usually do, I guess I will keep doing it.

A "dirty" edit is simply an edit to a vanilla object that you do not wish to exist. Most of the mods I create edit almost no vanilla objects, as I simply duplicate vanilla objects if I need to use something similar. This way, my mod can be almost entirely self contained, and will not be altered if someone makes a mod that changes something my mod would otherwise rely on. If I however accidently hit the ok button on a certain form, the CK might flag that vanilla form as edited, and if my mod is loaded after another mod that makes an intentional edit to this form, the other mod will essentially break and lose the changes to that form as long as my mod is loaded after.

You can intentionally change vanilla forms or objects though. For example, if you want to overhaul the perk trees, you have to make edits to the vanilla perk trees even if you replace all the perks with ones that you made yourself. In this example, where you make duplicates of every perk in a tree and change them how you see fit, then rearrange the tree to use all these duplicates, then another mod that is loaded before your mod that might reference these vanilla perks will not have any problems because you did not change any of the vanilla perks despite the game showing a perk tree full of altered perks. If another mod wanted to alter the perk trees, your two mods would conflict. If you for some reason wanted other mods that reference vanilla perks (maybe they have a magic effect that temporarily adds one of the vanilla perks to the player, or checks for a vanilla perk or something) to use your modified version of the perk, then you would intentionally modify the vanilla perk rather than duplicating it.


It is all a matter of being aware of the implications of your changes. Do you want other mods to conflict with this or that or potentially reference this or that? Do you want this or that to be self contained and not conflict? Do you want this or that to reference something that could be potentially altered by another user?


The only thing you can do is be conscious of what you are changing and how it will effect users that may be using mods that make changes as well. As for the truly unintentional dirty edits, every time you load up your file in the CK, just click details before you set it as the active file and load it, and then flag the edits that were by accident to be deleted. If you do that every time you load your mod, and are aware of the consequences of your changes and what exactly you are changing, you will be fine.



Example 1) You want to alter some epic piece of armor in the game to give it a better enchantment. Best course of action? Edit the armor piece, but give it a new enchantment that you created instead of editing an existing enchantment (unless you want this armor to use a different vanilla enchantment instead of a custom enchant). This way, you wont conflict with mods that edit enchantments, you will only conflict with mods that edit that piece of armor.

Example 2) You want to make a new spell. Best course of action? Make entirely new spell, magic effect, ect. If you point at stuff in the vanilla game such as an actor for a summon spell, and you do not want changes made by other mods to effect your mod, then make copies of those too and use those instead of the vanilla form. If you want all new actors, visual effects, or sounds, make sure you are not editing the vanilla objects to be different and you are making all new actors or visual effects instead of changing vanilla ones.

Example 3) You want to alter how an existing spell works, and you want all mods that are spell mods to utilize your change. Best course of action? Alter the vanilla magic effect and tell mod users to load your mod last. Other mods that use this magic effect will use your new, changed effect, which is kind of like a conflict but it was intentional.

In all three cases, you should always regularly check to see if the CK has flagged a vanilla form as changed, and delete that edit each time you load your mod.

you can add a new interior or worldspace that links to Tamriel with no vanilla edits (and thus esm friendly if you need that)

dropping a load door into tamriel will automatically send it to the (0,0) persistent children group (since load doors are automatically flagged persistent). any references in this group all stack and is perfect safe for multiple mods to have items all in here.

when you link your doors by teleporter, you do not have to finalize the tamriel navmesh ONLY under these conditions:

1. you make no changes to the navmesh whatsoever
2. there are no other door teleport markers in the same exterior cell that already have green triangles under them


that said you can safely move your door teleporter to where you want it and it doesnt need a green triangle for it to work. the automatically generated NVMI subrecord is enough to guide any NPCs pathfinding to and from the door. this even works with multiple doors that you added

Thanks for the replys guys.

Regarding load door, if I don't edit the navmesh and don't finalize it the green triangle wont appear and NPCS won't be able to follow right? Maybe the best thing is the cow.....

NPCs will still follow through the door

Thats good news, last time I tried that it didn't work.

In another note, tomorrow I'm going to write a tutorial to recover data from a corrupted mod, I think I've mange to recover almost everything, it's a mess but at least it's there! ^^

because the navmesh still needs to be finalized from the other side of the door (the one that is in your custom space, sorry if i forgot to mention that), finalizing that navmesh will create a NVMI record in the NAVI group, and that is what the NPC will use to navigate its pathfinding

Thanks for the answers, another question, but what about the static that "covers" the door? Since it's on top of the original navmesh, npcs are going to walk trought it, etc, no?

it depends on how much it sticks out. you can always put a collision box around it and set the collision layer to L_Navcut.

this will put a REFR in the cell (edited), but since REFRs stack, it's a harmless edit

Why didn't I think in that! A collision box! What a simple elegant solution! Thanks!