Trait order in counters

[jestew]

Hey Brian,

Yes, I've seen your updated docs - many kudos to you for your efforts, sir - they are appreciated, by those of us less informed in the arcane ways!

The warning of 20+ years of modules waiting to be broke is probably the best reason to leave this sleeping dog.

As for your idea of how to upgrade prototypes - yes, something like this was what I had imagined. I had simply thought of numeric layers (1-999) for example, but I do like your idea of symbolic layers - that would allow different 'bins' for traits to be added and the order that each trait was added to the bin determined its order within the bin and the bins are pre-ordered.

[Cattlesquat]

Yeah that would be the same approach.

Also, you appear to be a Snit!!!

[andorman]

I found this thread when trying to troubleshoot some features that seemed to break when updating the Malifaux module to 3.4.3: it seems that the position of the 'can rotate' trait is no longer affecting the 'move fixed distance' trait. Regardless of how I position the traits, the movement always seems to be oriented with respect to the current rotation of the piece. I double checked the module on 3.2.17, and all the ordering effects seem to work appropriately, but I just can't seem to get the position of the 'can rotate' trait to do anything in 3.4.3. Is there a feature update that I'm missing, or is this a new bug that's been introduced?

[Cattlesquat]

Hi Andorman -- please post this in the Technical Support forum, with specific steps on how to reproduce (e.g. a way to boot the specific module and look at a specific piece and do a specific thing and then "3.2.17 - right behavior", "3.4.3 - wrong behavior")

[Brent Easton]

Hi Andorman, Do you still have an issue? I tried your latest module M3E-Malifaux-v1j.vmod out on Vassal version 3.4.3 and the 'Move Fixed Distance' movement direction seems to rotate correctly with the models.

[andorman]

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.

[andorman]

The code changed here:

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

[westjensontexas]

Do you still have an issue?