The “Within a Deck, apply to Fixed number of pieces” for a Global Key Command isn’t functioning as I expected. If I apply it to only 1 card, it applies it to the top card on the deck, regardless of it it actually fulfills any Matching Property. So if my Matching Property is Type=Red. It will only look at the top card and take it if it is Red, otherwise, it does nothing. I would have expected it to search the deck and take the first Red card it finds. So next, I created a Global Property called “Already_Drawn”, which I intend to cycle between 0 and 1. I added another && condition to the Matching Property so it is: DeckName=“Card Deck”&&Type=“Red”&&“Already_Drawn==0” and set it to search the entire deck. Already_Drawn changes to 1 once the Send To Location fired once, so a Restrict Commands should prevent any more cards from being drawn. My last step was to figure out where in the sequence I should place a second Set Global Property so that Already_Drawn resets to 0 momentarily after the next “Draw Card” click, so that it allows just a single card to be taken again. I tested this and it works. Is this the best solution or is there a cleaner way to do this?
That’s more or less how I generally do similar things.
What I do with situations like this is have a phantom deck and if I want a card with Type=Red, I would send a command to the deck to move all Type=Red cards to the phantom deck, draw one card from the phantom deck and then send them all back to the regular deck. You can even create the phantom deck on a visible board, if you like, as it happens so fast, no one will notice a deck popping in and out of existence.
As do I. I opened Bug 12519 (vassalengine.org/tracker/sho … i?id=12519) on this very issue some (long) time back, but have never had a chance to get back to it. I’d like to get this one sorted out.
I have worked out a fix for this. This is one of those bug case where I can’t think of any reason why you would want this to function the way it does now. But is there some module that depends on it? I suspect no-one actually uses this functionality (Select fixed number from Deck selected by matching properties) because it just doesn’t work.
Joel, I’m wondering whether we need a new Preference tab ‘Compatibility’ to hold our slowly growing list of bug workaround preferences? I would start it off with ‘Disable DirectX D3D pipeline?’, ‘Drag ghost bug correction?’ and ‘Moving stacks should pick up non-moving pieces’ for starters.
Oh wow, yeah I find it difficult to imagine that anyone could have managed to even make a module dependent on that. A little bit too broken to need a compatibility preference, I’d guess.
But I’m totally behind the Compatibility preference tab. If the cool new chatter were to be approved, it be a customer as well (safeguard against dependent modules that accidentally trigger HTML or the color properties).
Brent,
If you recall on another thread, I mentioned that when I rapidly clicked undo, units disappeared from force pools, never to return. My best guess is that bug is also related to this bug. I implemented the solution above (using a boolean for Already Drawn) and it works but feels clumsy. Players click to purchase a unit and it searches a force pool deck, pulls the first unit that matches, then a true boolean result stops additional draws. My hunch is that switch combined with units and searches flying all over the place stumbles out of sequence with the rapid undo clicks. I’m guessing if this bug is fixed and I remove that extra step, that other bug will go away as well…
PS How do I get my hands on the fix? Willing to test
This fix, plus a whole bunch of undo related fixes should make into the 3.3.0 beta4 release, probably this weekend. Joel will drop a note on the forum when it is ready. I will be very interested to see how the original version of the module responds to this release. If Undo is still not 100% restoring the original state, we will investigate further.
My feeling is that I don’t need to add a compatibility option for this bug. It is so broken as to be unusable for any purpose that makes any sense.
It doesn’t help that the current implementation of the ‘Apply to Deck’ option doesn’t really support the addition of a 4th option without a whole boatload of re-work and/or crappy workaround code.
Well, turned out any $…$ variables in a Beanshell property match expression where not being evaluated anywhere, on either the source piece or the target pieces, so definitely no need for any compatibility setting.
Fix committed, should be included in 3.3.0. Will now work as per the manual page.
Thus spake Brent Easton:
This fix, plus a whole bunch of undo related fixes should make into the
3.3.0 beta4 release, probably this weekend. Joel will drop a note on the
forum when it is ready.
I have been slammed the past 10 days, first by a migraine, then by my
daughter’s school starting up online, an impending release of our
software at work, and one of my monitors has suddenly become unsuable.
It’s going to take me a few days to start on the backlog.
–
J.
No worries Joel 
I have had a quiet week at work for once and been able to spend some quality debugging time. Take you time, I have a bit more to come, plus I am going to try and do a run through the reference manual.
Was this fix committed to 3.3.0-beta4? I’m still experiencing the same behavior in my module. It only works if I keep the limiter with a Global Property and a Restrict Command. Otherwise, it’s still only looking at the top x cards in the deck regardless of matching properties.
As per this thread: https://forum.vassalengine.org/t/3-3-0-beta4-version-numbering-bug-fixes/10696/1
All bugs that change game play and unit behaviours are being pushed back to 3.3.1. Should be a beta1 out for it soon.
Ah. Missed that thread. The reasoning makes sense. Thx.
I’ve uploaded a 3.3.1 test build you can try, VASSAL-3.3.1-test-35-g484afd49:
Many thanks! The bug appears to be fixed. I’ve been using a boolean limiter for several different GKC’s so I’m going to remove them all and test over the next few days and let you know if it works in all instances.
Additonal followup. I’ve been testing the undo bugs related to this GKC, and that also seems to be fixed - or in the least, occuring with signficantly less frequency.