The direction in which Force Cone pushes back is chosen inconsistently. To illustrate, as it happened in a match, C casts force cone to the left, hitting A and B: Code: before after .... a... .a.. .... ...c ...c .b.. b... A moves diagonally to the up and left, while B moves only along the row to the left. Whatever algorithm push back may use (the obfuscation of which is a separate design problem), it's clearly not consistent across rotations of the playing field.
A was facing right. B was facing up. A did not have the immovable trait. (Also, I meant "slide back", not "push back"...)
Additional clarification (and renaming the characters listed), There was a (map, not wall-of-stone) blocked terrain space in between the enemy character (previously 'A', now 'E') and my own character (still 'B'). There was also one of my characters standing at the position now marked 'A': Code: ..E.. .A|.C ..B..
I don't recall... sorry. I managed to set up another situation, though, where the following occurred: Code: before after .%%%. .%%%. ..E%. ..E%. +A+%C +A+%C ..B.. .B... % - impassable, non-blocking (water) + - blocking (wall) E - enemy A,B,C - my characters, C is caster, casting left Also, I dunno if it would be relevant, but the passable terrain around the enemy (but not character B) was covered in smoke in both cases.
Sorry, and here's the row below B: Code: before after .%%%. .%%%. ..E%. ..E%. +A+%C +A+%C ..B.. .B... %%... %%...
I would really love it if slide backs allowed the attacker to choose which square the target(s) get moved to, restricted by the fact that it has to be "away" (i.e. a greater distance away). An alternative would at least be some UI indication of where targets would end up. There are pretty regular questions about how exactly these behave, and I tend to devalue slide backs since I can still never be 100% certain.
