~~兰博的不(bu)公平选边持续了14年！！！
根据近期全球服务器(qi)白金及以上段(duan)位的综(zong)合数(shu)据，兰博在蓝(lan)色方的胜率为49.4%，而(er)红色方胜率为44%，导致胜率差距达到5.4%，这使得兰博成为红蓝方胜率差异最大的英雄。
经过测试，兰博Q/R技能的总伤害、伤害段数和(he)单次伤害(hai)目(mu)前在红蓝双方都是相同的。然而，红色方兰博Q/R技(ji)能开始和结束造成(cheng)伤害的时间被向后推迟了(le)，这(zhe)使得红色方释放的Q/R比蓝色方晚了大约0.2秒（如下图所示）。
这种情况只发生在红色方(fang)兰博对蓝色方英雄使用Q/R技能时（对小(xiao)兵或训练假人使用时(shi)则正常）。这个问题已经存在了(le)超过10年，尽管在2014年的4.9版本中曾宣布修复。
在实际游戏中，由于敌方(fang)走位和其他原因，Q/R技能很难打满伤害。在这种情况下(xia)，蓝(lan)色(se)方通常比红色方(fang)多造成一到两段伤(shang)害，并(bing)更(geng)早地触发装备效果（如兰德里的苦楚）和符文（如征服(fu)者）。
可通过游戏内简易测试复现该bug，发现其他(ta)条件不变时，蓝方兰博对红方英雄至少造成3段伤害，而红(hong)方兰博对蓝方英雄仅造成2段伤害。关于R技能，其debuff会显示在状态栏，测试更简单。最(zui)简(jian)易方法是让乐芙兰(lan)用W（魔影迷踪）穿过兰博大招。 蓝(lan)方兰博会(hui)对红(hong)方乐芙兰造成2段伤(shang)害，而红方兰博对蓝方乐芙兰仅(jin)造成1段(duan)伤害。
原理：
伤害和状态计算按固定顺序处(chu)理，很可能基于单位ID优先级： 蓝方(fang)英雄(xiong) > 红方英雄 > 假人/小兵(bing)
bug触发(fa)条件：
当低优先级单位(wei)（红方兰博）伤害(hai)高优先级(ji)单(dan)位（蓝方英雄）时触(chu)发bug
当高优先级(ji)单位（蓝方(fang)兰博）伤害低优先级单位（红方英雄/假人）时不触发
因此红方兰博对(dui)目标假人的行为与(yu)对蓝(lan)方兰博对红方英雄相同，使(shi)我们能同时(shi)观察两种场景且时间完全同步。
Q技能发(fa)现：
兰博Q每秒造成4次伤害（每0.25秒1次），红方(fang)兰博Q对蓝方英雄有约0.25秒伤害延迟(chi)，若Q被提前(qian)打(da)断，红方兰博会少1段伤害（如2:1、3:2等） 这意味着每次线上Q换血都可能丢失伤害，严重影(ying)响红方兰博表(biao)现
R技能发现：
红方(fang)兰博R对蓝方英(ying)雄有0.25秒伤害(hai)延(yan)迟，伤(shang)害不(bu)同(tong)步——红方兰博(bo)的伤(shang)害会在目标间交替生效
原作者对bug起(qi)源的推测：
兰博(bo)Q/R被归类为DOT-AOE伤害，在引(yin)擎层（AOE）和脚本层（DOT）表现不一致(zhi)，这导致了兰博代码在引擎层与脚本层存在隐形耦合。
原作者怀疑：
原始bug（红蓝(lan)方伤害不均）被"修复"的方式是给红(hong)方兰博添加延迟，虽(sui)"平衡(heng)"了总伤害却(que)制造了更隐蔽的新bug，即设计师将一个(ge)小bug修成了一个更隐蔽的大bug，该bug影响2011年4月26日兰博(bo)上线以来的(de)数亿局(ju)游戏，包括约3000场职业比赛
~~有意思，可能发现什么了。我(wo)会去(qu)看(kan)看。
~~哇，你是官(guan)方人员吗？
~~他们名字旁边的拳头图标是只会发给真正(zheng)的拳头员工的，所以他肯定(ding)是！
~~是的，GalaxySmash是拳头主要的……呃，是其中一个(ge)主要负责bug的人。这(zhe)对兰博(bo)玩家来(lai)说真是个好日子。
~~哈哈，只是Reddit上最爱发言的那(na)个。在这待得够久(jiu)了，所以也见过不少东西了，而且自己也能搞定一些简单的(de)问(wen)题了(le)。
~~感谢你(ni)维(wei)护我最喜欢的游戏
~~乐意效劳，这也是我还有所有英雄联盟玩家共同的游戏嘛
~~如(ru)果我没理解错的(de)话，早在4.9版本，兰博在紫色方（蓝色方）时Q技能的伤(shang)害偏低(di)，所以他们搞了个修复(fu)方案，内容是：“如果兰博在(zai)红色方，就给(gei)Q技能(neng)的(de)伤害增加(jia)0.25秒的延(yan)迟。”
但是——他们从没考虑过“如果有人在兰博的Q或R技能范围内反复进出”会怎(zen)么样，结(jie)果现在每(mei)一段伤害的刷(shua)新都有(you)了0.25秒(miao)的(de)延迟。
这不是什么像(xiang)意大利面条的代码，这就(jiu)是写死的代码。
~~我(wo)去，这最初的“修复”方案也太没道理了，笑死。
~~当你意识到拳头的(de)代码一(yi)直都是意大利面条(tiao)时，这个(ge)最初的修(xiu)复方案就完(wan)全说得通了。在S4那(na)个年代，他们还在不停地往这坨面条上加料，当时的游戏代码根本就(jiu)没(mei)人想过去控制一下。
~~意面平行宇宙
~~那时候(hou)他们确(que)实搞了很多这种用蛮力做的蠢修复。
~~纠(jiu)正一下(xia)，紫色方当时就(jiu)是红色方（以前是(shi)蓝色方对阵紫色方，后来改成了(le)蓝色方对阵红色方）。
~~我花了大约四年时间追踪兰博在不同阵营的胜率，研究了所有能想到的(de)，也和(he)拳头(tou)员工聊过。尽管我(wo)和u/caenen_、u/vandirilol测(ce)试(shi)了所有能想到的可能性，但我们就是找不到(dao)这个bug到底是(shi)什么，甚至不确定是否存在。所以今天(tian)早(zao)上看到这个消息真是太酷了。
重要的是：这是Reddit上那个视频作者的帖子，里面有更(geng)详细的信息(xi)。
此外(wai)，还得补充一点，兰博在蓝色方还(hai)有一个额外(wai)的优(you)势——施放大招更容易。由于HUD界面的位置，在(zai)红色方施放远距离(li)大招时，为了瞄准而向(xiang)后移动，更容(rong)易导致角色脱离视野，而蓝色方则没有这个(ge)问题。这一点一(yi)直都知道，也被(bei)认为是兰博胜率(lv)差异的部分原因。但有一(yi)点(dian)一直暗示着可能还有其他问题，那就是兰博在极限闪击模式（一张横向地图）中也存在(zai)同(tong)样的蓝(lan)红方胜(sheng)率差距。
这就是为(wei)什么每当有人问起(qi)这个问题时，我们唯(wei)一能给出的答案就是：“嗯，有证据(ju)表明存在(zai)一个bug，但没人(ren)能找到。”
很高兴(xing)这个问题终于水落石出了。也很高兴我们终于能找到一个解决方案，来应对“如何(he)从平(ping)衡(heng)性角度处理一(yi)个在(zai)同一时间，一边胜率41%，另一边(bian)胜率59%的英雄(xiong)”这个难题。
