Jump to content

Lexy's: Legacy of The Dragonborn Special Edition


Recommended Posts

I'm finding that Ask Innkeepers to Show Room SE is not working in my game. I have the .bsa extracted and deleted, the .esp has been included in the Miscellaneous Merge, and the mod is unchecked in the left pane, but in-game innkeepers still just have just the vanilla dialogue. It was working back when I first installed it, at least some of the time, but now not at all. Anyone know why this might be happening?

Link to comment

Seems like this is something to consider when doing the pre-smashed patch (from Mator's description):

 

Q: How should I use Smash and Merge Plugins together?
A: Creating a smashed patch for just the plugins you're merging prior to merging (and including the patch in the merge) can make your merges "better", assuming the resulting smashed patch has any records in it.  Your full load order smashed patch must be regenerated whenever your load order changes, so you will want to get your merging out of the way prior to generating it.

 

It does sound like a good idea for all of our merges, actually. One could test for each merge and see if any records come in the partial smashed patch, and, if so, include it in the merge instructions.

 

For the pre-smash patch in particular, has anyone tested this? One thing that's been bugging the crap out of me is feeling that by using Merge Plugins standalone before running smash, we're crunching a lot of mods with the "rule of one" and thus not using smash to its full potential in resolving conflicts. I actually don't understand if we aren't losing what bit of conflict resolution Wrye Bash would have done with those mods, or if they're entirely irrelevant to the process. Seems like the easiest way to figure this is to do a test, following the pre-smashed patch instructions but running smash over the block of inactive plugins after we move them to the bottom, and see the smashed patch contains any records in it.

Link to comment

So I did the test above, with smash.all for only the pre-smashed patch plugins prior to merging. The smashed patch for only those plugins contains all of them as masters but only one record, the NPC Ancano. If I clean masters, the only master that's left is the main SRCEO plugin (which isn't in the redundant group). I checked the records and all Smash did was to pick the Conjure Frost Atronach spell from SRCEO instead of vanilla. In all other respects, it simply follows MLU - NPC Retexture Conflict Resolution.esp but it does get that spell from NPC Retexture - Conflict Resolution.esp.

 

I don't know what you guys make of this - for one, it seems like smash.all almost doesn't do any change, but that one little edit (which I don't know if it's relevant or not, it could have been included in MLU - NPC Retexture Conflict Resolution.esp if that were Lexy's intention) makes me wonder if this could become relevant depending on build and if it would matter in other merges as well.

Link to comment

Seems like this is something to consider when doing the pre-smashed patch (from Mator's description):

 

Q: How should I use Smash and Merge Plugins together?

A: Creating a smashed patch for just the plugins you're merging prior to merging (and including the patch in the merge) can make your merges "better", assuming the resulting smashed patch has any records in it.  Your full load order smashed patch must be regenerated whenever your load order changes, so you will want to get your merging out of the way prior to generating it.

 

It does sound like a good idea for all of our merges, actually. One could test for each merge and see if any records come in the partial smashed patch, and, if so, include it in the merge instructions.

 

For the pre-smash patch in particular, has anyone tested this? One thing that's been bugging the crap out of me is feeling that by using Merge Plugins standalone before running smash, we're crunching a lot of mods with the "rule of one" and thus not using smash to its full potential in resolving conflicts. I actually don't understand if we aren't losing what bit of conflict resolution Wrye Bash would have done with those mods, or if they're entirely irrelevant to the process. Seems like the easiest way to figure this is to do a test, following the pre-smashed patch instructions but running smash over the block of inactive plugins after we move them to the bottom, and see the smashed patch contains any records in it.

I sorry I don't understand what you are trying to get at the primary point of creating the "Pre Smash Patch" is to further reduce overall plugin count which takes it down around the 190 mark. Then using SMASH to do what Wrye Bash did and merge leveled list and a few more bit and bobs. If you have less the 255 plugins and feel you don't need to or don't want to create the Pre Smash Patch you don't have to and just Run SMASH.

Link to comment

I sorry I don't understand what you are trying to get at the primary point of creating the "Pre Smash Patch" is to further reduce overall plugin count which takes it down around the 190 mark. Then using SMASH to do what Wrye Bash did and merge leveled list and a few more bit and bobs. If you have less the 255 plugins and feel you don't need to or don't want to create the Pre Smash Patch you don't have to and just Run SMASH.

My point was this: are those mods completely redundant for Smash, or aren't they? If you merge them before running Smash, their records will be carried into the merge based on the "rule of one" by Merge Plugins Standalone. If there were any conflicts that Smash could have resolved in a more detailed manner, they're lost once you switch those plugins for the merge and run Smash on your build. So Mator's suggestion is that a "mini-Smashed patch" could be made for each merge (not just the pre-smashed patch merge, but all of the merges as long as they have conflicts within those mods that Smash can handle) and that resulting "mini-patch" would be merged with the rest (Mator's quote in my post above). This, of course would only be relevant if there are indeed conflicts withing that group of mods, that Smash could resolve better than just a simple "rule of one" merge. So I tested with the pre-smashed patch and got that one Ancano record, not very relevant maybe, but perhaps other merges would yield more impressive results. I'm thinking, for example, about the weapons and armor merge since I'm using DeserterX's Legendary Armors and its levelled lists conflict with pretty much every other armor mod.

 

 

Don't know if I got the idea through this time. I'm still trying to figure out how Smash works since I don't want to abandon my tried and tested Wrye Bash unless I know what I'm doing...

Link to comment

this will be folded into v1.11 of the main CR when it is released (There is a TESTING Version on the Discord Channel)

Since we're already doing a CR merge by the end of the guide, which is great because it makes it more modular for people who decide to do some part(s) of the guide differently, why not take that modular approach further and install all the relevant patches for this build individually, and merge them all in the end?

 

Just food for thought, this is probably not a priority and I'd really rather see if Omega makes it in or not. Still, it sounds like an idea...

Link to comment

My point was this: are those mods completely redundant for Smash, or aren't they? If you merge them before running Smash, their records will be carried into the merge based on the "rule of one" by Merge Plugins Standalone. If there were any conflicts that Smash could have resolved in a more detailed manner, they're lost once you switch those plugins for the merge and run Smash on your build. So Mator's suggestion is that a "mini-Smashed patch" could be made for each merge (not just the pre-smashed patch merge, but all of the merges as long as they have conflicts within those mods that Smash can handle) and that resulting "mini-patch" would be merged with the rest (Mator's quote in my post above). This, of course would only be relevant if there are indeed conflicts withing that group of mods, that Smash could resolve better than just a simple "rule of one" merge. So I tested with the pre-smashed patch and got that one Ancano record, not very relevant maybe, but perhaps other merges would yield more impressive results. I'm thinking, for example, about the weapons and armor merge since I'm using DeserterX's Legendary Armors and its levelled lists conflict with pretty much every other armor mod.

 

 

