wrong targets of target type "cleave"

LostTemple1990 commented 3 years ago

sim error result and real log.txt In turn 6, unit (11) cast spell 326 to only target (3) in real log but in both target (3) and (4) in sim It seems that BLZ has modified the rule of "cleave" in 9.1? To fix this,I've delete two elements in line 165 in vs.lua local adjCleave = { [0x50]=3, [0x51]=4, [0x62]=3, [0x63]=2, [0x70]=1, [0x73]=4, [0x74]=3, [0x82]=0, [0x83]=1, [0xa3]=2, [0xb0]=1, [0xb2]=3, --[0xb3]=4, [0xb4]=3, } the commeted elements were deleted for a element in adjCleave like [0xa3]=2, It means that when the source unit is in slot 'a'(in another word ,slot 10) (the first num in 0xa3) and its recent target is '3' (the second num in 0xa3) the spell with target type "cleave" will also effect the unit in slot '2' (the value)

zealvurte commented 3 years ago

I've only had a case where I encountered the incorrect value of [0xa2]=3 so far, and as with yours, I removed it and added [0xb2]=3 to correct the sim.

Compared to me, you have one new value [0xb0]=1, and have commented out both 0xb3 and 0xb4. Do you have some specific logs I can use to test those out?

LostTemple1990 commented 3 years ago

the log I post above shows the value of 0xb3 is incorrect see what the unit (11) do in turn 6 in log(text in line 3 is the log) the same to 0xb4 = 3,this value means that both unit 3 and 4 is exist in field and according to the rule of melee target,unit 11 will select target 3 when both 3 and 4 exist so this will use the value of 0xb3 = 4 which was mentioned above

I've deleted the log which shows the value [0xb0]=1, but I think it's easy to check out this value We put only two unit in both slots 0 and 1 to the mission 2300(the same mission to the log above) and then check what the unit (11) do in turn 1 I'll try it again when my command center refresh this mission

LostTemple1990 commented 3 years ago

log.txt here is a log for value [0xb0] = 1 you can check what the unit (11) do in turn 11 it cast spell 326 to both unit 0 and 1 in turn 11 so I add this value to the table

zealvurte commented 3 years ago

Thanks for the logs. I was able see where changes were needed as you said. I've also checked those values against a collection of 73 other logs, and didn't find any issues, so I'm happy with them for now.

The 0x7* entries are all unused as VP is using an entry in adjCleaveN for that (I've opted to remove that entry and keep the entries in adjCleave, as I don't quite trust that the rarer outcomes it can produce would be correct).

There's a few values that would never be used because of the targeting priority too:

[0x63]=2: 2 is targeted before 3
[0x74]=3: 3 is targeted before 4
[0xa3]=2: 2 is targeted before 3

I suspect there's other values that should be there, but aren't yet (likely 2 per slot, except in the cases where the order makes one impossible). I've put in a few experimental ones, but I don't have any logs that would show if they're right or wrong.

The targeting logic really is hard to fathom...

LostTemple1990 commented 3 years ago

Perhaps it may need a big change if you remove the 0x7* in adjCleaveN According to the source code of target cleave, unit(7) may cast cleave spell to unit 0 , 1 and 2 when there are only units(0,1 and 2) exist in field(no logs proved, I just image this situation from source code) So it needs some logs to verify if you remove it

zealvurte commented 3 years ago

Correct. You'd need an entry like [0x72]={0,1} to remove it from adjCleaveN. I spent some more time with it yesterday and think I cracked the behaviour.

I've decided to rewrite the handling to just have them all in adjCleave and support such table values there, so I don't use adjCleaveN at all now. It's probably less efficient memory and performance wise, but it made the logic easier to read and debug for me. I'm still working on testing some of the values though.

That ends up looking like the below (nils and order are just there to help me visualise targeting priority):

[0x05]=6,   [0x0a]={7,9,11},    [0x07]={9,11},  [0x09]=11,  [0x08]=12,
[0x16]=7,   [0x1b]={8,10,12},   [0x18]={10,12}, [0x1a]=12,  [0x15]=9,
[0x25]=6,   [0x29]=10,      [0x27]=11,  [0x28]=12,
[0x36]=7,   [0x35]={9,10,11},   [0x3a]={9,11},  [0x39]=11,  [0x08]=12,
[0x47]=8,   [0x46]={10,11,12},  [0x4b]={10,12}, [0x4a]=12,  [0x45]=9,
[0x52]=nil, [0x50]=3,   [0x51]=4,
[0x62]=3,   [0x60]=nil, [0x61]=4,   -- 1: UNVERFIED
[0x73]=4,   [0x72]={0,1},   [0x70]=1,
[0x84]=nil, [0x83]=1,   [0x82]=0,
[0x92]=nil, [0x93]=0,   [0x91]=4,   -- 3: UNVERIFIED, 1: UNVERIFIED
[0xa2]=nil, [0xa3]=nil, [0xa4]=nil, [0xa0]=1,   -- 0: UNVERIFIED
[0xb2]=3,   [0xb4]=nil, [0xb0]=1,
[0xc4]=nil, [0xc3]=2,   [0xc0]=1,   -- 4: UNVERIFIED, 3: UNVERIFIED, 0: UNVERIFIED

zealvurte commented 2 years ago

Here's a log for [0xc3]=4 (note this is from 9.2 PTR, so you will be missing spells 350 and 351 for it). log-2319_12-3-cleaves-4.txt