Property Visibility

Module Design
1

What are properties’ visibility and scope? Global properties are visible to nested pieces? Nested pieces’ properties not visible to global pieces?

Without proper visibility, I’d have to duplicate many properties across game pieces, just so to keep game pieces “in the know”.

2

Ok, before I go crazy and make EVERY property global, just so that every game piece has a chance of peeking at properties they need…

Can someone tell me if there is something I’m missing?

How do I, say, access a Map’s Zone’s property from anywhere? Syntax such as $MapName_ZoneName_PropertyName$ ??

I’m taking a short break, and waiting on any developer who might know property scopes in vassalengine. After that, I’m giving it all up, and making a gigantic list of truly global global properties.

3

Traits within a Counter search for Properties in the following order:

  • Within each Trait of itself in order from the trait at the bottom of the list up to the top
  • Zone Global Properties defined within Zone the counter is currently in
  • Map Global Properties defined with the Map the counter is currently in
  • Global Properties defined at the module level.

A counter can NOT directly acccess:

  • Properties in another counter
  • Zone Global Properties in a zone that it is not in
  • Map Global Properties in a map the it is not in.

Regards,
Brent.

4

I see. No accessors for more nested properties, right? But I’m still hoping… perhaps a global trigger action can call on all relevant game pieces to report their private properties?

1 eg will be getting every relevant game piece to add its own property’s value into a global counter.

Thanks for clearing that scope thing up so concisely!

5

Ah, but that is a different question. You can do this easily with a Global Key Command (GKC). A GKC issues the same Key Command to all counters in the game, based on a Property Expression being true. That Key Command can initiate a Set Global Property command that adds a local property value to an accessible Global Property.

6

But the traits are executed from top to bottom, right? In any case/direction, is each trait fully evaluated before starting on the next one? That is, can we have an earlier trait set a property, and have a later trait see the change in that property?

Also, how are Trigger Actions executed when they have multiple “Perform keystrokes”? And same questions about evaluation as above.

Sorry if questions are a little dry and technical. Is there somewhere I must read?

7

No, when processing KeyStrokes or responding to a request for a property traits are executed from bottom to top in the order you see inthe Piece Definer.

Think of a counter as a Stack of cards with the Basic Piece on the bottom and the other traits layered on top in the order defined. When a command is issued to the counter, or a property is requested, it is first passed to the trait on the top of the stack (i.e. the bottom of the list), If it can’t do the action or satisfy the problem, it hands it on to the next trait below it (i.e. the trait above it in the list) and so on until the Basic Piece is reached.

Note that there is a lot of confusion over what is termed the ‘top trait’ and the ‘bottom trait’. The ‘bottom’ trait in the Piece Definer is the ‘top’ trait in the stack of traits that make up the counter.

The image of the counter is produced in the opposite order, with the base image of the Basic Piece overlayed by any image produce by each subsequent trait below it on the Piece Definer (or above it in our stack of cards analogy).

When a Trigger Action is activated, the KeyStrokes are issued to the current GamePiece one after the other. These KeyStrokes may cause additional Keystrokes to be issued, which will be interleaved in the order they are issued.

Try the draft Vassal Module Designer’s Guide here: mediafire.com/?0tabexd3typmma7

Any comments gratefully received.

8

Thanks! It all works as expected now. So I got the traits processing order reversed!

Another question, regards traits that are Prototypes. Can I arrange the Prototypes such that their traits are processed BEFORE/AFTER other non-Prototype traits? Or does it not matter where (in traits order) I place the Prototypes, because they are always processed FIRST?

9

When a counter is built and placed on the board, the prototypes in the counter are expanded and replaced by traits in the prototypes. The Order is then the standard bottom to top processing. So yes, where you place the prototype trait in the counter definition controls the order in which the traits within the prototype are access with respect to the traits in the main counter definition.