Accessing Masked properties

Technical Support & Bugs
1

Hi Stine, Tim,

I am not happy with the solution I have implemented for accessing BasicName and other properties by GKC’s acting on Decks. It is a fudge that works for now, but may be invalidated by later security work.

I am trying to get my head around why you need to access the BasicName (and other properties) while the counter is actually masked. In ‘real’ terms, it is the equivalent of people looking at cards in the Deck before they are drawn. It should not be necessary.

Can you please explain in words rather than Example counter layouts?

Once the card is unmasked, BasicName is accessible, why can’t you just use the name then?

Is it just a convenience thing? i.e. it is easier to access BasicName while the piece is still in the Deck for use later when it is no longer masked?

Is it because your module has cards already in the Deck at game start?

There may be some easy way around this if I can understand what you are trying to achieve.

Regards,
Brent.

2

Hi Brent,

Did you mean me or another Tim - Do a lot of card stuff but don’t think I’m
involved in this one and felt pretty safe it doesn’t affect anything Ive
done unless you’ve seen something?

Tim

Post generated using Mail2Forum (mail2forum.com)

3

The thing is that not all GKC’s correspond to things that a player would do in a real game. Sometimes they represent actions taken by the game itself, as it were. Like dealing out the cards at the beginning of a game or maybe removing all the cards of type X from the deck and then reshuffling it. I think most of these cases apply to Decks rather than pieces on the board.

rk

Post generated using Mail2Forum (mail2forum.com)

4

Hi,

I have mixed news.

It turns out I just needed to move SEND LOCATION below the SET GLOBAL PROPERTY trait for my cards and accessing BasicName and other markers is ok. However, it ONLY works for markers set above the SEND TO LOCATION trait.

It doesn’t work for the “Color” trait in the example I made in the other thread, as it is below the prototype - where the SEND TO LOCATION is - in the list of individual card traits. Alternatively, if I move the prototype below Color then Color is now masked because the MASK trait is at the top of the prototype. Then it would finally work only cutting the mask trait off the prototype and placing it at the top of each single card, which is tedious work (–> incidentally, feature request: improve multiple card edit to let people add a trait at once for all cards).

Alternatively I can just use triggers firing on the SEND TO LOCATION trait to read all markers after the card is sent, and be done with it (with a cost in terms of command keys necessary, though).

Either way, it doesn’t sound right that one is forced to add MASK traits on individual cards as opposed to just a prototype (first solution) or to add triggers consuming command keys (second solution) to achieve this, though.

Moreover, there is the case Robert hinted to: assume the program (i.e. an hidden engine or generator piece triggered by some event, like turn moving on or user clicking somewhere) wants to remove the cards “foo”, “bar” and “baz” from a masked deck, then there is now no way of doing that, except adding markers below the mask trait with the name of the card reiterated.

Wouldn’t it be simpler to let traits freely read masked properties as in 3.0? Where exactly is the security problem? Fear somebody could hack a module to read other people’s masked cards (properties)? If so, wouldn’t that be like a drop in the ocean and wouldn’t it be better to tackle the all hacking modules problem in a global way (encryption/hashing… whatever) like it was discussed elsewhere on the forum in the past?

Recapping: I can work around this change introduced with 3.1, but is it really a change for the best?

Thanks,
Stefano

Edit: actually rethinking about it it looks like any trait below the MASK trait on a masked card are never visible unless the card is first unmasked (which is what the SEND TO LOCATION placed to the bottom of the list does, I guess). If they were, then setting a global property to the value of the marker Color should work even if Color is defined below the SEND TO LOCATION trait, shouldn’t it? (It did work in 3.0)… confused Stefano

5

Hi Stefano,

This topic is still under discussion between the developers, but the consensus so far seems to be that cards in face-down Decks should be handled differently to a Masked piece sitting out on the play surface.

I have already committed one change to return the old behaviour for cards in Decks. I have found a couple of other things that need addressing, and so need to make more changes, but there should be no need to change your module. Masked Properties in cards in Decks will be available to GKC’s.

However, Masked properties in cards/units that are not in Decks will not be visible except to the player who masked the unit.

