Greetings! I don’t know the current state of the Vassal 4 project, as there don’t seem to have been updates for some time, but in the hopes that it is still live (or if some further updates to the 3 line after the coming 3.3 are to be considered instead), I have a few wishlist features to contribute. I’ve got about 400 hours of work into the Paths of Glory 9.4 module, during which time I’ve been able to hone a wishlist down to things that I think are “legitimate” – i.e. things that are either not presently do-able in the existing engine, or are only do-able in a very cumbersome (slow performance) kind of way. Possibly some of these have already been suggested in the past, but I thought it might be useful to the team have a list from an experienced module builder.
Chat - Ability to set different bold/italic/font-size/font-color/etc in the Chat window, for different game messages. Presently all the game messages come out in a single monotone of one color and boldness setting, and only “chat messages” from the players themselves and system messages are entitled to a separate color. It would be fantastically useful to be able to have certain “more important” messages have a different boldness, and to have certain classes of messages have a different color. Ideally the boldness could be changed WITHIN a single message, so that I could bold e.g. a single word or phrase within a report message.
SumStack – instead of only being able to sum the value-of-a-property across a stack, it would be fantastic to also be able to sum the number of pieces in a stack that have a particular property. So SumStack(“GE”) would return the number of pieces in the stack that contained a GE property. Even better would be able to SumStack the number of pieces that matched an expression (e.g. a SumStack for the expression {Side == “GE”}. Also useful would be to sum for the number of unique values of a particular property (e.g. a SumStack for the marker “Side”, such that if a stack of three pieces contained two pieces where Side==”GE” and one piece where Side==”AH” then the sum returns “2” for two unique values.)
Movement Trails – there are many use cases in which Movement Trails are mostly useful only if they can be turned on or off globally for all pieces. Unfortunately the current 3.2.17 implementation only offers per-piece switching, it also makes building a global-trails support extremely cumbersome because (a) only “toggling” trails is supported, no way consistent way to force trails to a known state, (b) trails internal “locallyVisible” flag is often only first initialized when the piece is drawn for the first time, creating bugs with not-yet-seen units sitting on reinforcement boards. Functionality that would help:
(1) Provide an option to force trails on and off globally for all units (preferably with a “matches expression” field)
(2) Either initialize locallyVisible at At-Start Stack execution time, or ensure that a clear-movement-history command will set it properly rather than using the unitialized garbage value.
(3) Allow the trails-on flag for an individual piece to be forced to a known state (rather than only toggled).
(4) Allow the trails-on flag for an individual piece to be “read” as a property.
(5) Allow the “Moved” flag for an individual piece to be “written” as a property, and if it is written to false the move history should be cleared.
Stack Selection - When I roll over a stack and receive a “Mouse-over Stack Viewer” box, how about if I can hold the SHIFT key down to force the box to stay up while I can then select an individual piece from the stack by clicking on it? And potentially drag pieces left/right to reorder them?
Hand Arrangement - When I draw a bunch of cards from a “deck” and put them in my hand, I’m allowed to have a hand as big as I want, but the cards only want to arrange themselves horizontally in a massive line. How about the option to have hands use multiple lines of cards e.g. if I resize my hand window to have room for several rows of cards?
“Once Per Stack” Commands - When the player has selected a whole stack of pieces, and then executes a key command on the stack (from either right+click menu or a hotkey), it would be super-useful to have a system property FirstPiece which was set to “true” for the very first piece in the stack to receive the key command in question and “false” for every other piece. That was I could implement functions to be performed once per stack rather than for every single piece in the stack. In the present version, a few once-per-stack functions can be implemented by using a kludgey global semaphore, but there are others for which even this is not possible.
Turn Trackers “writeable” – when I create a Turn Tracker, it writes its value(s) into global properties (e.g. “Turn”), which is helpful. However, if I then set the value of that Global Property myself (responding, perhaps, to the Turn marker being dragged a different place on the board), the Turn Tracker does not notice the change and does not update. This leaves me with the unfortunate choice of either “building my own” Turn Tracker (e.g. with my in-game Turn marker) which means giving up the dockability-into-the-toolbar, or else staying with the toolbar turn tracker and accepting that I can’t have any functions in the module itself that update the Turn (e.g. to set up a scenario that “starts in 1942” or to allow dragging the turn marker on the board to update the turn).
“Mask” ownership of cards to be properly/consistently initialized at startup to a predictable state. Presently cards that start face down in decks on the mapboard appear to receive “random” (presumably uninitialized) mask ownership data (so for example doing a draw-specific-cards from a face-down deck at runtime will randomly mask some cards and not others – this can be “fixed” in a scenario setup by manually dragging every single card to the discard pile and then putting it back where it goes - must be manual as even a global send-to-location doesn’t work - but this is unbelievably cumbersome and prone to introduce misplacement of cards in the scenarios). It would be great if this Mask ownership were either automatically initialized to “” (unmasked) ownership, or (better) if there were a way to specify the initial ownership, with being the default.
Pieces not so hair-trigger fidgety - Ability to set a pixel tolerance value for pieces/locations, such that accidental “drags” of pieces for only a few pixels will have the pieces snap back to their original locations w/o firing any triggers. Presently the pieces are so sensitive that many attempts to “double click” on a stack are instead resolved into moving it a few pixels, which both fires a lot of moved-on-map triggers unnecessarily and also tends to mush around pieces nicely arranged on cards to go to the wrong places. Ideally, when this pixel-tolerance is in effect, the player can still force a piece to be adjusted “by one or two pixels” through the expedient of first dragging the piece outside the minimum tolerance zone, and then adjusting it back in – when I start dragging the piece/pieces/ will actually stay completely put until I’ve dragged at least, say 5 pixels (but let module designer adjust this) and then be moving “live” once I hit the tolerance zone – I could then move it back inside the tolerance zone if I really did want to adjust the thing only a pixel or two.
Ability to hide and unhide toolbar items - Presently I can either put something on the toolbar or not put it there, but I can only hide it in a “requires restart” mode. I would like to be able to fire GCK’s that enable and disable toolbar items.