這個系列內(nèi)容大概是科學分析一些游戲bug或"bug"的原理并給出可能的解決方案

往期內(nèi)容歡迎查看本人專欄

本期算是危機合約前緊急加的，比較短，所以作為半期
內(nèi)容只有一個：擲能者的索敵，到底出了什么問題？

這個bug最早可查記錄：https://ngabbs.com/read.php?tid=22591000
大概概括一下就是：擲能者組長有3個或以上備選目標，且至少一個備選目標位于協(xié)議入口時，擲能者組長不會選擇最后一個部署的目標
這個問題可以說是非常奇怪了，單純用權(quán)重排序無法解釋

所以我們來看一下擲能者組長使用的是哪種索敵方式

可以看到，擲能者組長使用postFilter=4，即按仇恨值降序排序
使用secondaryFilter=3，即在權(quán)重排序后再優(yōu)先攜帶指定buff的目標，buff名為tower_t_1[charge_range]
設(shè)置sortByTauntLevelAtLast=True，即在最后再按嘲諷等級將備選目標排序一次，這個機制是這次更新新加的
問題極大概率出現(xiàn)在這三步中的某一步

一開始想當然覺得嫌疑最大的是sortByTauntLevelAtLast，因為這個機制是這次新加入的
但仔細想想，bug的生效條件中有一條“至少一個備選目標位于協(xié)議入口”，說明bug的生效和secondaryFilter的排序有一定聯(lián)系

我方干員使用secondaryFilter的還有對空狙，安德切爾和格勞克斯
于是拿同樣會打多目標的藍毒做了個實驗
然后奇跡出現(xiàn)了...

藍毒也出現(xiàn)了不打仇恨值最高（即離終點最近）目標的現(xiàn)象，例如視頻中就不會攻擊距離終點最近的源石蟲
藍毒并沒有將sortByTauntLevelAtLast設(shè)為True
那么問題基本可以確定在secondaryFilter上

接下來就是翻代碼...
然后發(fā)現(xiàn)最大目標數(shù)設(shè)為1和最大目標數(shù)>1是分開處理的
那么只看最大目標數(shù)>1的部分就好了

上面的代碼只要看到132行就差不多了

部分函數(shù)和變量為了方便識別做了重命名(注意那個列表是個指針)

如果看不懂或者不想看這里解釋一下
這一大坨的內(nèi)容邏輯大概就是：(簡化版邏輯，只保留了有效部分)
設(shè)置一個名為初始值為0的名為index的變量
從前到后遍歷備選目標列表
如果發(fā)現(xiàn)某個元素滿足secondaryFilter的條件
則將這個元素與第index項元素交換位置
然后index++

發(fā)現(xiàn)問題了嗎...

舉一個例子

假設(shè)我按 斑點->月見夜->末藥->紅豆 的順序進行部署，其中最先部署的斑點位于協(xié)議入口
首先進行仇恨值排序，順序為紅豆>末藥>月見夜>斑點
然后是secondaryFilter的排序，這個時候會從紅豆開始進行遍歷
前3項因不滿足條件不會觸發(fā)再排序
遍歷至斑點時，按前文所述的邏輯，會將斑點與紅豆(index=0)的位置進行對調(diào)
這樣一來，整個優(yōu)先順序變成了：斑點>末藥>月見夜>紅豆...

在這種情況下，受攻擊的會是位于協(xié)議入口的斑點，和倒數(shù)第二部署的末藥。最后部署的紅豆反而不會受到攻擊

這就是這個bug的原因

另外我查看了直到0.8.72版本(沒記錯的話是開午間)的客戶端，無一例外存在這個問題
這個問題極大可能從開服就一直存在，但是因為觸發(fā)條件較苛刻，觸發(fā)時不明顯一直被忽略
直到這個版本才被扒出來...

解決方法：改掉底層邏輯(需客戶端更新)
觸發(fā)再排序時請將列表中從遍歷項(不含)至index項(含)之間的全部項目后置一項
不要只是單純交換了...

本文原載于NGA：https://ngabbs.com/read.php?tid=22618647

作者為本人

此專欄以CC BY-NC-SA 4.0協(xié)議發(fā)布