pack A Real Explorer's Guide to Skyrim

[CJ2311]

There's no tool or script for that, but you can simply load all your load order in TES5Edit, right click one of them, and select "Apply Filter".

 

I don't remember the filter settings off the top of my head, but if you still have the default settings it should be easy: in the top left corner, uncheck "Single Record" and "Override without conflict"

This'll hide everything that's not conflicting, and will make checking for conflicts much easier :)

[dreadflopp]

Ok,thanks! :-)

[Nearox]

I'm going to wait a bit with updating the SRLE - REGS CR guide until the frequency of additions/changes that Neo makes to the SRLE CR section has gone down a bit.

 

Do keep in mind that generally speaking, the majority of conflicts should not need patching.

Edited March 12, 2014 by Nearox

[CJ2311]

Here's a screenshot of the filter settings I tend to use:

[oldmcgroin]

Hi Guys,

Thanks for making this awesome pack. I currently have STEP Core, Extended, Weather and Lighting and this pack however I have a small problem.

 

Whenever I go into the sewers (provided by Skyrim Sewers 4.0) I seem to have missing textures (ie the textures are purple or black) I went to the Skyrim Sewers Nexus page to see if there was a cause however I couldn't really find any information other than to install the ESM version, which I did and this fixed the problem.

 

Now however I have a conflict marked up by ModOrganiser that says that REGPatch - Cities.esp is missing the Skyrim Sewers.esp (as this has to be deactivated if installed the ESM).

 

Now will this cause me issues down the line or can i safely ignore it and/or is there a way to fix this issue?

[Nearox]

Did you install the Skyrim Sewers 411 Main File following the REGS instructions? If so, the necessary meshes and textures should be in your install list in MO (but not the .esp).

 

You cannot ignore the REG Patch - Cities if you use Skyrim Sewers. It has loads of important navmesh (and other) fixes which will otherwise break your game at some point.

Edited March 12, 2014 by Nearox

[CJ2311]

Now that's a weird occurrence...

 

Since the esm is working for you, I'd suggest deleting the old "SkyrimSewers.esp", and renaming the newly downloaded "SkyrimSewers.esm" to "SkyrimSewers.esp"

That way it'll still be considered as a .esm file by the game, but "REGS Patch - Cities.esp" will be able to read it as well.

[oldmcgroin]

Did you install the Skyrim Sewers 411 Main File following the REGS instructions? If so, the necessary meshes and textures should be in your install list in MO (but not the .esp).You cannot ignore the REG Patch - Cities if you use Skyrim Sewers. It has loads of important navmesh (and other) fixes which will otherwise break your game at some point.

Hi Nearox,

 

Yes I followed the REGs instructions (deleted the bsl, ini and readme) and I have the meshes and textures and the esp file in the folder. I ticked the esp in MO. Not sure what you mean about the esp not being in the install list...

 

 

Now that's a weird occurrence...

 

Since the esm is working for you, I'd suggest deleting the old "SkyrimSewers.esp", and renaming the newly downloaded "SkyrimSewers.esm" to "SkyrimSewers.esp"

That way it'll still be considered as a .esm file by the game, but "REGS Patch - Cities.esp" will be able to read it as well.

OK I will try this if it won't mess anything up!?

Edited March 12, 2014 by oldmcgroin

[Nearox]

Is it working for you now?

 

In either case, after all the testing we have done over the past few weeks, this has never been an issue for us. I still think there is something slightly off with your install... Well I hope CJ's suggestion worked out :)

[oldmcgroin]

Is it working for you now?In either case, after all the testing we have done over the past few weeks, this has never been an issue for us. I still think there is something slightly off with your install... Well I hope CJ's suggestion worked out :)

I renamed the esm and the confilcts went on ModOrganiser.... Not had a chance to check the sewers again yet but I'll hopefully do that tonight. It is a strange one! Fingers crossed everything stays intact! Apart from this little issue so far so good! Thanks for the help

[keithinhanoi]

CJ2311 / Nearox  -

 

I am considering adding REGS to my mod lineup for my new play through, and have been looking through all of your customized plugins versions of some of the mods, and the patch plugins.

 

