Many items need only the name, so we can just place the name directly in this case.
JsonMapper supports hydrating the object directly from the string using the pre-existing constructor for this.
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 is useful when making changes to the generator, since regenerated schemas can now be tested for validity. This helps to find bugs in the generator.
this allows more compaction in certain cases, such as tallgrass recently.
instead of blacklisting any mapping which reuses the same flattened infix, we select the flatten property which produces the smallest number of distinct rules, which produces the most compact schema possible.
this change also permits potentially flattening other types of properties such as for corals (live/dead and type), although only one may be selected at a time.
as seen in pmmp/BedrockBlockUpgradeSchema@ebd768e5b2, this enables use of newFlattenedName in more places (by allowing the flattened values to be transformed before building the new ID), as well as reducing the number of remappedStates in general by compacting stuff which was partially transformed like color silver -> light_gray.
processRemappedStates() needs to know about the full set of states to generate reliable mappings.
Without it, it may generate flattening rules or state matching criteria that unintentionally match states that it's not aware of.
Sadly, this does make some schemas bigger, but it's for the best.
this is now able to determine which properties were renamed and/or changed when multiple renames occurred in a single version.
This also fixes unrelated properties being considered mapped to each other when there was only one property in the old and new state (e.g. mapped_type and deprecated for hay_bale in 1.10). Now, these are properly considered as unrelated.
this coincidentally fixes mangrove doors being tagged with unwanted blockstate runtime IDs. Their items client-side are not actually blockitems, so the client doesn't expect them to have blockstate IDs attached.
This reduces the chaos in the creative inventory slightly (for some reason the client responds to this stuff by putting random creative items in the wrong places), but the mess is still substantial and I don't know what caused the rest of it.
closes#5818
technically we shouldn't be breaking BC of internals signatures in a patch release, but it's internals, and that's an unwritten rule anyway. In any case, no one is likely to be affected.
this was achieved by storing binary representations of the blockstates, rather than the original BlockStateData.
Due to the insane object:data ratio of Tag objects (40:1 for ByteTag for example), modestly sized NBT can explode in memory footprint. This has been previously seen with the absurd 25 MB footprint on file load.
Previously, I attempted to mitigate this by deduplicating tag objects, but this was mitigating a symptom rather than addressing the cause.
We don't actually need to keep the NBT around in memory, since we don't actually use it for anything other than matching blockstates. In this case, we can allow the code to be possibly a little slower, since the lookup is anyway slow and the result will be cached.
In fact, using encoded ordered states as hash keys significantly improves the speed of lookups for stuff like walls, which have many thousands of states.
We keep around generateStateData(), since it's still possible we may need the BlockStateData associated, and it can be easily reconstructed from the binary-encoded representation in BlockStateDictionaryEntry.
this significantly reduces the size of schemas when state remaps are used (see pmmp/BedrockBlockUpgradeSchema@85b83b360e).
in addition, this will likely offer a substantial performance and memory saving when walls get flattened, which will eventually happen.
