Currently, Vassal supports multiple piece palettes.
I have found this to be very helpful as I can have a “Master” palette (typically hidden) that includes everything and (possibly multiple) piece palettes intended for player use.
Based on other threads, not all module developers use Piece Palettes. However, the lack of a comprehensive Piece Palette make the job of maintenance harder - especially for a maintainer who is not the original developer.
Accordingly, I think it would be helpful if the editor provided a tool to automatically build a comprehensive Piece Palette, scanning all at-start stacks, etc.
Also, it would be helpful to have the ability to create a symbolic link from a Piece Palette back to the “Master” - thus enabling the ability to update only one location and not update 2 (or more) different Palettes.
So it looks to me like you’re desiring some sort of “piece library” for the module which catalogs every piece in a module.
The reason I am not using a piece palette in my module is that piece palettes currently have no provision for limiting the quantity of any piece on the palette.
If there were a way to specify the quantity of a piece offered on a palette along with a “return to palette” trait like Return to Deck, I’d be all over using such a palette in my module. Currently, I’m using a Chart Window with Tabbed Panes to simulate the Piece Palette. Also, I am defining most of the pieces offered through the Chart Window as cards assigned to a deck of that particular piece. To facilitate returning the piece to it’s place when a game action triggers such a return these pieces are given a Return to Deck trait.
Being able to limit the quantity of a piece offered on a piece palette would be very handy. There could be a text box in the editor to accept the quantity limit for the piece which could be left blank (default) for an unlimited quantity.
A “Return to Palette” trait would be very nice as well. This could work like Return to Deck and return the piece to the spot on the palette from which it was taken.
I agree with you, regarding adding the ability to limit how many can be drawn from a palette. This would have saved me a large amount of time in updating the EE module, since instead I had to create many At-Start-Stacks.
However, I still like the idea of a “master” or “library” palette and symbolic links.
I’m sure I’m not experienced enough to see most of the benefits of a “master” or “library” palette, but I can see that it would help with inventorying the pieces to make sure they are all in the module. Also, I can’t see how such a thing could detract from a module.
I would go significantly further. The ‘Master’ piece definition library would be the one and only place where piece definitions of any sort exist, and will not be related to any Game Piece Palettes that players may see.
The ‘Game Piece Palette’ that exists in the Player would be a completely separate component. The default version of this will just show all of the pieces in the Master library, but a designer can easily replace this with a version that contains a sub-set of pieces with limited pull counts.
At-start stacks will not exist as such, they will just be stack of pieces pulled from the Master library to create (auto-refeshing) pre-defined setups.
Piece Definitions in Replace and Replace with Other will be links to existing pieces in the Master library, not completely separate, new definitions.
NOTE: You do have to be careful not to nobble the creation of new scenarios. If you hide the ‘Master library gamepiece palette’, how does a user create new scenarios or what-if’s?
If the designer wants to make offer players maximum flexibility to create new scenarios, then a piece palette which (essentially) duplicates the master library could be created.
Exceptions might include debugging units, which I created when I was re-architecting the EE module - such as a unit which has the ability to echo back it’s current map and zone and was never intended for a player to access.
Player accessible palettes should include ability to either set the allowable count to “zero” or “infinity” (actually a realistic integer maximum like 2048) so the designer can configure how many of given unit type is available.
I have reservations about the library being the “one and only” place for piece definitions and getting rid of at-start-stacks, but I see how it could be workable…
At least how I was thinking about it, units in the library are templates (built up of prototypes + unique definitions) that form 80-100% of unit definitions. In the ideal case, there would be no need for further customization. However, at least how I use at-start stacks, I take a unit template (e.g., German INF-4) and there are minor deltas added (location, entry time, etc.).
While every minor variation could be located in the library, it would lead to proliferation of minor variations. Not a showstopper, but something to consider from a management perspective. Probably helpful to have expandable/collapsable dropdowns…
Brainstorming… class & subclass structure
GERMAN
*INF
**INF-4
***INF-4 (basic)
***INF-4 (41 add)
***INF-4 (42 add)
I’m guessing children would inherit most traits from parents… How to handle cases where you want a child to inherit some, but not all traits…?
I think you misunderstand me. Those things that change in-game (The ‘state’ of the piece) like label text, DP starting values, rotation etc.) would still be set in just the same way. There would only be one piece definition in the ‘master library’, which you would drag over when creating your scenario and set those specific details.
I use at-start stacks to pre-code things for automation purposes, keeping these in a hidden map until they are deployed via a button push that triggers traits on these units, that aren’t on the generic units.
So this isn’t a case of dragging a manually dragging a block out of the library to create a scenario and then setting in-game states like block rotation, labels, etc. Manually dragging blocks was onerous enough, that it was one of the biggest elements I tried to automate when I re-architected the Europe Engulfed module.
While every permutation could be stored in the master library, some of them are small enough that it may simply clutter the library.
In particular, I have blocks that are coded by deployment location and trigger on a unique button push or trigger condition occurs:
Example-1 INF-2 deploys to Belgium, when [deploy Belgium] is pushed
Example-2 10x German INF-4 deploy to (German Force Pool Map) in Jan-Feb 1942
In both cases, I see how it could work with a master-library and no at start stacks, but it would move the deployment logic which is currently built into the variant pieces in the at-start stacks.
If it were me, I would adopt the concept of a master library, but leave in at-start-stacks as an option for module designers.
I think my confusion is because I am used to working with modules where every unit is unique, so you only really have one type of each.
You are working with modules where there are multiple copies of generic units that you want to give variant behaviour to.
I do believe it is better to have the piece definitions in the master library where you can group the different variants in a folder for easy access rather than having the definitions spread over x different stacks.
However, I also see your point about the need for some sort of map-defined at-start stack (I have always hated that name), but such an at-start stacks in V4 would just consist of pointers to the real piece definitions in the master library. Same for things things like the Replace trait, you would be able to add and edit a Replace definition in a piece definition, but the actual Replace piece definition would be stored in an appropriate place in the master piece library.
I have issues exposing the “raw” master library during play, especially for units that are intended to be limited in number.
(At least how I see it, the master library, unlike palettes which link to it, have no restrictions on how many can be pulled from it). However, I see the need to access it during player creation of a new scenario…
Currently, a “new scenario” in V3 is accomplished simply be creating the placeholder and not associating a saved setup…
In V4, what if “new scenario” does the following:
Exposes the raw library (which is normally hidden)
Allows for definition of a new player defined piece palette which is specific to the new scenario (where both which units and how many can be specified during creation)
This is sort of “in-between” state from simply playing an existing scenario and have full editorial control of the module guts and has the advantage of not needing to understand Vassal scripting.
I think what you are saying is that we make ‘Creating a new scenario’ a new special ‘thing’ that has it’s own particular work-flow where you might create additional components like palettes, side and seat default combinations, other things to be defined.
Rather than in V3 where there is nothing special about creating a scenario, any old save game can be a scenario and you are stuck with the imposed module definition for most things.
Sounds good to me.
Another thing that would have been very useful for me is to be able to hide certain components in a particular scenario. Map Windows and their button and Chart Map widgets that are not used in that particular scenario.
Does Scenario creation happen in the Editor (Which requires the Editor to have Player features) or does it happen in the Player (Which requires the Player to have Editor features)?
Perhaps you create a saved game in the Player, then create a scenario with it using the Editor?
It might even make sense to have a separate scenario editor, that can take the components created in the module editor and arrange them as necessary for a particular scenario. However, I suspect it would probably make more sense to just roll those functions into the module editor…
Disagree (strongly) w/ making this part of the editor, since IMHO one of the goals is for regular players to be able to easily create simple new scenarios. I see this as an enhancement to the current V3 capability to create a new scenario, without having to learn Vassal scripting.
My thought on this, is that when launching a module, “Create New Scenario” is an additional option.
The (non-Vassal-savy) player then can easily create a new scenario by: (simple 2 player example)
Create a new German Piece Palette
*drag Panzer KW IV from library to German palette - set # available to “1”
*drag German Infantry platoon to German palette - set # to 3
*drag German Weapons platoon to German palette - set # to 1
Position units on map
*drag the tank and 4 infantry platoons from the German piece palette to their starting locations on the map
Okay. And this simple functionality couldn’t be part of the editor why? I’m just saying it might be easier (from a programming standpoint) to add this to the editor instead of the player, or it might be simple enough to make it a separate program.
A superset of the capability very well might exist in the editor. But, the focus of the discussion (for me at least) was brainstorming on what the player’s ability to create a new scenario in V4 should look like…