Vassal 3.4.xyz errors/warnings

Technical Support & Bugs
21

Except my clock was right 24-7 under 3.2.17 ;-) And, while I am not a professional programmer anymore, I have programmed in my life, for many years, both as a hobby and as job, btw.

Anyway, I made my point and I won’t press it further.

So, m3tan, I added those Alerts for Pax Emancipation directly in the map global key commands, Like this: {BasicName==“Cooperative Market setup” && (NumberOfPlayers != 0 ? Alert(“ERROR: the cooperative phase has been setup already.”) : 1) == 1}
{(BasicName==“Competitive Market setup”) && (NumberOfPlayers == 0 ? Alert(“ERROR: the cooperative phase has to be setup first.”) : (CurrentEra == “COMPETITIVE ERA” ? Alert(“ERROR: the competitive phase has been setup already.”) : 1) == 1)}

They work under 3.2.17 and 3.4.11, no hiccups.

What do you think? Deprecated coding again? Thanks.

22

Brent, regarding the Talon module I removed those Alerts from the CPs and fixed (hopefully) all unquoted $variables$ in beanshells. I saved this new release under 3.2.17 and those reported problems are now gone, apparently, when the module is opened with 3.4.11. The new release is in my development folder

https://drive.google.com/drive/u/1/folders/0B1ftnUlDGp-dSHVVdzNkX2VVbGM.

However, I just noticed another issue: under 3.2.17 the ship counters in the Counters window (top left of toolbar) show a text label like “SP=32” (for the Ship points setup costs) along the top left edge of the counter. This text label is not showing anymore with 3.4.11.

This text label is towards the bottom of the “Ship” prototype (first one in the prototypes section) and is just displaying $SPlabel$ where SPlabel is a CP set to

If(CurrentMap=="","SP = "+ShipPoints,"")

Basically I was using the fact that CurrentMap is undefined in a piece palette window - and defined elsewhere in the module. (I checked, and indeed CurrentMap is still blank/undefined in piece palettes, even under 3.4.11, see the extra central yellow text label now displaying Map=$CurrentMap$.)

What gives? Perhaps CPs are now NOT calculated at all in game piece palettes with 3.4.11? Or the above condition returns false because now undefined does not mean blank and I have to use some other statement? (Actually, is there something like an undef function/operator in Beanshell?)

P.S. I just noticed that the “SP=…” text label is not showing even in the module editor under 3.4.11 (but it is under 3.2.17).

23

Yes, that would be correct. Calculated Properties being calculated off-map result in spurious Bad Data Errors being generated when Properties are referenced that are not set up correctly in off-map pieces. It looks like this was included in 3.4.4 as part of another fix to Calculated Properties and so was not documented properly in the Change notes. My apologies for this.

It looks like you have managed to find a valid use-case requiring off-map CP calculation.

I can offer you two options:

  1. Instead of $SPlabel$ as your Text Label text, use {CurrentMap=="" ? "SP = "+ShipPoints : ""} . This will work now.

  2. Wait for a while until I have time to add a ‘Calculate when off-map?’ checkbox to Calculated Property.

Regards.

24

Oh, wow! Since there is no Expression Builder icon/button showing, I had never noticed that even with Vassal 3.2 (or perhaps even earlier) text label values could use Beanshell expressions.

I am going for solution #1 then. But perhaps a “Calculate when off-map?” functionality for CPs would still be nice, because one never knows who might have, or have had, need for that.

Thanks.

25

Brent, I don’t know why, but changing Beanshells to double quote things breaks the Talon module now. In some instances, at least, haven’t tested them all.

For example, in the “Terran Ship Token” prototype changing a trigger property match from

Controller != $PlayerName$

to

Controller != “$PlayerName$”

Breaks an entire setup chain. Those triggers should fire only when Controller is not equal to $PlayerName$, but they are firing with the double quotes now, which is befuddling. Controller was just setup to be equal to $PlayerName$ when a player “takes control” of a faction, by using certain commands. This is not a 3.4.11 thing, though: removing the quotes the code “works” (by chance?) as before.

However, with 3.4.11 some tokens (like map features) that are placed at setup from a startup gkc are not setup properly anymore. For example, see the Empire War map, Terran or Talon tabs: every other row is empty under 3.4.11 now.

Since you were kind enough to open bug tracking for Talon issues, I could give specifics to reproduce everything. However, I am starting to despair. I don’t think I can update Talon to 3.4.11 compliance, making also sure I don’t leave behind unsupported unquoted expressions which might stop working in a future release etc. There are too many subtle/hidden changes that break things beyond a quick update job. Or, at least, a job worth doing spending a reasonable amount of time on. This being quite a complex module, that is.

I will just post a warning to use 3.2.17 for it, which was fully tried and tested for this module at the time. Most people will not notice that warning and assume the module was broken to start with, but that’s life… Thanks for you help.

26

When I was looking at your module, I noticed a couple of old-style property match expressions that are NOT Beanshell expressions - they did NOT have the {} around them. If you modify those expressions and add the quotes, it will break your module unless you also add the {}.

27

