tm,
Thanks for your patience with me. I still have much to learn about VASSAL module programming. That post you sent me was helpful. It should be a part of the “Game Piece” page in the Reference Manual. Is anyone maintaining the Reference Manual?
I guess I didn’t formulate my question clearly enough and that’s why you feel like it’s been answered. Let me try a more precise formulation:
There are 34 different types of traits, starting with Basic Piece and ending with Set Global Property. There are four different “entry points” into a piece:
- A player can select it by left-clicking it.
- A player can trigger a pop-up menu of choices by right-clicking on it.
- A player can type a keystroke that the piece is listening for.
- The engine can fire a keystroke that the piece is listening for.
In each those four different entry points, which of the 34 traits are involved? For a particular entry point, and the traits that are involved in that entry point, in which order are the traits executed?
Not knowing the answer to these questions makes it hard to program in VASSAL. It sounds like you are recommending determining the answer to my question by trial and error, “learn by building modules”. But if I take the trial and error approach, I’ll probably end up coding all sorts of stuff unnecessarily, and my resulting module will be complex and difficult for maintainers to support. In order to create a nice clean module, I need to know the rules of the VASSAL programming language.
From what I’ve seen working with it so far, I get the sense there are two distinct pathways through a piece. If the entry point is mouse clicking (selecting), then it behaves in the way described in that post you sent me. If, however, the entry point is a keystroke, then I get the sense a completely different set of rules apply.
You mention TriggerAction and ReportAction as being exceptions, but I count at least 9 different traits that listen for keystrokes. Some of those determine whether a keystroke makes it to another trait, and in those cases order could matter (or it could be that those “Restrict” type traits apply to all other traits in the piece irrespective of order). From trial and error, so far I’ve determined that ReportAction and GlobalKeyAction both fire before Delete actions, but TriggerActions fire after delete actions. This suggests that there is a list. A list that determines the order in which key listening traits fire when there are multiple traits on the same piece listening for the same keystroke. I confirmed that Delete happens before TriggerAction by moving the Delete above TriggerAction and then below TriggerAction and in both cases the Delete prevented the TriggerAction. But when I removed the Delete alltogether, then the TriggerAction happened. Why did Delete take precedence over TriggerAction in this case? Why is Delete higher than TriggerAction on the list? (“The list” being the order in which key-based traits are executed when multiple traits on a single piece listen for the same key.)
I hope that this clarifies my question. I am probably making a number of mistakes in the way I formulate my question because I am still learning how VASSAL works. I look forward to further enlightenment.