Skip to content

Auto-split the Bashed Patch once it has 255 masters #533

@Infernio

Description

@Infernio

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:

  1. Creating a new BP after the main one
  2. Unchecking patchers until the BP process completes
  3. Building the second BP with the patchers you unchecked in the second step
  4. 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:

  1. Ask for all masters used in the patch
  2. If those amount to <=255/253 (always the case except for really heavy SSE/FO4 load orders), just save it
  3. Otherwise, ask each top GRUP in the patch file for its master count
  4. 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
  5. 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
  6. Check if that got us to <=255/253 masters in the first file - if not, repeat the previous step
  7. 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
  8. 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?

Metadata

Metadata

Assignees

Labels

A-patchersArea: Patchers (Everything in the patcher package)C-enhancementCategory: Enhancement, a request to add or enhance a featureM-relnotesMisc: Issue should be listed in the version history for its milestone

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions