软件资源 造成的存档大小爆炸增涨的Actorprefix实体（MCPE-155283）修复软件。

[香脆鱼饼干]

你的存档正在受到来自微软的迫害​

---

链接库
这是bugreport：https://bugs.mojang.com/browse/MCPE-155283 有能力的upvote下吧。
这是骚扰的纪录： https://github.com/Amulet-Team/Amulet-Map-Editor/issues/702
这是微软官方解释Actorprefix更改储存方式的原因：https://docs.microsoft.com/en-us/minecraft/creator/documents/actorstorage
解决问题的插件：https://github.com/PREMIEREHELL/Amulet-Plugins/blob/main/EntitiePlugin.py
插件依赖的软件和库：https://github.com/Amulet-Team/Amulet-Map-Editor/releases

---

问题
此bug具体内容如上。关键信息大致可译为：Actorprefix 和其中储存的NBT数据被抛到脑后而永不垃圾回收，无论实体是被沙还是时间到了的那种消失（despawned）。成千上万的actorprefix被留在任何区块指针键外浪费空间。微软可能忘记了一个过期实体垃圾回收功能。
简而言之，就是1.18.30后实体生成后就永远不会从存档中消失。
在升级1.18.30后存档大小爆炸性增长，存档达到了惊人的1.9GiB，但感觉没跑那么多区块。于是将区块 地图 pendingticks 传送门 和挂载着的实体 全部删除后，发现LevelDB 依然剩余约850MiB 的数据，其中仅仅只有几MiB不是没有用的Actorprefix实体。
四处问问后，发现其他服总大小仅仅400多MiB的存档，含有较为惊人的200MiB actorprefix。
虽然这是个服务器存档，在个人本地，可能在压缩和不会刷出太多实体的加持下，这个问题不会太明显。
但依然，微软正在破坏所有人的存档！！！

---

不建议你使用此方法，如果你的存档小于512mb而且不是服务器用存档。
基岩似乎是1GiB开始影响性能，4GiB有明显性能下降。不知道微软改Actorprefix储存方式后会不会有所缓解。
你兴许有充足的时间等待微软官方修复。
但可以确定的是
1.18.30/31/32/33 1.19 1.19.10
都没有也不会修复​

---

解决方法
在发现问题后，趁着夜色跑到wall外面和老外讨论交流了一番，发现外面也是多脸蒙B，有且仅有两个人在讨论这个问题。Dan Martin（PREMIERHELL）和 gentlegiantJGC。这两个名字十分熟悉，既是bugreport的报告者，又都是Amulet 地图编辑器项目的管理。于是就溜达到某些git不存在hub 内的Amulet-editor 意见反馈，用 一大堆rubbish 组成一个魔术封包去骚扰以球两人回应。没想到，仅仅用几分钟gentle就回应了，一个小时后我们就有了解决的插件。
1.克隆EntitiePlugin.py 到 amulet安装位置\plugins\operations\ 像这种款

没文件夹就建文件夹。
2.启动Amulet 读取存档，此时如果存档大要的时间需要比较久，需耐心等待。
3.依次点击 3D编辑器 Operations 左上角选中“The Entitie‘s...”插件 点击“Delete All” 如下面这种款。此步任何一个地方所用时间都取决于你PC的性能，本身py就慢，这软件/插件还毫无多线优化……。
……
几小时后你就可以看到一个窗口上面写着删了多少limbo实体。我用约5小时删除了 12601867 个。 有图有真相。

---

细节（灌水）
在四处询问时，有为“大佬”称“直接删多余.ldb文件呗。” 我不知道他对leveldb了解多少，但我可以看出他要么是指的是给存档做个化疗，然后祈祷？或者，重开=删除多余ldb，因为ldb没了就相当于重开了。 另外有 ”大佬“ 称此事为区块储存错误……遍历所有区块后即可解决……。 在这群体中只有一位大佬提到了是实体的问题，但依然不愿详解……不知道，一知半解，留一手（好开发差件miancai），大概就这几种情况了。
跑到外面转的时候，自己发的贴子被bot吞了……问下为什么结果被老外说发的是一堆不可理解的rubbish……补上一句 Such a task for non-native-English Speaker. 后，估计让其感觉guilt，主动提出帮我改从谷歌生草机出的作文。（然而我不用谷歌bollocks-er……完蛋，eng白学……）
插件作者在entitiesplugin.py上一个版本中就有加list dead 的功能……其在bugreport 中也暗示到这些实体的删除方式存在。估计是我提出一键删除这个功能，才快速改下UI ，把已经有的功能再简化，所以才能几小时内就完成。 或者，其早就开始相关实验并且已经码了一些。 不过……为什么他不直接告诉我他早就写好了呢？？？
此插件是肿瘤削减术，根治还得靠免疫系统（微软修复。）。
如1.19.10不追加修复的话，至少未来两月这bug是肯定会继续发酵的。

如果你觉得本篇教程对你有帮助的话，就请给予些支持吧！​

 

[Railgun19982]

微软，逆麻麻石蜡
1.9G→2.6G
要不是这么一整估计服务器很快就寄了

 

