昨晚我修复了大部分万象添补0.17.11 中的新特性，卷帘门，的漏洞，没什么好说的，于是没有写新的闲聊帖。 不过今天，2025 年的最后一天，我想谈谈接下来可能会出现的内容，也就是接下来原版可能会开放的接口。 注意！以下内容为个人理解，最终可能不会成为原版内容。
自定义容器这里的自定义容器，就是指自定义箱子那类不需要实体，还能存储物品的方块了。 和以前的方块套实体实现的自定义箱子不同，这种自定义箱子应该是完全不涉及实体的，而且交互方式与原版方块相同的自定义箱子。 现在我们来讨论一下最终可能会开放哪些接口。我们首先假想地加入一个方块组件： "minecraft:container": {
"inventory_size": 27
}
|
其中 inventory_size 表示这个容器的容量，也就是其中含有物品槽位的数量。我们需要自定义箱子的接口，其中很大一部分目的，就是实现修改，主要是扩展，箱子容量。但是最终会不会提供修改箱子容量的接口，这我不能完全确定。 要是提供了这样一个接口，那就意味着原版开发团队面临着一个大问题：UI。 就拿现有的 JSON UI 说，现在的箱子 UI 布局都是（相对来说）硬编码的，这也是那堆利用实体实现自定义箱子的附加包要修改 UI 的原因。 在 资源包根目录/ui/chest_screen.json 中： // ...
"small_chest_grid": {
"type": "grid",
"size": [ 162, 54 ],
"anchor_from": "top_left",
"anchor_to": "top_left",
"grid_dimensions": [ 9, 3 ],
"grid_item_template": "chest.chest_grid_item",
"collection_name": "container_items"
},
// ...
|
这是 small_chest_grid，小箱子的物品网格，的定义。其中，grid_dimensions 指定了小箱子（单个箱子方块）的网格大小，可以看出这是 9 * 3，一共 27 格。这个数值是写死在这里的，没有通过 $variable_name 定义。（在 JSON UI 中，$ 用于定义变量。） 以上是经典 UI 的情况。不过对于携带版 UI，箱子网格是可以滚动的。最后如果真的可以修改箱子容量，那么还有一种可能，那就是把容量限制到 9 的倍数。不过，维度高度必须是 16 的倍数，这是子区块的限制；箱子容量必须是 9 的倍数，这就没什么技术性原因了，所以最后如果可以指定箱子容量，那么大概率不会有什么限制。 以上是考虑了 JSON UI 的情况；但是现在，很多 JSON UI 都被蜂鸟 UI 替换了，所以我们再讨论蜂鸟 UI，Humming Bird UI，也就是 Ore UI 的情况。 在 1.21.130 中，我们很容易注意到，在资源包根目录/ddui/root/chest_screen.json 中（其中 ddui 可能是 data_driven_ui）： // ...
"tag": "Container.FixedGridLayout",
"children": [
{
"tag": "Context.List",
"attribs": {
"data": {
"$relativePath": "$.items.levelEntityContainer"
}
},
"children": [
{
"tag": "Container.Item",
"attribs": {
"item": {
"$relativePath": "$"
}
}
}
]
}
]
// ...
|
可以看出，Ore UI 的箱子网格似乎是动态调整的。也就是说，如果之后箱子 UI 真的也换成了 Ore UI，那么这大概率不会妨碍自定义容器的加入。 说完了 inventory_size，我们继续完善这个假想的组件： "minecraft:container": {
"inventory_size": 27,
"drop_contents_when_broken": true
}
|
原版的方块容器有两种，一种是箱子 / 陷阱箱 / 铜箱子，破坏后会掉出物品；另一种是潜影盒，破坏后不会掉出物品，而是掉落含有这些物品的本身。需要注意的是，末影箱虽然形似方块容器，但其实它只是部分玩家数据的访问接口，玩家可以借此访问自己的“云空间物品栏”，仅此而已。 drop_contents_when_broken 字段应该会控制这种容器被破坏后是否会掉落自身所容纳的物品。
继续添加新的字段： "minecraft:container": {
"inventory_size": 27,
"drop_contents_when_broken": true,
"can_be_siphoned_from": true
}
|
can_be_siphoned_from 应该能控制漏斗或漏斗矿车是否可以从这个容器中吸取物品。虽然原版没有表现出相关功能的方块或实体，但是既然它已经存在于实体的 minecraft:inventory 组件中了，那么我想方块也会有这样一个字段。
接下来，我们面临这样一个问题：如何实现箱子开关时的音效和纹理变化等功能？为此，我们可以这样做：加入一个新的方块事件，比如 onContainerOpen 和 onContainerClose 这样的，然后 onContainerOpen: e => e.dimension.playSound('chest.open.custom', e.block.center())，这会在箱子打开时在箱子方块中心播放 chest.open.custom 音效。至于像木桶那样的纹理变化，可以通过方块状态与方块排列实现。 然而这里还牵扯到了另一个难题：方块动画。这里的动画是指模型上的动画，也就是骨骼的平移、旋转与缩放，而不是纹理上的动画。为了实现方块动画，原版给每个这样的方块都创建了方块实体，将方块渲染改为实体渲染，再应用实体动画系统。 这就是箱子、潜影盒、告示牌、旗帜等方块会在区块还没有渲染方块时出现的原因，它们走的是实体的渲染逻辑。 还有一点，那就是自定义容器加入的同时，可以配对的方块的功能也许也会加入，这样就可以创建自定义大箱子那样的东西了，不过这涉及更复杂的技术细节。 以上就是关于自定义容器的相关内容了，我期待这些功能在接下来几个测试版与预览版中出现。下一个测试版与预览版的发布时间大概率是 1 月 8 日左右。
其他方块与实体联系接下来可能会出现“实体与方块之间有特殊联系”的功能，比如嘎枝与嘎枝之心。这正好与一些现有的实现部分重叠，比如现在我们要实现方块的座椅功能，需要创建对应的实体；更新了这个功能之后，也许就可以用它提升整个系统的稳定性。 当然，即使最后加入了这个功能，它也可能非常基础。也许只能用来自定义嘎枝，因为官方是这么说的。 方块含雪以前我们只能让方块含水，不过现在，我们也许终于即将可以让方块含雪（这里指可以堆叠很多层的雪）了。 值得一提的是，基岩版的方块有前景层与背景层系统，以前我也写过相关教程。让方块可以含雪，实际上就是允许背景层为 minecraft:snow_layer；至于以后会不会开放其他相关接口，这还是未知数。
我们再来看去年暑假他们发布的方块的数据驱动开发计划，很多都部分实现或已经实现了，不过还有这些没有实现： 虽然第一条没有实现，不过现在我们已经有了战利品表相关的 API，所以也算是实现了；第四条中，含雪可能即将到来，含熔岩因为没有原版先例，可能需要更长时间。 至于第二条和第三条，那就没什么可说的了，目前一点消息都没有，就当第三条的尝试失败了，第二条难以实现吧。
好了，今天暂时这样，我要继续开发万象添补0.17.11 了。 | 
发表于 2025-12-31 17:18:16
提升卡
观察者
