When the Bashed Patch is activated by the "Activate <patch name="">?" dialog after a rebuild of the bashed patch it is correctly added to plugins.txt but the view in Wrye Bash is not refreshed so it seems as if the activation failed.</patch>
Do you have any mods imported like SPTUnlimitedRingsDragonborn.esp?
My bashed patch is picking this file up as a master and thus when I manualy enable Bashed patch the mergable mod SPTUnlimitedRingsDragonborn.esp is also checked as a master. then if I uncheck SPTUnlimitedRingsDragonborn.esp bashed patch is also unchecked.
What you describe sounds like intentional behaviour, not the bug I describe in my report. I fixed this particular bug in revision 2956 but forgot to comment on it here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You called the behavior intentional, but I believe that it is not without some degree of error. Now that I know it is not related to this bug report I will try and document it better in another separate report Unless I find this in another report or that it is proper behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you have any mods imported like SPTUnlimitedRingsDragonborn.esp?
My bashed patch is picking this file up as a master and thus when I manualy enable Bashed patch the mergable mod SPTUnlimitedRingsDragonborn.esp is also checked as a master. then if I uncheck SPTUnlimitedRingsDragonborn.esp bashed patch is also unchecked.
Merge Patches
• HoodsAndCirclets.esp
• SPTUnlimitedAmulets.esp
• SPTUnlimitedAmuletsDragonborn.esp
• SPTUnlimitedRings.esp
• SPTUnlimitedRingsDragonborn.esp
Masters for: Bashed Patch, 0.esp
00 Skyrim.esm
01 Dragonborn.esm
++ HoodsAndCirclets.esp
++ SPTUnlimitedAmulets.esp
++ SPTUnlimitedAmuletsDragonborn.esp
++ SPTUnlimitedRings.esp
02 SPTUnlimitedRingsDragonborn.esp
But if I use TES5Edit.exe to clean masters 02 SPTUnlimitedRingsDragonborn.esp is removed and acts normal again.
What you describe sounds like intentional behaviour, not the bug I describe in my report. I fixed this particular bug in revision 2956 but forgot to comment on it here.
OK thanks Daidalos
You called the behavior intentional, but I believe that it is not without some degree of error. Now that I know it is not related to this bug report I will try and document it better in another separate report Unless I find this in another report or that it is proper behavior.