I have just discovered the “Replace with Other” trait and find it very useful… But… One change would make it enormously more powerful…
The ability to select a DECK as opposed to a specific card in the DECK. This would allow a single card to be drawn from the Deck obeying the normal deck rules (e.g., random, fixed order, etc.).
Can you fully describe the use case? If it’s what I think you’re describing, there are easy ways that already exist to accomplish the goal.
I am trying to create a module from scratch to implement an old game - Throneworld. The game is hex based and depending on setup (2p, 3p, 4p, 4p-variant, 5p, 6p, 2p-intro, 3p-intro, 4p-intro) the board is populated from 4 different decks: Throne Worlds, Inner Worlds, Outer Worlds, Fringe Worlds, plus there are out of play hexes and player start locations.
I have implemented a throw-away counter with decision logic that will (depending on player setup), locate the correct type of world in that hex. Every hex will have it’s own decision logic counter.
Currently, I found it trivial to use the “Replace with Other” to implement the Blank-Out-of-Play hexes. But because I can’t select a deck, the same approach won’t work for pulling from the various decks.
Appreciate any help/advice…
I threw together my idea quick and verified it works, it only took a few minutes. If you want a demo module I can link one tomorrow.
The basic plan would be to have all the hexes that will populate your map have a prototype that has a pair of Dynamic Properties to store X and Y coordinates and a Send to Location that will send a hex to the value of those properties. They all start in the 4 decks you identified, whether those decks are ordered or randomized is irrelevant for this to function.
A placeholder or throwaway counter that starts on your grid to be replaced by a hex from whichever deck needs a minimum of 3 traits: a Global Key Command (for fetching a hex to replace it), a Delete trait to get rid of itself, and a Trigger to initiate those two and sequence them correctly. The GKC identifies a deck to take from, grabs precisely 1 piece, and slips the values of the CurrentX and CurrentY properties of the originating placeholder hex directly into the Dynamic Properties of the hex being fetched from a deck (this is why those DPs went into the prototype). Then it sends the key command for the hex to fire its Send to Location trait–destination is the XY coords you just copied into it from the placeholder hex.
Call it all with a simple Trigger to fetch the replacement hex and then have the placeholder hex delete itself.
If a placeholder hex could be replaced by something from more than one of the 4 decks, you’ll need more GKCs to account for all possibilities, and maybe more Triggers with whatever logic dictates which deck something is taken from. But the core logic isn’t too complex: store the location of the placeholder, GKC to get replacement off a deck, have replacement send itself to stored location, delete the original.
Thanks much - greatly appreciated! If you don’t mind linking the demo module that would be useful, but I think I’m following your logic.
However, I also think enhancing the “Replace w/ Other” to allow decks would still be a great enhancement…
Assuming it will work equivalently, I’m guessing I can replace X/Y in your example with the grid location (for counters to be centered in grid).
Yes, if you have a grid numbering scheme defined, then only one Dynamic Property on the hexes should suffice, and you’d store gridLocationLocationName and pass that to the StL instead.
EDIT: correct erroneous reference, see below.
Here’s a very stripped down demo: Test Module
Start a new game, clone the initial gold start hex piece a few times, then use “Replace this Hex” on it.
Downloaded your demo (which works great), but having trouble getting it to work in a grid.
Issues:
Using the CurrentX/CurrentY properties (as your demo), the piece is not centered on the calling piece but offset considerably.
$gridLocation$ doesn’t actually seem to be implemented in Vassal. (see both results of calling it in chat log and the picture of available basic piece properties).
I think I have diagnosed the cause of the offset when using the CurrentX/CurrentY construct. I’m fairly sure it’s a bug.
The main map had padding: Horizontal=100, Vertical=50.
These appear to be (incorrectly) being applied when sending a piece. When I set these both to zero (0), I see the following:
Note that these appear to be aligning in the lower left corner of the image, rather than the image centroid.
Looks like you could use LocationName based on your diagnostic report output there. gridLocation should be defined (see the Grid Numbering reference) unless you overrode it somehow.
I don’t have any suggestions on the off-center issue.
Unless these two items are being prevented from stacking together, the above will be normal.
No major heartburn w/ aligning on lower left of image, just wasn’t what I expected.
However, I do think there is a bug around how map padding is being improperly applied when sending a piece.
Look in the component that contains the grid. I think you will find an option the determines how the LocationName will be reported.
After much fiddling about, I got send to Grid location using $LocationName$ working.
Thanks very much for all the pointers!
Yes, gridLocation only exists for the GridNumbering component to determine how the LocationName property is reported. gridLocation exists nowhere else.
