Game crashes every 10 min with Sexout

[RitualClarity]

I have been lucky. I have been runing mods in Fallout for the longest time and haven't had too many problems. Hadn't had a need to merge anything.. I read the OP.. Carefully consider the mods I am using for what might overwrite others etc and focus on select mods to use and play. When I wanted to use other mods I would wait until that play through is done and install those mods and then play again. New game each and every time. I have learned what mods I like and work well with each other and so far not to many problems. However I would only run 40 or so mods at any given time though.. Not to many and not to heavy on the scripts and conflicts .. That helps.

 

Going forward with TTW, Project Nevada and all the Someguy's mods etc I will want to run more and more mods so I will have to learn how to properly clean and merge etc patches and such.

[KainsChylde]

If you ran a filter for making a merge patch and came up with a lot of red mods, DO NOT CLEAN THEM!!! That's not the purpose of that filter, and red does not mean they're dirty. The red just means they conflict with something.

 

Conflicting isn't technically a bad thing in and of itself. All a conflict is, is changing something. Technically, and mod that changes something from the vanilla game is a conflict. These red conflicts just show what a merge patch needs to iron out.

[jaam]

Red are conflict, and that's basically the purpose of a mod, to change things

ITM are greens and those are the one you MUST remove. Anyway let xEdit do it for you, he knows.

 

99.99% of mods claiming that ITM are necessary simply do not understand what an ITM is. ITM are bad because they can hide a change by another mod by reverting to the previous value.

Deleted reference MUST be "undeleted" and then deactivated (and in most cases moved far away). Once again just let xEdit do the job.

The hardest ones are deleted navmesh which guarantee pathing issues. Unfortunately the process for undeleting them is both complex and not automated. (Lookup Arthmoor gudide on google).

 

 

Dirty edits is another animal. But this one you cannot handle automatically. Dirty edits are involuntary change to the game by a mod. They must be removed, but except for obvious things like an object moved in a cell never used by the mod, only the modder can definitively know if they were voluntary or not.

[RitualClarity]

 

Deleted reference MUST be "undeleted" and then deactivated

I assume that this means that if some modder does use this reference.. the game won't crash because the reference is still there.. If you didn't and some random mod does call that file the game will crash because the mod cannot access the file and complete what it has been instructed to do.

[jaam]

Yes. That is the whole purpose of the undelete function. Avoid crashing when something else access a no longer existing object. Which, by the way, means don't use markfordelete on anything you don't create yourself for private use.

[RitualClarity]

I was watching Gohper's video on cleaning and such and if I understood it correctly:

1. I only really need to activate the mod that is in need of cleaning. FNVedit will select those "explicitly" required for that mod to work ( masters) Unless there are some "implicit" hidden non master files that are required posted in the OP. If there are any those also need to be selected.
2. If modding and changing anything in the game.. delete something like a rock etc. I am suppose to go through that process to deactivate that resource not the "markfordelete" option ( as you mentioned Jamm) because the "deactivate" option will still allow some other mod to access that file or container etc. Also only do so where absolutely necessary if related to the base game files.
3. Use extreme care when cleaning someone elses mod because a "dirty edit" that you might think is there might be there for a purpose from the creator of the mod. It is better to try to inform the author of any serious issues r/t their mod so that they can fix/repair or clarify why those records are changed.
4. Click Ok and the changes will be written back to the original esp/esm that it was from.. ? The mod that you are editing.

[prideslayer]

I was watching Gohper's video on cleaning and such and if I understood it correctly:

 

I only really need to activate the mod that is in need of cleaning. FNVedit will select those "explicitly" required for that mod to work ( masters) Unless there are some "implicit" hidden non master files that are required posted in the OP. If there are any those also need to be selected.

This is correct. FNVedit is smarter than the GECK. All you need to look at a mod, and all it's masters, is select that mod. FNVedit will load all the required masters. I don't know what you mean about implicit masters. The only thing FNVEdit will "miss" are buildrefs or other trickery in scripts, which it can't fix anyway even if it could detect them.

 

That last sentence means don't bother even loading those "implicit" mods because you won't be able to do anything about them. If they need fixed, you have to do it in the GECK.

 

If modding and changing anything in the game.. delete something like a rock etc. I am suppose to go through that process to deactivate that resource not the "markfordelete" option ( as you mentioned Jamm) because the "deactivate" option will still allow some other mod to access that file or container etc. Also only do so where absolutely necessary if related to the base game files.

I find it faster, modding workflow wise, to just delete them in the geck, then do the undelete+disable in fnvedit. You can't just disable them in the geck, and unless you like writing down names/IDs and hunting for them in fnvedit, this way is much easier and faster.

 

Just don't forget to do it.

 

