NON_MOVABLE

morvael · May 8, 2009, 5:23am

How to prevent moving pieces that are NON_MOVABLE, but does stack, with the stack they are in?

When I select an individual piece from stack that is NON_MOVABLE, I can’t move it - ok, but when I select a stack (even when all pieces inside it are NON_MOVABLE) the stack moves…

Brent_Easton · May 8, 2009, 5:37am

What version of VASSAL are you using?

How are you making the piece non movable?

B.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 6:06am

Also I have noticed that I can’t move NON_MOVABLE piece if I select it inside a stack of 2+ pieces. Selecting a lone piece allows to move it every time (propably a lone piece == stack so it moves).

I have created my own simple trait, based on the VASSAL.counters.Immobilized that just returns NON_MOVABLE = true all the time. I didn’t like NO_STACK forced to true in the original trait. It seems however that there are problems as described above when piece stacks normally, so I understand why NO_STACK is forced. However I would love to see that changed.

I’m using 3.1.4.

edit: to be more precise - what I don’t like when NO_STACK is in effect that no longer a nice stack of pieces is drawn on the map and one may think there are less pieces that in reality are. They may be visible in mouse stack viewer but what I’d love to see is to get a stack painted with every piece in it, be it moving or not. And the reason a piece is restricted and cannot move is to better enforce the rules and allow moving the piece only by (for example) SendToLocation etc. (while maintaining a consistent look on the map).

Brent_Easton · May 8, 2009, 6:21am

Well, there is no guarantee that custom traits will work properly with standard VASSAL. You have gone and created your own custom trait that does not behave like any standard VASSAL piece. To support it, you will probably need to create your own custom PieceMover also.

The reason NO_STACK is enforced is because VASSAL.counters.Immobilized implements the ‘Does Not Stack’ trait.

B.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 6:24am

Yes, it implements it but I want to use only the “move piece - never” part of it. And though it looks like easy done by returning NON_MOVABLE = true in fact it’s not because other part of Vassal is not honoring that property fully (and it’s part of core Vassal code).

In current form NON_MOVABLE should be called NON_MOVABLE_WHEN_NO_STACK in order not to confuse the developer…

edit: I can either make my own PieceMover (but I don’t know yet how to force my module to use it) or in the method DeckVisitor.visitStack (inside PieceMover.createSelectionProcessor) there should be added checking if a piece is NON_MOVABLE (treat as not selected) - and that’s all

Brent_Easton · May 8, 2009, 6:32am

Yes, Standard VASSAL does honor it properly, because in Standard VASSAL, you never get a stackable non-movable piece. Why should other parts of VASSAL support a construct that cannot exist in Standard VASSAL?

To support what you want to do, you need to modify other parts of VASSAL to support this new creature you have created.

???

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 6:37am

Ok, I will modify it by extending PieceMover and overriding createSelectionProcessor(). I just wonder what is the proper method of linking the new piece mover to the module? By replacing manually all lines “” inside the buildFile? Or is there a better method?

I said NON_MOVABLE_WHEN_NO_STACK because NON_MOVABLE is not stand-alone (ie a NON_MOVABLE piece is movable when it’s not NO_STACK at the same time).

Brent_Easton · May 8, 2009, 6:50am

Before you start, why do you want non-movable pieces that stack?

You mean replace all <VASSAL.build.module.map.PieceMover> with <MyProject.MyPieceMover>? That would be the easiest way.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 6:58am

Ok, it works and I am happy

Just 5 lines of code modified (comparing to the same part in the original PieceMover).

I want pieces to stack because then the game look nice, like paper game. If there are 4 counters on a hex I want to see 4 counters, not 2 and additional 2 only with mouse stack viewer. Being unmovable (you can’t force that in paper game, but the rules says explicitly that the counter will not move anywhere - for example location control marker - it should stay in a given hex for the entire game) shouldn’t result in counter losing it’s 3rd dimension. With one such counter per hex you can live with it, but I have more than 1 and it starts to look ugly then.

If you would ever like to add that feature to the original Vassal:

PieceMover lines 234-252 (now)

[code] int selectedCount = 0;
for (int i = 0; i < s.getPieceCount(); i++) {
if (Boolean.TRUE.equals(s.getPieceAt(i)
.getProperty(Properties.SELECTED))) {
selectedCount++;
}
}

    if (((Boolean) GameModule.getGameModule().getPrefs().getValue(Map.MOVING_STACKS_PICKUP_UNITS)).booleanValue() || s.getPieceCount() == 1 || s.getPieceCount() == selectedCount) {
      DragBuffer.getBuffer().add(s);
    }
    else {
      for (int i = 0; i < s.getPieceCount(); i++) {
        final GamePiece p = s.getPieceAt(i);
        if (Boolean.TRUE.equals(p.getProperty(Properties.SELECTED))) {
          DragBuffer.getBuffer().add(p);
        }
      }
    }[/code]

I have changed them to (in reality this is in my own subclass of PieceMover):

[code] int selectedCount = 0;
int noMoveableCount = 0;
for (int i = 0; i < s.getPieceCount(); i++) {
if (Boolean.TRUE.equals(s.getPieceAt(i).getProperty(Properties.NON_MOVABLE))) {
noMoveableCount++;
} else
if (Boolean.TRUE.equals(s.getPieceAt(i).getProperty(Properties.SELECTED))) {
selectedCount++;
}
}

    if ((noMoveableCount == 0) && (((Boolean) GameModule.getGameModule().getPrefs().getValue(Map.MOVING_STACKS_PICKUP_UNITS)).booleanValue() || s.getPieceCount() == 1 || s.getPieceCount() == selectedCount)) {
      DragBuffer.getBuffer().add(s);
    }
    else {
      for (int i = 0; i < s.getPieceCount(); i++) {
        final GamePiece p = s.getPieceAt(i);
        if ((Boolean.TRUE.equals(p.getProperty(Properties.SELECTED))) && (Boolean.TRUE.equals(s.getPieceAt(i).getProperty(Properties.NON_MOVABLE)) == false)) {
          DragBuffer.getBuffer().add(p);
        }
      }
    }[/code]

