Mator

I don't think it has anything to do with script fragments. If the merge is really Green, then you may be having some kind of bug. Can you contact me on Steam so I can help you work through this? My steam is matortheeternal. I have a planned feature that will make every color in the application customizable by users from an INI file. I'll then provide optional downloads for people with different types of color blindness.

Well, if the merges are green, it must be because the Background Loader isn't finished yet. (that's my guess, anyways). If you hover your mouse over the build merges button it'll tell you why it's disabled.

Documentation section Limitations -> Doesn't Do Conflict Resolution. I think you mean "greyed" out, but ok. Buttons are "greyed" out when they are disabled. The build merges QuickBar button is only enabled if there are merges that can be built. If you go to the Merges Tab you can see all of your merges. If a merge is green it means it is ready to be built or rebuilt. Any merge that is not green is not ready to be built or rebuilt. The color corresponds to the Merge's status, which you can find information on in the documentation. You can read the status by selecting the merge and looking at the first field in the Merge Details (it's called Status). You can get guided instructions to making the merge available to build/rebuild by right-clicking it, going to plugins, and choosing "Resolve Issues".

Yeah, that is not crowd sourced, lol. That is "developer"-sourced.

Awesome, thank you. :) I believe there is indeed a few that I missed, some even from Oblivion. I never used Bash tags before, so my understanding of how to carry things forward to Skyrim may not have been perfect. But, as you yourself has said, it's really easy to make smash settings! :D The window isn't quite complete, but it appears whenever there are conflicts between the settings you're combining. The dropdowns gives you N + 1 options per each record type. The "merge" option will have Smash combine the conflicting settings as best it can. The other options tell smash to use one or another setting for that record. If you click on the panel the drop-down box is in and have an option other than merge selected, the tree on the right will populate with what the current active setting for that record will look like. You can select multiple record panels to populate the tree further. I don't yet have tree previewing for the merge option figured out yet, but it'll come soon. :) Overall, I don't really like the look and feel of the window that much right now, but it's OK. At the very least it does serve a purpose (reminding you of what the smash settings look like and giving you an idea of what the result of combining the settings will be).

I know that LOOT provides bash tags, but I'm 99% certain those aren't crowd-sourced, do you know what crowd-sourced means? It means that anyone can, with minimal effort, make a contribution. LOOT doesn't have the architecture for this, and if it did there wouldn't be one set of tags per plugin, there'd be different people saying different things. Smash's dictionary will allow different people to say different things and will allow for far greater flexibility. I don't really feel the need to argue this more because I already gave a clear justification as to why my approach will be better than what's currently offered through LOOT. I don't like integrating with existing software solutions when I know I can do better with minimal effort. A backend for the purpose of providing a dictionary of smash setting recommendations (or tags, w/e), has been planned since day 1 of work on the standalone. I'm not going to change my plans. Everyone will be equal, but authors can of course actually tag their files themselves, so there's no issue there. That was an accident (including the zip in the zip). I made and uploaded this ZIP file before the v0.2 release. I wasn't necessarily planning to do a new release, but decided I should after uploading the tags. Those bash tag smash settings are identical to the ones in v0.2.

That doesn't sound right to me. It's mostly functional, the features that remain are all just extras that improve user experience. Functionally, Smash is basically complete, asides from a few algorithm fixes. https://github.com/matortheeternal/smash/issues If you look at what's here there's almost nothing about Smash Settings or the Algorithm, the two core functionalities of the program. If you're having problems you should say something because assuming it's barely functional is incorrect. If you're finding bugs I want to track them so I can fix them! File header*. Smash doesn't access the LOOT masterlist, and most likely never will. I'm not a big fan of LOOT. Smash will, however, have its own dictionary that it will access for the same purpose. The main difference being smash's dictionary will be crowdsourced and will allow the recommendation of arbitrary smash settings. I could make a smash setting specifically for a plugin X, and then submit it to the Smash Backend, and then make a recommendation that users use that setting with plugin X. You might also be interested in this: https://github.com/matortheeternal/smash/issues/86 It's been that way for awhile. There are a fair number of people who have been using Smash to reduce manual repetitive TES5Edit patching work by 95%-99%. The main difference between now and then is you can just use Bash tags, which are familiar.

v0.2 has been released. You can get it on GitHub: https://github.com/matortheeternal/smash/releases