Use extreme care when cleaning someone elses mod because a "dirty edit" that you might think is there might be there for a purpose from the creator of the mod. It is better to try to inform the author of any serious issues r/t their mod so that they can fix/repair or clarify why those records are changed.

Dirty edits are things like records identical to the master. The only reason to intentionally do something like that is to "undo" a change made by another mod, by putting the dirty mod later in the load order.

 

I've only ever seen one mod do this intentionally, and it was to 'undo' changes to itself. For example if you take the sexout ESM, convert it to an ESP, and set the real sexout ESM as its master -- no mods will be able to modify records in the sexout esm, if the esp you make is last in the load order -- it will 'undo' any changes.

 

Click Ok and the changes will be written back to the original esp/esm that it was from.. ? The mod that you are editing.

When you click OK you're given a list of all the files you've modified in fnvedit and asked if you want to save them or not (each mod has a checkbox yes/no to save), and if you want to make backups. Always say yes to the backups. FNVEdit will place a copy in the "FNVEdit Backups" directory inside the data dir.

[prideslayer]

Oh a caveat to the first point about fnvedit automatically loading mods -- you must have the load order correct first. Part of what fnvedit does is find conflicts based on load order (if you want it to), so it leaves the load order as-is. This is important if you modify an ESM in the geck -- doing so will change the load order when you save, the edited mod will be last.

 

This is a problem when working on an ESM that is the master of other ESMs in your load order -- e.g. working on sexout.esm in the geck and saving it results in sexout being placed after slavery, legion, scr, etc in the load order. You have to fix that in fomm before opening it in fnvedit, or fnvedit will complain and quit.

[RitualClarity]

 

I don't know what you mean about implicit masters.

It was the term used by the narrator meaning those hidden mods that have included but not masters. I understand that those will need to be fixed in the GECK ..

 

then do the undelete+disable in fnvedit.

Simply run FNVedit.. Select mod.. Wait for it to verify the load order.. and run undelete and disable.. that is all that is needed when deleting references in a mod ? That sounds too simple.

 

Dirty edits are things like records identical to the master. The only reason to intentionally do something like that is to "undo" a change made by another mod, by putting the dirty mod later in the load order.

 

I've only ever seen one mod do this intentionally, and it was to 'undo' changes to itself. For example if you take the sexout ESM, convert it to an ESP, and set the real sexout ESM as its master -- no mods will be able to modify records in the sexout esm, if the esp you make is last in the load order -- it will 'undo' any changes.

Gopher warned about messing about with this on someone elses mod. So I assume for the most part it is safe to do so ? I understand that removing "identical to master" records are safe to do since nothing has been changed

 

When you click OK you're given a list of all the files you've modified in fnvedit and asked if you want to save them or not (each mod has a checkbox yes/no to save), and if you want to make backups. Always say yes to the backups. FNVEdit will place a copy in the "FNVEdit Backups" directory inside the data dir.

Cool, great point. So essentially if changes to mod A, B and C are done. Those changes are recorded to each respected mod. If for some reason I change my mind on changes to Mod B I can just unclick the box and only changes to mod A and B are recorded. If I say yes to backups( yes backups always backups.. ) I can go back and restore those changes if something horribly went wrong.. is that about right.

 

Now r/t the OP's post. Cleaning should be one of the first steps to minimize the crashing then patching. Correct. Patching would be more efficient if all the mods needed cleaning are properly cleaned.. Or am I still missing something here.

 

On a side note.. I have gotten so motivated.. I have started to restore and set up on of my many computers for more fun with mods.. .. LOL

[RitualClarity]

Oh a caveat to the first point about fnvedit automatically loading mods -- you must have the load order correct first. Part of what fnvedit does is find conflicts based on load order (if you want it to), so it leaves the load order as-is. This is important if you modify an ESM in the geck -- doing so will change the load order when you save, the edited mod will be last.

 

This is a problem when working on an ESM that is the master of other ESMs in your load order -- e.g. working on sexout.esm in the geck and saving it results in sexout being placed after slavery, legion, scr, etc in the load order. You have to fix that in fomm before opening it in fnvedit, or fnvedit will complain and quit.

 

Cool point..

 

I always as a first rule before doing anything r/t gaming is verify my load order.. However.. I never realized that FNVedit changed the load order on those mods modified.. GECK changed the load order on those mods that were modified.

 

Cool thing is FNVedit is smart and will give a warning about missing master.. and it gives good info.. at least as far as my limited experience with it shown me.. .

 

Edit to fix the horrible mix up between GECK and FNVedit.. .

[prideslayer]

 

Oh a caveat to the first point about fnvedit automatically loading mods -- you must have the load order correct first. Part of what fnvedit does is find conflicts based on load order (if you want it to), so it leaves the load order as-is. This is important if you modify an ESM in the geck -- doing so will change the load order when you save, the edited mod will be last.

 

