Bad behavior in activating layers in 3.2.3

Technical Support & Bugs
#6

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

#7

Brent’s fix is in the current dev build, 3.2.4-svn8629. Try that:

vassalengine.sourceforge.net/builds/

#8

Works like a charm!

#9

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]

#10

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.

#11

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.

#12

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] On Behalf Of Brent Easton
Sent: Wednesday, April 10, 2013 6:48 PM
To: 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

#13

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.

#14

From: 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.

#15

Tried again with 3.2.4-8631, no change.

#16

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 :slight_smile:

#17

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.

#18

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.

#19

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.

#20

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
To: 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

#21

Nevermind - I missed the key command field totally duh!

From: Timothy Mccarron timothy.mccarron@sbcglobal.net
To: The mailing list for VASSAL messages@vassalengine.org
Sent: Fri, April 19, 2013 8:43:15 AM
Subject: Re: [messages] [Technical Support & Bugs] Bad behavior in activating
layers in 3.2.3

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
To: 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

#22

Using negative numbers when following a property only has meaning where you also use the 'Level 1 = ’ option to specify a that level 1 is greater than 1. Negative numbers in the following property will then be adjusted relative to that value. So if Level 1 = 5 and the property value is -2, then level 3 will be displayed.

If the follow property value causes the actual level to be displayed to be less than 1, then level 1 will be displayed.

#23

I just tried a quick “fire” order and still didn’t get the green box around the firing unit when activated. There was a green line around the photo on the order card when played, but not around the unit when I activated it?

#24

You will need a new version of the CC:E module for this to work.

#25

I reinstalled the only available module (January 2012) to no avail. Is there going to be a corrected module for this problem, or some kind of patch?