Restricted Access not working with custom trait

Module Design
1

I am working on a module for which I have implemented some custom traits. I want one of these traits to be public, and one to be restricted to the piece owner. However, I have discovered that for pieces which include my custom traits, the Restricted Access trait doesn’t work and any player can access all of the piece’s traits. (Not just my custom traits; all of the traits in the trait list which appear before the Restricted Access trait, which should be restricted, are accessible.)

The obvious assumption is that either I’m clobbering something, or else that I’m not implementing some necessary logic in the custom traits. My custom traits are based on some existing traits, though, so I’ve looked at their code fairly extensively, and nothing jumps out at me as being an obvious candidate for something I’ve screwed up.

I am setting the “Also belongs to initially-placing player” flag in the trait editor, which sets restrictByPlayer to true in the Restricted class.

It seems likely I am doing something wrong, or possibly this is a bug? Either way, any suggestions or assistance would be welcomed.

Regards,

2

Any traits you want restricted must be above the Restricted Access trait in the trait list. When you say “appear before”, I’m not sure if you meant prior too the RA trait (listed underneath) or above the RA trait. …so, I thought I’d mention this in case this may be the problem.

3

Thus spake “L.Tankersley”:

It seems likely I am doing something wrong, or possibly this is a bug?
Either way, any suggestions or assistance would be welcomed.

For custom code questions, it can help if you make the code available.

–
J.

4

[DrNostromo: I understand the trait ordering issue; it’s not that.]

Here is what I did this morning:

I copied the TableInfo.java code into a new class of my own, called TableInfoTest.java. The only changes I made were:

  1. putting this in my own package rather than VASSAL.counters
  2. added a few imports (GamePiece, KeyCommand, PieceEditor) needed to address errors arising from (1)
  3. changed “TableInfo” to “TableInfoTest” throughout
  4. changed String ID from “table;” to “tabletest;”
  5. changed getDescription() to return “TableInfoTest” rather than “Spreadsheet”

I modified my MyCounterFactory.java to include:

	     ...else if (type.startsWith(TableInfoTest.ID)) {
	    	 piece = new TableInfoTest(type, inner);
	     }

I copied the .class files into my module file and fired up the VASSAL editor.

I created two pieces in a game piece palette, with the following traits (in order as listed in the piece editor):

PIECE #1:

BasicPiece
Text Label
Restricted Access (initial owner: Observer, also owned by placing player)

PIECE #2:

BasicPiece
TextLabel
TableInfoTest (to add this trait I had to import my class using the Import button in the piece editor)
RestrictedAccess (initial owner: Observer, also owned by placing player)

I saved the module and started a game with 2 players (Side A and Side B; neither was observer). Player A copies a piece of type #1 to the map and verifies he can access the label trait. Player B cannot access the trait – so far, so good.

Now player A copies a piece of type #2 to the map. Player B can access all of the traits of piece #2 – not good.

Now player A copies a third piece, this one also of type #1. Player B can access the label trait of this piece, too. Huh? It seems like having a piece on the map that includes the custom trait screws up restricted access for other pieces that are created later, even if they lack the custom trait.

5

It probably isn’t working because you put it into your own package (which you say you did) but did not create a custom command encoder whch would extend the basic command encoder and edit the vassal buildfile to point to the new custom command encoder in the new package (which you dont say you did)

6

No, actually, I did this as well – I just didn’t do it this morning which is why I didn’t think to include it in my list of things I did.

7

You mentioned the first Piece #1 could not be read by player B (as intended) before Piece #2 was placed on the board. You also mention the second Piece #1 could be read after Piece #2 was placed, but you don’t mention whether player B could read the first Piece #1 after Piece #2 was placed. I’m guessing it can, but the answer might help narrow down the possibilities of what happened.

8

Sorry, I thought I mentioned that but I guess I didn’t. No, after the placement of the problematic piece #2, the first piece #1 was still restricted; that is, player B could not access the trait of the first piece that was placed even after the piece with the custom trait was placed. As noted, however, player B could access the trait of an identical piece that was placed after the custom trait piece was placed.

I hope that’s clear; after rereading the above the term “piece” is starting to lose all meaning in my brain…