What’s the purpose of At-Start Stacks? Is there anything they can do that can’t be done with saved setups?
My understanding of at-start stacks is: They’re there to drive people like me nuts by allowing module designers to hide the piece window; Making fixing setup bugs a nightmare. 
On Mon, Aug 31, 2009 at 11:04 PM, uckelman <messages@forums.vassalengine.org (messages@forums.vassalengine.org)> wrote:
Post generated using Mail2Forum (mail2forum.com)
I have made a good number of modules, and I ALWAYS use at-start stacks to do setup. I avoid setup files at all costs. Why?
-
I can make ANY change to a module, and it is instantly used. A piece in an at-start stack immediately adopts a prototype or trait change. With a setup file, I must either rebuild the file from scratch or run it through the converter. It is particularly painful during module development.
-
For YEARS, the file converter has been unreliable. I have not tried it lately (because I avoid scenario files), but I would always meticulously check its work and find errors. I finally got fed up and dismissed it. I dread having to update modules that have lots of scenarios because I am always forced to rebuild all of them by hand.
You know, you asking this question makes me think you are a bit out of touch with module development.
Joel,
Your question suppose that you “must” mandatory use a game pieces palette to make saved files …
But the At-Start Stacks is in a way a limited pieces pool … more flexible than the saved files management.
Plenty of modules do not use a game piece palette because of the infinite draw provided…
The main problem with saved files declared is a pre-defined setup is that it’s very complex to use :
1 you must know that the save must be done with no Playerside selected
2 you must redone a saved file each time you have modified traits on pieces / cards and the updater is a black box for most of vassal designers.
At-Start Stacks is one of the best simple function used
Regards,
Grégory
Thus spake “shilinski”:
In the long run, I think it makes more sense to have a module updater
which works properly and eliminate At-Start Stacks, than to maintain
duplicate functionality.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
It isn’t duplicate functionality though.
At starts provide limited counter mix while piece palette is infinite.
Unless you change piece palette to allow defined quantities they will not be
the same
Post generated using Mail2Forum (mail2forum.com)
Furthermore,
module and there are certain pieces that are always needed and placed in the
same location for each scenario it is just easier to define those components
as At starts instead of having to drag them out and place for each scenario
file you need to create
Post generated using Mail2Forum (mail2forum.com)
The piece palate has to be changed to allow limited quantities. I
looked into it once, but it turned out to be much harder than it
sounds.
- M
On Monday, August 31, 2009, Tim McCarron timothy.mccarron@sbcglobal.net wrote:
[quote]
It isn’t duplicate functionality though.
At starts provide limited counter mix while piece palette is infinite.
Unless you change piece palette to allow defined quantities they will not be
the same
Post generated using Mail2Forum (mail2forum.com)
One more reason for At starts, we have missed, but makes them very useful.
Pieces used for example as overlays w/ DNS trait set to select never and
move never.
When placing this type of piece from a palette it could be accidently
released in wrong place and placement is critical for LOS etc…makes the
palette not a very attractive usage option in this case
Post generated using Mail2Forum (mail2forum.com)
There are several different concepts being discussed here that are not necessarily related. The game piece palette has little to do, in my opinion, with at-start stacks vs scenario files. I admit I usually have a palette at hand when I construct scenarios for a scenario-laden game, but I almost always hide it before I release the scenario.
For a single-scenario game, I will always opt for at-start stacks over a scenario file. Oh, sure, one could just make a reliable updater (I won’t hold my breath), but it that environment, I STILL have to run the updater every time I make a trait change to a piece. I don’t have to do that with an at-start stack.
But you know what the real problem is here, in my opinion? The save game files contain too damned much information that ought to be back in the module. When I load an old saved game with a new module version, why does it preserve all the old traits and not recognize the new ones? Why doesn’t it build a new instance of the piece based on the new module’s trait definitions? Then the discussion of file vs at-start becomes rather moot.
Stan,
That sounds sensible, but when you think it through, you will realise that doing things this way will create infinitely more problems that you hope to solve.
Think about two players trying to play a game with different versions of a module that have a significantly different definition of gamepiece A. Under the current scheme, the definition of A in the Save Game is the definition of the player who first creates piece A. From then on, Piece A behaves exactly the same for all clients playing that Save Game, regardless of their current definition of piece A. Meaningful play is possible between multiple players, regardless of the source of the Save Game, with no action required.
Now let’s look at your scenario. Player 1 starts a game and a log file and then creates piece A and executes a series of commands on piece A, leaving it in a particular state. He saves that game and sends it off to player 2. Player 2 loads up the save game and recreates piece A based on his (different) definition of piece A. Now he starts to replay the log file. Oops, half the commands that player 1 executed now relate to traits that do not exist in player 2’s version of piece A. At the end of the log file, the state of the game for player 2 is now completely different from what player 1 saw when he finished creating it. Meaningful play is completely impossible between these players without significant player action.
Piece definitions get changed ALL the time, but the existing scheme allows any in-progress PBEM and interupted on-line games to continue without interruption or player action.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Good discussion.
I’m a player first, module designer second and I generally don’t bother with scenario setups in my modules.
So-what if a player has to setup a scenario himself? They’re about to play a game which requires a fair amount of commitment, a scenario setup is a tiny, tiny slice of effort in comparison. Many enjoy doing the setup themselves anyway, myself included.
These days I put in one scenario as a demo but leave the rest to the players. Someone who is about to spend 6 months playing This Hallowed Ground isn’t going to mind spending an hour setting it up. 
That’s why at-start stacks bother me; So much effort and restriction for so little gain.
Ben
I don’t mean this to sound insulting, but I don’t think you have thought this through yourself. Doing things the way they are now have caused more problems than necessary.
What possible reason would one permit this? I certainly would warn the players right off. One module has a significantly different definition of piece A? So how different is that from loading a save game from Afrika Korps and expecting it to run in Twilight Struggle? It is one thing to allow both players to upgrade to a newer module and see the changes, but you are denying this because you want the capability for players to run different versions of the same module? This is good how?
Unless you also save the entire original module, I don’t understand how one can have meaningful play. It is like taking a fish out of the lake, throwing him on dry land, and commanding him to “swim.” Somehow you want to take a piece defined and born in another world to work and play in a different one.
Now I know you have not thought it through. Your whole defense is based on each player running a different version of a module and how wonderful it is that they can do it. The truth is they can’t because the map can be smaller so pixel addresses aren’t on map, send-to locations don’t exist any longer, etc. Yet somehow you want both players to be able to use different module versions. And if that’s not what you meant, carefully re-read what you wrote.
And for the dubious privilege of being able to run different module versions, I cannot change a module and have many changes reflected automatically in the saved games. For scenarios, I must either rebuild them from scratch or I have to run an “updater”, which I should not need in the first place and probably something you don’t think is necessary. I can’t fix a module for a couple of gamers who are 6 months into a pbem game because they can’t see the change even if I give them the new version. (And actually, how many products out there behave like this?)
As a module developer, I know when I update a module significantly and when I make a minor change. I know when to tell a player, yes, you can use the new version or not. Unfortunately, that all doesn’t matter.
If it were me, I would save only fundamental piece information in the save file. Things like location (and if those aren’t valid anymore, it’s the module maker’s responsibility to either rename or warn the users.) I would save trait STATE but not the traits. When I loaded a saved game, I would build the pieces from references back to the module. I would use trait state when it applied, ignored it when it didn’t, and used defaults when necessary.
Without looking at the code, it’s almost as if current vassal saves serialized objects and reconstitutes them in a world where they may no longer exist. Instead, I think they should have a reference to a piece builder back in the module with state information in ASCII format. If it’s impossible to rebuild the piece, then throw an exception and announce the save file is incompatible with that version. Perfectly acceptable, and something that a module designer would rarely resort to.
Stan,
I don’t have time to reply to you at the moment. I will get back to you later with a detailed reply.
You have latched onto my mention of the two players using significantly different modules, which I used for emphasis. Forget about changes to map sizes etc. I am only talking about counter changes. My arguments also apply to two players using modules with only minor differences, which happens a lot, especially in PBEM play that may take many months with multiple small updates to pieces along the way.
The trade-off is essentially between player discomfort and designer discomfort and as players outnumber designers by 100 to 1 (say) I think you would be outvoted on which way to go on this one
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Tim McCarron”:
We should add an instance limiter trait, then. It’s something that people
have asked for quite a few times. With an instance limiter trait, it
wouldn’t be dangerous to let the user delete pieces whcih are supposed to
exist in limited numbers.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “bsmith”:
Actually, I would. I hate spending time on setup. If I have to create a
(static) setup myself, then I’ll probably want to contribute that to the
module after I’m done. An hour spent doing the setup is an hour I can’t
spend playing the game (or coding).
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I know too others uses of the At-Start Stacks function. Instead of Why do we have a such function, i’ll try to show too how this function is used …
1) Place information and text on the “board”
It’s pleasant to have a zoomed information text with you put the mouse on a text description. The use of “Information tokens” is very pleasant because you do not have to zoom the main board. A token used as a text is zoomed (Mouse over stack function parameters).
In a way this is not playable tokens.
2) Reproduce a Board parts
VASSAL is limited by the concept on a FIXED map area. Indeed, even if you build a map (with parts) at the starting of a game, it’s after this choice impossible to change the Board during play.
Then, if you use tokens (placed with At-Start Stacks) joined to reproduce a game board map, you can easly change the configuration of the playing area.
- Setup invisible tokens
Invisible tokens are placed by expert Vassal Designers to grant automation called by a global command. The At-Start Stack function is also used in this case.
There are certainly more way …
0 Vassal Designers = 0 Vassal Players 
Regards
Grégory
It does not matter whether there are minor or major module changes. There is no benefit to running version 1 pieces in a version 2 module. Players download newer versions because they want the fixes. There is no benefit to them to hide them.
When you list some benefits to the players with the current system, then we can celebrate their good fortune.
Thus spake “shilinski”:
The sort of fixes where this is advantageous are ones which are not global.
For example, suppose that a missing piece is added to the module, or a
spelling mistake is corrected. In that situation, which is by far the most
common kind of update, we want saved games to continue to work.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
called by a global command. The At-Start Stack function is also >used in
this case.
This is probably the biggest reason in support of at-start stacks (ASS for
short
Yeah you could add it into a palette and drag it out when you need it, but
for those of us doing automation, it would get to be a pain having to drag a
piece out to the board every time you make a change to see if it works. With
at-start stacks, I can at least position it out of the way, tweak settings,
start a new game and test it. Lather/rinse/repeat.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)