Don't know if I got the idea through this time. I'm still trying to figure out how Smash works since I don't want to abandon my tried and tested Wrye Bash unless I know what I'm doing...

     I kind of like this idea, of course its another extra step, but I do like it.

Link to comment

My point was this: are those mods completely redundant for Smash, or aren't they? If you merge them before running Smash, their records will be carried into the merge based on the "rule of one" by Merge Plugins Standalone. If there were any conflicts that Smash could have resolved in a more detailed manner, they're lost once you switch those plugins for the merge and run Smash on your build. So Mator's suggestion is that a "mini-Smashed patch" could be made for each merge (not just the pre-smashed patch merge, but all of the merges as long as they have conflicts within those mods that Smash can handle) and that resulting "mini-patch" would be merged with the rest (Mator's quote in my post above). This, of course would only be relevant if there are indeed conflicts withing that group of mods, that Smash could resolve better than just a simple "rule of one" merge. So I tested with the pre-smashed patch and got that one Ancano record, not very relevant maybe, but perhaps other merges would yield more impressive results. I'm thinking, for example, about the weapons and armor merge since I'm using DeserterX's Legendary Armors and its levelled lists conflict with pretty much every other armor mod.

 

 

Don't know if I got the idea through this time. I'm still trying to figure out how Smash works since I don't want to abandon my tried and tested Wrye Bash unless I know what I'm doing...

I so you are suggesting we create a smash Patch for each and every merge then add that to the merge? then at the end still create an uber Smash Patch? Interesting definitely something to consider and investigate.

Link to comment

He’s basically saying; create a mini CR for each merge, then include it in the merge. Probably generally a good practice, but only necessary if there are unresolved conflicts within a merge, which there really shouldn’t be - each merge should be inspected for conflicts prior to merging in the first place, and I’m doubting the expedience of actually running Smash every time. If there are unresolved conflicts in a merge I’d bet it would be easier to just make a patch as you inspect the plugins for each merge - you’re still going to have to inspect the smashed/merge patch before incorporating it anyway.

 

Unless you just want to blindly press a button and hope it does what you want.

Link to comment

He’s basically saying; create a mini CR for each merge, then include it in the merge. Probably generally a good practice, but only necessary if there are unresolved conflicts within a merge, which there really shouldn’t be - each merge should be inspected for conflicts prior to merging in the first place, and I’m doubting the expedience of actually running Smash every time. If there are unresolved conflicts in a merge I’d bet it would be easier to just make a patch as you inspect the plugins for each merge - you’re still going to have to inspect the smashed/merge patch before incorporating it anyway.

 

Unless you just want to blindly press a button and hope it does what you want.

I will investigate next week but most of the merges with conflicts such as the MLU Patches merge I provide a consistency patch (This in effect is a mini CR for that Merge) anyway.

Link to comment

I so you are suggesting we create a smash Patch for each and every merge then add that to the merge? then at the end still create an uber Smash Patch? Interesting definitely something to consider and investigate.

If it proves worthwhile, it would be a simple case of adding the smash bit in the merge page, for each merge where it proves relevant. Doesn't seem hard to text it in a simple way and it might even help to get people acquainted with smash before the big final push.

 

If there are unresolved conflicts in a merge I’d bet it would be easier to just make a patch as you inspect the plugins for each merge - you’re still going to have to inspect the smashed/merge patch before incorporating it anyway.

I'm with you there, part of what's keeping me from embracing Smash is that I trust the manual sEdit conflict resolution, not so sure about the automatic one. However, in some cases Smash may actually save you a lot of time. When I build my Weapons and Armor merge I inspect its mods for conflicts and there usually are, especially in the levelled lists which is something that supposedly both Smash and WB handle pretty well. Last time it took me about 30 minutes of painstakingly copying records around so that the levelled lists are merged -  and I'm not even sure I'm doing it right. I'd like to try and smash those to see what comes.

 

I don't expect game-breaking conflicts to show up in the mergers, or we'd have nailed them by now. Probably some consistency conflicts like the Ancano thing I found in the pre-smashed patch. If such conflicts do show up, smash might help Lexy from having to provide a consistency patch for each merge. Still, xEdit does feel like safer ground - at least until you inspect the smashed CR to see if it got the conflicts right.

Link to comment
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.