3.2.2 bug: adding a stack to an expanded stack

i play OCS via vassal modules and some use 3.1.20 and some use 3.2.2.

if i move a stack of two units into a large stack that has been expanded via double click, the order of the incoming stack is reversed.

for example, an ocs inf div typically has a step loss marker under it. when i move the two counters together into an expanded stack, the step loss markers goes from being underneath the inf div to on top of it in the new stack.

this also happens with trucks carrying a supply marker.

if i move the inf div stack into a non-expanded stack this reversal of stacking order does not happen.

this bug is not in 3.1.20.

Thus spake perrya:

i play OCS via vassal modules and some use 3.1.20 and some use 3.2.2.

if i move a stack of two units into a large stack that has been expanded
via double click, the order of the incoming stack is reversed.

for example, an ocs inf div typically has a step loss marker under it.
when i move the two counters together into an expanded stack, the step
loss markers goes from being underneath the inf div to on top of it in
the new stack.

this also happens with trucks carrying a supply marker.

if i move the inf div stack into a non-expanded stack this reversal of
stacking order does not happen.

this bug is not in 3.1.20.

This looks like a bug in 3.2.2. Please try 3.2.1 and 3.2.0 and let us
know if the bug happens there as well.


J.

Thus spake perrya:

i play OCS via vassal modules and some use 3.1.20 and some use 3.2.2.

if i move a stack of two units into a large stack that has been expanded
via double click, the order of the incoming stack is reversed.

for example, an ocs inf div typically has a step loss marker under it.
when i move the two counters together into an expanded stack, the step
loss markers goes from being underneath the inf div to on top of it in
the new stack.

this also happens with trucks carrying a supply marker.

if i move the inf div stack into a non-expanded stack this reversal of
stacking order does not happen.

this bug is not in 3.1.20.

I’ve found the breaking commit—5605—so we should be able to fix the
problem for 3.2.3. I’m amazed that nobody noticed this before, since
revision 5605 is from May 2009!


J.

Thus spake Joel Uckelman:

Thus spake perrya:

i play OCS via vassal modules and some use 3.1.20 and some use 3.2.2.

if i move a stack of two units into a large stack that has been expanded
via double click, the order of the incoming stack is reversed.

for example, an ocs inf div typically has a step loss marker under it.
when i move the two counters together into an expanded stack, the step
loss markers goes from being underneath the inf div to on top of it in
the new stack.

this also happens with trucks carrying a supply marker.

if i move the inf div stack into a non-expanded stack this reversal of
stacking order does not happen.

this bug is not in 3.1.20.

I’ve found the breaking commit—5605—so we should be able to fix the
problem for 3.2.3. I’m amazed that nobody noticed this before, since
revision 5605 is from May 2009!

At PieceMover.java:607, we have this:

for (GamePiece piece : draggedPieces) {
comm = comm.append(movedPiece(piece, mergeWith.getPosition()));
comm = comm.append(map.getStackMetrics().merge(mergeWith, piece));
}

Before r5605, we had this:

comm = comm.append(movedPiece(dragging, mergeWith.getPosition()));
comm = comm.append(map.getStackMetrics().merge(mergeWith, dragging));

If I switch these lines back to how they were pre-5605, then I don’t
see the reversed stacking problem when dragging pieces onto expanded
stacks.

It’s not clear to me that this is the correct change. Brent?

I’ve added this to our tracker as Bug 9967:

vassalengine.org/tracker/sho … gi?id=9967


J.

Hi Joel,
You are in the right spot, but the fix is not quite right.

dragging contains a list of all pieces that the user starts dragging
draggedPieces contains a list of the pieces that are allowed to exist at the destination point.

The problem seems to be that the pieces recorded in draggedPieces is reversed from what it should be.

However, I don’t quite understand why the code is even entering this section when dropping onto an extended Stack, this code should only be executed when the destination is a Deck. I will look into this further.

Brent.

Thus spake Brent Easton:

Hi Joel,
You are in the right spot, but the fix is not quite right.

dragging contains a list of all pieces that the user starts dragging
draggedPieces contains a list of the pieces that are allowed to exist at
the destination point.

The problem seems to be that the pieces recorded in draggedPieces is
reversed from what it should be.

However, I don’t quite understand why the code is even entering this
section when dropping onto an extended Stack, this code should only be
executed when the destination is a Deck. I will look into this further.

The way the blocks are nested right now, it looks like the Deck code
runs from 588 to 605, and the else block at 581 is for the case where
ther is something to merge with generally.


J.

On 12/03/2013 9:47 AM, Joel Uckelman wrote:

Thus spake Brent Easton:

Hi Joel,
You are in the right spot, but the fix is not quite right.

dragging contains a list of all pieces that the user starts dragging
draggedPieces contains a list of the pieces that are allowed to exist at
the destination point.

The problem seems to be that the pieces recorded in draggedPieces is
reversed from what it should be.

However, I don’t quite understand why the code is even entering this
section when dropping onto an extended Stack, this code should only be
executed when the destination is a Deck. I will look into this further.
The way the blocks are nested right now, it looks like the Deck code
runs from 588 to 605, and the else block at 581 is for the case where
ther is something to merge with generally.

Ok. Leave it with me, I will have a closer look tonight.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Thus spake Brent Easton:

Hi Joel,
You are in the right spot, but the fix is not quite right.

dragging contains a list of all pieces that the user starts dragging
draggedPieces contains a list of the pieces that are allowed to exist at
the destination point.

The problem seems to be that the pieces recorded in draggedPieces is
reversed from what it should be.

However, I don’t quite understand why the code is even entering this
section when dropping onto an extended Stack, this code should only be
executed when the destination is a Deck. I will look into this further.

Brent.

Your fix isn’t quite right—it breaks Undo.


J.

On 13/03/2013 9:59 AM, Joel Uckelman wrote:

Thus spake Brent Easton:

Hi Joel,
You are in the right spot, but the fix is not quite right.

dragging contains a list of all pieces that the user starts dragging
draggedPieces contains a list of the pieces that are allowed to exist at
the destination point.

The problem seems to be that the pieces recorded in draggedPieces is
reversed from what it should be.

However, I don’t quite understand why the code is even entering this
section when dropping onto an extended Stack, this code should only be
executed when the destination is a Deck. I will look into this further.

Brent.
Your fix isn’t quite right—it breaks Undo.

Ah, yes. It would. Will have another look.

Brent.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Brent’s fix is in trunk@svn8577. It works for me. Try VASSAL-3.2.3-svv8577 and let us know whether this solves the problem for you.

vassalengine.sourceforge.net/builds/