Mator

Merging will not carry bash tags over, but you can apply Wrye Bash to a merged plugin just as you can to any other plugin. Just edit the description and add the bash tags. I'd add them at the beginning so they don't get truncated by the CK, should you choose to load the plugin in the CK.

See, the nature of this issue is it comes not from the files you merge, but from the files you don't merge. (sometimes from the ones you merge as well, if they reference themselves with GetFormFromFile... *shivers*). But anywho, because of this your only course of action is to know which mods use this and what mods they use it with. Essentially, if any mod brags about being explicitly compatible (offering features/changes) with another mod without requiring it as a master or using patch files which require it as a master, you're dealing with GetFormFromFile. I already know the only way it can be done, it just sucks ass and I really don't want to do it.

Critical issue with build 2.0.1.30. If you updated to it, you should still be able to update to 2.0.1.33. If not, you can try creating a text document called changelog.txt in your merge plugins folder, which should stop the access violation and resume normal functionality. I also updated the download in the OP to 2.0.1.33.

Yes. Critical bug. Fixed just now. GitHub Issue.

One of many reasons to not like LOOT. #iHateLOOT

Yeah, I might have to poke them a bit. Documentation has stuff on it, I think (EDIT: Yes). So does the OP. That suggests your load order isn't sorted so the plugins you want to merge are contiguous, which is bad. Don't use LOOT.

I will be making a video at the time of full release. There's no point in making a video for a beta when the final version may have a lot of features that aren't/weren't present in the beta, because then I'd have to make a video again. My time is very limited. If someone else wants to make a video, they are of course free to (please, convince Gopher or someone to make a video, that would get Merge Plugins so much more exposure). Integrations tab: You only need the BSAOpt integration if you're using the "Build merged BSA" option. You only need the decompiler, compiler, papyrus flags paths if you're using the "Handle Script Fragments" option. Search box: There might be a search box, not yet certain of that. There will definitely be type-based searching/jumping through plugins and merges, like there is with the windows filesystem.

Ok, yeah. I haven't updated the xEdit lib used by MP for awhile, because I didn't know there were updates to definitions (not paying attention). Easy to drop them in though. Next build will have these fixes, which may fix the issue you have, Neovalen. EDIT: Here is a build for you to try, Neovalen.

It's using xEdit definitions which determine all the logic of copying records. So in terms of the plugin produced from merging it'll be pretty much exactly the same as with the merge plugins script. Just done faster. BSAOpt is only necessary for the Build merged BSA option. I personally won't be using that option, but it was highly requested so I made it anyways. Chapollion is indeed only required for script fragments.

Nice avatar by the way. DeviantArt has good stuff. :3 Since 05/23/2015.

Haha, not quite.

Merge Plugins Standalone has been publicly released To get the latest version (v2.1.1) you'll have to download from Nexus Mods. I'll be pushing the new version onto the backend in a few days (I just want to encourage people to download from the Nexus so they can endorse it). This thread is now effectively closed. Thanks, - Mator

This is, in fact, the intent. :)

The timeline I gave? No, not irony. That schedule is moderately realistic, albeit probably optimistic. Sticking dates on things tends to be a bad idea, especially with me. But... I'm going to do my best to get things done in about that speed. It might not turn out quite like that. I hope if anything, I get ahead of schedule. :)

Well, I initially listed them as ranges in weeks (e.g. 2-3 weeks from now), but I decided that was too confusing to read. I was adding dates, and then I removed the week ranges, and then it seemed all specific. Certainly take all these dates with a grain of salt. I can barely predict what I'm going to be doing tomorrow, let alone next week. :P

