4cc26be8342a80d0959efb4e622b1cc2fd01c47f

GGitHubImplement Azalea and Flowering Azalea blocks with tree generation (#6925)

cf1e30a7创建于 1月1日历史提交

文件	最后提交记录	最后更新时间
property	Tidy up in block properties aisle	8 个月前
BlockObjectToStateSerializer.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockSerializerDeserializerRegistrar.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockStateDeserializerHelper.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockStateReader.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockStateSerializerHelper.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockStateToObjectDeserializer.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
BlockStateWriter.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
FlattenedIdModel.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
Model.php	Unify block serializers (#6769) This has several advantages: Easier to implement new blocks (one less file to modify) Easier to adjust serialization of existing blocks Guaranteed consistency between serializers and deserializers Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.	8 个月前
UnsupportedBlockStateException.php	Throw a more specific exception on unknown block IDs	3 年前
VanillaBlockMappings.php	Implement Azalea and Flowering Azalea blocks with tree generation (#6925)	4 个月前