[香脆鱼饼干]

微软，逆麻麻石蜡
1.9G→2.6G
要不是这么一整估计服务器很快就寄了

喜欢记得点赞转发哦、 。
其实其影响到底如何还有待商议。因为入你所见，微软改这个储存方式的根本目的就是为了排除冷数据塞存档造成连续读取降速之类的。actorprefix的确储存在了区块数据外。再怎么dummy，其影响也不会和之前一样显著。
同时，如果关注bugtracker 就可以知道，foxynotail 表示，其可能不是微软的锅，微软可能没忘记垃圾回收功能，可能是谷歌LevelDB 没弄好。其表示在leveldb返回确认相关actorprefxi被删除了，过一段时间还是会“复活”。
Meh，总而言之，可能影响不会那么惊人，但肯定有。尤其是你要备份存档到网盘那种……（我们就是）。 6Mbps 小水管备份2gb存档明显吃力。这些都是实体，数据熵值十分高，levelDB 压一遍后再用7z压只能得98%之类的压缩率。所以，我们是不得不删些。如果你存档只有几个mb甚至几百mb都可以考虑先不折腾。
毕竟折腾一下，基于你存档内有多少实体，可能要花几个小时的时间。有些小天才可能等不了就关了，然后坏存档。

 

[予纾]

1.19.10确实不会修，结果直接更1.19.20修了

 

[香脆鱼饼干]

更新。
1.19.20.20 预览版修复。不知道什么时候合并到主线……
==================

https://feedback.minecraft.net/hc/en-us/articles/7285705024909-Minecraft-Beta-Preview-1-19-20-20-21

=================

 

[finder]

更新。
1.19.20.20 预览版修复。不知道什么时候合并到主线……
==================

https://feedback.minecraft.net/hc/en-us/articles/7285705024909-Minecraft-Beta-Preview-1-19-20-20-21

=================
浏览附件31267

请问这个更新会自动删除存档中已经存在的死亡实体吗

 

[香脆鱼饼干]

请问这个更新会自动删除存档中已经存在的死亡实体吗

理论上是的，但微软在。20.21 还是没弄好。先等等吧。

 

[Railgun19982]

喜欢记得点赞转发哦、 。
其实其影响到底如何还有待商议。因为入你所见，微软改这个储存方式的根本目的就是为了排除冷数据塞存档造成连续读取降速之类的。actorprefix的确储存在了区块数据外。再怎么dummy，其影响也不会和之前一样显著。
同时，如果关注bugtracker 就可以知道，foxynotail 表示，其可能不是微软的锅，微软可能没忘记垃圾回收功能，可能是谷歌LevelDB 没弄好。其表示在leveldb返回确认相关actorprefxi被删除了，过一段时间还是会“复活”。
Meh，总而言之，可能影响不会那么惊人，但肯定有。尤其是你要备份存档到网盘那种……（我们就是）。 6Mbps 小水管备份2gb存档明显吃力。这些都是实体，数据熵值十分高，levelDB 压一遍后再用7z压只能得98%之类的压缩率。所以，我们是不得不删些。如果你存档只有几个mb甚至几百mb都可以考虑先不折腾。
毕竟折腾一下，基于你存档内有多少实体，可能要花几个小时的时间。有些小天才可能等不了就关了，然后坏存档。

levelDB本身就是kv数据库，只要能击中内存那多少数据都不影响性能，所以此举似乎只影响较小内存的服务器，至于不想折腾存档的方法的话，多插几条32G就可以了

 

[Railgun19982]

可以授权转载一下和做个视频嘛
让我解救千万服主于水深火热之中

 

[Railgun19982]

喜欢记得点赞转发哦、 。
其实其影响到底如何还有待商议。因为入你所见，微软改这个储存方式的根本目的就是为了排除冷数据塞存档造成连续读取降速之类的。actorprefix的确储存在了区块数据外。再怎么dummy，其影响也不会和之前一样显著。
同时，如果关注bugtracker 就可以知道，foxynotail 表示，其可能不是微软的锅，微软可能没忘记垃圾回收功能，可能是谷歌LevelDB 没弄好。其表示在leveldb返回确认相关actorprefxi被删除了，过一段时间还是会“复活”。
Meh，总而言之，可能影响不会那么惊人，但肯定有。尤其是你要备份存档到网盘那种……（我们就是）。 6Mbps 小水管备份2gb存档明显吃力。这些都是实体，数据熵值十分高，levelDB 压一遍后再用7z压只能得98%之类的压缩率。所以，我们是不得不删些。如果你存档只有几个mb甚至几百mb都可以考虑先不折腾。
毕竟折腾一下，基于你存档内有多少实体，可能要花几个小时的时间。有些小天才可能等不了就关了，然后坏存档。

润去levelDB的GitHub仓库看了一下，actorprefxi错误返回删除是老顽疾了，老有人拿这个去骚扰Google的程序员
不过既然基岩版铁了心用levelDB那我估计微软最后也会出相应的解决办法吧，希望如此

 

[出众年华]

1.19.20好像修复了

 

[喵咪咪]

有没有删除玩家数据的方法