properties and hidden state

The default behaviour for finding the value of a property when there is no such property is to return the name of the property itself. For example, if a field includes $thing$ and there is no property $thing$ then the value of that property defaults to “thing”. Under most circumstances, you can get around this by setting $thing$ to “” or 0 and then you get what you expect.

However, say you have a mouse-over-stack-viewer that displays the value of $thing$ below each piece. If you set a Marker to thing = “”, then you won’t see anything. However, if the piece is hidden, the piece suddenly has no observable property named $thing$ and it will show “thing” below the piece to the opponent.

My first reaction is that if there is no visible property named $thing$, then its value should be “”. My question is, is there anything in VASSAL that depends on $thing$ equalling “thing” if it’s not defined or not visible? I can’t think of a reasonable use for this default behaviour. I would like to change it so that it returns “” if undefined or not visible, because, right now, it’s seems odd.

  • M.

The only reason behind defaulting to the property name was to give some feedback to the module designer. If an action produces a message “The result is value” then there’s at least a clue that the property ‘value’ has not been set. If you produce the message "The result is " then the designer has to dig around to find the name of the property whose value hasn’t been set. That said, this behavior isn’t critical. Nothing else in VASSAL depends on it. Some modules may be depending on the defaults, but I don’t think that’s too likely.

The correct solution here is probably to explicitly eliminate hidden pieces from what the stack viewer shows. For example, if you mouse over an opponent’s stack that has some visible and some hidden pieces, do we currently get the right behavior?

rk

Post generated using Mail2Forum (mail2forum.com)

Instead of “hidden”, I really meant obscured. Right now $PieceName$ returns “Unknown Piece” if obscured. However, “$PieceName$: $thing$” will return “Unkown Piece: thing” if obscured.

I think for this particular case, I would prefer that the mouse over stack viewer says nothing no matter what the “Text below each piece” field says if the piece is obscured. That would preserve the reminder that the field is not set except when the piece is obscured, in which case, you have no business knowing anyway.

However, I also notice that if you show summary statistics above a piece, it will show it even if one, several, or all pieces have those properties obscured. That shouldn’t be.

Here’s a very simple solution: if a property is obscured in the mouse-over-stack viewer, then that property should return “?”. If summary statistics encounter a piece that is obscured, then stack summary should also return “?” for those properties. What do you think?

  • M.

2008/8/27 Rodney Kinney <rodneykinney@comcast.net (rodneykinney@comcast.net)>

Post generated using Mail2Forum (mail2forum.com)

That makes good sense.

rk

Post generated using Mail2Forum (mail2forum.com)

Yes, “?” sounds good for the Stack Viewer. I agree that in general, an obscured, hidden or missing property should return “”, not the property name.

*********** REPLY SEPARATOR ***********

On 28/08/2008 at 12:34 PM Rodney Kinney wrote:

____________________________________________________________

Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au (b.easton@uws.edu.au)

Post generated using Mail2Forum (mail2forum.com)

I think the solution is to introduce a method in Decorator called setExposeMaskedProperties(). This is mentioned in a FIXME in Obscurable.java. However, the note hints that the default should be FALSE which I don’t agree with. The full comment is:

// FIXME: Access to Obscured properties
// If piece is obscured to me, then mask any properties returned by
// traits between this one and the innermost BasicPiece. Return directly
// any properties normally handled by Decorator.getproperty()
// Global Key Commands acting on Decks over-ride the masking by calling
// setExposeMaskedProperties()

I think it should be the other way around – i.e., that CounterDetailViewer should call setExposeMaskedProperties(false) before calling getProperty and then setExposeMaskedProperties(true) after. I can’t predict what’s going to break if false is the default (although Global Key Commands is mentioned – I’m sure there could be others), but at least this way, the change is localised.

Ideally, I would like to add a method called getProperty(key, exposeMasked), but it’s unworkable.

Unless anyone objects, I’ll go ahead and make the change.

  • M.

2008/8/28 Brent Easton <b.easton@exemail.com.au (b.easton@exemail.com.au)>

Post generated using Mail2Forum (mail2forum.com)