Trait order in counters

Sorry to be so late getting back to this. To be more specific, there are 2 move fixed distance traits which are used in the module - one of which is intended to use the ‘can rotate’ trait, the other is not: ‘Move’ should follow it, while ‘Nudge’ should not. This is especially problematic because of the asymmetry in how the translate function rounds integer values - it seems to apply a ceiling function to the values, so it biases movement toward the positive direction.

The bug was introduced in the rework to Translate in I think 3.2.2:
// Handle rotation of the piece, movement is relative to the current facing of the unit.
// Use the first Rotator trait below us, if none, use the highest in the stack.
FreeRotator myRotation = (FreeRotator) Decorator.getDecorator(this, FreeRotator.class);
if (myRotation == null) {
myRotation = (FreeRotator) Decorator.getDecorator(Decorator.getOutermost(this), FreeRotator.class);
}

If it fails to find a rotator below itself, instead of properly applying the movement unrotated, it retrieves any rotator anywhere else in the stack, hence nullifying any trait order effects. The workaround is to just add a dummy ‘can rotate’ trait below the first translate trait.

The code changed here:

Merge pull request #15 from BrentEaston/Bug_12948_Move_Fixed_Distance…
commit 5978d37e8180e71cd14567f74761ec86390b9a65

@Cattlesquat : Hey Brian - could you update your link to the trait order image - looks like it broke when the forum got moved. I think it’s superuseful. And maybe a link to the discussion you wrote in the Reference Manual?

PS. Yeah, I’m a Snit! Snit’s Revenge! was the first module I attempted to write but SJ didn’t want me to post it to the internet - so it remains in my private archive.