Well, I just solved it.It is necessary to have "Mod B.esp" upper in the list of mods in Tes5Edit than "Mod A.esp".I'm not exactly sure how to do that, but after few trys (changing file names etc), I managed to do that and it is workingHope you will understand
Bethesda role playing games using the Gamebryo engine, including The Elder Scrolls games (TES4 and TES5) and Fallout games (Fallout 3, Fallout NV, and Fallout 4), have a limit of 255 plugins (roughly 140 for Fallout New Vegas). While this may seem like a lot, most heavily modded games need more plugins than allowed with this limit. This small guide outlines the primary methods for merging existing plugins and for creating plugins that merge conflict resolutions and content for multiple mods.
There are multiple methods that can be used to merge all or portions of esp plugin files to allow large collections of plugins to fit inside the plugin limit of Bethesda games. Some of these methods create or merge compatibility patches for multiple mods using a single esp plugin, thus reducing the need for multiple esp plugins to provide compatibility patches for various pairs of mods.
Until recently the only tools that could provided automatic merging of mods for Bethesda games were TES4Gecko which automatically merges Oblivion plugins, and FNVPlugin which merges Fallout New Vegas plugins.Mators Merge Plugins provides very capable mod merging tools that can be used across all the Bethesda games that are much more capable than any older merging tools. The x in xEdit stands for the first three letters of each of the separate editors for each of the Bethesda games. Merge Plugins requires the most recent version of xEdit which is available at the Fallout 4 reference above.
This guide does not cover the use of patches created by SkyProc or other similar tools. In Skyrim, SkyProc is used by several active Skyrim mods (e.g., ASIS, Dual Sheath Redux) to create mod-specific patches.
Mator's Merge Plugins utility can be used to merge theoretically any installed mod with any other installed mod following "The Rule of One", which requires that the behaviour of the assets after the merge are identical to their behaviour before. This includes mods containing Papyrus scripts (.pex files), NAVM/NAVI (navmesh) records and FormIDs (new objects created by the plugin).
For mods that don't create objects used by other mods that aren't being merged, the resulting merged mod should be free of any problems. Examples of mods like this are (note the examples are old and will be replaced shortly with some newer examples)
The current version of the Merge Plugins utility can also merge mods without changing the FormIDs, thus preserving the capability to use items in these mods without the need to revise all the mods that use these items. This also preserves items that already exist in saved games.
The Merge Plugins utility also works well with mods that provide items like armor and clothing. The only issue with these mods is that if the mods being merged change sufficiently when updated then a new merge of the underlying mods might not preserve all of the objects in a players inventory, as discussed in the Q: My hair's gone?! My armor's gone?! My weapons are gone?! My face is gone?!?!WHAAATTTT?!!!?! question in the FAQ for the older script version of the mod. This won't be an issue if FormIds were not renumbered.
Merges of mods with conflicts uses the standard Rule of One approach that is also used in the Bethesda engine itself. The latest loading plugin that affects each object will be included in the merged plugin. A check for conflicts can be done manually by looking at the records and sub-records in xEdit or by using the Conflict Filters capability in xEdit described in section 4.3 of the FNVEdit Training Manual.
If the plugins being merged are compatibility patches, particular care must be taken since these patches typically need to load later in the mod load order and because there might be conflicts across different compatibility patches that need to be resolved. If this automated technique is used, it is a good idea to create one plugin that combines the optional patches for an individual mod vs. creating one plugin across many different mods since the automated method uses the simple Rule of One to handle conflicts. If the plugins being combined are from the same mod, always start with the plugin for the main portion of the mod if it is being merged. For large mods with multiple compatibility patches it's usually best to merge only the patches. The advantage of including the main mod is that there may be intentional overwrites in the DLC or optional capability plugins, and if the main mod is included then by adding the main plugin first the combined plugin will have the correct records.
The merged mods created by the Merge Plugins mod can merge plugins with navmesh records, but if more than one of the plugins includes navmesh overides some additional steps are needed before using the newly merged plugin. These steps are described in this post and this post in the A Real Explorer's Guide to Skyrim topic. These require deleting navmesh records in the plugin and then opening the merged plugin in the Creation Kit. An excellent detailed example of how to do this is available in one of the documentation forums for the Skyrim Expanded Towns and Villages mod.
This STEP forum topic, which includes a pointer to this Afkmods post by Arthmoor, discusses the record types that are automatically merged by Skyrim itself. For these there is no need for any additional merging. There are not many such record types, but it is important to know which ones are included.
Documentation on creating a bashed patch with Wrye Bash is available in the Bashed Patch section of the General Readme for Wrye Bash (use the "?" icon on the bottom of Wrye Bash to display this file) and in the Wrye Bash Pictorial Guide. There is also a video on this and additional discussion on Wrye Bash in the STEP Wrye Bash guide. The bashed patch can automatically resolve and merge several types of conflicts between mods.
The data record merging used in the bashed patch handles several types of conflicts. Like the xEdit Merge Patch discussed below, for records that are part of "leveled lists" it can properly handle situations when one mod changes a sub-record and another mod changes a different sub-record and also when when two or mods change the same sub-record. In addition to resolving conflicts in leveled lists, Wrye Bash can also automatically resolve some non-leveled list record types when two mods change the same sub-record. For example, if one mod changes an NPC skill level to 50 and another mod changes the same skill to 60, the bashed patch will choose one of these changes or use a compromise value based on both (e.g., 55). In performing this task it uses Bash tags (for more details on the tags see here) to help determine which mod's records should have precedence when there is a conflict. These tags can be assigned manually in Wrye Bash, by using the BASH tags sutodetection script for xEdit, and (when implemented) automatically assigned to a mod when LOOT is used.
The Skyrim version of Wrye Bash does not merge nearly as many record types as the versions for TES4 (Oblivion) or Fallout (Fallout 3 and Fallout New Vegas). Wrye Bash for Skyrim handles record types for leveled items, leveled NPC, Names, Item Stats for armor and weapons, and a very small set of game settings (GMST). The only game settings it handles are ones explicitly included in the bashed patch menu; it does not include any GMST records from mods. It remains, however, the best way to merge leveled lists and leveled NPCs, but with the WB limitations in Skyrim other utilities are often needed to supplement its capabilities. An experimental version of Wrye Bash for Skyrim is available that handles a much larger set of hash tag types; once this has been tested Wrye Bash will be able to handle some of the merging that is especially tedious to do manually.
TES5Edit (and the equivalent xEdit programs for the other Bethesda games) can automatically create a Merge Patch that merges some potentially conflicting records across multiple mods. In Skyrim it can only work with a few types of records and is primarily useful as a starting point for creating manual patches. With the emergence of the Merge Plugins tool discussed previously there does not seem to be any need to use the xEdit Merge Patch.
Using this capability of TES5Edit is quite different than using the Merge Plugins mod described above since here TES5Edit is being using to create a set of merged records that only include records for which the mods being merged have conflicting entries while above it was merging entire mods when the mods had no conflicts. It can handle plugins that include scripts. This is described in section 4.8 of the FNVEdit Training Manual (the most recent available documentation for TES5Edit) and in Sharlikran's "Merge Patch" video. As the video points out, when using this TES5Edit (and the equivalent programs for the other Bethesda games) feature make sure to remove the Leveled List records and the leveled NPCs from the Merge Patch (note that unlike the edit programs for other Bethesda games the TES5Edit Merge Patch does not currently include leveled NPCs). It is recommended that Wrye Bash be used to take care of leveled list merging, as described above. Like the Wrye Bash bashed patch, the Merge Patch needs to be recreated whenever there is a plugins are added or updated that would change the patches automatically produced in the Merge Patch. The documentation on the Merge Patch suggest manual review of the patch to fix conflicts that the automated Merge Patch process was unable to fix. 2b1af7f3a8