Mator

For sure man. I don't support merging merges in merge plugins. I feel like saying "if someone does that, **** them", but building your code for the lowest common denominator is always a good idea. Looking forward to seeing it back up! Silly Ganda deletes his own mods. XD r/skyrimmods is arguably the best part of the Skyrim Modding community right now, in my opinion. I love hanging out there and interacting with the community there. I've also heard it was bad at some point, though it's been nothing but awesome while I've been there. With regulars like Chesko, Sheson, Enai, myself, and others you should fit right in. :)

Are you working on the Nexus page still, Ganda? It came up on google search results but said the author has hidden it. :'( Let me know when it's ready so I can pop in and give my thumbs up/endorsement. EDIT: Also, are you planning on posting this to r/skyrimmods?

Slightly inaccurate. The only scripts Merge Plugins "can't merge" are ones with GetFormFromFile calls (also GetModByName, checkModPresence, and IsPluginLoaded calls). That's what you're handling here. Merge Plugins handles script fragments and ordinary scripts don't need any special handling. EDIT: Seems other people covered that already. I explained all of this to hishy in depth at some point. It's cool that he managed to remember the details enough to get someone to make a solution. Merge Plugins COULD handle it, but it would have to function similar to how Ganda has this programmed in that it'd have to check all scripts after each merge because each merge can require the alteration of any number of scripts from any number of other mods/merges. ANYWHO... Really awesome to see this! I wanted to program it but I've been programming my ass off on Mod Picker so I haven't had the time. Nice work Ganda, I'll check out the code sometime soon-ish. :) EDIT 2: I think it'd be better to absorb it into Merge Plugins because Smash doesn't have the hooks into the Papyrus Compiler/Decompiler integrations yet. It'd be a "post-merge fix things patch". The LODGen stuff can be handled immediately during the merging process like other file specific assets though. EDIT 3: Line 278 LMAO. This feels a bit inefficient. The way I'd do this is to process all the script files once and build a dictionary of all the GetFormFromFile, GetModByName, checkModPresence, and IsPluginLoaded calls in all scripts, then iterate over that dictionary and for each dictionary item iterate across all the maps. Or just combine all the maps into a single map and use a simple indexOf call on a single map to see if a plugin is merged. The main reason this would be faster is you only have to load the script files once to build the dictionary of the calls, then load them once more to actually replace the calls as necessary. Right now you're loading the files n times, where n is the number of maps in merge_data_list, which is a lot of Disk I/O which is slow (even with tiny files). Alternatively you could also just reverse the loop order (so iterate over the files and per file iterate over the maps). This would force the LODGEN to be a separate loop as well. Looks pretty good overall though. Only other thing I'd suggest is breaking things into more functions so you don't have quite as much nesting going on and so the main procedure is abstracted a bit.

Read some things about detecting merges and stuff. If you need me, just call me on my banana phone.

I totally agree with you on these paragraphs. I do think you should also see the links I posted in my previous post regarding Mod Author's rights though, because it is important to understand that granting Bethesda these rights does not revoke or invalidate the Mod Author's rights. It's a purely legal issue - you basically sublicense your work to Bethesda assuming you use the CK to produce it. That doesn't mean you lose the rights to control how individuals/entities other than Bethesda copy/distribute it. A Mod Author's intellectual property rights remain on their work. More than one legal entity can own rights to a work.

I think you should refer to the links I edited into my previous post where there has been discussion regarding what rights a mod author has over their content. I agree with you it's fairly gray in some ways, but one thing that is not gray is that a mod author owns all files they produce for a mod (including the ESP files) and can assert intellectual property/copyright over it. That supersedes the EULA (and the EULA doesn't even attempt to revoke such rights). I do agree that we should use "Copyleft" philosophies in modding, but I also see that some portion of the current community could be against that. You'll be able to use any mod/plugin in your Mod List on Mod Picker regardless of whether or not we have an entry for it on Mod Picker. Custom entries will not have the benefits of compatibility, install order, load order, or conflict information, however.