This is really impressive stuff, and it's amazing how much thought you've put into putting all of these different elements together such that they seem contiguous and intended to work cooperatively.

 

My challenge is that I've got some mods in my lineup that are non-STEP, so I will have to do some extra conflict resolution. This is one of the reasons why I started a STEP thread to collect together a list of record / sub-record types that are merged at runtime and/or do not require conflict resolution in TES5Edit.

 

With that in mind, I'd like to ask if you could elaborate on this comment at the bottom of the REGS - SRLE Conflict Resolution Guide page:

 

"Children records do NOT need conflict resolution. I.E. all the records within a <Persistent> or <Temporary> subfolder of a Cell."

 

Firstly, do you mean both interior / exterior cell children records?

 

Then, I'm wondering about things such as Record Flags for <Persistent> / <Temporary> Cell children records - including flag such as PersistentReference Quest Item DisplaysInMainMenu, NavMeshGround NoRespawn, InitiallyDisabled, etc. -  wouldn't those need to be carried forward?

 

Another sub-record type that seems would be a good idea to forward in a <Persistent> /<Temporary> Cell children records is NAME - I've carried forward changes from No Snow Under the Roof in a few Cell children records, for example, to make sure NSUtR's snow pile models are used such as here:

 

 ETaC 0 Complete.esp Worldspace 0000003C <Tamriel> Block -1, 0 Sub-Block -2, 2 0000937C <MorthalExterior05> Temporary 00077E2E

 

Also, I see mods which change this record, such as Neo's Skyrim Coin Replacer Redux, which can be reverted to vanilla by later-loading plugins.

 

A third one I see that would need conflict resolution is Data - Position/Rotation. So, here I see ELFX overriding placed object locations as set in SkyrimSewers, and it seems the Position/Location values should be carried forward from SkyrimSewers (so the object is in the right place.)

 

Then, on the other hand, there's sub-record types that seem don't need to be forwarded if later-loaded mods don't make any changes, such as VMAD. Also Navmesh records (NAVM) shouldn't be carried forward or combined to a patch in TES5Edit, right?

 

Any help would be appreciated here - basically I'm wondering what "rule of thumb" you use for deciding what doesn't need to be carried forward into a patch. 

 

TIA!

 

EDIT: I just realized you may only be referring only to subrecords that actually have Children in the record structure as presented in TES5Edit. So for example:

 

3DNPC.esp Worldspace 0001691D <WindhelmWorld> Block 1, 0 Sub-Block 4, 1 Children Temporary 0004B66C

 

and you're not talking about records such as this one:

 

3DNPC.esp  Worldspace 0001CDD3 <LabyrinthianWorld> Block -1, 0 Sub-Block -1, 1 0001CF11 <ValkyggOrigin> Temporary 0001D791

 

Is that right?

Edited March 13, 2014 by keithinhanoi

[CJ2311]

@keithinhanoi:

 

That note about children records actually only applies to mods that change locations in the game (both interiors and exteriors), it was something that I told Nearox to take into account when writing the conflict resolution page, and should really not be written as a comment there, nor does it apply to any other type of mod.

 

Sorry about the confusion it caused, I'll delete it asap.

 

A good example of why I made that comment would actually be NSUtR which you mentionned:

Both regular ETaC and the replacer in REGS change some buildings from having 1 story to 2 stories, which basically translates ingame as using a different model for the exterior of the house, so if you forward the model that NSUtR uses for that house, you'll end up with a one story building on the outside.

 

Take this record for instance: Worldspace 0000003C Block -1, 0 Sub-Block -2, 2 0000937C Temporary 00077E2E

NSUtR changes the base (model) to a snowy one, whereas ETaC completely disables it and puts another house in its place. Which basically means those 2 mods aren't compatible and will need a proper patch made in the CK.

[Nearox]

Sorry about that confusion abotu children records :)As for the following:

Then, on the other hand, there's sub-record types that seem don't need to be forwarded if later-loaded mods don't make any changes, such as VMAD. Also Navmesh records (NAVM) shouldn't be carried forward or combined to a patch in TES5Edit, right?

