In the real boardgame, at the beginning of the Round each player needs to roll Nd8 (N is a scenario property). The d8 have these faces: 3 Green, 2 Blue, 1 Red, 1 Purple, 1 Yellow. Once rolled, the player pick N tokens of the colours showed by the d8.
The module i’m modifying implemented this by creating a deck of tokens, from which you right-click to draw multiple cards, enter “N” in the popup that appears, drag from the deck, and finally right-click on the stack of tokens you just dragged and click “reveal”: this randomizes the 8-level layer in each of the tokens, and you finally know what tokens you got.
This is … “too far” from the real experience. And also, you dont have green/blue/red/purple/yellow tokens, but just “generic tokens”, forcing me to do tests and tricks if i want to allow specific action to different colour tokens.
Instead, i would like to have specific-colour tokens, and maybe a piece on the board that fires an action that sends (creates? summons? Clones?) these tokens to a specific zone in the board. The token are visible to all the players, but a bonus thing will be if they are owned by the player that fired the action (so they could be only moved/played by him).
I would put the tokens in separate decks, one for each colour, and use a random number from 1 to 8 to send a token from the correct colour deck into the stack of the player who picks the tokens.
There is a “Send to Location” trait you can use to send a token to a destination on the board.
As for the generic tokens, you probably will have to add a Marker trait to each token that indicates the colour of the token.
If the number to draw N is fixed by the scenario, it presumably does not change over the game. In that case, it can be set, and locked, in a ScenarioOption. It can of course also be set via a ChangePropertyButton. In any case, it can define a global property named NTokens.
Next, add a Turn counter, and add a Hotkey when entering a new round. That hotkey - say RollTokens is then send to some hidden piece.
and the token pieces should define a SendtoLocation trait with the key MoveToTokenStack to move the token piece to an appropriate place on the board or similar.
@cholmcc : thank you for this very detailed answer (and sorry for this late reply)
I’m building what you said and it “kinda” works: i see the report when the TurnCounter hotkey gets fired, and i can make the TriggerAction on the piece works, but only using a menu command: the turn hotkey Named Command RollTokens doesn’t “reach” the piece.
I’m pretty sure i’m missing something obvious here… maybe just where to put that “hidden” piece.in order for the NamedCommand RollTokens to “reach” it (right now, it is visible, on a board in the module map).
Hotkeys or named commands send from the Turn Counter are only sent to the module as a Global Key Command. To send the hotkey or named command on to a piece you need a trampoline Global Key Command.
Suppose your Turn Counter send the named command RollInitalTokens. Then you need a Global Key Command in the module that triggers on that named command and sends it on to the piece - e.g.,
Global Key Command
Hotkey: RollInitalTokens
Global key command: RollTokens
…
What happens is that the Turn Counter issues the named command RollInitialToken, which is picked up by the module Global Key Command. That Global Key Command then sends the named command RollTokens to the appropriate pieces.
The Turn Counter hotkey or named command is never seen directly by pieces.
Thanks.
Propagation of these command is a bit hard to digest, between historical naming (hotkey, toolbar buttons) and globalwhatever(this at least for a non-native english speaker). So i was suspecting that my problem was something similar.
I’ve also learned that whateverCommand are not sent to Game Piece Palettes (-edit- i think this should be mentioned in the docomentation), so a piece can only be pulled down from there by a “Place Marker” trait inside another piece, and only then sent to a location; and this was another problem on top of my first one
Now, i have two more questions, which are still related to the solution of the original problem, but slightly more generic:
How can i “assign” the ownership of a piece to a player (say, Player1)?
I’ve read somewhere that this happens when you send a card from a deck to another deck: if the latter is owned, the card inherit (or just gain) that ownership. If this is the only possible way, should i use a “deck of tokens” as “source” instead of a Piece Palette, and send the tokens to a player-owned deck instead than to a map zone?
Pieces in the Game Piece Palette are really only there for one to add them (either manually or via Place Marker trait) later on. The do therefore not receive hotkey commands nor named commands. Only pieces on some map will get those.
That’s why one often needs a hidden piece (a piece with an image of size 0x0 pixes) that is always present on a map (via a At-Start Stack). It could be also be a turn marker or similar ever present marker. That piece then receives the Global Key Commands and delegates it elsewhere.
One thing a hidden piece can do, is to use Place Marker traits to pull in pieces from a Game Piece Palette. Note the configuration Keystroke to apply after placement of the Place Marker trait which allows you to execute a command on the newly placed piece - for example a Send to Location trait. Also note the configuration Set Dynamic Properties in marker which allows the hidden unit to pass data on to the newly placed piece. For example, the set Dynamic PropertyTargetLocation to something depending on how the hidden marker was activated. Another way to acheive something similar is via a Global Property.
Depends very much on what you mean by “ownership”.
Should the piece only be visible to a (set of) particular side(s)? Then you need the Invisible trait
If the piece should be visible but its details hidden, then you need the Mask trait
Should certain commands only be allowed in particular circumstances - including current active side? Then you need the Restrict Commands trait
Should certain traits not be active for a (set of) particular side(s)? Then you need the Restricted Access trait
You can of course combine all these in a single piece or prototype. Important: Pay attention to the order of the traits.
If you consider the list of traits as “decorators”, then the bottom most, trait must be a Basic Piece traits. This trait is shown in the editor as the top trait. All traits then decorate all previous traits in the list.
(This is how it is implemented in the code - traits optionally contain another, decorated, trait, with a back link to any possible decorator).
For example, imagine the piece defined (as shown in the editor GUI) by the traits
Basic Piece
Send to Location
Restrict Access
Place Marker
Here,
Basic Piece does not decorate any other trait.
The Send to Location decorates the Basic Piece.
The Restrict Access decorated the Send to Location which in turn decorates the Basic Piece.
Finally, the Place Marker decorates Restrict Access, which decorates Send to Location, which decorates Basic Peace.
A trait can only act on other traits that they (possibly indirectly) decorates. That means, when processing commands, we start from the outer-most, non-decorated, trait and work our way in toward the Basic Piece.
There are two exceptions to this:
When drawing the piece, the traits are drawn in reverse order - start at Basic Piece, then any trait that decorates that seeking out to the outer-most un-decorated trait.
When aTrigger Action or Report trait in the list, its execution is deferred, in reverse order, until the list has been processed (until we reach the Basic Piece). Incidentally, this is why one cannot report on actions before they have actually completed.
Note, traits in a Prototype Definition referenced by a Prototype trait are inserted into the piece list of traits, in order and where the Prototype trait appears when the piece is constructed (usually on module load).
