VASSAL 3.2.0 tomorrow?

We’ve had no new bugs reported for 3.2.0-beta4 (except 9407, which I fixed), so I’m looking to release 3.2.0 during October as promised.

3.2.0 would be essentially the same as 3.2.0-svn8425:

vassalengine.org/~uckelman/builds/

Everyone, please have a look at this, and report back before tomorrow night if you find any show-stoppers.

I hate to be a party breaker, but I think that sometime between beta 1 and beta 2 a disruptive bug was introduced in the LAYER trait, possibly when Brent updated the “follow property” field to be an expression. As a result of it, my Marvel Heroes module does not work anymore with a certain scenario/side combination.

Please see this thread.

I confirmed the bug is still there with build 8425.

What about bug 9400? Probably not show-stopper, I suppose, though I wonder if a lot of counter stacks will want to shift a little when it does get fixed. (One-pixel shifts in stacks can be really hard for end-users to figure out.)

I don’t know what I’m supposed to be seeing here. I modified the metadata in the test module so it could be loaded in 3.1.20 for comparison. Here are screenshots from 3.1.20 and 3.2.0-svn8426:

[attachment=1]3.1.20.png[/attachment]

[attachment=0]3.2.0-svn8426.png[/attachment]

There’s no difference in piece alignment.

Thus spake barbanera:

I hate to be a party breaker, but I think that sometime between beta 1
and beta 2 a disruptive bug was introduced in the LAYER trait, possibly
when Brent updated the “follow property” field to be an expression. As a
result of it, my Marvel Heroes module does not work anymore with a
certain scenario/side combination.

Please see this thread[1].

I confirmed the bug is still there with build 8425.

[1] https://forum.vassalengine.org/t/bug-4717-not-really-fixed-in-beta-2-or-3/5322/1

The change was introduced in svn8331. It’s not clear to me yet whether
this is actually a bug.


J.

Thus spake barbanera:

I hate to be a party breaker, but I think that sometime between beta 1
and beta 2 a disruptive bug was introduced in the LAYER trait, possibly
when Brent updated the “follow property” field to be an expression. As a
result of it, my Marvel Heroes module does not work anymore with a
certain scenario/side combination.

Please see this thread[1].

I confirmed the bug is still there with build 8425.

[1] https://forum.vassalengine.org/t/bug-4717-not-really-fixed-in-beta-2-or-3/5322/1

I can’t follow how this module is supposed to work. There’s nothing
I can do unless you explain what the relationship is between the
House of M card and the X-Men_playing property.


J.

Ok, let me repeat the steps needed:

  1. start Vassal 3.2.0 beta 1
  2. open Marvel Heroes 1.1 for offline play
  3. pick side “solo play”
  4. click ready for Avengers and F4
  5. the scenario deck pops up, draw till you get the scenario “House of M”
    There should be no error reported. Now:
  6. click ready for the X-Men
  7. the string “UNPLAYABLE” overwrites the House of M scenario card (and the start game arrow disappears), as this scenario is only playable when the X-Men are not involved.

Now repeat steps 1-7 with Vassal 3.2.0 beta 2 or later. On step 6 you will get the error message:

  • Bad Data in Module: House of M [Layer - Scenario playability] - Expression evaluation error followProperty[X-Men_playing]

and the string “UNPLAYABLE” does not appear.

The misbehaving layer is called “Scenario playability” and it belongs to the House of M scenario card (you can find it towards the bottom of the module, under the Scenario map window). It is set to follow the value of the global property “X-Men_playing”. This gp has a default value of 0 and gets updated to 1 when you click ready for the X-Men.

I can’t understand why all of a sudden such a simple layer definition will not work anymore: it was working in 3.1.18 and 3.2.0 beta 1.

Thus spake barbanera:

Ok, let me repeat the steps needed:

  1. start Vassal 3.2.0 beta 1
  2. open Marvel Heroes 1.1 for offline play
  3. pick side “solo play”
  4. click ready for Avengers and F4
  5. the scenario deck pops up, draw till you get the scenario “House of
    M”
    There should be no error reported. Now:
  6. click ready for the X-Men
  7. the string “UNPLAYABLE” overwrites the House of M scenario card (and
    the start game arrow disappears), as this scenario is only playable when
    the X-Men are not involved.

Now repeat steps 1-7 with Vassal 3.2.0 beta 2 or later. On step 6
you will get the error message:

  • Bad Data in Module: House of M [Layer - Scenario playability] -
    Expression evaluation error followProperty[X-Men_playing]

and the string “UNPLAYABLE” does not appear.

The misbehaving layer is called “Scenario playability” and it belongs to
the House of M scenario card (you can find it towards the bottom of the
module, under the Scenario map window). It is set to follow the value of
the global property “X-Men_playing”. This gp has a default value of 0
and gets updated to 1 when you click ready for the X-Men.

I can’t understand why all of a sudden such a simple layer definition
will not work anymore: it was working in 3.1.18 and 3.2.0 beta 1.

Is X-Men_playing actually the correct syntax for the property
expression? Is the hypen being interpreted as a minus?

Brent, can you have a look at this?


J.

Do we have a new target date for the “official” release of 3.2? Just curious, because my module requires the tiling feature, so I’m waiting for 3.2 to release the module.

Thanks,
-Mark R.

Thus spake mroyer:

Do we have a new target date for the “official” release of 3.2? Just
curious, because my module requires the tiling feature, so I’m waiting
for 3.2 to release the module.

