Mator

Investigating. Will edit. EDIT: Also, those are records, not files. EDIT 2: The only error I was able to recreate was This error can be safely ignored. The highest priority override of that record does end up in the Merged Plugin, it just fails to copy from Immersive Citizens - AI Overhaul.esp because it's set as a temporary reference in that plugin while it's a persistent reference in all patches (This is due to a TES5Edit error when you try to copy a record to a file when it's already in that file and the record you're copying has a different persistent flag state than the record in the file you're copying to). EDIT 3: Using v1.9.5 of the Merge Plugins script. Merge Plugins v1.9.5

I've had to deal with this in the past in regards to Merged Plugins. Awhile ago users were reporting merged plugins causing their map to freak out/be zoomed wrong/unusable. I investigated and found it was because of conflicting edits to the MHDT subrecord on the Tamriel Worldspace. The Merge Plugins script resets the MHDT subrecord to the Dragonborn defaults in all merged plugins. See Lines 1379-1391 It should be noted that older versions of the Tamriel worldspace record will have different subrecord definitions for the MHDT subrecord, so in order to fix it you have to delete it and remake it (as is done in the script).

You didn't install the version of mteFunctions included with the download for Mator Smash or you replaced it with a different version. Redownload the archive from the OP and make sure to replace your mteFunctions.pas file with the one from the archive (in your Edit Scripts folder).

Can TES5Edit access your MO load order?

Thanks for that correction. I'm amazed I got everything else right. :o

The backbone of TES5Edit is not something the creators of TES5Edit came up with themselves, it's something that's inherent to how Bethesda encodes their files. TES5Edit was largely reverse engineered from Bethesda files and tools, and has been referred to by the developers as the "Skyrim Plugin Decoding Project". Records, formIDs, filenodes, and references also weren't created by Bethesda. They trace their roots back to basic data storage concepts and databases. In the context of databases you'll see the word record (or row) used very often. The Bethesda plugin files themselves are comprised of a bunch of packed records. What packed means is hard to explain from a technical standpoint, but the result of packing the records (or arrays, depending on the context) is an increase in space and time efficiency. Like records in most databases, these records have unique IDs. These IDs are essentially just unsigned integers, and are equivalent to DWords in 32-bit implementations. That is to say, they're a data type that takes up 32 bits of space, which gives them a maximum value of 232 or 4,294,967,296 or 168 or $FFFFFFFF (all of these numbers are equivalent). You'll recognize the final representation of this number as the maximum FormID possible in any Bethesda game. FormIDs are just hexadecimal representations of the ID associated with a record (or form). Form is roughly synonymous with record. More technically speaking, you could consider a Form to be a type of record (in the database sense) with certain header information as defined by bethesda (record flags, record signature, formID among those). Your reference to FileNodes seems out of context. As a TES5Edit user I can imagine no reason why you'd be concerned with that. If you can clarify what you mean maybe I can help. Regarding references. A reference is just what it sounds like it is - a reference. It's like a pointer in programming. You basically have an address which tells you where another object is so you can make relationships between various records. In this case, the address is the record's FormID. The difference between base and non-base records is more esoteric. To understand this we have to delve into the concept of a load order. So, from what we've said so far, we've established there are records, and that we can have up to about 4.3 billion records in the game (barring memory limitations, of course). The thing is, we might want to separate our records into logical units (or for users to be able to create new logical units with records in them) in the future. For Updates, DLC, or Mods. This is where the notion of a file and a load order prefix comes into play. If we have more than one file now, we have to make sure that all of the content in those files lines up and that cross-file references will work. This requires us to be absolutely certain that a FormID isn't taken already. If each file just arbitrarily assigned FormIDs in the 4.3 billion record space, there'd be no guarantee that File A and File B wouldn't try to make completely different records at the same FormID and thus cause serious issues to occur. Thus we reserve the first two hexadecimal digits (a space of $FF = 256 = one byte) for an affix that will be assigned to files based on the order that they are loaded into the game. This makes certain that no two files will try to create records at the same FormID when the game runs, as the Record's FormIDs will be allocated at execution time to prevent conflicts. This also allows us to set a priority order for changes, so two files that change the same thing can be ordered so one of them wins out over the other. Ok, so we have a load order now. The next question is why do we have override/injected records (I think that's your question). While we allocated our FormIDs to complete different spaces to prevent unwanted conflicts, in so doing we made it so patching is impossible. However, it is extremely valuable to implement patching in a way that doesn't require modifying the original files, as it makes installation and management much easier. This is where master files, override records, and injected records come into play. An override record is a record that has been allocated outside of the file's FormID space and that collides with another existing record's FormID. That is to say, records in a file are all initially allocated to FormIDs in the range $xx000001-$xxFFFFFF ($xx being the number of masters the file has). These are defined as the FormIDs IN that file. NOTE that these FormIDs will be mapped to $yy000001-$yyFFFFFF when the file is loaded into the game, with $yy corresponding to the file's load order position. In contrast, FormIDs at $00000001-$00FFFFFF would be considered as referring to FormIDs in the first "master" of the file. So if I have a file "Test.esp" which has Skyrim.esm as it's master, records that are part of Test.esp will be in the $00000001-$00FFFFFF range and records that are being put into Skyrim.esm are in the $00000001-$00FFFFFF range. If any record already exists in Skyrim.esm at the specified FormID it will be "overridden" by the version in Test.esp, else what happens is what's called "injecting records". Similar to how FormIDs in the file get mapped based on the load order position of the file, FormIDs that refer to a master get mapped to the load order of the master. So $00000001 in Test.esp gets mapped to $00000001 in Skyrim.esm because Skyrim.esm is at load order position 0 (thus not a particularly good example). I'd imagine you're probably pretty confused now, but there's the information dump you seemed to be asking for. Cheerio. -Mator

