I’m wanting to add the campaign system to the Up Front module. For that players need to be able to change the individual soldier’s stats.
Original
Campaign
Original
Campaign
I’ve done that via the layer trait. Everything is working fine as far as stepping properly through each layer and appearing when the command is given.
However I need the stats: Morale, KIA and Rank (SSG) to show up only on the rallied side (color side). And the Panic, KIA and Rank to show up only on the pinned side (b/w side).
The game pieces are structured with the “good” (rallied) side being the Basic Piece trait. The “bad” (pinned) side is a layer trait
I would like to do this without restructuring how the unit pieces were made. Is there a way?
The other element to the campaign system is a roster sheet to keep track of the soldiers’ performance in the battles they face. In the game it’s basically a spreadsheet to record results on. I found the spreadsheet trait and attached that to a basic piece and formatted the spreadsheet to work. However in testing it I found out that while the spreadsheet retains info put in it by the module creator it doesn’t for the player. So if after a game they enter the stats in for 6 guys, save the game and close it when they load it again what they entered is gone. Any thoughts on this?
I wish I could help you, but it is beyond my capability. I am excited to see someone add this in though. I love UpFront and this is a much-needed upgrade. Keep up the effort.
Perhaps a way to do this is to use DynamicPropertyTraits and LabelTraits. E.g.,
Layer
Images = [Backside]
Name = Step
...
Morale property
Actions = [[Increase Moralse,Some-Key,INCREMENT,{1}],
[Decrease Morale,Shift-Some-Key,INCREMENT,{-1}],
Name = Morale
Numeric = True
Min = 0
Max = 10
Label display
Label = {Step > 0 ? "Morale: "+Morale : ""}
...
The state of DynamicPropertyTraits should be written in saves, so they will come up correctly when re-loading the save.
These traits should most likely be done in a Prototype so that it can be reused across pieces.
The TableInfo (spreadsheet) trait is a bit tricky because - as far as I can tell from the code - user edits are only stored in the GUI element - not the trait itself. That means user-edits will not persist across sessions.
I think you’re better of with DynamicPropertyTraits for this too. The state of those are saved for sure. For example
Battles won
Actions = [Set battles won,SomeKey,PROMPT,{"Please enter # of battles won (was "+BattlesWon+")"]
Name = BattlesWon
Numeric = True
Min = 0
Max = 1000
This has the added benefit that you can use these properties (e.g. BattlesWon) elsewhere in the piece properties. For example, if more than 10 net battles have been won by a piece, then that piece earns a veteran status and gets an additional combat factor bonus
Battles won
TriggerTrait to set it (similar for BattlesLost)
Command = Set battles won
Actions = [KeyCommand1,KeyCommand2]
DynamicPropertyTrait to store it
Actions = [,KeyCommand1,PROMPT,{"Please enter # of battles won (was "+BattlesWon+")"]
Name = BattlesWon
Numeric = True
Min = 0
Max = 1000
DynamicPropertyTrait to set veteran status - note once achieved it will persist
Actions = [,KeyCommand2,DIRECT,{Veteran?Veteran:(BattlesWon-BattlesLost)>=10}]
Name = Veteran
Numeric = True
Min = 0
Max = 1
Value = 0
CalculatedPropertyTrait for effective combat factor
Here’s how I would do it. I would add two layer traits to a card. The first one is called “front,” and it contains all statistics images that go on the card’s front side (not the primary image). The second is “back,” and it contains all back-side statistics images. “Active always on” is turned off. Front’s activate command is “activateFront,” and back’s is “activateBack.” These commands are actually toggles, so perhaps it’s better to call them “ToggleFront” and “ToggleBack,” and that’s what I will use.
Let’s assume all your cards start the game on the front side. Unfortunately Vassal does not let us activate a layer trait at start by default. We want “front” to be active and “back” to be inactive. The only way I can think to do this is at start, send a command to every card. The command activates “front” or “back” depending on its starting state. We want only one of the two layers to be active.
Now that flip command you have? We need to change it. We eliminate the menu command “flip” and the key command ^F. We replace it with a string key command, say “Flip.” This way users can’t directly access this command.
We add a trigger trait. This has the menu command “Flip” and the ^F. We add to it these commands:
Flip
ToggleFront
ToggleBack
Everything described above can be done by consolidating into a single always-active Layer trait with two levels and that follows a Dynamic Property–with less configuration. Level one’s image is your front side labels, level two’s image is the back side labels. The piece gets a numeric value Dynamic Property ranging from 0 to 1 and that loops around, with a single control (the “Flip”) that adds 1 to it. The initial value of the DP is determined by which side should begin face up if it’s not uniform across all pieces.
It’ll make life much easier in the long run–especially if you have multiple Layer traits on a single piece–to give each such trait a Name (this is the second box from the top, with the hint text “Name used to generate properties exposed by this trait”) rather than letting it remain blank. Then you can evaluate expressions against a specific Layer.
A unit with its front and back states as two levels of one always-active Layer trait.
Campaign stat overlay images with the desired (different) items for the front and back of the unit
A single Dynamic Property to control which state the unit is in. Changing it automatically adjusts which level of the unit layer and stat overlay layer is active (and thus which image to show–because each layer is set to follow the property value).
The cards right now do several things. I can’t mess that up. There are commands that auto pop counters on them. Other commands that put image layers to indicate specific status. That’s why I’m worried about restructuring.
I understand the idea of putting it in a prototype. Unfortunately AH wasn’t too consistent with their printing in the 80s so image offsets almost have to be adjusted per card to properly mask the original stats.