EssArrBe: No, no readme. This is an alpha, after all. If you want to learn more you can read this and the other threads, and I can answer specific questions. GrantSP: Smash settings for Skyrim need to be in .\settings\Skyrim. If you want additional settings you're in luck, because I just built a smash setting for every bash tag that was present for Oblivion. It took me a couple of hours, don't know why I didn't do this sooner. Bash Tag Smash Settings Unfortunately, automatic tagging for these settings won't work unless you rename all of them to remove the "Bash." prefix. I put this prefix there because I'm going to be changing the tag detection feature to specifically detect bash tags and expect them to have Bash. at the beginning of their name. This will allow me to change the way smash settings are displayed later down the road. Hishutup: "Barely functional"? I mean, sure, I haven't completed all of the planned features, but this seems borderline insulting. What the **** are you talking about?

Alright, I'll add that to my list of todos. Todo item #46: Make a spatial conflict detector. (woot sauce)

YouTube Video Nexus Mods Page Reddit Post GitHub WHAT IS MXPF? MXPF is an API that wraps around xEdit's user script functionality. MXPF offers users a set of useful functions which make creating patches far easier and more approachable. In a few lines of code you can copy every record fulfilling certain conditions to a patch file, and then edit those record values. MXPF is simple, robust, and highly efficient: making xEdit scripting easier to learn and leverage. An alternative solution to SkyProc, MXPF is the first of several projects that I will be undertaking to bring the power and flexibility of xEdit scripting to the masses. GETTING STARTED Getting started with MXPF is easy. Start by taking a look at a few of the provided example scripts. These are heavily-commented scripts which will provide you with a foothold on how xEdit scripting works, and how MXPF augments your scripting experience. Also refer to the documentation, which will help you understand how MXPF operates. If you're unfamiliar with xEdit scripting, object oriented pascal, or programming in general there are a wide variety of resources you can check out. xEdit scripting is a great place to start programming, it's where I started. Don't be afraid - the first step is always the hardest. I am willing to help anyone who wants to learn to make and leverage xEdit scripts, regardless of your use case. As more people learn to make xEdit scripts there will be ever more people who can help. If you need help getting started or resolving an issue, just let me know, and I'll be there. Feel free to ask for support in the comments section, by forum PM, on r/xEdit, r/SkyrimMods, the #skyrimmods IRC, and the xEdit HipChat. RESOURCES There are a growing number of resources available for learning xEdit scripting below is a list of publicly available resources that you can tap into when you need help. Google General pascal/delphi questions/issues can be resolved using publicly available documentation or past discussions on forums/stackoverflow. TES5Edit Scripting Functions This is a great reference for the functions available in xEdit scripting. TES5Edit on GitHub You can also look at xEdit's source code, but I'd avoid that early on. Scripting files are wbScriptAdapter.pas and wbScriptAdapterMisc.pas THANKS Major thanks goes out to Zilav for developing xEdit scripting. None of this would be possible without him. Thanks also goes out to everyone who's a part of the xEdit scripting community. Let's change Bethesda game modding for the better.

Yes, what you're looking for is a multiply-indexed path. I plan on updating QC and QD to support multiply-index paths, but in the meantime I can give you a quick little script, I think. The script would use ElementsByMIP to get the list of elements whose values we need to change. So a script could be unit UserScript; uses mteFunctions; var sPath, sFind, sReplace: string; Records: TList; function Initialize: Integer; begin Records := TList.Create; sPath := InputBox('Path', 'Enter the path to the elements you want to change', 'Leveled List Entries\[*]\LVLO\Level'); sFind := InputBox('Find Value', 'Enter the value you want to find', '7'); sReplace := InputBox('Replace Value', 'Enter the value you want to replace found values with', '20'); end; function Process(e: IInterface): Integer; begin Records.Add(TObject(e)); end; function Finalize: Integer; var i, j: Integer; rec, element: IInterface; lst: TList; begin lst := TList.Create; for i := 0 to Pred(Records.Count) do begin rec := ObjectToElement(Records[i]); AddMessage('Processing record '+Name(rec)); ElementsByMIP(lst, rec, sPath); for j := 0 to Pred(lst.Count) do begin element := ObjectToElement(lst[j]); AddMessage(' Processing element '+IndexedPath(element)); if GetEditValue(element) = sFind then begin AddMessage(Format(' Replacing %s with %s', [sFind, sReplace])); SetEditValue(element, sReplace); end; end; lst.Clear; end; end; end. I'll test this code and edit the post if it works. EDIT: Fixed some errors. It works. To use this script you'll need to have the latest version of mteFunctions from GitHub. Right-click and choose save link as on this link: mteFunctions.pas