Fixed.

Hi guys, Lately I've found myself in the position where I have far more Skyrim development projects than I can complete. This has led me to the idea that it might be cool to have a network of xEdit developers who can work together on projects, and focus their collective attention on particularly promising efforts. The network would be for anyone interested in making xEdit related solutions. It doesn't matter if you don't have any experience. Below are some examples of projects that would fit in this network: xEdit Scripts Merge Plugins NPC Visual Transfer Tool Real Shelter Patcher Automation Tools (NPC Generator, QuickChange, QuickDisplay, PerkTreeUI, ... etc.) DynDOLOD Mator Smash iActivate Forge Menu Overhaul Bash Tagger mteFunctions Standalone applications using xEdit as an API Merge Plugins Standalone Mator Smash Standalone Guides/Tutorials xEdit Scripting Guide Ultimately I want to be able to make it so developers can share their work with each other and create an environment of learning and contribution. If someone has too much stuff on their plate they can pass things off to other developers to tackle. This is based on the idea that we all just want to make solutions that people find useful. I know I have a backlog of like 10 scripts I need to update and maybe 10 more that I haven't had the chance to make. Rather than just sitting on all these potentially valuable solutions, I'd like to share them with newer TES5Edit scripters so they can get the chance to learn more about TES5Edit scripting and make a cool new tool for the community to benefit from. If you think this sounds like a good idea, please post a reply! First off is an xEdit subreddit: xEdit Subreddit This will be a place for announcements and following ongoing projects. It's largely intended for the general xEdit audience. Second up is the xEdit HipChat: Guest Access Join xEdit HipChat This will serve as a place for general discussion, support requests, and development efforts. I'm really excited about HipChat and the integrations it offers with services like Google Drive, Asana, GitHub, and BitBucket. Feel free to join! I'm looking to bring more people into xEdit scripting and development, so come one come all

Yeah that shouldn't influence TES5Edit's execution in any way.

The ETA is largely dependent on the amount of time I can put in now that I have a full-time summer job. It's not a situation I've been in before, so I can't really say much with certainty. Smash is a big deal, but prior to developing something new that I don't fully understand, I decided to make something that I already understand. The transition from script to standalone application is not trivial. Attempting to do Mator Smash as a standalone application right from the get-go would be a far more inefficient way of doing things than the way I'm doing them now. Code reuse will be high, so in a way I am working on Mator Smash right now, just not directly. Also, the Merge Plugins standalone application is kind of a big deal. I'm doing my best to get things done as fast and efficiently as possible. Please bear with me - I'm a single programmer trying to redefine the way we all play and mod the bethesda games. That's no easy feat! Regards, -Mator

All development has been pushed back. Focus has shifted to developing merge plugins as a standalone application using the TES5Edit API which will serve as a precursor/sample codebase for developing Mator Smash as a standalone application.