No question is stupid! :) I'm nowhere near as good as people make me out to be. I just work really hard and pretty much never play the game itself. (which seems fairly common in modding) :P Yeah, it's not really there yet for "one-click and done" to be a valid procedure to follow. You could do it, but it might not resolve things the way you want it to. It's a beta project for a reason. ;) I'd recommend experimenting with it, but not using it on a full large load order with a single button click like Wrye Bash. It's not quite polished enough for that yet. Sounds fine by me. Again, results may vary, it's beta. ;) In terms of merging plugins, I'd recommend using my Merge Plugins script (or Merge Plugins Standalone, which is in alpha) for that. Smash may eliminate unnecessary plugins at some point in time in the near future, but it doesn't do that yet. If stability and reliability are your top priorities, I wouldn't recommend using smash in its current state. Just be a bit patient, it'll be in standalone application form before you know it! :) You want a rough estimate? Ok, I'll give you a very rough timeline of some events: Merge Plugins Standalone Public Beta - September 22 MXPF Release - October 2 Merge Plugins Standalone Release - October 9 mteFunctions refactor - October 9 Mator Smash Standalone Alpha - October 16 Mator Smash Standalone Public Beta - November 6 FO4Edit Work Begins - November 10 Mator Smash Standalone Release - November 20

Depends on who you talk to. I think it's fine, but hishutup thinks it's a bad idea because you'll get records patching that you don't want to be patching. Smash is blind - if it sees a conflict in a record/subrecord that is not excluded, it will resolve it. Unnecessary and harmful because the TES5Merged Patch makes mistakes that smash doesn't. Same with a bashed patch. You should use smash as you'd use a Bashed patch, so replacing the bashed patch. You should use neither a Bashed patch nor a TES5Edit Merged patch. Yes. Treat a smashed patch the same way you'd treat a bashed patch. No, it doesn't matter at all. The script recognizes the Mator Smash ESP by its author field, so the filename is irrelevant. Development of Smash has been put on hold until a standalone application for it can be made. The speed of development when using smash as a script (interpretted code) was too slow to iterate effectively, so I decided to drop it until I had completed Merge Plugins Standalone so I could then make a standalone application for it similar to Merge Plugins Standalone. Mator Smash Standalone will be up to 360x as fast as the script (based on benchmark comparison of a similar recursive traversal method for GetChildRecords). If it ends up being as fast as I expect, it should complete in around 10 seconds regardless of the size of your load order. The script can be used for certain things, and you can talk to hishutup to get his thoughts on this. He uses STEP as well, so he should be able to provide you with some very relevant thoughts and advice on using smash with your load order.

"if he is going to immediately upload it or upload it immediately" there's a difference between immediately uploading and uploading immediately? Is one more immediate than the other? XD

Yeah, I realized as much. I'll try to make a post there sometime soon. If the talk pages are really truly not intended to be used they should be disabled. MediaWiki does give administrators that power. You probably could even set up articles to have their talk pages redirect to their appropriate forum threads.

I brought up some discussion points in the talk section on the article. Please see: Guide talk:XEdit