Yeah I know this exact line of the EULA. It is often misinterpreted, but we've been over it on r/skyrimmods and on Nexus Mods several times now. It states that you grant Bethesda these rights, but not that you forfeit your own. The original creator of the content maintains all copyrights over the content they create. In order for that to not be the case the EULA would have to use the words "forfeit all rights to the New Materials" or something similar, which it does not. I can look up the past discussions for you if you want, but it's just going to be a couple of google searches most likely (so you should be able to find them yourself). EDIT: A few of the aforementioned discussions: https://community.bethesda.net/thread/11856?start=0&tstart=0 https://forums.nexusmods.com/index.php?/topic/3361700-fallout-4-mods-are-all-owned-by-bethesda-according-to-the-eula/page-2&do=findComment&comment=30155670 https://www.reddit.com/r/skyrimmods/comments/4h6cwp/discussion_on_modpacks_copyright_contracts_and/ https://www.reddit.com/r/skyrimmods/comments/33pw0t/licensing_and_mods_coming_from_a_gamer_with_a_bit/ I'm pretty sure the CK cannot be used to produce asset files asides from ESPs, but I also haven't really used it much at all so I could be wrong. Also I'm fairly certain that converting a file to a proprietary file format does not give the owner of the file format the right over the content in the file. But this is all getting pretty deep and I'd have to talk to a lawyer to figure out the actual nature of this. According to wikipedia (which isn't citing a source for this) the ownership is a contentious issue. I'd want to find legal precedent in regards to this, but the only point I'm trying to make is that it's not clear and straightforward that converting a file to a proprietary format gives the owner of that file format legal ownership over the contents of the file. And I think even if it was true to some extent there'd be a huge number of restrictions (else we could just create a proprietary audio format and convert songs to it to take ownership over them and then legally sell them)...

Uhuru: Read your PMs. z929669: The only content which Bethesda can claim ownership over in a mod is the ESP file (assuming it was produced with the CK). Their EULA/IP does not give them the right to take ownership over content a user produces on their computer and packages into a modification for their game. It is currently completely legal for a mod author to sell models, audio files, scripts, and textures associated with mods so long as the tools used to produce those asset files do not make a legal claim on them. xEdit is a bit more of a gray area, but technically you could also sell plugin files if they were created with xEdit. Mod Authors have complete copyright control over their mods, and stating otherwise is a misunderstanding of Bethesda's EULA and the legal nature of software. It's certainly all difficult legal stuff, but I'd assert that referencing an asset from a modification (asset being a script, audio file, texture file, or model file) does not make that asset a "part" of that modification. Insomuchas Bethesda cannot claim legal authority over the asset files referenced by mods unless the assets were created with one of their tools which they can claim legal authority over (or in a proprietary file format, though that's another discussion entirely).

My initial response was mistaken it seems. I got the procedures and requirements for the handling of general assets and file-specific assets confused. (I haven't done development work on or used Merge Plugins in over 6 months now). That said, I don't know if asset isolation serves to simplify the merging process enough to be worth recommending as the primary process, especially considering the manual steps involved. If you want to avoid asset duplication and a cluttered load order you might be better off using MO's Optional ESPs functionality, though I could argue against that as well. Your process can simplify things. I think it'd be most valuable if you put all of the plugins you want to merge in a single mod in MO, that way you can easily enable that mod for the purposes of merging. I'd actually recommend using entirely separate profiles for merges that exceed 100 plugins though, as that allows for the quickest re-merging experience possible. EDIT: And it should be noted that, even if you isolate the plugins from their assets, Merge Plugins should still handle file-specific assets assuming the mods containing the assets are active in MO. It is of the utmost importance that those asset-containing mods are enabled when the merging takes place, else Merge Plugins will not be able to handle file-specific assets as described on page 44 of the documentation, which will break most merges.

Glad to hear my sources helped, though I am kind of sad you just straight-up ported the pas scripts. y u no rebuild code still, great work. let me know if there's anything else I can do. :) -Mator

Congrats on the beta release, Sheson! Seems like you didn't need my help after all. :D I hear it's a lot faster than the script. Glad to know I was right about that bit. :) EDIT: One major question. How many firstborns do I need to sacrifice in your name to see the source code?

Hi baronaatista, You'll be able to make a description for your mod list with markdown (including embedding images). That means you can link to your specs/guides/tutorials/even write a guide/tutorial for users who want to use your mod list. I personally foresee that some users will make really in-depth guides to go with their Mod Lists (sort of like mini STEP guides) which will then attract users to use their mod list. The process is certainly complicated on the development side of things, but the user experience will be really easy and intuitive - even moreso than Merge Plugins.

