Mator

Thanks! I just updated it today. My goal with it was to not JUST make a plugin selection screen, but to make a smart plugin selection screen. I think I've done that fairly well, but we'll see what the users say.

Hi RafterMan, - You can load either the .dproj file or the .dpr, either one will work. - You can also use "compile project" or "run without debugging" or "run". All will produce an executable, the run options will actually run the executable, and debug will allow you to use breakpoints in the IDE. A shortcut for running the application in debug mode is pressing F9. - The backend folder has a secondary "backend" application, this is an application that I'm running on a server, and is what people who run Merge Plugins connect to in order to submit reports, get program updates, and get dictionary updates. It is a project that is completely separate from the frontend Merge Plugins project, but it shares some code with the frontend through the lib\mte folder. You won't be able to run the backend application without certain dependencies, however (mysql 5.6, a properly installed libmysql.dll file, and a properly configured database as per the setup script). - The project is set up so all required libraries are linked to the project file through relative paths ..\lib\. You don't need to install any libraries or packages, it should just compile! A lot of projects don't work like this, but I really like the simplicity of being able to clone + compile on any machine without additional setup. - Master is a branch that targets Delphi XE, merge-plugins-10 targets the latest IDE from Embarcadero, Delphi 10 Seattle (or more generically, Rad Studio 10 Seattle). If you're using Rad Studio 10, use the merge-plugins-10 branch, if you're using XE use the main branch. Other versions may work with either branch (I have not tested other verisons), but I think versions XE5->10 will compile with the merge-plugins-10 branch, and versions XE->XE4 will work with the main branch. Regards, -Mator

^You can also just disable dynamic plugins prior to running merge plugins. Next version will have plugin selection form and better plugin loading in general, so look out for that.

I know I'm a bit late responding here, but thanks z929669! :D

If there's a bug, please report it on the GitHub issues page so I can address it. You're not using the program correctly. You should NEVER move the plugins out of the mod folder they're installed in. That folder is the key to how merge plugins copies general assets, so if you want to use the copy general assets option to make a completely standalone "mod" in Mod Organizer, you absolutely have to leave those ESPs in their original folders. I don't really understand what your process for merging is. Mine is far simpler: 1. My mods in the left pane of MO are organized by category. (you can also sort by category in MO, if you don't have them in the by-category install order) 2. I select all of the mods I want to merge from a particular category by clicking on the top mod, holding shift, and clicking on the bottom mod. 3. I press SPACE to activate all of the mods. 4. The mods are already in a single solid block in my load order, so I start Merge Plugins, add them to a new merge, resolve any issues with the merge (you can ignore non-contiguous errors if you want), and then build it. 5. I select the block of mods in Mod Organizer and deactivate it. 6. I right-click -> All Mods -> Refresh Mod Organizer's mod list, and then activate the merged mod, which is the last item in the mods list. As you yourself have found, Merge Plugins Standalone has a massive number of advantages over the Merge Plugins Script. If you're having problems with it, you're probably doing something wrong, because it's pretty solid. That said, the next version will have a plugin selection form (already built) so you can choose not to load certain plugins into the application if you so wish. -Mator

Unless you want to submit reports, you do not have to login. You also don't have to login more than once. Once you've registered your account you should be set unless you reinstall windows/switch computers.

Awesome! Thanks!

Here's a video tutorial I made on Mator Smash. It's pretty long, but I cover a lot of stuff. Check it out!

No sub-forums, please. I don't think there will be enough use to warrant subforums. If the usage level gets high later on then we can make sub-forums. I will take responsibility for moving topics to the sub-forums if this ends up happening. But yeah, that sounds great! Thanks TechAngel! Maybe we can adjust that description and do this instead: Mator's Utilities Support Support for the utilities developed by Mator ( Merge Plugins, Mator Smash, AutomationTools ). Because mteFunctions isn't a utility, it's a library. Later on when I've released MXPF and the mteFunctions refactor we can use the description: Mator's Utilities Support Support for the utilities and libraries developed by Mator ( Merge Plugins, Mator Smash, AutomationTools, mteFunctions, MXPF ).

How about Mator's Utilities Support? I don't like just "Mator" because it feels like incorrect grammar.

Absolutely. I just think a top-level forum for all of my tools would be sufficient. It could be named any of the following: - Mator Utilities Support - Mator Tools Support - Mator's Support Forum - Mator's Support Section - Support for Mator's Utilities ... Or something else. I see it as being used in a few ways - for general discussion, support requests, and updates. Bascially the same as any other utility's subforum, just for everything that I make (because I make a lot of things). The description would list my major projects that the forum is intended to be about (so mteFunctions, Automation Tools, Merge Plugins, Mator Smash). Just having such a forum would encourage me and others to really break the 100+ post mega-topics up into different discussions, promoting discussion and growth overall. Also, it seems like there have been a few instances of users posting the Other Tools Support forum, so that will be properly directed to this new subforum, which is nice.

No, it not yet suitable for users in the way you describe. Your english was perfect. :)

