How to design text labels in 3.2.6 and up

I had a working text label in 3.2.5, and it stopped working in 3.2.6 and the development build. The text label numbers display correctly during play but remain static on zero when viewed during a log playback.

Anyway, here’s the design, and if anyone can help me get it working in 3.2.6+ I’d be very grateful:

Basic Piece
Does not stack
Text label - deck counter
Marker - layer = 4
Calculated Property - GT
Dynamic Property - Core total

Text label:
$GT$ (I also tried {GT} and {GetProperty(“GT”)})

Calculated Property:
If(GetProperty(“tiles draw_numPieces”)-GetProperty(“Core total”)<=0,0,GetProperty(“tiles draw_numPieces”)-GetProperty(“Core total”))

Dynamic Property:
Name: Core total
Value: 0 (is numeric)
Key Commands: cc1 > set value 1, cc2 > set value 2 etc.

All this is triggered by another set of buttons that set the ccX value and add tiles to the “tile draw” deck. The actual text label should go from zero to (number of tiles in tile draw)-(dynamic property value).

Thanks for reading!

Could you please post a link to the module, and an example log file that shows this please.

Thus spake Brent Easton:

Could you please post a link to the module, and an example log file that
shows this please.

Also, try this in the most recent 3.2.7 build.


J.

Here is the dropbox link for the module, made with the latest dev build:
dropbox.com/s/ws4o5k3vmrh89 … 7test.vmod

Here is a log created from the moment the module was started. Only two steps, but a lot happening in those two steps. Key point is step 2, where the 2 unnamed pieces on the main map, in the deck counter and core At-start stacks associated with the open board, don’t change to the numbers 10 and 9, respectively.
dropbox.com/s/k5fnfgz89lxbm6o/testlog1.vlog

Here is a save created immediately after ending the log that shows the two text labels showing 10 and 9, as they did when the two actions were taken and the log was being created. This save state should be the same as the save state at the end of the above log, but isn’t.
dropbox.com/s/127k844q26tjf … save1.vsav

Note that we’ve also had ongoing and bizarre bugs when PBEM games have tried to use a .vsav file much like the one above to continue multiplayer games, so 3.2.6+ seems to be unplayable with this module for the moment.

What did you to do create the log?

Started a game, chose player side ‘Arythea’ and map ‘Open’. Began the log. Clicked the ‘New Game 7’ button (step 1). Clicked the ‘full conquest’ button (step 2). Ended the log. Saved the game.

That’s all I did. If you need a more thorough breakdown of all the pieces and traits activated when the ‘New Game 7’ button and the ‘full conquest’ button are clicked I can provide that, but it would take me a while to write out. Each click triggers a lot of pieces and traits.

Thus spake Benkyo:

Started a game, chose player side ‘Arythea’ and map ‘Open’. Began the
log. Clicked the ‘New Game 7’ button (step 1). Clicked the ‘full
conquest’ button (step 2). Ended the log. Saved the game.

I can reproduce the log problem with 3.2.8-svn8785.

Can you create a minimal module which exhibits the problem, or strip
out everything from this module which is not necessary for exhibiting
the problem?


J.

Thanks for checking it out. I tried stripping out everything I could safely get rid of and it is still reproducible. Here’s the link:

dropbox.com/s/fmc1mp3sn5yn6 … uild2.vmod

I could try stripping out more, but hopefully this is barebones enough to be useful. The tiles themselves are still a bit over-engineered, but I’m sure they aren’t the source of the problem.

There’s no longer a map choice, and the two buttons left are ‘new game 3’ and ‘full conquest’, which is taken from the game palette after clicking ‘new game 3’. The same two steps as before, with the same bug.

Thus spake Benkyo:

Thanks for checking it out.

The commit which changes the behavior of your logs is 8691, which was
supposed to fix Bug 2714. Brent’s already reopened this bug, since the
change doesn’t fix the problem in all cases. I’ll point him at this
thread so he can look at this as well.


J.

Try 3.2.8-snv8788: vassalengine.sourceforge.net/builds/

This reverts commit 8691, which should solve your problem. Unfortunately, it also reintroduces Bug 2714.