# Bad behavior in activating layers in 3.2.3
**URL:** https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870
**Category:** Technical Support & Bugs
**Created:** [March 31, 2013, 3:18pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870 "2013-03-31T15:18:15Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@maramonster](https://forum.vassalengine.org/u/maramonster)
#### Post date: [March 31, 2013, 3:18pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/1 "2013-03-31T15:18:15Z")
Hello,
I found an issue with every build of 3.2.3 from 8566 up to 8616. if you make a layer with one image and an activate keystroke, it requires two keypresses to activate it the first time. I think it’s setting an invalid initial state, and then toggling it off on the first key press before toggling it on the second.
I’ve shown this to uckleman and he wants verification that it’s not a bug in my module. I have the simple module i created to illustrate this bug here: [http://studiospryte.com/uploads/brokenbuffclean.vmod](http://studiospryte.com/uploads/brokenbuffclean.vmod).
if you wish to replicate it yourself in your own module, the settings are here:
---
### Author:  [@Kori](https://forum.vassalengine.org/u/Kori)
#### Post date: [April 1, 2013, 12:55am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/2 "2013-04-01T00:55:53Z")
Getting the same thing on the windows version of 3.2.3. Always takes 2 key presses to enable the buff the first time in new or old modules. Was working fine in 3.2.2 but stopped functioning in one of the dev builds for 3.2.3.
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 1, 2013, 11:02am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/3 "2013-04-01T11:02:06Z")
This is Bug 9700 - Unit ‘flip’ problem that was supposed to be fixed. I will look into it.
Brent.
---
### Author:  [@maramonster](https://forum.vassalengine.org/u/maramonster)
#### Post date: [April 1, 2013, 2:57pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/4 "2013-04-01T14:57:33Z")
Awesome 😃! thanks!
---
### Author:  [@uckelman](https://forum.vassalengine.org/u/uckelman)
#### Post date: [April 1, 2013, 8:56pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/5 "2013-04-01T20:56:45Z")
Thus spake Brent Easton:
> This is **Bug 9700 - Unit ‘flip’ problem** that was supposed to be
> fixed. I will look into it.
>
> Brent.
I fixed a bad JPEG loading problem today which we should get out in
3.2.4 soon. Should I wait for you to fix this, or go ahead with 3.2.4?
–
J.
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 1, 2013, 9:07pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/6 "2013-04-01T21:07:50Z")
9700 is important and should go into 3.2.4. I can see what the problem
is and will get it fixed today.
On 2/04/2013 7:56 AM, Joel Uckelman wrote:
> Thus spake Brent Easton:
>
> > This is **Bug 9700 - Unit ‘flip’ problem** that was supposed to be
> > fixed. I will look into it.
> >
> > Brent.
>
> I fixed a bad JPEG loading problem today which we should get out in
> 3.2.4 soon. Should I wait for you to fix this, or go ahead with 3.2.4?
–
* * *
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: [b.easton@exemail.com.au](mailto:b.easton@exemail.com.au)
---
### Author:  [@uckelman](https://forum.vassalengine.org/u/uckelman)
#### Post date: [April 4, 2013, 12:07pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/7 "2013-04-04T12:07:19Z")
Brent’s fix is in the current dev build, 3.2.4-svn8629. Try that:
[vassalengine.sourceforge.net/builds/](http://vassalengine.sourceforge.net/builds/)
---
### Author:  [@maramonster](https://forum.vassalengine.org/u/maramonster)
#### Post date: [April 5, 2013, 1:02am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/8 "2013-04-05T01:02:59Z")
Works like a charm!
---
### Author:  [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)
#### Post date: [April 10, 2013, 11:09am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/9 "2013-04-10T11:09:40Z")
I have gotten 2 reports so far that layers are not working properly anymore in 3.2.4
I have not confirmed it - dont have 3.2.4 yet, but looking at the actual layer in question it relies on the layer being inactive (Always Actice checkbox off) and the key command turn it on via trigger action trait command. Nothing special here, worked flawlessly until 3.2.4
see pic below - almost same as first one in this thread (although Im on image 2, image 1 is same except it is green when it first turns on - the increase command cycles to the red image via trigger later)
[attachment=0]activateLayer.jpg[/attachment]
---
### Author:  [@uckelman](https://forum.vassalengine.org/u/uckelman)
#### Post date: [April 10, 2013, 3:29pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/10 "2013-04-10T15:29:07Z")
Thus spake Tim M:
> I have gotten 2 reports so far that layers are not working properly
> anymore in 3.2.4
>
> I have not confirmed it - dont have 3.2.4 yet, but looking at the actual
> layer in question it relies on the layer being inactive (Always Actice
> checkbox off) and the key command turn it on via trigger action trait
> command. Nothing special here, worked flawlessly until 3.2.4
Brent made another attempt at fixing Bug 9700 in 3.2.4. If this is not
the module relying on the old buggy behavior the fix was supposed to
correct, then it’s likely caused by the fix itself.
Brent?
–
J.
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 10, 2013, 11:47pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/11 "2013-04-10T23:47:37Z")
The original problem was caused by an issue in the way the Activation Status was saved for Layers in 3.2. The Activation status was being saved in two different ways and these where getting out of step with each other.
What I think you are seeing is due to the pieces being saved incorrectly under earlier version of 3.2 and are now that the bug has been fixed, have ended up activated when they should be inactivated or vice versa.
What I need to know is:
1. Does this just happen with pieces from saved games or pre-defined setups that where created in earlier versions of 3.2, or does it also happen with freshly pulled pieces?
2. Does the Tools → Refresh Counters command fix the problem?
3. Does resaving the game and then reloading it fix the problem?
I am away for the next 4 days so will not be able to do anything much till then. My hope is that the Refresh Counters will fix the problem (Fingers crossed!).
If not, I will need an example module and save file.
Brent.
---
### Author:  [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)
#### Post date: [April 10, 2013, 11:58pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/12 "2013-04-10T23:58:56Z")
Brent,
I’m not sure what you are asking because the module in question I reported
against was fine since 3.0 (2007) up to 3.2.2 if you pulled the pieces from
a tray or if they were part of a save file setup…
Does this narrow it down or are you asking against the original report in
this thread which is against recent dev builds?
Tim
-----Original Message-----
From: [messages-bounces@vassalengine.org](mailto:messages-bounces@vassalengine.org)
[[mailto:messages-bounces@vassalengine.org](mailto:messages-bounces@vassalengine.org)] On Behalf Of Brent Easton
Sent: Wednesday, April 10, 2013 6:48 PM
To: [messages@vassalengine.org](mailto:messages@vassalengine.org)
Subject: Re: [messages] [Technical Support & Bugs] Bad behavior in
activating layers in 3.2.3
The original problem was caused by an issue in the way the Activation Status
was saved for Layers in 3.2. The Activation status was being saved in two
different ways and these where getting out of step with each other.
What I think you are seeing is due to the pieces being saved incorrectly
under earlier version of 3.2 and are now that the bug has been fixed, have
ended up activated when they should be inactivated or vice versa.
What I need to know is:
1. Does this just happen with pieces from saved games or pre-defined setups
that where created in earlier versions of 3.2, or does it also happen with
freshly pulled pieces?
2. Does the Tools → Refresh Counters command fix the problem?
3. Does resaving the game and then reloading it fix the problem?
I am away for the next 4 days so will not be able to do anything much till
then. My hope is that the Refresh Counters will fix the problem (Fingers
crossed!).
If not, I will need an example module and save file.
Brent.
* * *
Read this topic online here:
[https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/11](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/11)
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 11, 2013, 12:15am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/13 "2013-04-11T00:15:42Z")
Tim,
I’m saying that using the module in 3.2.2 broke the saved games in a way that was not visible in 3.2.2. In 3.2.3/3.2.4 the broken-ness becomes visible.
Your module just happened to keep working under 3.2.2, others didn’t.
What i need to know now is if it is possible to get your module working under 3.2.4 at all by testing the 3 methods I requested, or whether we have to pull the whole fix and investigate further.
Brent.
---
### Author:  [@bdgza](https://forum.vassalengine.org/u/bdgza)
#### Post date: [April 12, 2013, 5:54am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/14 "2013-04-12T05:54:00Z")
From: [https://forum.vassalengine.org/t/bug-vassal-3-2-4-cc-europe-2-2/5901/1](https://forum.vassalengine.org/t/bug-vassal-3-2-4-cc-europe-2-2/5901/1)
The right-click “Activate” command in Combat Commander: Europe v2.2 module no longer works with VASSAL 3.2.4. It works fine in 3.2.3 and before.
1. Does this just happen with pieces from saved games or pre-defined setups
that where created in earlier versions of 3.2, or does it also happen with
freshly pulled pieces?
→ The module is from 3.1.17. Problem with pre-defined setups and with newly created pieces.
2. Does the Tools → Refresh Counters command fix the problem?
→ Refresh Counters doesn’t work on modules from 3.1.17.
3. Does resaving the game and then reloading it fix the problem?
→ No, pre-defined setups, saved games, reloading, all the same.
---
### Author:  [@bdgza](https://forum.vassalengine.org/u/bdgza)
#### Post date: [April 12, 2013, 6:18am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/15 "2013-04-12T06:18:06Z")
Tried again with 3.2.4-8631, no change.
---
### Author:  [@sithstalker](https://forum.vassalengine.org/u/sithstalker)
#### Post date: [April 16, 2013, 10:20pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/16 "2013-04-16T22:20:57Z")
I’ve also been having this problem since last week when I loaded 3.2.4. I sent Tim an e-mail over on the BGG site on the 12th to let him know as well. It has occurred with newly initiated as well as saved games. The “non-activation” indicator issue is the only one that I have had since the update, but am glad to read that it’s not just me 🙂
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 16, 2013, 10:33pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/17 "2013-04-16T22:33:28Z")
I am looking into this and so far it only seems to be happening with Combat Commander and I am not sure why. I have tried the Devil’s Cauldron module for example, that does basically the same thing and it is working fine.
Has anyone seen this problem ( a layer not showing when it is supposed to) in a non Combat Commander module when using Version 3.2.4?
Thks.
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 18, 2013, 10:29pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/18 "2013-04-18T22:29:17Z")
I am homing in on the solution to this problem. It is not in fact a bug in the Activate command, but a bug in the Reset command which is also being sent to the pieces as part of a Trigger. This explains why it is only happening with CC:E. I hope to have this resolved within the next day.
---
### Author:  [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)
#### Post date: [April 19, 2013, 10:33am UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/19 "2013-04-19T10:33:27Z")
Ok, I think I have finally got to the bottom of this.
The Activation command is working correctly in 3.2.4. The culprit is the Reset command that is being issued to the counters as part of a Trigger that activates the counters in CC:E. This is why Combat Commander appears to be the only module affected.
It turns out that the Reset command has always been ‘broken’, up until 3.2.4 when it was ‘fixed’ as part of my changes to fix bug 3700. Try this in 3.1:- Add a Reset to Level 1 to a counter with Layer. Do the Reset command and the counter Activates on to layer 1. Now do an Activate command to deactivate the layer and the Activate command has no effect. Do it again and the layer de-activates. Sound familiar? This is basically bug 3700 being caused by the Reset command.
Both the manual and designers guide say this of the Reset command:
Specifies a keyboard command that resets the Layer to a specified level. This does not automatically activate the Layer.
I’m not sure where this came from, but the Reset command does, and always has, automatically activated the layer if you sepecify a positive level number. If you specify a negative level number, then the layer is deactivated and set to the level number (i.e. Reset to -2 says move to level 2 and force deactivate the layer). It is quite clear from the code that this is how it supposed to work. So when CC:E trys to activate a counter, it is telling it to Reset to level 1 and Activate, immediately before issuing the Activate command which toggles the activation back off again. In 3.1, the bug in reset caused the first activation after a reset to be ignored, which meant that it appeared to work and masked the bug in the module.
The solution for CC:E is to change the Reset command in the Aon Layer in the Activate Routine prototype from Reset to layer 1 to Reset to layer -1.
With the introduction of Named Key Strokes in 3.2, the Layer trait was extensively re-written and if I had done it properly, CC:E would have broken with the first 3.2 release and we would have seen this much sooner.
I have also just about finished reworking the Refresh Counters option to work correctly on modules containing older saved games as setups. The problem occurs where these games where originally built before Game Piece id’s existed and have never been allocated one, so no link exists back to the palette slot they came from. I am adding an option to search for a palette slot based on the counter name. This should make it possible to then refresh these older save games (and all games started using them) with the Refresh Counters command.
I hope that all makes sense.
Brent.
---
### Author:  [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)
#### Post date: [April 19, 2013, 1:43pm UTC](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/20 "2013-04-19T13:43:14Z")
Ok, I follow what you are saying but one thing does not fit (or maybe wont fit
later on)
You say to use reset to a negative to deactivate the layer / or keep it from
activating, but I seem to recall that when we went through and got layer
redesigned to work with properties you also allowed for layers to understand
negative numbers.
Although in this instance we are not following a property with -ve values, what
is going to happen to layer that follows a property with -ve values.
Hmm, trying to answer this it seems I found something else looking at the 3.2.4
layer interface. So I can follow an expression but I can also leave the layer
inactive - how would I activate it? - nowhere to enter a command to do that.
Also you cannot reset a layer that is following an expression which makes sense
then, just that the Always active? state does not
I am not sure what should be done here, compared with the past
* * *
From: Brent Easton [b.easton@exemail.com.au](mailto:b.easton@exemail.com.au)
To: [messages@vassalengine.org](mailto:messages@vassalengine.org)
Sent: Fri, April 19, 2013 5:33:33 AM
Subject: Re: [messages] [Technical Support & Bugs] Bad behavior in activating
layers in 3.2.3
Ok, I think I have finally got to the bottom of this.
The Activation command is working correctly in 3.2.4. The culprit is the
Reset command that is being issued to the counters as part of a Trigger
that activates the counters in CC:E. This is why Combat Commander
appears to be the only module affected.
It turns out that the Reset command has always been ‘broken’, up until
3.2.4 when it was ‘fixed’ as part of my changes to fix bug 3700. Try
this in 3.1:- Add a Reset to Level 1 to a counter with Layer. Do the
Reset command and the counter Activates on to layer 1. Now do an
Activate command to deactivate the layer and the Activate command has no
effect. Do it again and the layer de-activates. Sound familiar? This is
basically bug 3700 being caused by the Reset command.
Both the manual and designers guide say this of the Reset command:
_Specifies a keyboard command that resets the Layer to a specified
level. **This does not automatically activate the Layer**._
I’m not sure where this came from, but the Reset command does, and
always has, automatically activated the layer if you sepecify a positive
level number. If you specify a negative level number, then the layer is
deactivated and set to the level number (i.e. Reset to -2 says move to
level 2 and force deactivate the layer). It is quite clear from the code
that this is how it supposed to work. So when CC:E trys to activate a
counter, it is telling it to Reset to level 1 and Activate, immediately
before issuing the Activate command which toggles the activation back
off again. In 3.1, the bug in reset caused the first activation after a
reset to be ignored, which meant that it appeared to work and masked the
bug in the module.
The solution for CC:E is to change the Reset command in the Aon Layer in
the Activate Routine prototype from Reset to layer 1 to Reset to layer
-1.
With the introduction of Named Key Strokes in 3.2, the Layer trait was
extensively re-written and if I had done it properly, CC:E would have
broken with the first 3.2 release and we would have seen this much
sooner.
I have also just about finished reworking the Refresh Counters option to
work correctly on modules containing older saved games as setups. The
problem occurs where these games where originally built before Game
Piece id’s existed and have never been allocated one, so no link exists
back to the palette slot they came from. I am adding an option to search
for a palette slot based on the counter name. This should make it
possible to then refresh these older save games (and all games started
using them) with the Refresh Counters command.
I hope that all makes sense.
Brent.
* * *
Read this topic online here:
[https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/19](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870/19)
[Next page](https://forum.vassalengine.org/t/bad-behavior-in-activating-layers-in-3-2-3/5870.md?page=2)