I was looking at possibly using the “At Start Stack” capability…
The available units are already defined in “Game Piece Palette”… However, there appears to be no (obvious) way to leverage those preexisting definitions.
Is there a way to do this…?
Example - A German Infanty-4 is a defined piece type. I would like to have 4 of those units set up as a “At Start Stack”.
When I find a module set up like that (bleh), I go and make a new entry under Global Prototypes for e.g. German Infantry-4. I copy all the traits from the piece someone already put somewhere (either in the palette or in an At Start stack) into the Prototype.
Then, in the game piece palette, I erase all the traits and instead add the Prototype trait (e.g. Prototype as “German Infantry-4”). You will still need to have the Basic Piece trait for the actual display name of the piece; I like to remove the art from the Basic Piece and instead display it with an always-active Layer trait.
Then in the At Start stacks, you can ALSO add pieces and reference the Prototype as “German Infantry-4”, and you will get the same effect.
Both Paths of Glory and For the People modules use this frequently, so you could examine the game piece palettes (and at start stacks) for those to get the general idea.
Brian
Personally, I only use At-Start stacks for things that are never going to move or change, not for game setups. Pre-defined save games are far more flexible and easier to maintain.
I just use the At-start stacks for things like Non-movable markers and counters and Invisible Global Key relayers. Even then, I also use the method Brian mentions in case I need to create the same thing in the Game piece palette so I can add it to existing games if needed.
For Paths of Glory, where there’s “essentially only one setup”, At-Start stacks save a lot of time.
I personally loathe the “pre-defined saved games” because having to remake them ends up being 20-30 minutes of work even when I touch some tiny little thing (since they carry all their old prototypes). I’m sure I’ll like them a lot better in Vassal 4 when they don’t do that any more. At this point I probably have a solid man-week in on re-doing scenario files for Paths of Glory and For the People!
In the For the People module I made Global Key Commands to do each individual scenario setup, which at least means it only takes 20-30 minutes rather than the hour and a half (plus mistakes) it would probably take to set up all those scenarios.
What would be ULTRA NICE in Vassal 4 is if it lets me load up the old scenario saves, fix up anything I want to change if needed, automatically add in the proper default value of any new e.g. Global Properties I’ve created, but keep all my pieces in the same position, etc, etc. If changing a prototype USUALLY didn’t mean having to touch the scenario setups that would be golden. I gather this is the general plan.
Brian
Brian, you really shouldn’t have to do this. The Game Piece Refresher (Tools → Refresh Counters) should be able to refresh all pieces in a saved game even if the prototypes have been changed. I change protoypes regularly in some of my big modules and all I have to do is load the save game, refresh it, save the game and reload it into the module. Takes 1-2 mins per save game.
The only time you should need to rebuild a pre-defined setup from scratch is if you add or remove any map windows, or add, remove or move any Decks.
Be careful what you wish for:) More on this later. We hear the complaints from Module Designers about this, but we don’t hear all of the Module Users NOT complaining about the problems that blindly changing this will cause. We need to define the actual problems that need to be solved.
That’s pretty much how my workflow goes using the Game Piece Refresher.
I have found the piece refresher fails “frequently and unpredictably”. By unpredictably I mean it’s hard for me to tell exactly when it will, but that also means I can’t tell which changes are “okay” and which changes are “very much not okay” and so I end up as a practical matter having to abandon it as a viable solution. Incidentally this state-of-affairs was originally communicated to me by one of my predecessors on the Paths of Glory module when I was asking various “WTF-is-up-with-XXXX” types of question, and my own experience has certainly confirmed it.
For example, just today I tried (in spite of knowing better) to refresh-counters on a Paths of Glory 9.6 (or maybe 9.5, but anyway) save hoping I could use it in 9.7. For my trouble I received an extra Game Turn marker in Liege, which I suppose used to be a fort-destroyed marker or a CP Control counter or something like that. And then whichever other counter used to be in Liege just doesn’t exist anymore. I can’t really tell how many other things are or are not right, but an extra Game Turn marker in the middle of Belgium definitely catches the eye!
I do have the following vague rule-of-thumb:
(1) If I have ONLY changed things that AREN’T prototypes, then it will almost certainly work.
(2) If I have changed a Prototype but it’s a “top level” prototype, then it MIGHT JUST POSSIBLY work
(3) If I have changed a Prototype that is referenced by other prototypes, then it ABSOLUTELY WON’T WORK.
This has also been true in For the People, incidentally, it isn’t some Paths of Glory specific thing. And I was seeing that long before I ever started playing around with custom classes.
I hear you hear, BUT, I can tell you that the current behavior is nothing but an endless set of bug reports to me the module designer.
As a module I am happy to consign “storing prototypes from old module versions” to the absolute-fail pile and jump feet-first into meeting the Devil I Don’t Know. HOWEVER, some super-easy-to-implement Vassal 4 features along this line that I would absolutely LOVE would be:
(1) Checkbox & version number blank to FORBID loading a saved game from before a certain version – no, you’re not allowed to EVEN TRY loading a save from Paths of Glory 9.0 into Paths of Glory 9.7.
(2) Checkbox & version number blank to WARN loading a saved game from before a certain version (and I get to supply part or all of the warning message, saying specifically some of the things I think might go wrong).
I’m left to wonder if either you don’t use as many prototypes as I do, or don’t nest them, or what other difference in development pattern has made it so that this works in your modules but doesn’t in mine (and the fact that I was specifically warned of this problem by a previous PoG module designer suggests that it isn’t a problem unique to me). I’m actually flabbergasted to hear that this works for anyone making modules of reasonable complexity, I had this filed under “It Is Known”! 
Brian
Yes, At-Start Stacks are golden. They save so much time. Predefined setups are horrid to rebuild and I’ve lost count of the number of types of module edits that the Counter Refresh can’t handle–glad the feature is there, but it’s extremely limited in its usefulness.
Hi Brian,
Ah. Are you by any chance making changes by editing the build file and copying and pasting Game Piece definitions around? One of the consequences of this is that unless you hand allocate unique gpids to the newly pasted definitions this will break the links between the pieces in any existing Save Games and their source in the module in an unpredictable way, causing the Game Piece Refresher to behave erratically. Unless you rebuild a Save Game from scratch after this sort of editing, you will never be able to refresh it properly.
The Combined GTS D-Day module now has 684 prototypes in multiple hierarchies up to around 5-6 levels deep. I use the Refresher day in day out while building these modules.
And therein lies one of the issues with going the other way. You will require every PoG player to keep a copy of every version of the module they ever started a game with in case they ever want to go back and review something in it.
True, but are unfortunately only suited to the limited set of games that have a single valid start configuration.
Had you ever considered that this is a bug that should have been reported?
Hi Brent!
Interesting, that’s at least a lead. To the extent I do hand-editing it’s usually for “search-and-replace” (renaming) types of reasons, or reorganizing of existing elements. And I can remember at least one time specifically forgoing hand-edit to create new objects because of “wondering if anything bad would happen” viz the gpid issue. But I can’t guarantee I’ve never done it.
Given that my forays into hand-editing were after my Paths of Glory editing career was well down the road, and my warnings-received-about-refresher were very early, it makes me think maybe I received the module in an already “broken” state.
So the next question… if gpid’s are “haphazard” e.g. maybe some items even have duplicate ones, do you think that would create a “lasting brokenness”? (In other words, even though a brand-spanking-new savegame is being made with each module version, it’s still flaky to ever refresh?) I’ll certainly at least be going and having a look around for that sort of thing.
As a module designer I can live with that as long as I have some control over it – i.e. I don’t want to lock out EVERY older version, but many SHOULD be. And it would actually be pretty close to what the situation currently actually is with PoG – if you’ve got a saved game from 9.0 you’d better not be loading into 9.7 anyway – it’s just that now there would be a way to be up front about what will run right and what won’t.
I would certainly be very excited if there was some functionality available for reliably porting saves forward (doing something about pieces that don’t exist anymore, doing something about pieces that exist now but didn’t used to) but I know from long experience that’s a HARD problem – a hard enough problem to do for one game one time, let alone generically across any number of games.
Brian
I realize you asked this of Joel rather than me (I having arrived fairly recently on the Vassal scene, in a lull period when bugs didn’t seem to be getting reported-and-repaired very much), but I will say that it actually never occurred to me that this was a “bug” level behavior – partially because I never experienced the counter refresher in an environment that worked in the first place (PoG’s apparently already being “broken” before I arrived), but also partially because the counter refresher presents kind of clunky – it doesn’t actually put offer any information about why it’s there and when one would use it, nor anything about when it’s safe and when it isn’t (this last being of course more relevant to my own experience than yours). One just eventually figures out “oh I bet this is trying to join things back up with new prototypes” and tries it and then maybe it works, but there’s nothing anywhere in the presentation of counter-refresher nor the documentation (at least that I encountered) encouraging module designers “here’s what you do when you make a new version – and it should work!”
Compared to, say, the Undo bug, which stood out immediately as a bug both because Undo is a clearly player-facing feature and because it’s really clear what it’s promising to do and really sticks out when it’s not doing it.
So anyway I can easily imagine plenty of module designers just thinking “it is what it is” and not even realizing that the team thought of this as a reliable tool for this purpose!
Brian
By reading other answers, I’m not sure what you are asking, but for me, I do this: In the editor, right-click and COPY the piece listed in the piece palette. Then right-click the at-start stack and select PASTE-- 4 times. Done. There’s your leverage. At that point I double-click the at-start stack definition and click the button that lets me position the 4 pieces precisely on the map. If they are brand-new pieces, they may show up as a white box, but if you save the module and re-edit, they will appear in their true form.
Wow. It must be our week to disagree. I would correct that to say pre-defined games are far more rigid and a beast to maintain. And I don’t think I’m alone on this. I avoid saved game scenarios with a passion and use only if I must, which is always a scenario-based game. With at-start stacks, I can edit without worry and overhead. Pre-defined games? Either rebuild each fricking edit from scratch or run some refresher thing on every scenario, even if it worked right. It’s still more time and work than just using at-start stacks.
I’ve tried using the refresher from time to time through the years, and I have given up every time because it screwed things up. It’s like remarrying a divorced spouse and suddenly remembering why I divorced them in the first place. You’ve had your chance, I say. At this point, I have zero trust in the refresher software. If I tried it yet again, I would have to check each setup piece by piece and hope it didn’t screw up traits that aren’t obvious. I might as well just recreate the scenarios at that point. But of course, it will work perfectly and then some in version 4.
I begin to understand your guys vehement opposition to storing the piece definitions in the Game File. As I mentioned, I use the Refresher day in day out on modules with 1000’s of pieces, hundreds of prototypes and 10’s of scenarios without problem.
But honestly, no-one has ever mentioned this on the forums that I can tell or I would have looked into the problems. I am obviously not using features that cause problems. I am more than happy to investigate the issue if you can send me instructions to reproduce it.
If the module editor detects duplicate gpid’s on start up (gaps in the gpid sequence are not a problem), then it can only have occurred by someone hand editing the buildfile and so the current gpids are unreliable. It them renumbers all gpids from scratch. All new games going forward will then be consistent with this new version of the module. All save games created before this point will be inconsistent and will (probably) not refresh correctly.
If you have been carrying forward a Save Game that was created prior to a gpid renumbering event, then yes, that save game would be ‘broken’ and would stay ‘broken’ for refreshing. If you are using At-Start stacks to create your game setup using the Vassal ‘New Game’ comand, then this is not a problem as the game pieces are re-created from the current definition each time a new game is started and will be guaranteed to match the gpids stored in the module.
Bear in mind I’ve pretty much only done modules for card-driven titles, and cards tend to have decks, which Counter Refresh can’t touch. It’s been so long my memory’s hazy, but seems like I had all kinds of trouble with map-related changes (design and/or naming of zones, regions, etc) and complex trigger logic that referenced them. When I iterated on things, it tended to be when I had accumulated a large batch of changes or vastly different methods of accomplishing a goal/need.
So given the troubles, and that I found At-Start Stacks much easier for enforcing a limited counter mix than a hidden palette, it was an easy decision to stop even trying the Counter Refresh tool.
The counter refresher has nothing to do with map issues, that is a completely different problem. At the moment, if any of the following change, an existing saved game can not be updated in any way to incorporate them:
Changes to Zones should be reflected in new games as these are not stored in the saved game.
The Counter Refresher also cannot update any Game Piece that is obscured to you (masked) or invisible to you as this would be a security breach. Any player could modify the module and remove the mask from the obscured pieces and then refresh the game to show his opponents pieces. In such games, both players in the game need to do a refresh to update any obscured or hidden pieces they may own.
Face-down Decks are a special case where the pieces are actually obscured from all players, so yes, they are a problem. To use the Refresher on this sort of game setup, you would need to design the start-up so that the cards start in an un-obscured Deck, say a face-up discard deck, or in an At-start stack ready to be added to the deal deck.
Don’t get me wrong, At-Start stacks are great, but they have limited use in multi-scenario games. I also don’t like the fact that you have to re-define the piece in the At-start stack that you have already defined in your Game Piece palette.
My preference would be that Game Setups are not actually simple save games, but are a description of how to setup the components for the game. The Game Setup would be more like a log file than a save file, recording what components should be pulled and placed on the map. When you load a ‘Game Setup’, it will automatically re-pull all of the required components.
Note that this would resolve the problem of ‘It is difficult to update game setup files when you update a module’ without requiring a decision on whether or not the game piece definitions are stored in the game save file.
A separate problem is ‘It is difficult to update the definition of game pieces in saved games created with an earlier version of the module’. We have to be careful here, because there are legitimate reasons why a module user would NOT want the game pieces updated to the new versions and we have to allow for this in some way, even if it is to force the module user to only use the version of the module that the game was created on.
For me the whole point of At-Start Stacks is to not have those pieces in the palette at all, so this isn’t an issue for my workflow. If Counter Refresh reliably works for other folks, great!
I think At Start stack kind of are a set of instructions on how & where to place pieces, and within the limits of their current implementation they’re robust, intuitive, and easy to use. They just don’t currently support multiple setup positions.
If there were a way to have little “folders of At Start Stacks”, essentially one folder per “Scenario”, and then when a scenario was picked then that set of At Start stacks would be processed, then that might be pretty good?
Viz Game Piece palettes – I actually don’t like giant crowded game piece palettes full of every piece in the game. I go for a main simple grid of maybe 10-12 super-common markers (e.g. for PoG it’s Control Markers, Trenches, Forts, Out-of-Supply – pairs since there is one for each side), and then one or two tabs (e.g. “Victory Point Markers”). And basically they produce the things game palettes are good at producing, which is infinite copies of things that players might need undetermined numbers of.
For individual pieces with any identity (e.g. German 7th Army, the “Guns of August” Event marker, etc), I only want the exact right number of pieces to exist – no creating or deleting, just transferring from reinforcement card to mapboard to deadpile to maybe being rebuilt. So none of those exist in my palettes, they’re At-Started onto my reinforcement cards or else to their starting positions on the map. You can’t make an “extra” German 7th Army, and you can’t delete the one that starts the game, only send it to Eliminated or Permanently Eliminated boxes.
So some pieces that get at-started onto my maps ARE also in my palettes (e.g. starting Trenches). I don’t feel like I’m “defining them in two places” because my definition of a trench lives entirely in the Prototype. There is that “one uncomfortable thing” where the Prototype isn’t allowed to include the NAME of the piece, so I have to make sure to type “CP Trench” or whatever each time I put one somewhere – I do wish there was a way to specify in a Prototype a piece name in the way I can specify art in a Layer trait instead of only in BasicPiece. And so then the “Name Trait” from the Prototype would serve as the name of any piece referencing that prototype assuming the BasicPiece’s name field was left blank – sort of like the relationship between BasicPiece’s art field and a Layer trait’s art.
Briefly back to counter refresher … well I’m glad to discover I’m not the only one having problems! I can note for sure that every release version of Paths of Glory from 9.2 onward has been from “completely clean, fresh, brand new save files” – since that’s the only thing I’ve been able to get to work. But between major versions, say, 9.4 and 9.5, you can load one of the older saves and “things will basically work” i.e. you’ll have all the functionality you’d have had in 9.4, but if you try to run the refresher to promote the save to 9.5 then there seems to be the risk of all sorts of subtle hell breaking loose. I guess perhaps between major versions things might have gotten different gpids? And therefore can’t find their proper home in the new version?
I guess now that I know this is “a thing”, I’ll keep my eye out, e.g. for a reliable repro case or something.
Brian
Absolutely. I’m suggesting that for Vassal NG we extend the process of what happens when an At-start stack is instantiated to every piece that is on the board in the ‘Game Setup’. i.e. we make a special case of ‘starting’ a game. It’s basically equivalent to your suggestion of ‘folders’ of at-start stacks, except that you wouldn’t really want to do that as if a piece appears in 10 different scenarios, you would need to define it in 10 different at-start stacks.
A unique Game Piece should be defined in one and only one place, and then be used/referenced wherever it is needed - In a game start definition, in a Place Marker definition, wherever.
The issue with untidy palettes is already solved. You can define 2 different game palettes and hide the one you don’t want to appear in game. However, in Vassal NG, I would envision a ‘Master’ game piece palette that only exists in the module editor. You would need to define any user palettes that appear for the players (with an option to ‘copy’ the master palette if you are lazy).
Not unless you are hand-editing the buildfile and duplicating gpid’s. The fact that it is not working is a bug and I would appreciate a heads up if you can reliably reproduce it.
Thumbs up on all.