I’ve used the “$$” expressions extensively since their introduction and they’ve worked flawlessly with a variety of operators such as COUNT and !~ and nested with multiple && and ||. If I had to guess, you have some stray syntax that is non-Beanshell or the culprit is a tangentially related expression that is indirectly causing the “$$” expressions to appear to be failing.

28

Yeah, I made sure NOT to change the non Beanshell expressions.

Ok, this is getting weirder. As I mentioned I have this property check in a trigger trait in the Terran Ship Token prototype (only trigger there) which originally was as follow and, most importantly, was working as intended under both 3.2.17 and 3.4.11 (i.e. NOT triggering when Controller matches PlayerName):

{((isCasualty==1) || (CurrentMap!=Faction && CurrentMap!=Faction+" 1000") || (Controller!=$PlayerName$))}

It also works as above if I switch to Controller!=PlayerName (which I guess would be the recommended syntax).

However, If I switch to Controller!=“$PlayerName$” it does not work as intended in my module, because the trait triggers (with fatal consequences for a certain setup routine).

What gives? I don’t understand.

29

BTW, here are a couple screen shots relative to the other setup issue I mentioned (where pieces won’t show up in 3.4.11).

Talon (Empire War map, Terran tab) under 3.2.17:

[attachment=1]TalonMap3.2.17.png[/attachment]
and under 3.4.11:

[attachment=0]TalonMap3.4.11.png[/attachment]
Discouraging…

30

Help me out here—what are the missing images? Where are they defined? It’s hard to help when I don’t know what I’m looking for.

31

I can tell you that the module behavior for those images changed from 3.3.2 to 3.3.3-beta1, which was released in the middle of August. I could do more if I knew what I was looking for in the module.

32

Those images showing greyed out space ships are placed at startup by the following:

  1. Empire War map window → TALON tabbed panel → Terran tab → Terran map window

  2. BB, BA, CL, … at-start stacks (one per ship type) to place an initial one (at the bottom of each column)

  3. Place Marker traits - triggering on “setup” which is invoked by a startup GKC - inside those same at-start-stacks to spawn another one, which spawns another one in turn etc, increasing each their own counter (numBB, numBA…), and stopping at 5

Here is an example (disregard the Invisible trait, which is empty and not used):

[attachment=0]BBtemplate.jpg[/attachment]

33

Go to Preferences > Compatibility and check “Use Classic Moved Fixed Distance trait move batching”. That will solve your piece placement problem. Brent can probably explain why, and what to do instead.

34

Thanks, hopefully Brent will chime in and point me what needs to be changed in the module itself (not the end user preferences), then. Especially for future reference, I mean.

As for this particular module: this is all very much discouraging, as I said… At this stage, who knows how many other things there are that are failing under 3.4.x and that I have yet to notice.

35

Thus spake barbanera:

Thanks, hopefully Brent will chime in and point me what needs to be
changed in the module itself (not the end user preferences), then.
Especially for future reference, I mean.

As for this particular module: this is all very much discouraging, as I
said… At this stage, who knows how many other things there are that are
failing under 3.4.x and that I have yet to notice.

This has been true of every version change in VASSAL—each release during
3.2 could have broken something. Also each release during 3.1, and during
3.0, and each release before that. And each update to Java or your drivers
or OS… Basically this is true of all software ever written.

We can’t programatically determine what effects changes we make will have
on your module, and we can’t fix bugs at all if we have to also maintain
previous behavior. If we stop fixing bugs, then I’ll simply be having this
conversation with someone else—someone who is complaining about the bugs
we haven’t fixed–and I’d prefer to defend a decision to fix bugs instead
of a decision not to fix bugs.

Your module seems to have relied on a quite a few bugs—way, way more than
any other module we’ve seen. That’s bad luck. If you don’t fix these things,
eventually the module will become unusable, and I don’t mean unusable with
3.4. I mean unusable with 3.2.17, because people will have an increasingly
difficult time running 3.2.17—it relies on Java 8 and that’s not far off
from the end of its life.

Now is the time to fix these problems, while there’s still a collective
memory of what’s involved. Wait and it will only get harder.

–
J.

36

So, wait a minute, the Move Fixed Distance change was to fix a bug? Not some kind of performance improvement, instead?

Well, what can I say… I was just using Move Fixed Distance to place a marker and shift it up 150 pixels, which in turns places another which does the same etc.

I challenge everybody to figure beforehand this was relying on a bug.

37

Yes, the old Move Fixed Distance behavior prevented Undo from working properly. We’d had complaints about Undo failing sometimes for more than a decade and only discovered the cause in June. It was an extraordinarily difficult thing to troubleshoot.

No one’s claiming you should have known.

38

Ok, but may I ask then if fixing that old standing bug perhaps didn’t break something else in the meanwhile?

I cannot understand why just doing that multiple place, move, spawn cycle would not be supported by the new Move Fixed Distance trait.

Or perhaps it is, but it should be done some other way? Forgive me but “move batching” the old way gives me hope it can be done, but it doesn’t give me any hint how to do it updating the module itself.

That procedure really helps me to avoid having to define 50 different at-start-stacks to deploy 50 equal pieces on a line, say. I could try switching to STLs, I guess (to CurrentX/CurrentY+displacement), assuming that would work instead. But that would be painful/slow updating of basically all of my modules.