I am using a HK (Turn) associated with a GKC to remove a given active layer on all the pieces present in the map. It works, but it takes a whopping 30 seconds to remove the layer on just 7 pieces.
What can cause such a delay? 
My first suspect is that the GKC search criteria is hitting many more than 7 pieces, and so all the pieces are getting the key command to process - which has an overhead even if there is not such command on the piece.
If this doesn’t help, would you like to supply a screenshot of the GKC definition ?
Well, I did some tests to get a deeper idea of the nature of this problem.
Test 1: I disabled the HK (turn), created an action button in the toolbar and launched a HK from there at the same GKC: no difference as it always takes about half a minute to eliminate the layers from 7 out of 10 units present in the map.
Test 2: I did the same test using Vassal v. 3.2.17, the one I used most of the time.
Result: it took only about ten seconds to reset the layers.
In both cases the GKC was structured as follows:
Key Command: RESAAT
Matching Properties: AA_Active = true
Hotkey: RESAA.
At first glance, it seems that the delay is due to changes made to the GKC in the more recent versions of Vassal compared to 3.2.17.
Panther_2010
The big GKC change in v3.5 was fast match. I came across 2 or 3 performance bugs with this that @Cattlesquat fixed. I wonder if this could be another one?
Can you test in v3.4.13 … ie just prior to fast match?
Mark
Hello marktb1961,
I was finally able to find Vassal version 3.4.13 and test it.
The reset of the layers ends after 11 seconds, exactly the same time measured using version 3.2.17.
Apparently the fast match isn’t as fast as it should be.
Hoping to have been of some help in identifying the problem, I look forward to future developments.
Yours,
Panther_2010
You are using that latest v3.5 when you get the performance problem? ie v3.5.8.
If so, could you post a link to a demo module please?
I created a test module with a blank map, a single piece, a single layer, no properties, no prototypes and did the same test, always in version 3.5.8, the same one in which I am developing my module.
This time the removal of the layers was practically immediate.
So the problem is not in the functionality of the GKC, but certainly elsewhere, somewhere in my module, which contains numerous properties, both dynamic and global, many prototypes and numerous HKs activated by the turn counter. I’ll start a series of tests by disabling all the prototypes and HKs and then activating them one at a time, looking for the one that creates the delay in the execution of the GKC.
Sorry for this.
1 Like