limit "place counter"

Module Design
1

My units have a “place counter” trait, used to place a control marker on map hexes. Keyboard accelerator CTRL-Z makes it fast and easy to use.

But when the whole stack is selected, multiple counters are placed. Not a big deal at first, because they don’t stack so only one is apparent.

But later, if the hex is retaken, those must be deleted and sometimes it’s a PITA.

question: Is there any way to limit the place counter trait so only one counter is placed?

2

I’m thinking of a possible workaround: pre-populating the board with non-selectable non-movable control markers, with three layers, (always active, loop). First layer would be transparent. Second and third layer would reflect Faction-A and Faction-B.

The prototype for unit would include a GKC “change control”, that would change the control marker in the same location to the appropriate layer.

Now the problem is I cannot get the right syntax for the “matching properties”. I think it should be somethink like:

LocationName == $LocationName$

So first one would refer to the target unit (control marker) and second one, inside $…$ would be evaluated for the piece sending the GKC. But i cannot make it work. What I am misunderstanding?

3

Why do think the format should be that particular one as opposed to the two correct formats that are shown as examples in the Reference Manual?

Is this format listed somewhere we don’t know about? I’m not trying to be mean, but we are in the process of updating the documentation and you’re not the first person to make this mistake. Is this format presented somewhere in the documentation or in the wiki?

Thanks.

ps. Either

LocationName = $LocationName$

or

{LocationName == “$LocationName$”}

should do the job.

4

Not that I think this particular format would be correct. After several tries on my own with no success, I went to the documentation for help and I thought I had copied the example verbatim. Aparently I cannot read or write and messed up with the = sign.

And of course, it works if i type it like that!

Many thanks!

5

No problem :slight_smile:

I think it does point out that the doco needs to be clearer on the difference between the two. The = to == is a subtle difference that is easy to miss.

6

I’m definitely planning to cover expressions better in my doc revamp

7

I was one of those people… Here are my 2 cents:

  • Most of the online help windows open in kiosk mode (no navigation toolbar or browser buttons). So you can only have one window open at a time and can’t minimize it. Clicking on a hyperlink is a one-way street. You can’t even return to the Module Editor unless you close the active help window, so one cannot refer to the online help documentation while building an expression. I’d often wind up desperately clicking help all over the place to try to find a page that I saw earlier but was forced to close. I eventually gave up on the online help and started relying on the 3.1 Designer’s Guide PDF, which turned out to be an even bigger regret.
  • The 3.1 Designer’s Guide PDF needs to be set on fire. It’s totally obsolete and was the source of most of my misery the first week or so I was learning Vassal. It predates Beanshell entirely, so it kept steering me towards building Classic expressions when I should have been learning Beanshell.
  • When one is new to a programming language, inconsistencies and undocumented bugs have a nasty multiplier effect on the already steep learning curve. I remember pulling my hair out trying to figure out why my GKCs weren’t working. You start second guessing everything and wind up breaking syntax that is actually working. Thankfully, you (Brent) were here to inform me that one of the step-by-step examples in the Designer’s Guide doesn’t actually work. And thanks again for subsequently fixing that bug.
  • Some examples of “inconsistencies” that seem obvious to me now, but really confused me back in May:
    a) Beanshell doesn’t use $$, except when it does. {PieceName==“$PieceName$”}.
    b) You must use Classic unless you see a calculator. Use {} to denote Beanshell. Except for Calculated Property, which must be Beanshell and does not use {}.
    c) There were a couple others but I don’t recall at the moment.
  • My vote would be to eradicate any mention of Classic in the documentation except where absolutely necessary. Obviously we need to retain it for functionality of existing modules, but the dual syntax really steepend the learning curve for me. It felt like I was using some weird hybrid of BASIC and C++. I can’t tell you how many times I had an = when I needed an ==, or vice versa. Again, it’s all obvious to me now, but I struggled mightily until a light bulb went off that { meant “exit BASIC, enter Java/C++” and } meant exit Java/C++, enter BASIC"…
8

All good points.

9

Excellent points. I am actually spending most of my Vassal time today (and probably for several more days) on a pass through the online documentation. Will then use that as a basis for redo of PDF in due course. Probably also the wiki, although I will also try to grab and include any tidbits that might have accumulated there back into the whole doc set…