Yes, there are security issues. It makes it possible for module designers to inadvertently allow players to identify masked units belonging to other players. Once player A masks a unit, there should be nothing that player B can do to identify any of the features that are masked, no matter what other traits are loaded on top of the mask. Module Designers need to be confident that this is true no matter what other complicated gizmos they add to their units.

Yes, but the point of any encryption/hashing system would be to make it impossible for non-owners to access masked properties - it would not be possible for me to code around it - the data would not be physically accessible on your copy of Vassal running on your machine. So you would be back to square 1, which is why I suggested working around the problem now.

I believe the main issue is the handling of the masked properties in Decks. This will go back to how it worked on 3.0, so I think this should get your module going again.

Regards,
Brent.

6

I’m getting confused also. The position of a Marker trait should not effect finding the value of the marker (unless it is Masked). Your description of what you see with the Color Marker sounds like a bug. Unfortunately, problems like this are extemely difficult to diagnose in a complex module - there are so many other Key Commands happening, it is almost impossible to debug and tell if it is a Vassal bug, or an issue with your module.

Can you create a simplified module that demonstrates clearly the issue?

Again, I’m just lost in the words of the description and can’t picture what the problem is. A simple example would really help.

Regards,
Brent.

7

Sorry to disturb too … :blush:

But let me express what i was talking about Accessing Masked property to Joel in visit in Paris …

It’s just an idea … an trying to enlarge the brainstorming point …

Actually, the owner of a masked element is the player who has taken it or masked it the first time.

-Advantage : The owner is the only viewer.

-Drawback : When you are on an auction system and you want to reveal things for all at the same time … you must trust each player to reveal his proper taken without modifications before revealing (yes i know that i can log a modification with a report trait)…

Why ?

Because an ObscuredtoOther = true or False can be set but only affect the owner of a piece masked (same as Invisibletoother)

The only way to pass over this is to create a Game Master player side which is also included in the mask trait as a side who can reveal. Then you must also trust the Game Master player.

Enlarge the perimeter :

To insure privacy for masked or invisible elements, at the present time with have all … (just my point of view).

But, how to reveal in the same time ?

The creation of GM_ObscurerToOther and GM_InvisibleToOther (GM for Game Master in this sample) can be a kind of way to reveal tokens without looking at the “Ownership concept”.

Just my opinion …

8

Hi, here is an example module. There is a deck set to always draw cards unmasked.

Just right click on the “action” gif to draw a card, send it somewhere to the right of the deck and check that a couple of global properties were set all right on the send.

It works as is, i.e. with the send to location trait in the prototype, below everything else (marker and set global properties traits).

However, if you edit the individual cards in the deck moving the prototype above the Color marker then Color won’t be read anymore (no problem in 3.0). Why is that? It is even below the mask trait now… (but also below the send to location and set global properties traits…).

Same if you move the send to location trait in the prototype above the set global properties trait, then neither Color nor BasicName would be read (no problem in 3.0), but that’s as expected in 3.1 beta with the card still not having been sent (thus still masked), I guess.

Thanks,
Stefano

9

Fantastic! Thanks Stefano, that will make life much easier.

Regards,
Brent.

10

Just noticed,

The security fix prevents inspection of discard decks that are defined face
up and listed by their basic name if the card was discarded by the owner
without being revealed

All the list shows in this case is basicname,basicname to an opposing player
etc… defeats purpose of deck open to inspection by all

Post generated using Mail2Forum (mail2forum.com)

11

Thanks Tim,

I was aware of that. I am working on an overall solution to the problems, but essentially, Decks will go back to have free access to properties.

Regards,
Brent.

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

On 16/05/2008 at 5:21 PM Tim McCaron wrote:

[quote]
Just noticed,

The security fix prevents inspection of discard decks that are defined face
up and listed by their basic name if the card was discarded by the owner
without being revealed

All the list shows in this case is basicname,basicname to an opposing
player
etc… defeats purpose of deck open to inspection by all

Post generated using Mail2Forum (mail2forum.com)

12

Allowing “select specific cards” from a face down deck (still owned by nobody) with a listing by $BasicName$ won’t work either. Not much point having a face down deck while allowing anybody to select a specific card from it, I know, but I was just using it (in 3.0) for debugging purposes.