I noticed that a bunch of the aforementioned conflicts from shurah are with markers and STAT object references. I could fairly easily make an xEdit script that could detect these kinds of conflicts, and optionally fix them. Would that be something that would be valuable to the community?

S'all guud. :} BTW, v0.1.1 is here. Huge update, lots of new stuff/fixed stuff. You can get it in the OP. EDIT: Also make sure you read the changelog! Smash no longer looks for settings in the same place, so you're going to have to move your settings to a new location to use them with v0.1.1!

Can you be more specific/provide screenshots/logs?

Not yet, but it is planned. Sounds great! :) You're welcome. I like what I do and I like to think I make a difference for people. Your gratitude is greatly appreciated. :)

Hi EpitomyOfShyness! I recognize you from the Merge Plugins thread on the Nexus, nice to see you stumbled across Smash. :) I know that using Smash right now is a lot of work, but my hope is that, with more development, that will change. I would love it if you would share the settings you make. It's really important to me that Smash is built on collaboration, so I want everyone's settings so I can see what people are doing and get a better of idea of what works and what doesn't work. Best Regards, -Mator

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 want to encourage people to download from the Nexus so they can endorse it).

Oh, I see. I must have missed that. So yes, there is more explanation necessary. Why merges should be built from the source plugins: The merge is less complicated, FormIDs are renumbered less, the merge is more cleanly managed, and there aren't any weird issues cropping up with overrides/conflicting assets. So one thing that people did with the script is they merged into an existing merged plugin or combined an existing merged plugin with a new plugin to make a new merge. Merging into an existing file introduces weird complexities with how overrides and conflicting assets are resolved which means the resulting ESP/merged mod is not the same as it would have been if you merged from the source ESPs. You might not get the right version of certain records and you may end up with the wrong copy of certain assets, and there is absolutely no way to properly combine the records/assets without the source plugins being loaded. Merging a merged plugin and another plugin into a new merge creates a two-stage merge. Viz., if a merge is included in a merge and both merges are managed by the Standalone application, the application would be building both of them in a single session if a plugin was updated. When a merge is performed the plugin produced is volatile until it has been saved and reloaded. Building a merge with a merged plugin that has just been built in the same session is dangerous because there are processes that occur when that plugin is saved. By forcing users to make all their merges from the source plugins, I avoid a lot of unnecessary complexity and can provide a greater guarantee for merge stability. Merging is already an extremely complicated process, so merging a merged plugin (or merging into a merged plugin) is the sort of thing that I don't ever want to support. If the xEdit API is altered so plugins can be cleanly DELOADED, then it would be more reasonable to suggest this, but until such a time you'll just have to build your merges from the source plugins every time. In the program's directory there should be a doc folder. In that doc folder should be a PDF of the documentation.

it's also italicized.

You haven't loaded the plugins that are part of that merge, so Merge Plugins can't rebuild it. As per PreventsAccidentalPickUp.esp Shown as Included You should read the documentation section on Merge Statuses. Also you shouldn't merge BlockStealRedux because it's been reported to not work in merges by two users with an average rating of 0.0 (as per Not in Merge). Furthermore, one of the users in hishutup and he points out the ESP has a dll and will not merge correctly because of that. (and he's a trusted source on these sorts of things). -Mator

You should definitely keep them. The way the tool works is it completely rebuilds a merge from the source mods. If you delete the source mods you will be unable to rebuild the merge. You can, however, delete the source mods and then make a new merge that includes the merged plugin, but it's bad practice. (and actually isn't possible the current public build, but will be possible when 2.1 is released here in the next few days). Right click the merge and click toggle rebuild status? Just a guess, it should have automatically set it to the "Ready to be Rebuilt" status, but if not you can do it manually with the aforementioned "Toggle Rebuild Status" option.

Just click the build button to rebuild the merge. :)

Yes, but if you ever need to rebuild that merge you'd have to re-download those mods (unless you kept the archives). Yes, so long as those ESPs don't have file-specific assets associated with them (unlikely for patches, but not impossible). An alternative approach could be to disable copy general assets when merging those ESPs. No, you can't do that. Merge plugins runs off of the xEdit framework which requires all master files to exist.

I'm going to be making a new topic there for a project that I just started up once me and my team have made some more progess on it. I know I'm not really making lots of new topics in there, but I feel pretty good about the topics that are currently there. Looking forward to seeing users use it more once Merge Plugins Standalone is released.