I will just collate here a few deck related feature requests that I have (but feel free to argue me out of them or add your own):
add a command key and a customizable/wipeable field (currently fixed at “Face up”) to flip the entire deck face up or down (already posted in a separate thread and added to the bug tracker) ;
often decks are used as containers of pieces which are not really cards, and the term “card” might confuse players, thus it would be nice to be able to customize the “Draw multiple cards” and “Draw specific cards” texts (or at least to be able to replace the word “card” with something else, like “piece”, “token” or anything one wishes to use);
the Mouse-over Stack Viewer can be currently checked to include the top piece in a Deck, it would be nice to be able to only include the top piece in face up decks, excluding instead face down decks in the same map;
when a global hotkey invokes deck commands (like flip, reverse, send to another deck etc) allow suppression of the corresponding report messages to screen, even if the request for suppression is actually coming from a GKC which is running the global hotkey and not the global hotkey itself.
Not 100% deck specific, but it would be nice to be able to use $variables$ to dynamically set the “Fixed number of Pieces” on which a GKCs should execute a command, when those pieces are in a deck.
This would be great to have. I currently specify the max number that might be required and do a comparison in the GKC search field to prevent the action once the (variable) required number of pieces have been processed, but with lots of pieces/iterations the inefficiency starts to show, I think.
A few reasons; mostly to do with learning Vassal. The remaining one is that a Trigger requires one more step (ie laziness) and for small numbers, the GKC condition works ok. I replicated it for a larger number out of habit… so now I’m off to see if loops will cut back startup time for a game with up to 14 hands to something less noticeable! Thank you… I will report back.
I guess that was addressed to marktb1961 , but just in case: yes, I use the a trigger with a loop to achieve the same purpose. But that implies coding/mantaining overhead and readability, when you could just have that “Fixed number of Pieces” be a Beanshell expression. Just a nice to have feature; workarounds exist, sure.
I’m going to derail this thread just a tiny bit. Sue me. When you loop in the trigger trait, you can define a loop index property. I haven’t used this option hardly at all because the docs don’t define this property’s scope. To be useful for me, the index would need to be global so the pieces I’m working on can see it. If I define a global property, can I use it as a loop index, or would trigger define a second property with a different scope?
As penance for derailing, I say again what I want most in a deck: a hot key to alphabetically sort a deck based on a property. I’d kill for this. You might think “oh, I suppose,” but here’s some things you could do with this:
You need to lay out a display of cards sorted by a number/string printed on the card. Right now I don’t know how to do this, but with sorting, I’d stick the cards in a deck, sort them, and pull them off the deck to the display top to bottom.
I have a game that has a prepared deck or stack of pieces. A shuffled bunch of “A” pieces go on top a bunch of “B”s and so on. I define a property in each card called “type” that is A, B, C, etc. I first shuffle the deck, then sort by type. Voila, all the A’s (shuffled) are on top, then B’s, then C’s. This is far easier than how I would have to do it now.
I need to put a specific card in the bottom 10 cards of a deck. All cards have a property type=A. I randomly change 10 of them to type=Z. The specific card is type Z. I put it in the deck, shuffle, and sort by type. Done. Again, I can do this another way, but the other way is more work.
The one thing I find missing in Vassal that I’d want the most is sorting. Even sorting two cards is a burden. I’d probably have each piece implement the Sortable interface. Then this could be extended from decks to stacks. If a stack could be sorted, imagine a stack with leaders always at the top, soldiers in the middle, and fortifications always at the bottom—and still be a single stack.
Afaik, the index, say Counter, used in the trigger trait is local to the piece where the trigger is. To have something visible to other pieces use a SetGlobalProperty to increase a global property, say GlobalCounter, by 1 each time (one of) the repeated commands in the trigger is fired. Or just copy over the value from Counter, if you still need the local loop index for whatever reason.
Expect a letter from my lawyers!
Seriously, no derailing, yours is a deck related request, still. It gets assigned #10 in the running list, which is by no means in priority order. For what is worth, I agree that this feature you suggest would be pretty nice, to avoid all the hard work you are hinting to.
The thing is Vassal already can sort decks! If you enable the option to choose one or more cards from a deck, it can sort the display / choices by a property. So it’s there, just out of my grasp! My nose is pressed against the glass, but the toys are not for me.
Please check out the VASSAL snapshot build for “14341” – an experimental version where the Return to Deck trait accepts an expression for the target deck (instead of the much-hated “please select specifically a deck from a list of every single item in the whole module” dialog). If you beat the crap out of this and it still seems to work, and not break old modules, we might be able to include it in 3.6.
I piddled around with it for a few minutes and it seemed to work, but it really deserves some decent testing if we’re going to include it.
Warning - this is a 3.6 “experimental feature” so please experiment with AN EXPENDABLE COPY of your cool module, rather than “the real thing”. Just saying.
I have just tested it a bit and it seems to work pretty well, thanks! I will test more, as soon as I get a chance.
Question: with Vassal 3.5 one can now specify a Description for the Return to Deck trait - I think this was added by Brent to answer another request of mine in another thread - but I notice that the actual deck the piece is returned back to will also show up in the piece editor, not just the description. Is this for backward compatibility? Otherwise, perhaps, when there is a Description defined I would think showing only that would suffice.
Okay, another “feature build” is up – it is in the “DeeperDeckDooDoo” branch (sorry - I was scolding myself for adding crazy deck features and this one seemed particularly scary to code and I forgot branch names got used as the test build names, haha!)
For this one I need some testing by specifically Stan Shilinski because this is your feature! There’s a checkbox at the bottom of the Deck configurer that allows you to turn on a “Sort” command with all the trappings. The property it actually sorts by is the same property you list in that box you list for the “Draw Specific Cards” (if you don’t use the Draw Specific Cards option the sort property will still appear, it will just be up there higher than the other stuff).
Everyone else very much welcome to test too. Again I gave it a “once over” – tried it, it seemed to sort my deck the way I wanted it to, etc. BUT if this is going to make it into 3.6 then I need you guys to download this build and test it substantially. Deck, as some of you know “especially Mark” is a dark and scary place to code – so I think I did this right, but boy does it need testing. And making sure it works when you make vlog files and then play them back, for example.
Again please use “an expendable extra copy of your module” to test – don’t save over top of your main cool module: since this adds fields into the XML, modules that you save with this version will not load in 3.5.x.
As a right-click command, sorting worked, but I was surprised the sort was in descending order–not what I thing most would expect. I can live with this, but you would need to document it.
You probably should disable “sort” if “re-shuffle” is “always” because sort is pointless then.
What I could not get to work is programmatically being able to sort a deck. It is as if the sort function is not exposed as a global hot key. I set up a piece via the hot key trait to sort a deck, but nothing happened. I got a report that the hot key trait executed but not a report from the deck sort function that it had received the hot key command from the piece. I must pause testing at this point.
Again, thanks for this. I think though if this gets involved, then I will move it to its own thread.
Okay, check it out – the NEW version from DeeperDeckDooDoo branch has:
(1) Checkbox for whether you want ascending or descending sort (and it will match the one it does for draw-specific-cards, rather than be the opposite)
(2) Sort option is disabled when reshuffle is “always”
(3) Fixed the programmatic side of the hotkey (I think - please test, but I did find a smoking gun)
This snapshot passed all my tests! It worked in a small test vmod and in a bigger one. Good job. I even tested it across vlogs and via the server. I also did ascending and descending sorts. Thank you.
One thing that caught me though was that it is a “string” sort and not a numeric one, so when I sorted with keys such as 7, 8, 9, 10, 11,12, it produced correctly 10, 11, 12, 7, 8, 9. Oops! I don’t expect you to do anything about this, but any docs should warn users because it is an easy thing to overlook.
Should be able to include an option to ‘Attempt a numeric sort if possible’ and fall-back to an alpha sort if any cards contain a non-integer for the sort property.