7/13日中午更新：
感谢您的工作，本次需要测试的修复内容较多，且部分涉及低概率随机事件，需要取得一定的置信概率后方能得出初步结论。进度随时在本帖子内各条更新。
【已修复】前言：不知道腐竹您的服务端mod是否已经更新，上周反馈的三种【派对树】，经周六线上测试仍暂时无法种植。如服务端尚未更新，这条可忽略。谢谢！
1、【已修复】【漏斗】无法正确判定非【橡木箱子】以外的各种【大箱子】，单个漏斗只会抽取大箱子中一半的物品。需要将原版漏斗检测大箱子的逻辑套用到mod中所有的箱子类型上。
2、【已修复】酿酒用【木桶】内的各种液体的材质分辨率较差，疑似被纵向拉伸
3、【待修复】该问题确认为材质包未覆盖，非方块数据问题。
在\assets\lotr\textures\blocks目录下，缺少表示成熟第7阶段的flax_3.png材质，只有6阶段的材质需要从传承版文件中移植、并对其同步代码。
【亚麻】作物的成熟阶段的材质和成熟前最后一阶段的材质相同。
由于除成熟阶段外，其他生长阶段均和传承版贴图一致，怀疑为贴图缺失bug；需要核实。
左：正常不同阶段材质；右：当前成熟阶段材质
4、一些lang文本缺失问题：
①【部分修复】：新的文本为Transport Ship，需要汉化。
【运输船】的物品栏UI标题调用文本缺失：
②【已修复】在【中州】使用【床】（各种类型的），聊天框中提示的“已设置重生点”的文本缺失：
③【待核验】雇佣单位的转移所有权按钮文本缺失：
④【待核验】雇佣单位设置驻守点的按钮文本缺失：
⑤【待核验】【骑乘小马的夏尔警卫】在警卫雇佣界面的NPC名称文本缺失。
5、【已修复】NPC掉落装备时，某些情况下会在物品上重复留下2次相同的”Belonged to”所有者NBT信息，且格式错误（“曾经属于: %s”，说明字符串没有正常引用，而是直接变成了%s文本输出）
6、【待核验】投掷物形式发射的【德鲁伊甸镖】、【陶瑞斯镖】的贴图方向和弹道方向呈90°垂直(水平发射时，镖模型的头部朝下)。可能需要调整材质文件朝向。
7、【已修复】一些掉落物的奖励池的列表缺失，需要查证：
①检索结果表明，【水稻种子】在所有的容器奖励池(LOTRChestContents)类定义中均搜索不到，且其方块形态的作物在所有东方生物群系(world/biome/rhun)的世界生成的Decoration过程中均不存在。
该问题群友在聊天中多次提及，因此请求核实该问题是否属于未来更新内容抑或设计问题。
俄罗斯团队于VX和discord均公开过水稻更新、种植方式的贴文，但目前尚未对获取途径做出相关解释。
②重制版对【古代黑努门诺尔装备】的类型做了扩充，但是没有将其添加到LOTRChestContents.class中的public static LOTRChestContents NEAR_HARAD_PYRAMID奖励池的参数中。导致一部分新添加的装备无法生成在调用了该函数的【古代哈拉德堡垒遗迹】和【哈拉德金字塔】中。
受到影响而无法生成的装备包括：【古代黑努门诺尔双手剑】【古代黑努门诺尔长矛】【古代黑努门诺尔骑枪】【古代黑努门诺尔弓】
8、【已修复】在【乌图姆诺】维度因使用【床】产生的爆炸而死亡时，播放的死亡信息是【%s爆炸了】。
正确的死亡信息应为【%s被[刻意的游戏设计]杀死了】
※应当调用的deathmessage为death.attack.badRespawnPoint.message
9、【待核验】【旗手】NPC被【玩家、雇佣单位或驯服的狼】杀死时，偶尔掉落的【旗帜】，丢失了【损坏值】的NBT数据，导致无论任何派系的旗手都会掉落damage=0的【刚铎旗帜】。
如果逐个判定修复bug较为复杂，个人认为也可以选择参照传承版，禁用该物品的掉落。
10、【待核验】在设置【关闭友军伤害】后、玩家发射的某些抛射物仍然可以命中友军NPC，（已知的包括而不限于：带有抛射物效果【地狱/炎、严寒、中毒】的箭/弩箭/镖、鸡蛋、雪球、卢恩火罐等）。
特别地，由于该效果、或者击退后摔落等造成NPC死亡的，视为玩家击杀，将导致声望损失甚至打破誓言等意外。
注：旧版本(1710Legacy)的处理方式为箭等弹射物弹开目标、新版本(1165Renewed)的处理方式为箭穿透目标。
11、【待核验】乌图姆诺返回传送门的渲染贴图缺失：
12、【已修复】【7/12更新：问题被证伪，暂搁置需确认】已经存在的【入侵号角】，有时会无法因为连续失败的生物生成尝试而自毁。
传承版中，【入侵号角】尝试生成NPC时，需要判定NPC落点方块是否合法（不位于与该入侵敌对的【旗帜】范围内，是不透明方块等等）；如果落点非法、则该次生成判定将失败。特别地，连续判定失败16次会调用endInvasion()强制删除该【入侵号角】实体，因此【旗帜】可以用于非武力手段破坏已经存在的敌对入侵。
参考文献：Invasion | The Lord of the Rings Minecraft Mod Wiki | Fandom
重制版该代码确认仍然存在(successivefailedspawns参数)，需要核验未稳定生效的原因。
一个例子：在服务器最后大桥以北。下图中，左侧该入侵周围6格以内的露天方块均为冰面（透明方块，不符合生成生物条件），但已长期存在、既无法刷新NPC也未自毁。
尝试使用敌对的【旗帜】覆盖来镇压入侵，也可以复现这个问题。
13、【已修复】非【橡木】的【大箱子】被右键打开和关闭时，block.chest.open和 block.chest.close音效效果被连续调用了两次。
单个方块的小箱子不存在这个问题。
14、【已修复】补充自上次测试：各种【杯具】被【流体】破坏时，杯子也会直接消失而非掉落为物品。
15、【待修复】经测试，盘子可以戴在头上，但会直接以物品的形式渲染，而非实体、也不会处理手中食物的物理效果。需要参照旧代码进行移植。
各种【盘子】失去了装备在【头盔】槽上的功能。
这是传承版延续的一个彩蛋，效果参考：Plate | The Lord of the Rings Minecraft Mod Wiki | Fandom 的最后一段。
可能相关的代码有多段，LOTRItemPlate.class、LOTRBlockPlate.class、LOTRTileEntityPlate.class；个人以为，可先行修复Item中的
@Override
public boolean isValidArmor(ItemStack itemstack, int armorType, Entity entity) {
return armorType == 0;
}这段代码后，戴在头部测试观察模型能否正确渲染。
16、【待核验】测试人员将对该问题进行不同在线人数下的自然生成测试，如问题长期未被证伪、可能仍需要审核其代码内容。
经不同运行环境下的验证测试，重制版对【古冢尸妖】BarrowWight的【自然生成】方式做改动后、古冢尸妖疑似难以自然生成（开箱的强制生成不受影响）。
代码比对：
传承版的代码相对简单，除了高度和亮度判定外，特别要求【生成实体所在位置y-1坐标的方块】==【世界生成时的原始方块】（通常是草方块）：
@Override
public boolean getCanSpawnHere() {
if (super.getCanSpawnHere()) {
if (liftSpawnRestrictions) {
return true;
}
int i = MathHelper.floor_double(posX);
int j = MathHelper.floor_double(boundingBox.minY);
int k = MathHelper.floor_double(posZ);
return j > 62 && worldObj.getBlock(i, j - 1, k) == worldObj.getBiomeGenForCoords(i, k).topBlock;
}
return false;
}重制版中，加入了单独的isValidBarrowSurface子函数扩充，意图将符合的生成条件从草方块扩大到泥土等其他方块。
测试人员认为该函数可能存在问题，如对实体坐标是否做了向下取整处理，worldObj.getBlock()的y坐标是否没有做(y-1)补正等等，导致返回了错误的方块而使得判定常值为false、生成失败。
请求核查（由于反编译问题、部分函数未显示、以源码为准）：
@Override
public boolean getCanSpawnHere() {
if (super. getCanSpawnHere()) {
if (this.liftSpawnRestrictions) {
return true;
}
return this.field_70163_u > 62.0 && this.isValidBarrowSurface(this.field_70170_p.func_180495_p(this.func_180425_c().func_177977_b()));
}
return false;
}
private boolean isValidBarrowSurface(IBlockState state) {
if (LOTRMod.equalsBlockState(state, this.field_70170_p.func_180494_b((BlockPos)this.func_180425_c()).field_76752_A)) {
return true;
}
Block block = state.func_177230_c();
if (block instanceof BlockGrass) {
return true;
}
if (block instanceof BlockDirt) {
BlockDirt.DirtType dirt = (BlockDirt.DirtType)state.func_177229_b((IProperty)BlockDirt.field_176386_a);
return dirt == BlockDirt.DirtType.DIRT || dirt == BlockDirt.DirtType.COARSE_DIRT;
}
return block == Blocks.field_150351_n || block == Blocks.field_150348_b;
}17、【待完全修复】关于雇佣农民NPC无法正常处理作物的理论-实测分析报告
目前测试情况：
①【无主的农民】(hiredNPCInfo.isActive=false)的行为正常，会自行耕地、播种默认的作物，因此判定农民的candoHoeing、candoPlanting、getUnhiredSeeds函数正常。
注：无主的农民播种时不会检测其物品栏是否存在种子，因为未雇佣的农民物品栏为null，仅调用预设的默认种子类型。
②【雇佣的农民】(hiredNPCInfo.isActive=true)移动AI完全正常；
农民可以执行移动到指定方块上可耕种位置的行为，因此判断其findTarget函数正常；
③【雇佣的农民】移动到指定位置后、无法使用【种子】播种、也不会使用【骨粉】对作物进行催熟。
但是如果执行的是耕地和收获已经成熟的的作物，农民的行为正常，收获的作物也可以正常进入农民物品栏。因此判断其candoHarvesting函数正常。
④关于箱子的行为，农民种子和骨粉数量不足(少于16个)时，无法从箱子中拿取种子和骨粉。农民在收获了作物超过16个时也不会将作物放进箱子中。
结论：
①农民的物品栏检测过程很可能出现了问题，因为雇佣农民既无法与箱子互动、也无法执行需要消耗物品的播种和施肥操作；而耕种和收获不需要检测物品栏消耗物品，则可以正常动作。另外，无主农民因为绕过了物品栏检测，反而能够执行播种行为。
风险最大的函数是getHiredInventory()错误地返回了各个不同的槽位的物品。请求查证该函数及其子函数getStackInSlot()是否正确执行。
②目前无法判断箱子检测函数getSuitableChest()是否运行正常。需要等待①修复后运行测试。
③农民的各个执行函数cando…ing()函数和寻路代码应当运行正常。
除开上述分析之外，代码和传承版对比之后，可能存在一些其他的问题：
a. 检测NPC物品栏是否存在种子的函数，相对传承版丢失了空指针检测的防御性代码：
if (theEntity.hiredNPCInfo.getHiredInventory() == null) {
return null;
}有抛出NPE风险。暂不确定这是否和上述①条的问题有关
b. 农民的种植执行AI（canExcuteFarming）代码在重制版中被前置，且其中调用了后续声明的cando…ing()函数。请求确认该方式是否存在先调用后声明的风险。
18、【待核验】经测试，【厨房战士】的成就疑似无法正常获得。该成就的条件是仅【使用】（抛掷）任意【餐盘】击杀一个敌人。
*大多数NPC有一个实体NBT参数，专门控制其是否只受到过盘子的攻击的flag，一旦受到其他类型伤害会被置为0。该参数可能在初始化时或因冬季受到冻伤等环境因素被意外置为false了。
19、【待修复】输入该指令仍发送相同的报错信息。测试者已经使用符合通用命名规范的远行队名称(英文字母和下划线组成)。
向远行队内部发送消息的指令/fmsg <“远行队名称”> <%s> 无法使用，输入后会报错；
绑定和解绑指令/fmsg bind/unbind <“远行队名称”>可用、但绑定后使用/fmsg <%s>仍无法发送消息。
20、【已修复】【奶酒】使用六个【马奶桶】和三桶【水桶】酿造；点击开始酿造后，六个装【马奶】的【空桶】不会返还而直接消失。
没有回复内容