I don’t know yet if I should change anything in visitDefault method? I think not but you may know better.

Brent_Easton · May 8, 2009, 7:51am

Can you send me the changes?

There is no reason that should not go into VASSAL core.

Your reasons for wanting non-movable stacking pieces are reasonable, I can see other people wanting this also.

I think what is really needed is that the ‘Does Not Stack’ trait gets an ‘Allow Stacking’ option! It isn’t really a ‘Does Not Stack’ Trait, it is a ‘Does not stack and Immobility’ trait.

B.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 8:17am

I have shown the code in my previous post. I’m glad you now understand why not-moving doesn’t really require not-stacking at the same time

Brent_Easton · May 8, 2009, 9:19am

I meant what where the changes you made to PieceMover?

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

morvael · May 8, 2009, 9:33am

Maybe this mail2forum thing didn’t send you the code. The intended change to PieceMover would be to adjust part of the createSelectionProcessor() method as shown above (visible on the forum) - so it treats NOT_MOVABLE pieces as not selected while deciding whether to drag entire stack or individual pieces.

uckelman · May 8, 2009, 12:29pm

Thus spake “Brent Easton”:

Having a ‘Does Not Stack’ trait with an ‘Allow Stacking’ option is going
to appear as nonsense to virtually everyone. One or both of these should
be renamed to reflect what they really do.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Tim_M · May 8, 2009, 12:42pm

we could have
Does not Stack trait and Does Stack trait

Both identical in terms of existing functionality except for the handling of stacking

From: Joel Uckelman uckelman@nomic.net
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Friday, May 8, 2009 7:29:15 AM
Subject: Re: [Developers]Re: NON_MOVABLE

Thus spake “Brent Easton”:

Having a ‘Does Not Stack’ trait with an ‘Allow Stacking’ option is going
to appear as nonsense to virtually everyone. One or both of these should
be renamed to reflect what they really do.

–
J.

Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

uckelman · May 8, 2009, 1:23pm

Thus spake Timothy Mccarron:

So I should expect a piece without either trait neither to stack nor not
to stack? What if it has both, will it stack and not stack at the same
time? That’s intriguing.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Tim_M · May 8, 2009, 1:36pm

thats easy,

if it has neither it will behave normally and stack without any of the other conditions that we could apply available with the DNS (or new DS) trait
if it has both, the piece will only obey the last of either trait in the stack - this is similar to what happens if you have 2 marker traits with the same property name but different property values

From: Joel Uckelman uckelman@nomic.net
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Friday, May 8, 2009 8:23:09 AM
Subject: Re: [Developers]Re: NON_MOVABLE

Thus spake Timothy Mccarron:

So I should expect a piece without either trait neither to stack nor not
to stack? What if it has both, will it stack and not stack at the same
time? That’s intriguing.

–
J.

Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Tim_M · May 8, 2009, 2:21pm

Thinking about this more, it may be that 2 different named traits will not act to overide another like the 2 marker example, so just in case, an alternative

Current behavior is a basic piece w/ nothing on it (no traits) is going to default to stack on a layer it is assigned to by designer (or top most layer “null”? if none defined by GPL)

A basic piece with a DNS trait is being told it is in a forced condition to ignore default stacking regardless of layer it belongs to but will obey its layer position still in the case of multiple layers (at least it should)

DNS provides added functionality of piece manipulation - selection and mobility criteria

So if creating an opposite trait “Does Stack” to DNS in order for stacked pieces to have the same extended functionality available in DNS is not the best thing to do, or seems unintuitive to add based on current behavior, maybe it would make more sense to move the extended functionality out of DNS instead to its own trait “Piece manipulation”. DNS becomes a true override condition of normal stacking behavior only - thats all it does, default stacking is left alone and now any piece regardless of stacking can also have mobility and selection criteria added to them through the Piece manipulation trait instead

From: Timothy Mccarron timothy.mccarron@sbcglobal.net
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Friday, May 8, 2009 8:36:26 AM
Subject: Re: [Developers]Re: NON_MOVABLE

thats easy,

if it has neither it will behave normally and stack without any of the other conditions that we could apply available with the DNS (or new DS) trait
if it has both, the piece will only obey the last of either trait in the stack - this is similar to what happens if you have 2 marker traits with the same property name but different property values

From: Joel Uckelman uckelman@nomic.net
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Friday, May 8, 2009 8:23:09 AM
Subject: Re: [Developers]Re: NON_MOVABLE

Thus spake Timothy Mccarron:

So I should expect a piece without either trait neither to stack nor not
to stack? What if it has both, will it stack and not stack at the same
time? That’s intriguing.

–
J.

Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Brent_Easton · May 8, 2009, 2:29pm

The name of the ‘Does Not Stack’ trait should change to something that reflects it’s actual action of 'Stacking, Selection and Movement Restrictions

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

rk1 · May 8, 2009, 8:08pm

It’s reasonable to have pieces that stack but don’t move. (In fact, VASL has this now, which requires its own PieceMover implementation similar to what morvael wrote.)

From the user’s point of view, it’s not acceptable to change the meaning of existing traits, so we should keep ‘Does Not Stack’ as is – the piece won’t stack and may or may not be movable. We should add an additional ‘Does Not Move’ trait – the piece won’t move and may or may not stack. The fact that there will be two ways to make a piece that doesn’t stack or move is not a serious downside.

rk

Post generated using Mail2Forum (mail2forum.com)