This is a problem when working on an ESM that is the master of other ESMs in your load order -- e.g. working on sexout.esm in the geck and saving it results in sexout being placed after slavery, legion, scr, etc in the load order. You have to fix that in fomm before opening it in fnvedit, or fnvedit will complain and quit.

 

Cool point..

 

I always as a first rule before doing anything r/t gaming is verify my load order.. However.. I never realized that FNVedit changed the load order on those mods modified.. Cool thing is FNVedit is smart and will give a warning about missing master.. and it gives good info.. at least as far as my limited experience with it shown me.. .

 

My point is that FNVEdit *doesn't* change the load order. The GECK does, whenever you save a mod. If your load order is:

Sexout Common Resources.esm
Sexout.esm
FalloutNV.esm

FNVEdit will just refuse to work. You need to fix the load order before you try opening anything in fnvedit.

[prideslayer]

Simply run FNVedit.. Select mod.. Wait for it to verify the load order.. and run undelete and disable.. that is all that is needed when deleting references in a mod ? That sounds too simple.

That's all there is to it. You might have to run the filter first, I don't remember.

 

Gopher warned about messing about with this on someone elses mod. So I assume for the most part it is safe to do so ? I understand that removing "identical to master" records are safe to do since nothing has been changed

Well identical to master (ITM) is just one kind of dirty edit. I used it as an example of a dirty edit that is almost always safe to 'fix', there's almost no reason to do it. My brain struggles to imagine a scenario where the ITM is intentional and removing it will break that mod, or a mod using it as a master.

 

Cool, great point. So essentially if changes to mod A, B and C are done. Those changes are recorded to each respected mod. If for some reason I change my mind on changes to Mod B I can just unclick the box and only changes to mod A and B are recorded. If I say yes to backups( yes backups always backups.. ) I can go back and restore those changes if something horribly went wrong.. is that about right.

Yes, though be careful with the A/B/C thing -- try to stick to just modifying one mod at a time, though you can have as many open as you want. If you do as you mentioned there, you may end up with broken mods -- if the modifications to B that you didn't save were required for your changes to mod C to work or something.

[RitualClarity]

 

My brain struggles to imagine a scenario where the ITM is intentional and removing it will break that mod, or a mod using it as a master.

Maybe someone that requires another mod as a master however also wishes to fix some very bad changes back to the vanilla? If it is loaded after the mod it is modifiying.. which it would have to .. those records would be returned back. If you removed those files the ones from that's mods master would be used which could break something.. Possible.  maybe.. likely .. probably not.. lol..

 

Yes, though be careful with the A/B/C thing -- try to stick to just modifying one mod at a time, though you can have as many open as you want. If you do as you mentioned there, you may end up with broken mods -- if the modifications to B that you didn't save were required for your changes to mod C to work or something.

Yea.. I hadn't thought of that. That could seriously mess things up.. Times when you will be glad you clicked "yes to backup" .. .

 

That's all there is to it. You might have to run the filter first, I don't remember.

Now that you mention that I believe you need to apply the filter for the program to find those objects that you wish to undelete and disable.

[prideslayer]

 

My brain struggles to imagine a scenario where the ITM is intentional and removing it will break that mod, or a mod using it as a master.

Maybe someone that requires another mod as a master however also wishes to fix some very bad changes back to the vanilla? If it is loaded after the mod it is modifiying.. which it would have to .. those records would be returned back. If you removed those files the ones from that's mods master would be used which could break something.. Possible.  maybe.. likely .. probably not.. lol..

 

I suppose if you make an ESM with an ITM (ITM.ESM), and then make an ESP using that ESM as a master (ITM.ESP). ITM.ESP modifies the ITM record it inherited from ITM.ESM. If you clean ITM.ESM, it might cause a problem with the esp. Might. I honestly cant remember if in this case, the ESP will get the ITM record or the original. If it gets the ITM from the master, that's easy to fix in fnvedit as well.

 

Any modder should be cleaning all the mods they are using as masters for their mod though, before they even start work on their mod, to avoid potential problems like that.

 

I look for records like that, and check for errors, with every sexout release. Sexout does not (though it did, pre-NG) modify a single vanilla record, and I'm happy to say is completely error free -- as far as fnvedit is concerned anyway.

[RitualClarity]

 

Any modder should be cleaning all the mods they are using as masters for their mod though, before they even start work on their mod, to avoid potential problems like that.

Thanks.. I haven't even thought about doing that before work.. That could avoid many problems when starting work..

 

Today is is a virtual cornucopia of info from all directions.. I am getting information overload between  this site and some other things I am working on ... Dam.. like the saying goes "when it rains it pours".. I believe that was a Morton salt slogan..