VASSAL 3.2.0 tomorrow?

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.

I am happy to report that it works straight out of the box: the error with a layer following the X-Men_playing variable is now gone.

I am not sure I understand the instructions Brent gave - as I had to do nothing except install this latest build to have it work again - but insofar minus signs and/or empty spaces and/or round brackets are still supported in expression builders and Vassal 3.2.0 in general I am pretty happy.

Thanks!

Should have been covered by the same fix.

I just wanted to point out that if you click on the Calculator icon and then feel confident enough to type in your own BeanShell Expression, then you have to be aware that to access any properties with spaces, parentheses, hyphens or other odd characters ($ and _ are ok), then you will have to use GetProperty(“Funny property (name)”) rather than the property name itself. If you use the ‘Insert’ button to select a property name from the drop-down list, then Vassal will do this for you automatically.

Hello
if no property in “list” of “turn counter” bug appears when I used the “expression builder”.
sorry for my english I pass by google translation
I’m French.

cordially

Thus spake ertiyu:

Hello
if no property in “list” of “turn counter” bug appears when I used the
“expression builder”.
sorry for my english I pass by google translation
I’m French.

I can’t find the expression builder you’re referring to. Is anyone else
able to replicate this?


J.

^ ^ better than speech

Version without bug
dl.dropbox.com/u/65597666/No% 20bug

Version bug
dl.dropbox.com/u/65597666/Bug

The bug appears when inserting “calculated property” in this piece in the “game room prototype definition” or any other function with the “expression Builder”.

By cons, if “list” of “turn tell” is cancel service works!

In addition, if a property is placed in “list” does it work
And once removed the bug do not come back.

Thus spake ertiyu:

^ ^ better than speech

Version without bug
dl.dropbox.com/u/65597666/No[1]% 20bug

Version bug
dl.dropbox.com/u/65597666/Bug[2]

The bug appears when inserting “calculated property” in this piece in
the “game room prototype definition” or any other function with the
“expression Builder”.

By cons, if “list” of “turn tell” is cancel service works!

In addition, if a property is placed in “list” does it work
And once removed the bug do not come back.

[1] dl.dropbox.com/u/65597666/No
[2] dl.dropbox.com/u/65597666/Bug

Try the 3.2.0-svn8432 build:

vassalengine.org/~uckelman/builds/

Is this better?


J.

GOOD :exclamation: :exclamation:

Great work! :wink:

no bug with version 3.2.0-svn8432 build

Thank.