Thread updated. Check out the r/skyrimmods Progress Report 4 for more information on our recent progress.

Hi VirtuousParagon, I have never tried changing the health of a creature that already spawned ingame, so I don't know how the game actually handles it. It may be that you changing the health and then loading the save game caused the dragon to just have its maximum health reduced, but its current health remain where it was in the save game. A merged plugin is just a plugin like any other plugin is a plugin. That is to say, the fact that this plugin is a merge isn't relevant to the problem you're having. Regards, -Mator

Hi Breems, We might be able to fit you in. I can interview you on Skype, Steam, or Discord to see what you could offer the project. Delphi was used to build an independent module - a command line application - to analyze and produce compatibility dumps on Bethesda Plugin Files. Delphi was used because the xEdit framework is written in Delphi and was easy to tap into to produce this application. You can see the module (called mod-dump) here: https://github.com/matortheeternal/mod-dump Regards, -Mator

Just wanted to let you guys know we updated the OP yesterday with some more in-depth FAQ responses and some elaboration about how the automated download/install feature will only happen with the blessing of the Nexus and Mod Authors.

I didn't consider that. If absolutely necessary we can only allow this for premium Nexus members, and for other members we point them to the Nexus Mods page directly. No, you misunderstand. An NXM link is essentially just a hyperlink, or a url, using a protocol which can be handled by Nexus Mod Manager or Mod Organizer. The file which would be downloaded from Mod Picker would essentially have a list of mod metadata, and in that metadata would be (for mods for which it is available) NXM links. These NXM links get executed and then NMM or MO queues and then downloads the mods from the Nexus Servers. It is slightly different than PCPartPicker because with mods there is a lot more "bulk". To be specific, a computer build has between 6 and 24 parts. A mod list has between 1 and 1024 mods (with merging). Our goal is to reduce the cost (in time and effort) to build a mod list, and part of that is reducing setup time. If the Nexus is concerned about this biting into their ad revenue we can talk about ways to encourage users to use their site, or restrict this feature to users with premium Nexus accounts. This is a large discussion that needs to be happen between me and Dark0ne/Nexus Staff. I'm in the process of reaching out to them right now. I think there is a way we could devise this feature to not bite into the Nexus's advertising revenue. We'll see. Mod Picker will also crowd source Install Order notes - which are notes about the order in which mods are installed. It will also be able to advise on install order based on the assets in each mod, as we will have complete asset file trees for each mod submitted to the site (including the files inside BSA archives). Absolutely. We understand how important install order can be. :) -Mator

Right now development on Smash and Merge Plugins is on hold until the Mod Picker Beta 40 days from now. I didn't really want this to be the case, but right now Mod Picker needs my help more than those projects do (with the big team of devs it's important that I set a good example and keep people focused and on track). Although, I actually have still been working on Smash and Merge Plugins indirectly. Both Mator Smash and Merge Plugins need a backend that will hold reports/statistics, and smash needs a backend to serve up Smash Settings. The Merge Plugins backend was built with Delphi and has been extremely unstable, and a general pain in the ass. I'm building a new backend to be used by Merge Plugins, Mator Smash, and possibly future projects as well. I'm building this backend as a RESTful API with Ruby on Rails, which means it'll also offer a web application for people to use. It's called MADI - Mator's Application Data Interface. GitHub Repositorty. I've also been working on a personal website so you guys can track my progress closer and keep up to date with what I'm working on. Rotation is very important. There's no way I can work on the same thing for too long without getting bored. By mixing things up I keep myself interested and avoid the risk of burning out. There's a delicate balance though between freedom and getting things done, so I have to be careful to not be too flexible with myself. :} -Mator

I have talked with Dark0ne about Mod Picker a few times, but not specifically about the download part of the equation. I'm not sure why the wouldn't like it, as both MO and NMM have a cap of downloading 5 mods at a time. Also, with the fact that our setup utility will detect already downloaded mods and not download them a second time I don't think it really matters... Huh, never heard of that. The key different between it and that is it will be generic, so it can apply to any mod list constructed by anyone. MSGO does something similar too, but it also applies to a fixed subset of mods. We're trying to apply generic automation to the process of downloading and installing mods, which is far more useful. Yeah, this is a big project and fairly complex. We do plan on having a large number of showcase/tutorial videos on YouTube when we launch, and on having thorough help pages as well. Yeah, I'm constantly being careful to not burn out. I wish I could clone myself, there are just so many things to do! -Mator