No I don't think you did. I just get a little defensive about my ideas sometimes. Sometimes unnecessarily. This is true, but I think the entire community can acknowledge that making mods interface with each other is a pain. I don't think it would be resisted. Given some nice MCM-like documentation, some mods setting an example, and some good PR, it could be adopted reasonably quickly. The best thing about it? It doesn't make Game.GetFormFromFile not work, it just allows mod authors who use that to switch to a better method if they so wish. It would be a smooth, easy transition. I agree we should see if we can convince Arthmoor to implement this type of interface. I would not recommend using Quest.GetQuest unless it was with an interface quest. That's just another rabbit hole. Yes, I agree. I was talking about xEdit scripts. I don't really like Papyrus-based compatibility, to be honest, but I would find it more reasonable with the Interface Quest design pattern. My responses to your next two quotes are directed largely at the subject of general compatibility approaches and xEdit scripting. The gain in efficiency is most clear when you have a single script that applies to multiple mods/use cases. E.g. the Armor Mod Builder. I do acknowledge that not every mod is perfectly "automatable", because some do a lot of arbitrary things that can't be generalized upwards. That said, you can actually use some fairly simple and maintainable methods to generalize exceptions. Generally speaking, people are always capable of finding new or different ways of programming things that get better and more generic. There is a huge well of untapped potential here. Absolutely, it does work, but it could be better. My place in this community (I feel) is to build tools and standards that allow us to do what we're already doing, but do it faster, more efficiently, and better. Instead of the community spending hundreds of thousands of hours making tape-on-patches for a game collapsing under the weight of mods slapped on with glue and staples, we should renovate our approaches - the system of mod creation and application - so components don't conflict quite so often. The current approach to modding is a conflict nightmare. With more generic, automated approaches we will be able to do more with less. I'll make it then, should be easy. Well, we should start dialing this in then, get some proof of concepts going, and start building a nice presentation. In a way, this is like selling a product. Ultimately, I think the determining factor is going to be mod authors pressuring each other to follow this "better standard" we'll be making. In order to make this happen we'll have to make a really clear, clean presentation on how this new system will work and what its advantages are. If we can educate a few authors to be able to "sell" this idea to other authors, everything else will fall into place. The first step is always the hardest. Let's do it. Well at least it's not quite as bad as you thought, but I still will acknowledge your point here. I think before we contact anyone we need to make a proof of concept. We need to quantify to ourselves how much is possible and how it's going to work. Once we've done that we can approach other authors with what we've found and a clear concise "sales pitch", so to say.

