My module Space Empires (vassalengine.org/wiki/Module … mpires:_4X) seems to have picked up a bug when players update to 3.2.5. There is a type of counter, Ground Unit, with a property sheet. A value on that sheet is tracked by a layer property such that when the value is changed the layer changes to display a different numeric counter next to the main counter. All of these properties exist within a prototype for the Ground Unit counters.
I have a similar setup for regular Ships again using prop sheets, layers and prototypes. This seems to be unaffected by the update to 3.2.5 and continues to work as normal.
My guess is either something happened that affected ONLY that prototype in the update, I’m not sure what, since they are almost identical in function. Maybe there was a bug I was using, unknowingly, that got patched?
I’ve also had counter prototypes “break” occasionally where they stop functioning normally. This was before the update when I was designing the module. However, this was usually fixed by restarting Vassal. Does not seem to be the issue here.
Brent, I had a look at this test module and found that the breaking
commit is 8665. The hit point display on the single piece in the
module shows 4/4 before 8665; from there on, the intial digit is
always 0. The fix for Bug 10128 seems still to be breaking things.
Would you like to look at this before I release 3.2.6?
The primary problem is that the majority of your expressions you use to follow in the Layers are incorrect. By chance, these expressions still worked prior to 3.2.5, but when I added the code to improve the efficiency of processing single property expressions, this caused you invalid expressions to fail.
Inside the expression braces {} it is incorrect to use the old $variable$ references. So where you use {$HP$}, this tells vassal to use the value of the dynamic property $HP$, which does not exist. The correct expression is {HP} or just HP will work.
There are two ways forward:-
Leave the code as is, you fix your module, and anyone else who has made the same mistake does the same.
I modify the evaluation of single property expressions so that $HP$ evaluate the same as HP.
I have committed a change to Brent-3.2-p2p@8717 to implement option 2 which resolves the issue.
I’m not a fan of fixes like this, generally—but as we don’t have a spec for any of this, we don’t reject invalid expression syntax on input, and it worked before, it’s hard to argue that {$HP$} is wrong, and this change should minimize breakage. I want to make sure we don’t do this kind of thing in V4.
won’t the syntax be governed by the scripting language, in this case, Python,
from the users perspective that is? It should be rejected and fail if the user
input is wrong I would think
From: uckelman uckelman@nomic.net
To: messages@vassalengine.org
Sent: Wed, May 22, 2013 10:04:51 AM
Subject: Re: [messages] [Technical Support & Bugs] Bug after update to 3.2.5
Merged to trunk@8719.
I’m not a fan of fixes like this, generally—but as we don’t have a
spec for any of this, we don’t reject invalid expression syntax on
input, and it worked before, it’s hard to argue that {$HP$} is wrong,
and this change should minimize breakage. I want to make sure we don’t
do this kind of thing in V4.
won’t the syntax be governed by the scripting language, in this case, Python,
from the users perspective that is? It should be rejected and fail if the user
input is wrong I would think
Yes, but that’s not the whole story. There will be an API which we make
available for use in the scripts—and I want to make sure that this API
is versioned, so that if/when we change it, we don’t have to do hacky
things to make sure that old modules continue to work.