^I think grant may have a point. :) Though I will take whatever windfall may come my way, of course.

Some bugs with v0.0.5.0, I'm fixing them now for a hotfix.

Mator Smash has been updated to v0.0.5.0. You can download the new version here. v0.0.5.0 - Added code so you can now toggle multiple nodes in the tree using the space bar. - Fixed Treat As Single Entity never being triggered because children nodes were always disabled and couldn't be toggle without removing the flag. - Fixed chain nodes linking nodes at different levels, which also led to access violations when trying to remove the links. - Failed smashed patch status now retains after smashing completes. - Smashing is now cancelable. - Now storing element definition type information in setting trees. NOTE: Elements in old setting trees will have the "Unknown" type. You'll need to rebuild your settings to get type information. - Made prune nodes option more user friendly and added an auto-prune option to the popup menu for fast and simple pruning. - Fixed bug with deleting a smash setting not removing it from disk. They now get sent to the recycle bin when deleted. - Fixed issue with processing records when they were set to not be processed in the setting (which created ITPOs). - Distinguishes between arrays better. Unsorted dtArray elements will now be treated as arrays, as intended. - Removes ITPOs after smashing.

Yep, gotta get stuff done.

New version is almost ready. I've resolved 11/14 issues so far: GitHub Issues

No, that just happened because you used a smash setting that only processed ARMO records. ;) Smash can conflict resolve any type of record. I'm planning on making a tutorial-of-sorts later today.

^that.

Awesomesauce!

Smash doesn't do that, and won't be able to do that. Smash will resolve conflicting overrides, and that is pretty much the absolute extent of what it will do. What you want absolutely requires specific patching "scripts". There's no reasonable way to generically predict changes from a specific set of records and apply them to all records given the massive range of changes that are possible and the complexity of them. Such a solution would have to involve machine learning and would not lead to positive outcomes 99% of the time.

bt4, I replied to you on the Nexus Mods thread. I'm fairly certain your issue is a detection issue (either wrong game path or wrong MO path), which can happen if you have multiple installations. I outlined some further steps you can take to help us identify what the issue is and resolve it.

Sure, I wouldn't mind! It'd be a nice umbrella subforum - I've kind of just been using the xEdit Support subforum for most of my needs, though it doesn't seem to quite fit with what I'm doing. The only thing I would be concerned about would be directing users to use it for things properly. So long as it's positioned above the "Other Modding Utilities Support" subforum and has a listing of what tools it's for (Merge Plugins, Mator Smash, etc.) it should be fine though. If STEP is up for this then I'm totally for it. Also, to expand on what I'm planning on doing tool-wise over the next half-year or so: Standalone Applications 1. Merge Plugins (currently in Beta, almost publicly released) 2. Mator Smash (currently in Alpha) 3. Some load order manager to replace LOOT (probably called SLOT - Structured Load Order Tool) 4. Some universal patching tool to replace SkyProc/SUM xEdit Scripting Projects 1. mteFunctions (refactoring) 2. MXPF - Mator's xEdit Patching Framework 3. Automation Tools (continuation) 4. Forge Menu Overhaul (revisiting) All of these projects will support all games supported by the xEdit project, with FMO/AT leaning more towards Skyrim.

Mator Smash Standalone Alpha is available: Download v0.0.4.0 here Some notes: - Core functionality is complete - The UX for smashing and the algorithm are both more-or-less complete, may be updated - Most of what needs to be done now is the creation of smash settings, which can be done by anyone with some knowledge of patching - I'll try to make some documentation/tutorial resources for creating smash settings so you guys can get started on them

Thanks for the information. I'll be doing stuff around this area to resolve these things soon.