Preface: This post may seem somewhat defensive. I fully respect krypt and I am in fact currently working on updating some scripts for her. However, I feel very strongly about my position in these matters. All of my energy and words below are directed not at krypt as a person, but at the subject at hand. I haven't looked at it either, I've only heard about it second hand. Oh, I know that an "ideal" framework is not achievable. I said as much in my OP. It would be great if the community could follow a specific format, and I honestly don't think any of this discussion is worth discussing if we don't consider the community capable of following a standard. Examples of standards the community follows: - Mod Configuration Menus - Separation of mods that do different things (not one mod that does a bunch of random things) - Numerous implicit standards from the Bethesda files - others..? I'm not super well-versed in this area, to be honest These examples (most notably the MCM example) show exactly how capable our community is at establishing and following standards. I think it is overly pessimistic to assume we wouldn't be capable of defining a new standard and documenting it sufficiently to get mod authors to buy into it. Heck, just getting a few top mods/modders to follow it would set enough of an example for the entire community to follow suit. There are certainly people who don't follow standards, but there always will be and that's not our problem. There is a HUGE difference between using Quest.GetQuest with a quest that exists for the intention of serving as an interface for other mods to tie into and using Game.GetFormFromFile or Game.GetFileByName to grab arbitrary information from arbitrary mods. In one hand the mod you're interfacing with with a component made for you to tie into, while in the other you're relying on arbitrary "random" things like filenames and FormIDs. Yes, an interface quest could be named anything (like a file), but an interface quest has multiple advantages: - You can store any number of arbitrary variables (aliases) in it which can be accessed by other modders to verify the quest is what you want, and not something else - It won't be broken by a formID renumbering, which is how things should be because FormIDs are arbitrary - It won't be broken by merging or files being renamed, which is how things should be because filenames are arbitrary and everyone merges files these days - It is extremely easy to re-implement/carry over between files (unlike filenames and FormIDs) Overall, the interface quest design pattern creates a massive increase in reliability for cross-mod compatibility when compared to the current method of using Game.GetFormFromFile or Get.GetFileByName. Agreements can always be broken. The question is how robust/reliable the agreement is. How easy is it for someone to break it, and how often is it actually broken? The current agreement (using Game.GetFormFromFile) is broken all the time. It is ridiculously delicate and anyone who has to deal with authors who use it can't help but scream (internally) "WHY DID THEY DO THIS?!". I know this because I've had people tell me how frustrating it is (not to mention the pressure that is puts on me to resolve it in Merge Plugins, which requires an insanely more complex solution than people just using a better design pattern). I feel I have the right, as a person who is burdened by this issue, to say that it really needs to change. Assumptions are the problem. With Quest.GetQuest used with an interface quest there is no assumption because all parties involved have taken actions to achieve the same goal. There is no room for misunderstanding, because everyone has taken steps with clear intention to achieve the same goal. This is not the case with Game.GetFormFromFile. In addition, Quest.GetQuest is extremely scalable and easy to change. Currently, if you want to access a record in a papyrus script from another file without requiring that file as a master (a silent dependency) you access that record by using Game.GetFormFromFile. Alternative to this, you could use Quest.GetQuest to get a quest which can then have an alias to the FormID you want to access. This way when the source mod gets updated your code doesn't have to change, because the alias on the quest gets updated. What we're looking for is to create a system where the least amount of work is necessary to make changes. I should be able to go into an ESP file and make some changes without creating hours upon hours of work for other mod authors who rely on that ESP file through some arbitrary inflexible system like Game.GetFormFromFile. No, script "breaks" are FAR easier to fix. You change a few lines of code and everyone re-runs the script, and everything is fixed for everyone. If we're talking about patching hundreds of files, which is easier: - Editing hundreds of ESP files - Editing a few lines of code in a script ? You tell me! As I said before, everything relies on assumptions, the question is how robust and reliable the assumptions are. Really good scripts, however, don't have to make many assumptions at all, and the ones they do make are extremely reliable. Sometimes it is not the script's job to handle more variations of input, but mod author's jobs to make mods that fit with established standards. You can automate exceptions. You can make automated solutions that are extremely robust. It certainly takes some time, but it takes FAR less time than making ESPs by hand. How many mods does FMO work with? Every one which follows some basic assumptions about armor/weapon filenames. Here, an example: How many ESPs patches worth of edits can FMO produce today? Thousands. How long would it take me to produce all of those ESPs by hand? Thousands of hours. How much time have I spent on FMO? A hundred hours Is this worth it? - 10-factor increase in efficiency, at least - Don't have to worry about changes/new mods, they work instantly - Don't have to have users manage hundreds of patches - Don't have to bloat load orders So, yeah, automation is superior, and always will be. I don't know what kind of point you were trying to make here. The present (and future) of the world economy (let alone Skyrim modding) is centered around automation. Non-automated methods cannot compete with automated ones. I addressed this earlier. This is extremely pessimistic. I strongly disagree with this paragraph and find it insulting. I have defined the standard of merging plugins. I have helped define the standard of xEdit scripts. I have built dozens of automated solutions that operate on standards. YES, standards are not "immutable", but that doesn't mean we can't operate on them. A world without standards is chaos. "Including support for the DLCs" is far too big to be classified as an update. It changes the masters of the file. That alone is enough reason to change the filename. The number of added records exceeds 1,000. The scope of intent of the file has increased from "fix bugs in Skyrim.esm and Update.esm" to "fix bugs in Skyrim.esm, Update.esm, Dawnguard.esm, HearthFires.esm, and Dragonborn.esm". In terms of logical scope, that's more than doubling. And, once again, the unofficial patch team can name their files whatever they want. No one has any right to tell them otherwise, and it is absurd to think that anyone should. Filenames are not made with the intention of "creating an interface". "Metadata, masters" shouldn't be necessary. When I look at my load order (a text document) I don't want to see a file and have to ask myself "is that this version of this file or this other COMPLETELY DIFFERENT version"? If they were to use the same filename I would have to forever call into question the existence of "Unofficial Skyrim Patch.esp" in every load order I ever saw ever again (and considering how popular these patches are, that's just about every load order). I don't want that. The UP team doesn't want that. If people don't like the new filename they can just continue using the old files (which will no longer be kept up-to-date). "forced to use USKP as a master because of a single cookpot record that it adds". Uhhh... that doesn't make any sense. You are not forced to use a mod as a master unless you want to modify content from that mod or make use of content it adds. If you want to make a mod compatible with the USKP you make sure your changes in override records don't conflict with theirs, and that's it. The USKP doesn't add many "new object references" to the game, and if your mod does happen to conflict with one of those you need a compatibility patch, not a master dependency on your main mod. Assuming you use a compatibility patch, your new work is just to make a new compatibility patch for USLEEP, which makes sense because it's a new mod... What about mods that rely on one of the unofficial DLC patches? What do they do for users that start using USLEEP? There is no EASY solution for everyone when it comes to this change. Instead of increasing complexity by leaving the filename the same and having people pray that things still operate the same, the filename should be changed so there isn't this crazy increase in complexity. If the filename changes there's a clean break. Asking whether or not a mod works with USKP/USLEEP is as simple as looking at the masters. You don't retroactively force all mod authors to have made their mod mastered to USLEEP, which is a massive complexity increase for them and their users. You're operating under the assumption that FormIDs won't change, that USLEEP and USKP will be close to being equivalent... but let's face the facts, things rarely work out this well and there will be differences that will compound over time. And if USLEEP gets updated to a certain point past the USKP there may come a time where a master dependency to "Unofficial Skyrim Patch.esp" will work for USKP, but not for USLEEP, or vice versa. WHAT THEN?! Users will go absolutely insane. The forums will explode! The skies will rain fire!!!! IT WOULD BE MODDING APOCALYPSE! Seriously. Not changing the filename is an insanely BAD idea. And the UP team has the right to do whatever the flip they want, so we need to stop discussing this like we have any say in what they do (because we don't). Would you be happy if there was an easy two-click solution to change a mod's master from Unofficial Skyrim Patch.esp to USLEEP.esp? Because I can make that. Then mod users/authors will have the power to change that at any time, effectively providing us with the advantages of the filename staying the same while not creating the mess that would be associated with it staying the same. Being reliant on the DLCs is a reasonable point... if we had modders who didn't have all the DLCs. The whole reason this idea is being executed on is because the polls have shown that a majority have all DLCs and would prefer a single ESP file for the unofficial patches. Also, I can't help but continue wondering how many mods are actually master-dependent on the USKP. (or otherwise dependent on a file with any filename) I think it's a fun discussion too. Apologies if I get a bit defensive in my post. It's just how I do discussions like this.

I'd like to participate in this.

I think this is a nice development. I'm not sure how well I like the acronym (do I really sleep? I'm not sure). I hope that it will provide a degree of simplification for mod users and authors alike. In regards to renaming the file- I think it makes sense to rename the file because it is a different file and using the same name would lead to massive amounts of confusion regardless of how many notifications were created. Heck, even I would be confused in certain cases. A new, unique filename is the most natural and most logical choice when you're making a new file. Compatibility issues are fixable. It is also not really the STEP team's responsibility to work with those. Here, a rant for our troubles about dependencies- Master dependency: The only reason you should ever have a master dependency on a mod is if you specifically require the content of that mod or specifically build off of it. If a user were to do that with the Unofficial patches, it only makes sense that they make an updated version of their work for USLEEP, because it is in many ways a different beast from the separated Unofficial Patches. The value a single plugin offers is great enough to make this worthwhile. Also, how many mods out there actually require the USKP as a master? It really shouldn't be all that many. Script (implicit) dependencies: The issue with this is it is a bad design pattern. I work in Software Engineering, and the entire nature of how these dependencies work brings a bad taste to my mouth. The number of assumptions made and the means by which these files are interfacing with each other is extremely unpleasant to me. This is largely based on the idea of a good application programming interface (API). I'll elaborate. When a modder uses a Game.GetFormFromFile call, they are attempting to bring compatibility between their unit and another unit which makes similar or conflicting changes without requiring a compatibility patch. The reasoning is that compatibility patches create load order bloat and can be difficult to maintain (which is a whole other discussion which I'll get to later). Anywho, the compatibility that the author is trying to create is directed not at the filename, but at the changes a particular file with that name makes. Thus, this is based on the assumption that a file with SomeModFileName.esp makes changes XYZ. This might not be the case. That mod could be updated, or a new mod could come around with the same filename (unlikely but possible), or mods could be merged, or... the list goes on. The point I'm making here is there is modders are trying to interface with other mods when no interface exists, and are thus relying on completely unreliable methods to "hack" an interface together. It is extremely delicate because it relies not just on file names, but on FormIDs and an unspoken, unagreed contract between mods that could be broken at any time. A good interface provides an explicit contract. The nature of what is provided and how it is provided is made clear from the get go. Sometimes the promise of what is provided isn't fulfilled, but in that case it is extremely clear whose responsibility it is to resolve. Either the creator of the interface changes their interface to fulfill their promises, or they change their promises to better describe what the interface provides. Now, I don't have a perfect solution for setting up such an explicit interface. I also don't think it is possible to make a perfect solution due to how mods function. However, I can tell you more or less how such an interface could work. Mod Alpha makes some changes to the game. It wants to provide other mod authors with a means to interface with the changes it makes. The first step of this is to allow mods to cleanly detect its presence in a way that is explicit, rather than implicit. I look towards the work around MCMs for inspiration on this. MCMs are implemented as a script linked to a Quest. SKSE offers a Quest.GetQuest() method. If Mod Alpha sets up a quest with an EditorID that is unique and fixed, any other mod can get that quest using Quest.GetQuest(). So Mod Alpha would make a quest with the Editor ID "ModAlpha-Interface". Then, using aliases and stages, Mod Alpha can make an interface which has various important information available. E.g. Alias CurrentVersion = "1.0.0", Alias bSomeBoolean = "true", or whatever. Mod Beta then wants to make some compatibility features if Mod Alpha is in the user's load order. It uses Quest.GetQuest("ModAlpha-Interface"), reads the aliases to make sure things are as expected (raising warnings if things aren't as expected), and then proceeds or terminates the activation of compatibility features. This does mean that in order to interface with mods, the author of that mod will have to make such an interface quest, but that's how it should be. Compatibility: Ultimately, the underlying issue here is just that multiple mods don't necessarily work together. This is because of the nature in which changes are implemented ingame. Most of the time, the intention of most changes isn't how they are actually implemented. E.g. In the case of an overhaul that changes the value and weight of every vanilla armor, the goal of the overhaul isn't just to change vanilla armors, it is to change all armors to reflect a new standard or base idea. The issue is the implementation (as an ESP that makes changes to specific armors) is unchanging. It doesn't actually LOOK at the armors that are present in the user's game, it just hardcodes its intentions on top of the armors that already exist. Herein lies the problem. The majority of mods execute their intentions in a non-extendable fashion, thus requiring the creation of compatibility patches, or papyrus links, or what have you. The solution? Well, something automated that iterates through items is what we need. That could be a papyrus script (which is pretty inefficient usually), or it could be an external "patching" script (e.g. xEdit script). The issue is xEdit scripting is still greek to most people and there aren't quite enough resources yet to make it accessible to everyone (as evidenced by people not using xEdit scripting more). I'm hoping to change this with some of projects, but I'm only one guy. There's only so much I can do with my free time. But ignoring the fact that mods have a severe disjoint between their intentions and their implementation, there's still the fact that, without automated compatibility patch creation, the standard in the community has become an unmaintainable cycle of "make new stuff", "make compatibility plugins/features so stuff works together", "make new stuff", etc. ad nauseum. So a whole bunch of the community's time is being wasted just trying to keep things up and running. Anywho, that's about all I have to say. Carry on. -Mator

Also, you can edit your posts. So instead of posting 4 posts in a row with one line of text, click the EDIT button on the post you just made and add your new line of text to your existing post. It's generally considered bad forum etiquette to double/triple/quadruple post save in some very specific circumstances. EDIT: