I am converting game piece damage sheets to check boxes rather than text.
The process of defining the check boxes is brutal (it took about 10 hours to do one ship). The result has been a massive slowness in the engine.
When making the check boxes and confirming they work the first few shields the delay was only 1-2 seconds but as more boxes were set up it has massively slowed down to almost a minute sometimes 10 seconds sometimes a minute.
Here is a vid showing the problem. The mod with these changes has not been uploaded and I can’t attach here due to size restrictions 256K where the mod if 14MB. If anyone wants to help and investigate I can email it to you or upload it and then delete it after you grab it.
youtu.be/EZpRuB242rE
The damage from the menu select(0:57) takes until 1:24 to appear. Almost 30 seconds. That check on the second row if from a click I did before opening the menu.
It would also be great if there were a way to define a grouped grid of check boxes graphically by clicking and dragging, assigning a group name and the size of the boxes 18x18 and the box is 2 rows and 8 columns top left point of the group is x,y name of group is shield #1. I would settle for the check boxes working and not grinding the client to a halt however. 
Ok I found I could upload and not have it on the modules DL list
vassalengine.org/wiki/File:SFBC_memleak.vmod
I think you’ve pushed the engines past their design specs captain!
The problem is not a memory leak, it is from making the damage check sheet counter too complicated. You can only add so many layer and other traits to a counter before it starts affecting performance of the Vassal system as a whole. It is a fundamental design limitation of Vassal 3.
If there only a limited number of these damage check sheets, then you can get around this by creating each one as a Map within a Chart tab, and create each checkbox as a separate counter.
The other alternative would be to create a custom Java trait for the damage sheets.
Regards,
Brent.
Why was it reporting a couple thousand unchecked boxes when the sheet only has 125 or so? If it’s just too much I understand that, but I don’t understand the misreporting of the number.
I had half the ships boxes done before it started slowing down. The last half is what ground it to a halt jumping from a 3 second delay to 40 seconds or more.
Sorry, I don’t understand this question, was this something on the video? A counter in Vassal is not just drawn and then left there, it is being constantly refreshed and redisplayed as you make changes or move the display. Each refresh requires ever trait to be visited and reassessed to see if anything has changed and then the counter image is rebuilt and redisplayed. So the ‘couple of thousand checkboxes’ being reported is probabably the 125 being reported 10 or 20 times each.
The problem is exponential. Small numbers of traits are fine, but after a critical point the problem becomes rapidly worse faster and faster.
Here’s an option that might help you reduce the boxes. Is the position of the X’s within a category important? If not, then replace the 16 checkbox layers in the Shield # 1 set (for example) by 1 single trait with 17 layers, each layer having one more checkbox displayed.
Regards,
Brent.
yes in the vid, it’s only 5 min, jump to 2 min 58seconds The pieces list has “unchecked” at 2623.
I just made 5 check boxes and the list shows 0505 unchecked. The numbers don’t seem proportional.
That text ‘0505 unchecked’ is coming from the ‘Label for pieces’ definition in the Inventory ‘Units on Map’. You have specified the label as ‘$LocationName$ $PieceName$’. Therefore, the ‘2623’ or ‘0505’ is the location of the piece on the map, not a count of anything. The ‘unchecked’ text is the name of the piece. It is called ‘unchecked’ because you have specified all your checkbox layer labels as ‘checked’ and ‘unchecked’ but have not specified if it is a suffix or prefix, therefore the layer name replaces the piece name
Regards,
Brent.
Ok, DUH! Thanks. I am replacing the X’s with a count down now and it is getting more responsive, so I think that will work.
I apologize I thought there was an actual mem leak I didn’t expect “unchecked” before the hex coordinate. That just completely threw me off it simply being the hex coordinate.
No problems, it’s easy to overlook little things that can cause really weird issues!