-
Notifications
You must be signed in to change notification settings - Fork 84
Closed
Labels
A-patchersArea: Patchers (Everything in the patcher package)Area: Patchers (Everything in the patcher package)C-enhancementCategory: Enhancement, a request to add or enhance a featureCategory: Enhancement, a request to add or enhance a featureM-relnotesMisc: Issue should be listed in the version history for its milestoneMisc: Issue should be listed in the version history for its milestone
Milestone
Description
Bethesda's plugin format has a hard limit of 255 masters, since FormIDs only have a single byte for master indices (and 2^8 - 1 = 255).
Right now, we show an error message and tell the user of a workaround, which involves:
- Creating a new BP after the main one
- Unchecking patchers until the BP process completes
- Building the second BP with the patchers you unchecked in the second step
- If that fails as well, keep repeating from step 1 with the newly split patch
It would be convenient if we could automate this. So when we go to save, do something like this:
- Ask for all masters used in the patch
- If those amount to <=255/253 (always the case except for really heavy SSE/FO4 load orders), just save it
- Otherwise, ask each top GRUP in the patch file for its master count
- If any of those GRUPs have >255/253 masters, error out entirely - splitting GRUPs into multiple sets of records is out of scope for this issue
- Sort by number of masters and move out the GRUP with the largest number of masters (or maybe we could calculate unique masters?) into a second PatchFile
- Check if that got us to <=255/253 masters in the first file - if not, repeat the previous step
- If the first file is now empty, error out entirely as well - clearly there is a more complex relationship going on in such a case than what this simple algorithm can handle
- Once the first file is done, move on to the second file and repeat from step 1
Not exactly high priority since it's fairly rare and a workaround exists, but would be nice to have.
We should also mark the second BP somehow and prevent rebuilding it - maybe don't add the BASHED PATCH author so that it doesn't get recognized as a BP?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-patchersArea: Patchers (Everything in the patcher package)Area: Patchers (Everything in the patcher package)C-enhancementCategory: Enhancement, a request to add or enhance a featureCategory: Enhancement, a request to add or enhance a featureM-relnotesMisc: Issue should be listed in the version history for its milestoneMisc: Issue should be listed in the version history for its milestone