Problems with Dynamic Property

Module Design
1

The linked module does fine counting steps in several Private Windows and the Main Map.

Unfortunately, the Dynamic Property called “counted” only works (switching from “yes” to “no” and back to “yes”) when the piece is dragged from Private Window Pro Col 1 → Private Window Pro Col 2 → Private Window Pro Col 3 and not from Private Window Pro Col 3 → Private Window Pro Col 2 → Private Window Pro Col 1.

It must be a problem of Trait Order but I tried all permutations to no avail. Any ideas?

ftp://ftp.snafu.de/pub/transfer/vassalt … _test.vmod

2

Unlike other traits, I have had problems with DP’s and Set Global Property traits when trying to figure out exactly where I should place them in trait order. I’ve found that all those problems went away when I simply placed the DP and SGP traits at the top of the trait list right under Basic Piece. Try that as see if the problem goes away. If not, i’ll be glad to take a look at the test.vmod.

3

Putting DP (which is the problem) and SGPs at the top doesn’t work.

I’d be glad if you could take a look at my test.vmod. The hot player side is “pros”, and the relevant part is to be found in the Prototype “protestant”.

Matthias

4

I took a look, hope that’s cool, and I do think it’s your trait order, yes. Say it’s moving from PC2 to PC1… I think it triggers increase TotalStepsPC1 first, then decrease TotalSteps when moved from PC2 after that (and so changing the yes to no).

Maybe separate those actions… perhaps remove setC and unsetC from the other trigger actions… then add two new onmove trigger actions with:

CurrentZone=~PC1|PC2|PC3|PC4
setC

and

CurrentZone!~PC1|PC2|PC3|PC4
unsetC

5

I’m looking into the mod now …specifically the “protestant” prototype. The first thing I’ve noticed is that you are listing your traits backwards. Traits are executed from the bottom up and it appears you’re attempting to execute them from the top down. That’s bound to cause some problems.

Also, I noticed that you are using “onmove” as a map trigger when you move a piece onto that map. That’s good. That’s how I would do it. However, on the Trigger Action traits, you are attempting to use the “onmove” trigger as “Watch for these keystrokes” when the trigger should be placed in “Keyboard Command”.

Someone else may be able to explain the proper usage or need for the “Watch for these keystroke” function but as for me, I’ve never used it nor ever found a need for it.

Other suggestion from experience …DP’s should be placed on the actual piece instead of a Prototype as a DP value applies to a specific piece as opposed to all pieces that carry that prototype.

I look into it further later in the day.

6

I actually followed the path given by “Tips and Tricks” which I found in the vassalengine docs. The trait order is the one employed there, where it works. For my needs I had to ammend it.

It actually made no differce having the DP outsourced in a prototype. I had it in the actual piece first and it behaved the same – which might have to do with the fact that the modul so far uses no more than one piece in total.

7

You problem is not related to trait order. The problem is with understanding…

  1. The “Counted” property is not built-in function in VASSAL. You could assign any name to it.
  2. You should not create extra DP if you use OldZone built-in property. But there is a bug in VASSAL: the OldZone property is updated only when you drag pieces by mouse. When you use commands to move you pieces, the OldZone is not properly updated. So the whole thing about “Counted” (or name it as you wish) property - is workaround this bug.
  3. So if you planned to move pieces only by drag&drop then simply remove all functions related to “Counted” DP and you will be fine.
  4. The mentioned tutorial from tips&tricks section consider the case when you need calculate something in ONE zone. In your case (multiple zones) think of “Counted” property as replacement for OldZone. For example name it “CountedIn” or “OldZone1” and assign it the name of CurrentZone (or CurrentMap or whatever).
    But I repeat it once again: use this spare property only if you want use commands to moving you pieces.
8

I’ve edited your module with my suggestions but you original problem persists. So it is not related to what I wrote. Sorry for my misunderstanding. Need more research.

9

Couple of things - yes the traits are backwards but this only minor problem, the main problem is trait built logic. Each trigger depends on the onmove keystroke and each time at least 2 triggers are firing 1 for leaving a zone and 1 for entering another zone (so which came first? chicken or egg scenario). RRVS noted this above somewhat

The logic needs a lot more definition for what you are trying to do.
You should have 3 start off trigger listening for the onmove keystroke based on where you moved to that then branches out to each possible combination of work you want to do.

so the 3 start off triggers would be:
Start1 when CurrentZone = PC1 listen keystroke ‘onmove’ execute keystroke ‘gotoPC1’
Start2 when CurrentZone = PC2 listen keystroke ‘onmove’ execute keystroke ‘gotoPC2’
Start3 when CurrentZone = PC3 listen keystroke ‘onmove’ execute keystroke ‘gotoPC3’

and from each one of these start off triggers you would have triggers based on where they came from that do the actual work ( so in the case of PC1 you would have 2 triggers:
PC2 to PC1 when OldZone = PC2 listen keystroke GotoPC1 execute keystroke unsetC, decTSPC2, incTSPC1, setC
PC3 to PC1 when OldZone = PC3 listen keystroke GotoPC1 execute keystroke unsetC, decTSPC3, incTSPC1, setC

rinse repeat the 2 above for PC2 and PC3 changing props/keystrokes as reqd.

This prevents trigger collision which you currently have ongoing and unexpected results like you are seeing. You follow 1 path to its end without triggering another path.

10

I look forward to try that, Tim. It might take some time though, as I’ll be offline for the next 4 weeks.

11

Yes, Tim is right. And both of these triggers try to change the same “Counted” value!

I change your module, and it works fine (in my humble opinion):
drive.google.com/file/d/0B5rEsE … sp=sharing
That is what I’ve done:

  1. Changed the logic of “Counted” property. Now it reflects the zone, where a piece was taken into account. In other words it is merely clone of OldZone property. By the way I renamed it to “CountedIn”.
  2. Separated the command, which changes “CountedIn” property (i.e. “setC”), from trigger actions, that increases/decreases “TotalStepsPC#” global properties. I made it by adding one extra Trigger Action (named simply “onmove”), that fired all other Trigger Actions one by one and only then changes “CountedIn” property.
  3. Improved logic when piece being deleted.

Hope this what you need.