No, because I’m now waiting on resolving these two problems. I need a
reply from Rindis regarding the stack offset problem, becuase I can’t
reproduce it. I need someone (Brent?) to look at barbanera’s problem.
I don’t know when either of those things will happen.


J.

Okay, 10-4. Thanks for keeping us informed.

I think you are onto something here: I changed the name of the gp from X-Men_playing to X_Men_playing and now it works.

Note that I have tons of variable starting with X-Men (X-Men_playing, X-Men_owner, X-Men_nemesis, etc) and changing them all would be very time consuming, as there are tons of restrict commands based on those.

I guess that maybe the update to allow for property expressions in the follow property field of layers for some reason doesn’t like the “-” (minus) sign in variable names. It might be a general problem with property expressions, though, which only showed up now because maybe I am not using the “X-Men…” variables in other traits which take property expressions.

Thus spake barbanera:

“uckelman” wrote:

Is X-Men_playing actually the correct syntax for the property
expression? Is the hypen being interpreted as a minus?

I think you are onto something here: I changed the name of the gp from
X-Men_playing to X_Men_playing and now it works.

Note that I have tons of variable starting with X-Men (X-Men_playing,
X-Men_owner, X-Men_nemesis, etc) and changing them all would be very
time consuming, as there are tons of restrict commands based on those.

I guess that maybe the update to allow for property expressions in the
follow property field of layers for some reason doesn’t like the “-”
(minus) sign in variable names. It might be a general problem with
property expressions, though, which only showed up now because maybe I
am not using the “X-Men…” variables in other traits which take property
expressions.

If this is the cause of the problem, then “X-Men_plyaing” is being
interpreted as the value of the variable X minus the value of the
variable Men_playing.

I find it weird that we ever permitted variable names to contain
anything other than A-Z, a-z, 0-9, and underscore—so my inclination
is to consider the old behavior a bug, not the new behavior.


J.

Mate, I was surprised myself to discover I could use the minus sign, blank spaces and even round brackets in variable names. Most likely there are other unexpected characters allowed (presumably all the ASCII ones).

But it was possible under Vassal till 3.2.0, maybe as early as beta 1 (or better build 0001). So much so I went ahead and made extensive use of them. Not just for the heck of it but because it helped me with the game logic/automation. For example, I use restrict commands based on $playerSide$_playing , say, and if $playerSide$ can no longer be X-Men but something like X_Men…

Another example: I have zones called like “Upper Manhattan (Support 1)” and a global property called “Upper Manhattan (Support 1)_free” which can be true or false. Will that global property stop working in property expression because it confuses it with an array component? The reason why I chose that name is because I can use $CurrentZone$_free to check if a certain zone is free or not. Why did I call zones with such complicated names? Report actions of course.

Before you consider that (those…) a bug, please consider all the legacy modules which might stop working now, not just the Marvel Heroes one.

I suggest to first make sure the minus sign was really the culprit (and not only a spurious problem with the Layer trait introduced by Brent between beta 1 and 2). If that’s the case, then I suggest - kindly request - fixing the Property Expression “engine” to allow legacy constructs based on “buggy” variable names.

Thus spake Rindis:

What about bug 9400? Probably not show-stopper, I suppose, though I
wonder if a lot of counter stacks will want to shift a little when it
does get fixed. (One-pixel shifts in stacks can be really hard for
end-users to figure out.)

User Rindis, you are delaying the release. Please reply regarding this
bug or we will proceed to offload your luggage. :slight_smile:


J.

Hah, I recognize that as the scolding lady on the PA system at Schiphol.

I have resolved the problems with using property names with - signs in them in BeanShellExpressions. Vassal should now correctly convert a reference to a property name X-Men to GetProperty(“X-Men”). This will occur when using any property name that does not follow the Java Variable naming convention. Using the Insert functionality of the Expression Builder does this automatically, but developers typing in their own expressions will need to be aware of this.

Joel,
As far as I can tell, this is a bug that has always been there so you won’t see any difference between 3.1 and 3.2.

The issue is that the snap-to point for a hex grid is not actually in the centre of the each hex. If you look closely at your example above, you can see that the square counter is just touching the hex grid at the top left, but is a couple of pixels clear at the bottom right.

This is not a good example because this grid is part of the map, but I confirmed it is an issue by testing on a map where the grid and centre points are drawn by vassal. I then created a dummy semi-transparent counted where the centre point is highlighted and it is clear that the centre of the counter is not on the centre point of the hex.

The Snap-to centre code and the hex grid drawing code use different code to calculate the hex centre and they are not producing the same results. The Snap-to code is generating co-ords a couple of pixels off-centre.

Great news, Brent, thank you. Do I understand correctly and I should now use GetProperty(“X-Men_playing”) wherever I was using just $X-Men_playing$ before? What about $playerSide$_playing where $playerSide$ resolves to X-Men?

Any chance you could expand your fix to empty spaces and (), i.e. round brackets, in variable names? Thanks.

Thus spake Brent Easton:

I have resolved the problems with using property names with - signs in
them in BeanShellExpressions. Vassal should now correctly convert a
reference to a property name X-Men to GetProperty(“X-Men”). This will
occur when using any property name that does not follow the Java
Variable naming convention. Using the Insert functionality of the
Expression Builder does this automatically, but developers typing in
their own expressions will need to be aware of this.

I’ve merged these changes to trunk@8431, and uploaded 3.2.0-svn8431:

vassalengine.org/~uckelman/builds/

Barbanera, does this solve the problem for you?


J.