I never specicially forwarded, or intended to forward, VMAD if it is the case as you describe. There should also be another type of record which needed to be the conflcit winner. I say should because I might have made a mistake, or two :). If you can put me to a specific FORMID I will check it out.As for Navmesh, it is my understanding from CJ that navmesh should generally not be touched in TES5edit but only in the CK. You shouldn't need to worry about it if you use REGS (or SRLE + REGS) because all the navmeshes have been manually fixed/redone by CJ in the CK and have been tested by the both of us.I should have made a note that the SRLE Conflict Resolution isn't completely finished yet. I've been wanting to wait until the updates from Neo to SRLE's CR part slow down. It could also use a bit more revision, so thanks for your input :)

[keithinhanoi]

@CJ2311:  Thanks for that explanation. From what you're saying I think the situation is that in interior / exterior <Persistent> / <Temporary> Cell records, it's important to know what the changes to each sub-record do when deciding to pull changes forward for earlier-loaded plugins (ie., conflict resolution).

 

With the example of that NAME sub-record change made by No Snow Under the Roof and then ETaC, I would not know about ETaC's change from a one-story to two-story building by just looking in TES5Edit. So yes, I see how that becomes a need to fix in CK if you want NSUtR's snow on top of the new building placed by ETaC.

 

Sorry about that confusion abotu children records :)

As for the following:


I never specicially forwarded, or intended to forward, VMAD if it is the case as you describe. There should also be another type of record which needed to be the conflcit winner. I say should because I might have made a mistake, or two :). If you can put me to a specific FORMID I will check it out.

As for Navmesh, it is my understanding from CJ that navmesh should generally not be touched in TES5edit but only in the CK. You shouldn't need to worry about it if you use REGS (or SRLE + REGS) because all the navmeshes have been manually fixed/redone by CJ in the CK and have been tested by the both of us.

I should have made a note that the SRLE Conflict Resolution isn't completely finished yet. I've been wanting to wait until the updates from Neo to SRLE's CR part slow down. It could also use a bit more revision, so thanks for your input :)

 

No worries Nearox - but I should also apologize, because in my post I didn't make it clear that I was giving general examples. 

 

I actually haven't found any problems in your awesome custom-built REGS plugins and patches. I really just want to know what kinds of records / sub-records you generally don't pull forward in TES5Edit, and VMAD seems to be one of them, from what you're saying.

 

I do understand that the NavMesh edits had to be done in CK, but I'm also worried about some mods in my personal lineup that also have NavMesh (NAVM) record changes in them that are also found in REGS.

 

One mod I'm using that has NavMash edits that "conflict" with the REGS plugins is Arthmoor's Alternate Start - Live Another Life.

 

Since I'm using Interesting NPCs, I've changed the load order rule in BUM for REG - Cities.esp and REG Patch - Cities.esp to come at the bottom of the Companions Load Early section of the Masterlist (side-note: I think you should add that load order information for Interesting NPCs users directly to the wiki page of the REGS Pack Guide.)

 

However, since Live Another Life still comes later in the load order, it overrides some of the REGS custom NavMesh records. So what should I do there? Also, from your experience in general, does the last-loaded mod with NAVM changes override all of the earlier loaded mods, or are they merged in some way when Skyrim runs?

 

Thanks again for all the help, and also for the amazing work you've both done here!

[Nearox]

We looked at LAL in the beginning of the pack development and it only had an inconsequential conflict with ETaC (Dawnstar) as far as I remember. Since we cut out all the non-vanilla- matching stuff from ETaC (in morthal, dawnstar and falkreath) there shouldn't be any issue running LAL at all. Pretty sure we can add LAL to the list of confirmed compatible mods. I know 100% sure that the Unbound quest works, as it is essentially the same in all starts. SRLE (which includes LAL) so far works flawless with REGS in all my testing. Each time I started a new char with LAL (like 2x a day last month) to test out some stuff (not a fan of coc anymore) I tried to chose a different start and haven't had an issue with it yet. But CJ can give a definite answer as he (probably) knows how LAL looks in the CK :P

 

As for 3DNPC.esp, I believe BOSS (quite erroneously) sorts that to near the top of the load order. I haven't used it myself for quite a while but I know that REGS has been made inherently compatible with it so the load order shouldn't matter. I am not that knowledgabel on this topic though.

Edited March 14, 2014 by Nearox