Mator

Stream is online! 10/31 5:00PM.

Let me know when you start working on it again and I will assist you.

Preface If you've ever written or used an xEdit script, you've probably installed mteFunctions.pas. mteFunctions is a library of useful methods that script authors can leverage to make faster, better scripts. mteFunctions has grown to be used by almost a dozen different projects, and is over 3000 lines of code, and we're starting to run into problems. Design About a month ago I outlined a design document which outlined the problems with mteFunctions, and solutions to these problems. You can view that design document here. Event I'm going to start on some initial coding/refactoring now, but plan on doing a lot of it this weekend on my livecoding.tv stream (Saturday 1:00PM PST -> 9:00PM PST, Sunday 9:00AM PST -> 9:00PM PST). I really want to bring in as many people as I can to share their thoughts/help produce code for this project, because I want mteFunctions to become something that is owned by the community, rather than just "some code mator makes that's kind of useful". I want us to all feel that this code belongs to us as a community. Invitation If you've ever made (or used) xEdit scripts, please come participate on the stream. If you want to help develop parts of the new mteFunctions, let me know and we can collaborate together this weekend. Regards, -Mator

Merged patch or merged plugin? Merged patches shouldn't take hours to build unless you're using Mator Smash, which is different (and please specify that). Removing a mod from a patch would be very hard, a manual job and difficult to reverse. You'd basically have to look at every reference to the mod you're trying to remove in the context of all overrides of the record it exists on, and then revert it to the correct winning reference (aka manual conflict resolution). Not fun, and certainly time-consuming.

^Your solution.

I had seen those hotkeys before, but never really internalized them. Thanks. When I just "compile" the project, will it still increment the build counter (in version, if I have auto-increment enabled) and will it still produce a new .exe file? That's the main purpose when I press build. Any other tips are more than welcome. I feel fairly comfortable in Delphi XE, but still have a few things that I don't understand well.

Don't think that's possible. PM me and I can help.

Haha, sorry about that man. >_

Hi guys, I've started work on Mator Smash Standalone. I'm going to be live streaming most of the development. Check out my livecoding.tv channel on weekends and evenings (PST). (streaming now, 10/18/2015 6:33PM PST)

The VirusTotal analysis seems to directly contradict that: VirusTotal analysis Analysis of just the exe: MergePlugins.exe virustotal analysis EDIT: I saw you said script, so I virustotaled the "Merge Plugins xEdit Script" archive from nexus mods as well. (Also 0/56) VirusTotal analysis

Added a GitHub issue for it. I'll look into it and should have it fixed very soon, if I can recreate it. In that case, it definitely appears to be some kind of truncation issue. As for where or how this is happening - that I'm not yet certain of. Ok, that's not even near the 255 character limit (I didn't think it'd be), so it has to be a different problem. The truncation must be due to some kind of issue with Delphi code for interfacing with the file system. It's probably going to be a pain to deal with this. Here's a GitHub issue for tracking this. I also made GitHub issues for everything else reported here.

Merge Plugins will not load merged plugins even if they're enabled in your load order. This is to prevent users from building merges into existing files/taking up unnecessary load order slots/etc. This does mean, however, if you patch your merged plugins you will not be able to start the application with the patches enabled in your load order. My thoughts: - I don't want merged plugins to be loaded, if possible - A plugin selection screen might help with this - When removing merged plugins from the user's load order, the program should also endeavor to remove plugins that use the merged plugins as masters. How I'd do this is not yet certain, but it could just be some special exception handling. So the same plugins only cause this exception when you check them for errors from the Merge -> Plugins -> Check plugins for errors menu item? Good to know, I'll direct my testing to that to see if there is something obviously wrong. This is an interesting error because the plugin it says it couldn't find doesn't have a filename that ends with ".esp" -- which it should. I don't know why this would happen, but it is why the program couldn't find the plugin. I already answered the bashed patch issue. The filename length could be a factor, but I honestly don't know. Strings have no length limitation in Delphi, I can have a string that's a million characters long without issue. Paths may have a limitation, but that shouldn't effect the stored filename of the plugin, and even if it changed the stored filename, the program would still be able to find the plugin because the filename in the merge is the same as the filename stored on the plugin itself (it's the same variable, which isn't being changed EVER). I really don't know exactly what's going on. The plugin that causes problems has a filename length of 78 characters, which is definitely the longest filename in your load order. Well the time that merge plugins had errors it seems like another program was using Skyrim.esm, which caused it to be unable to load it, which of course causes the rest of your load order to fail to load. It seems that the filename length was indeed the issue, but in order to figure out why I'd like to ask you what the full path to that file [740 Revenge of the enemies - Skyrim Immersive creatures - Step Core & Extended] is/was. If this path is near or exceeds 255 characters, we'll have our explanation. Looks like an error I can resolve quickly and easily. Thank you very much for the clear and detailed report!

