1,174 字，阅读时间 6 分钟。
虽然 Mojang 不一定听，但提了总比没有强，帮我们点下 Vote 投票，可能需要登录微软账户。
点击下方链接跳转相应建议帖子：
帖子翻译
资源包定义的自定义HUD元素
资源包应支持定义具有自定义布局和外观的自定义 HUD 元素。
资源包可以定义HUD组件，包括ID、纹理/字体/样式、屏幕锚点（左上、右上、左下、右下、中心等）以及与游戏窗口边缘的像素偏移量。数据包和服务器随后可以仅更新组件的动态值，例如文本、数字、进度或可见性。
如今，服务器通常使用 BossBar、ActionBar 消息、Title 或自定义字体等技巧来模拟自定义 HUD。这些方法虽然可行，但存在局限性且效率低下。频繁更改的数值需要反复发送整个显示文本/组件，包括未更改的格式。对于生命值、魔法值、货币、冷却时间、任务或服务器统计信息等 HUD，这会造成不必要的网络流量，并使布局难以控制。
客户端在加载资源包后应保留静态HUD定义，而数据包或服务器仅更新各个组件的值。这将提供一种简洁、高效且与原版游戏兼容的方式来创建自定义界面，而无需客户端模组。
对话框布局选项更加灵活
对话框是一个很棒的新功能，但其当前的布局对于许多服务器和数据包界面来说仍然过于僵化。以下两项改进可以在不将对话框完全变成自定义 GUI 系统的情况下提升其适用性：
- 允许将输入框和按钮/操作放置在主体元素之间。这样，创建者就可以构建更自然的布局，例如：文本 → 输入框 → 文本 → 按钮，而不是将主体内容、输入框和操作分隔到固定的部分中。
- 添加一个通用的响应式列/容器元素。它可以包含任何现有的对话框元素，并可指定首选或最大列数，例如 1-3 列。客户端会根据可用窗口大小计算实际列数和列宽，并在较小的屏幕上自动减少列数。这可以类似于简单的响应式网格或瀑布流布局。
允许服务器通过 HTTP(S) 提供区块数据
对于 RPG、小游戏和其他对许多玩家重复使用相同地图的服务器来说，通过普通游戏连接发送相同的区块数据会浪费服务器带宽。
服务器应能够提供用于存储静态区块数据的 HTTP(S) URL，从而允许将这些数据托管在 CDN 之后。客户端可以从该 URL 下载区块数据的版本化或哈希快照，而游戏服务器仅发送该快照之后所做的更改。如果缓存版本已经是最新版本，则无需再次下载。
这可以大大减少服务器的重复带宽使用量，因为成千上万的玩家会反复加载同一个大厅、地牢、竞技场或 RPG 世界。
对于实时更改，正常的游戏连接应保持权威性。服务器可以提供 URL、版本/哈希值以及任何必要的增量数据，以使下载的数据块保持最新状态。
如果支持完整的区块状态过于复杂，则该格式可以只包含方块和方块实体，而普通实体和其他动态状态继续正常传输。
这是作为可选功能，不会改变现有服务器的运行方式。
发表回复