From the FAQ: Will this replace or compete with Nexus Mods/Steam Workshop/Lover’s Lab? No, absolutely not. We’re being very careful to not replace functionalities from these sites. We will not be hosting any mod files. We aren't copying mods from other sites. We aren't reinventing the wheel at all, if you think that then you're probably misunderstanding what the site will be offering users. Might want to re-read the OP or refer to some of the links in the Various Links section for more information. The discussion about LOOT is a long one. I can assure you I have talked with WrinklyNinja about it and he acknowledges my perspective. It's not that LOOT is wrong so much as the user experience is inefficient. My philosophy is: Instead of having users tune a complex automatic sorting process to get the load order they desire, have the users create the load order they desire and then advise them about mods they sorted incorrectly. Here's a quote from my conversation with WrinklyNinja: What I want to offer on Mod Picker is a tool that can aid users in sorting a load order with crowd sourced data (similar to LOOT metadata), but that also enables users to make a clean intuitive load order with mods organized into logical groups. LOOT can't do that - it mixes everything up. I could go on about this at length, but I might just quote my whole message to WrinklyNinja if you still take issue with my stance on LOOT. What I imagine this doing for the STEP community is providing a place for you guys to share the STEP mod list in a way that can then be downloaded and installed by any user without them having to download and install every mod by hand, sort their install and load order, and then do any other additional setup. You guys would make a mod list on the site, add the mods to it, upload configuration files and links to any custom plugins for users to download (e.g. custom patches), and then our automated setup tool will be able to download and install the tools, mods, and configuration on any user's machine. In addition, whenever you want to add new mods to the list you could do so on the site first, and then evaluate asset file conflicts, record conflicts, and any user-submitted install order/load order/compatibility issues between them and other mods in the mod list. You guys will also be able to share the knowledge you have accrued about mod compatibility, install order, and load order on the site so anyone who makes a mod list with similar mods can take advantage of your knowledge. I honestly can't see how this wouldn't be something to be extremely excited about. :)

The general idea is you do the full process of selecting mods, sorting plugins, removing mods, adding compatibility patches, etc. from the website, and then download a file which is used to setup the tools, config, and mods for your mod list through your mod manager of choice.

No, it's a website. It won't replace any functionalities of Mod Organizer/Nexus Mod Manager - it augments them. Think of it as a tool to build and share mod lists. Sort of like what STEP is about. If you want to get a really good idea of what it'll be like, just explore the PCPartPicker site and make a build on it. Then imagine the same thing, except with mods. :)

That could be a very long discussion, but the short version of it is we crowd-source information on load order, and can make automatic determinations about load order based on other data points. This will allow us to support automatic sorting of plugins AND assisted sorting, where the user sorts the plugins however they want and we display notes about how anything is out of order for them to correct (with automatic correction options).

Floating point division by zero there is a new bug. I'll look into it. EDIT: It appears to happen when there are 0 records to smash.

The first window is where you select which plugins you want to load into memory. It's the same as the xEdit plugin selection window, it just has a bit more information. The second window shows the load order of plugins loaded into the program, and allows you to view details on those plugins (by selecting them) add them to merges, etc. See the documentation. Are you using a translation or have your system set to have different decimal separator than .? There are ongoing issues in both of this areas. The other possible reasons for this would be you don't have a dictionary file or Merge Plugins is having issues accessing your file system. Transient issue on some systems with Windows not keeping windows on top of each other. Detect integrations won't find anything if you have file system permission issues or if you don't have any integrations set up in locations Merge Plugins knows to look for them. That's a system issue. Open the PDF help file to access information on how you can fix that. There's a reason I provide the help/documentation in two formats! Ah, yeah, that's the issue with the decimal separator. When parsing floating point numbers the default behavior is to use the system format settings. The dictionary is formatted as: 1,234.567890 (. is decimal separator). Unfortunately by fixing one issue with format settings I created this issue instead. It'll be fixed in the next version. Until then you can change your region & language settings to use , for thousands separator and . for decimal separator, and it will work.