Glad to hear it, though I don't know why it fixed them. Haha. >_>'

@dreadflopp: This occurs during an error check? Does it happen when it's checking a specific plugin for errors? The error checking code is lifted directly from TES5Edit, so... yeah.

Is this a new issue as of the latest build (2.0.2.37), or has this been around for you for awhile? 1) not as far as I'm aware, but windows has a limitation for paths. 2) no, there's no arbitrary problem with that as far as I'm aware. I've done big merges with it just fine. I test merges with it regularly (not ingame so much as just with the application and examination in TES5Edit afterwards). 3) no, absolutely not. What it does have a problem with: 1) Building a merge, and then building it again in the same session (fixed in 2.0.2.37). 2) Cancelling a merge while it's building, and then building it in the same session (to be fixed in the next build). 3) Initialization exceptions didn't lock down the application quite properly as of 2.0.2.1, but this was fixed in 2.0.2.37.

You have to change your Merge Destination Directory on the Merges tab of the Options Window.

Glad you got it fixed. Unfortunately, an issue with how the program installs updates for itself caused errors around the english.lang file. In future updates it (and other files that will be distributed with program updates) will be guaranteed to get installed correctly. There was just some confusion between me and the API I was using for extracting ZIP archives.

Unlike merge plugins, the smash dictionary will be far more selective. That means that every submitted setting will be reviewed carefully. The way it'll work is per each plugin there will be setting recommendations from 1 or more users. Users can then opt to use any of these recommended settings. The general idea will be that recommendations should come from advanced users/mod authors who have put in the research to determine what should be used for a plugin. A setting submission would have a description of why that setting is recommended, and what was taken into account in developing it. Generally, most plugins won't have more than one setting choice unless all choices are equally valid. Input from multiple users will never be "combined".

Mod users will be able to use smash right out of the box, but the effectiveness of smash will increase over time as a dictionary (similar to that with merge plugins) grows through user-submitted smash settings. Ultimately, smash will be able to support a large variety of approaches, which will vary in their effectiveness. {Bash tags} will be supported. So a mod could be tagged by a mod author to make it easier for users to generate a patch of it. There will also be user-submitted/recommended smash settings. And of course, an individual user can always make their own smash setting for use with a particular mod (or edit the ones generated by tags or user recommendations). Ultimately, it will be a very flexible tool.

Going to have to push a few dates back. Everything that was going to be coming out today has been pushed back to next week Tuesday.

You do realize that I have 0 faith in LOOT and think it's an unreliable tool, right? I'm not talking about missing masters so much as out-of-order masters. Anywho, I'll try to look into this merge tonight if I can find the time. So busy.

Wow, a guide already. Awesome! :D Interesting. It's curious that no errors were found in the ESPs, and the script works but standalone fails. I'll have to look into this merge to see if I can get a better understanding of what's happening. Are you sure this isn't a load order/masters issue? -Mator

Thank you so much Grant! :) Yes, it's planned.

Go to the log tab when no plugins are loaded, right click, copy to clipboard, and paste it here. Also, this really should have been in the main Merge Plugins Standalone thread, not a new thread.

Try using a different filename. Right now your filename is identical up to the space, so there could be something weird happening. Either that, or something with the file indexes is really wrong. It could also be a load order issue, if the plugins aren't contiguous.