As I have been working with developers over the past year or so, I have noticed a few things come up that I am addressing in ME3Tweaks Mod Manager 6.1.5 that will have an impact on how mods are deployed for use by users as well as how the end user experience will be when using ME3Tweaks Mod Manager.

For many years (dating back to about 2016), my Mod Manager (back then, ~ Mod Manager 4.0) has supported 'deploying' mods - taking your mod in the mod library and packaging it up for distribution. This process compresses your mod in a specific way that is not the same as you right clicking the mod folder and saying 'Add to archive'. I purposely store certain items uncompressed to ensure a more smooth end user experience - faster loading, less memory required to decompress, etc.

I have noticed some mods are not using this deployment feature, and as such mods can take several *minutes* to even parse from archive in M3. This is not an ideal user experience. In 6.1.5 I'm adding checks to identify mods that are designed to be used with ME3Tweaks Mod Manager 6.0 and above, and if a mod is not deployed through M3 (I can tell by various aspects of the archive), a warning will be shown to the user that the mod was not properly packed for use with M3. Mods targeting 5.1 and below will not see this warning as these mods are typically older mods.

This is to help with several things:

• This will force (perhaps a better word is 'persuade') developers to go through the deployment checklist when deploying their mod. This checks for things such as broken textures, broken audio, incorrect TLK string order, etc.
• This ensures the mod is packed in a way that makes it fast to load and fast to decompress, while not compressing items that have no purpose being compressed, like TFC and BIK files.
• It produces a consistent experience for users.
  

• Mods cannot contain package files that are empty, as this breaks other tools in the scene. Mods that contain these will be blocked from deployment until the issue is fixed, either by populating the file or removing it.
• Mods that do not list a valid TLK string ID will not be allowed to deploy - this means a local TLK in the mod folder that corresponds the one listed in the AutoLoad.ini (ME1) or mount.dlc files (ME2/ME3). Developers trying to 'optimize' their mod by removing what they think is not essential data is not a practice I support, and in general is not a good idea. There have been multiple instances in the scene before where we tried to 'optimize' something and it ended up breaking it down the line - a good example of this is removing the dependency table, or additional packages to cook from package files, where it worked for some time and then broke things later. All DLC mods need a TLK, so they can be reliably identified and used by tools. Mods that do not follow this rule will be blocked from deployment.
  

• It ensures proper moddesc.ini design. The example I used is from the moddesc.ini I wrote for ME2 Controller, which was wrong and has since been fixed. It made me find some of the files were installing to the wrong location (but were technically still functional).
• It improves mod security. Mod Manager by design will not allow you to install files into another DLC mod (except for the LOCALIZATION header), as it would delete the destination DLC folder first. This could leave the user's game in a partially messed up state, where there's a DLC folder but it is filled with 'patch files' from another developer, and likely throw an error in-game. Mod Manager correctly prevented the patching of the mod directly, but it lead to a sub-par user experience.
•  There were some edge cases that allowed you to install files into existing DLC folders from another task - those edge cases are now closed. Mods should not be modified by other mods unless through the game's override system, as it makes a clear separation of the mod.
• It improves security for the game by disallowing installation to areas that could load native code, such as ASI folder or the exe directory (for ME3).