REPLACE WITH OTHER bug? (3.1.18 and 3.2 beta1)

I have a piece named FOO that on some commands triggers:

  1. a move fixed distance (to move some pixels to the right, say)
  2. a replace with other (to replace itself with a piece named BAR)

This does [size=150]not[/size] work if (and only if) FOO has the does not stack trait defined.

What happens is that FOO will move and stay on the board, while the replacement BAR will appear in the original location. It seems to me that replace with other is buggy and forces a send back to $oldLocation$ (but only of the replacement…) when attempting to position the new piece above/below something with does not stack defined.

I think this is a bug because replace with other should not care/worry about the does not stack trait. After all pieces that do not stack can still stay one above the other (they just won’t form a stack)… Moreover, this is a “replacement” and why would the original piece not be replaced at all?

For the record: I solved the problem by replacing first and having the replaced piece move next. This works even if the replacement has the does not stack trait defined itself. The attached test module demonstrates the issue. [attachment=0]rwo_bug.vmod[/attachment]

Thus spake barbanera:

I have a piece named FOO that on some commands triggers:

  1. a move fixed distance (to move some pixels to the right, say)
  2. a replace with other (to replace itself with a piece named BAR)

This does not work if (and only if) FOO has the does not
stack
trait defined.

What happens is that FOO will move and stay on the board, while the
replacement BAR will appear in the original location. It seems to me
that__ replace with other__ is buggy and forces a send back to
$oldLocation$ (but only of the replacement…) when attempting to
position the new piece above/below something with does not stack
defined.

I think this is a bug because replace with other should not
care/worry about the does not stack trait. After all pieces that do not
stack can still stay one above the other (they just won’t form a
stack)… Moreover, this is a “replacement” and why would the original
piece not be replaced at all?

For the record: I solved the problem by replacing first and having the
replaced piece move next. This works even if the replacement has the
does not stack trait defined itself. The attached test module
demonstrates the issue.

Is this still a problem with 3.2.2?


J.