generate-blockstate-upgrade-schema: fallback to exact state match when encountering ambiguous filters

this popped up due to new changes in 1.20.40. Really we need to improve the way the filters are calculated, but this workaround solves the issue for now.
This commit is contained in:
Dylan K. Taylor 2024-10-17 20:51:17 +01:00
parent 5cc1068cd4
commit 59d14de1d8
No known key found for this signature in database
GPG Key ID: 8927471A91CAFD3D

View File

@ -496,8 +496,31 @@ function processRemappedStates(array $upgradeTable) : array{
if($existing === null || $existing->equals($remap)){
$list[$rawOldState] = $remap;
}else{
//match criteria is borked
throw new AssumptionFailedError("Match criteria resulted in two ambiguous remaps");
//TODO: ambiguous filter - this is a bug in the unchanged states calculation
//this is a real pain to fix, so workaround this for now
//this arose in 1.20.40 with brown_mushroom_block when variants 10 and 15 were remapped to mushroom_stem
//while also keeping the huge_mushroom_bits property with the same value
//this causes huge_mushroom_bits to be considered an "unchanged" state, which is *technically* correct, but
//means it can't be deleted from the filter
//move stuff from newState to copiedState where possible, even if we can't delete it from the filter
$cleanedNewState2 = $newState;
$copiedState = [];
foreach(Utils::stringifyKeys($cleanedNewState2) as $newPropertyName => $newPropertyValue){
if(isset($oldState[$newPropertyName]) && $oldState[$newPropertyName]->equals($newPropertyValue)){
$copiedState[] = $newPropertyName;
unset($cleanedNewState2[$newPropertyName]);
}
}
$list[encodeOrderedProperties($oldState)] = new BlockStateUpgradeSchemaBlockRemap(
$oldState,
$newName,
$cleanedNewState2,
$copiedState
);
\GlobalLogger::get()->warning("Couldn't calculate an unambiguous partial remappedStates filter for some states of \"" . $pair->old->getName() . "\" - falling back to exact match");
\GlobalLogger::get()->warning("The schema should still work, but may be larger than desired");
}
}