Glad I could be of help. Let me know if you need any help with TES5Edit scripting in the future. I'm happy to help. :) Having AddMessage is fine so long as it's not making your script unreasonably long to execute. 50 seconds for a full load order is very reasonable, so you don't have to worry about implementing a ProgressForm for additional performance. Regarding ThreeTen's recommendation to forgo the Process function: You could do this, but I personally feel its nice to have the Process function because it allows users to run the script on a select few mods to create a patch for just those mods. As long as you provide clear instructions for general usage it shouldn't be an issue to your users. I mean, heck, my Merge Plugins script is super complicated, and it's being used by all sorts of people all the time!

Good call. Wasn't thinking about that.

Hi Millet. There are a few things in your script that would cause obvious slowdowns: 1. AddMessage will always be a slowdown when used. It forces a callback to the main application to update the GUI, which is slow. To avoid this issue you have a few options: - Don't log messages at all - Use a form with its own TMemo component. This will be marginally faster if the TMemo is shown, and much faster if it is hidden (see Merge Plugins or Mator Smash for an example of what I mean) 2. The Process(e: IInterface) function is going to process more records than you're actually interested in. As you yourself have stated in your code, you're only interested in records with signatures matching 'ACTI', 'CONT', 'FLOR', or 'FURN'. Instead of using the Process function to go through ALL the records the user selected (which is going to be slow), you can use element traversal in your finalize function to get to the EXACT records you want to process. You can still use the Process function to get the files the user selected. Pastebin for syntax highlighting: https://pastebin.com/wgQM5RaJ Also, only ACTI and FLOR records have RNAM elements, so you don't need to process CONT or FURN. I applied this script to Skyrim.esm and it completed: [Apply Script done] Processed Records: 1, Elapsed Time: 00:37 -Mator EDIT: Applied to a full load order of 154 mods and it completed in 1:54. Got some errors on certain FormIDs probably due to master issues. Will see if I can figure out a fix. EDIT 2: Fix applied. I stand by never using AddRequiredElementMasters in my scripts. The way I just implemented is clearly better because it doesn't cause FormID mapping errors. It's also faster. With the version of the script above I processed a full load order of 153 mods, including all bethesda files and DLC in 00:50. Would be even faster if I omitted the AddMessage() calls or used a progress form instead. EDIT 3: Final version of the script which doesn't process CONT/FURN because they don't have RNAM elements: https://pastebin.com/wgQM5RaJ

So an update on this- The next version will have massive GUI changes. I'm going to be rolling out a version with a GUI close to what will be in the final product. I'll also be making setting creation MUCH more user friendly by implementing a Checkbox Tree. Example of Checkbox Tree This update will also include some updates to efficiency, primarily around skipping records/subrecords. By utilizing either a tree or hashtable in memory I'll be able to determine whether or not to skip a record or subrecord much faster than the current implementation. After this update, my focuses will return to fixing bugs and general efficiency. Here's a look at the general plan for the future of Mator Smash: v0.9.5: Massive GUI update, efficiency increase in regards to settings v0.9.6: Bugfixing, general efficiency increases, and refactoring. (investigation into extended uses of conflict status) v0.9.7: Creation of additional features that are deemed necessary to provide easy, flexible, and functional patching to users. v0.9.8: Bugfixing, refactoring. v0.9.9: Creation of setting presets for various use cases. Final bugfixing. v1.0.0: Public release. This will probably take between 3 and 8 weeks, depending on my free time and on how fast I can achieve my goals. If anyone has any additional input regarding Mator Smash, sometime in the next few weeks would be a good time to share! -Mator

Right now smash is in BETA. That means it's not meant for use by the general public. It should only be used by people who are willing to test it and who have an intimate knowledge of things like plugins and compatibilty patch creation. You certainly could use it without this knowledge but there will be a chance of you messing up your game if you do so. Using tools while they're in beta can give you a preview of what modding may be like in the near future, but isn't something that I would recommend for anyone who's not willing to get their hands dirty, report bugs, etc. This isn't an "official release" topic, this is a topic for a beta of an automated compatibility patching solution.

Ah, based on user reports I may have not destroyed smashing speed in the latest version. It's always nice to realize you didn't actually break something you thought you broke. o_o' @Hishy: I wouldn't call it incorrect so much as "not 100% correct". The latest default setting update includes regex and skips just about every record type that we've seen problems on so far. Also, it seems that several issues that have been posted (by you and others) may be fixed in the current version. Still nothing on the ITPO front and unsorted arrays are just being skipped right now in the default setting - Last used settings. Yep, good idea. - Change all to X. Yep, planned. - Automatic settings. From SNAM - Description is planned. I agree with this statement. You can't just click smash and be done, you need to verify the changes in the smashed patch are to your liking. You don't need to check every record in each category, but I'd check at least 5 (of varying conflict colors). Well it's on 0.9.4, it will be public at 1.0. That will take probably another 10 iterations to reach (depending on the size of each iteration). I'd say it's getting closer, but there are still some large issues that need to be tackled. The goal of the final version is for the user to be able to click "Smash" and be done (or something extremely close to this). I want to get things as close to perfect as possible, and not require users to understand tags. I finished regex (really just support for a single wildcard * character in subrecord settings) in the current version in the OP, v0.9.4. As hishy said, there's no programming necessary for using this script.

v0.9.4 up. Improvements and stuff, yay.

That's a rather pessimistic viewpoint. Sure, there'll be bad mods, but there'll be good ones too. It's just a tool like anything else, so it'll be used both by experienced modders as well as by newbies. I think it's a great way to introduce more people to mod creation and get people who otherwise wouldn't share their design skills to share their work with the community.

This being released on April 1st is a coincidence. It is a real, working tool. :)

Available on Nexus Mods IN-GAME MODDING! Now you can generate mods from your saved games! Have you spent hours and hours making your player home just the way you want? Now you can easily share it with others or use it in another play through! Jaxonz and MatorTheEternal have teamed up to bring you this exciting new tool, consisting of an exporter mod and importer xEdit script. Mods you create are just like any other. You can load them in your game, edit them with Creation Kit or TES5Edit, merge them, or share them via Nexus, Steam, or other sites. Use with Jaxonz Positioner and Jaxonz Renamer for the ideal GameToMod experience! Features Supports Skyrim, DLC, and 3rd party content.Exports ObjectReferences from any interior CELL.Imports changes made via console or with popular decorating mods.Selectable filters by item type, source mod, or created/modified objects.User export and import options saved between sessions.Honors items renamed with Jaxonz Renamer.Honors items locked in place with Jaxonz Positioner.Graceful handling of objects brought from other locations. Requirements SKSE 1.7.1SkyUITES5Edit Installation Download from Nexus ModsInstall just like any other mod with NMM or MO.Copy the *.PAS files to your TES5Edit\Edit Scripts folder. Basic Usage Activate GameToMod and load up your saved game in Skyrim.Travel to a decorated cell, open GameToMod's MCM menu, select desired options, and click Create File.Exit Skyrim and start TES5Edit. Load the same mods used in your game.Right click on skyrim.esm, select Apply Script, select the GameToMod import script, and click OK.Select desired options, the exported file, a name for your new mod, and click OK.Check the results, exit TES5Edit, and save changes to your new mod.See the files section for detailed instructions with illustration. How To video coming soon! Compatibility Fully compatible with DLC and 3rd party mods.Not known to conflict with any other mod. Any load order works.Can be cleanly uninstalled at any time. Support Please use the Posts tab for all support/comments/suggestions/complaints. Private messages will just be redirected here.By posting publicly, everyone can help you and it helps help build information for others to use.Please read the first page or so of comments before posting your question. Chances are it has been asked and answered already.See the change log for a list of all improvements.

Was aware of the MODS alternate texture element not conflict resolving, but not of the VendorItemFoodRaw keyword not conflict resolving. Will need to investigate that with heavy logging. I don't see anything wrong in the third screenshot. ITPO. Well aware of this. I know why it happens, how users can remove it, and how I could remove them automatically after patching if I wanted to. Don't know how to detect them before patching yet. When the TIFC - Info Count subrecord is skipped those will... not disappear. Again, issue with ITPO stuff. Looks like an issue with GetMasterElement or with non-identical SortKeys. Will have to investigate further. There is no "forward as one" logic anywhere in Mator Smash yet. Rules- you would probably skip certain records/subrecords via rules to resolve some of these problems.

Ask yourself- Which was updated last? Answer: Mator Smash. (so use the one from Mator Smash) You can also open the mteFunctions.pas file in a text editor and read the third line to see when it was edited. The one in Mator Smash says: whereas the one packaged with Merge Plugins says

People keep asking this. As is stated in the OP, this replaces bashed patch functionality and does more. The answer is yes. I don't know exactly what the differences between FO3 and TES5 plugins are, so you may have to toy around to find the right setting for record/subrecord exclusion to keep your game stable. You may also want to skip certain DLC plugins that aren't automatically skipped via changing the setting on them to "skip".

Ok, global setting subrecordMode fixed. v0.9.2 is here. Will now tackle the issues with element duplication in unsorted arrays.