Ok, so the solution I proposed might work then.
I can’t seem to get this to happen on my Windows 7 64 bit machine. I have Java version 1.6.0_23.
What do you mean by ‘Up to date’ Java? are you using Java 7? Can you try installing Java 6 (1.6) and see if it still happens. There have been a number of funnies with Java 7, this could possibly be another.
Ok, Well, I have managed to get some strange behaviour, but not when moving a single SCM marker, only when selecting and moving two at once.
Your scheme for moving the VP markers is so complex, it is difficult to see whether there might be a problem in there somewhere. You could try a simpler scheme where you maintain the VP count in a Global Property, set the VP track up as an irregular grid with a region for each number, and use the ‘Send to Location - Named Region’ option to move the VP counter around.
I can fix this
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: Tuesday, September 18, 2012 4:49 PM
To: messages@vassalengine.org
Subject: Re: [messages] [Technical Support & Bugs] Moving pieces onto map
and triggers
Ok, Well, I have managed to get some strange behaviour, but not when moving
a single SCM marker, only when selecting and moving two at once.
Your scheme for moving the VP markers is so complex, it is difficult to see
whether there might be a problem in there somewhere. You could try a simpler
scheme where you maintain the VP count in a Global Property, set the VP
track up as an irregular grid with a region for each number, and use the
‘Send to Location - Named Region’ option to move the VP counter around.
Read this topic online here:
https://forum.vassalengine.org/t/moving-pieces-onto-map-and-triggers/5284/10
Sorry, I tried to be exhaustive with the pertinent info and slipped up. On the Windows 7 box I have 64-bit Java 1.6 update 35 installed, that’s what I meant by current (I’ve seen enough in other threads to dissuade me from using Java 7).
Each power’s VP total is already maintained in a Global Property. The sequence of events is as follows:
- Drag an SCM from the power card to the main map (or vice versa) and the key command applying to all units ending movement on map is received
- This executes one of two triggers based on the property match (if the OldBoard was the Power Cards or the Main Map)
- Trigger sends a GKC to the power’s VP marker
- VP marker does a Set Global Property to increment/decrement the VP Global Property by the correct amount
- VP marker executes a Send to Location to move itself to the new correct location on the track
I haven’t ever tried moving 2 or more SCMs simultaneously, as that should never occur in the game.
You have the same setup as me and I have not been able to get it to fail.
It may seem retarded, but expand the expression and add your Maps, make the
expression ironclad - be sure.
The boards are not on the same map. Sometimes the pme neglects this I have
found (why I have no idea), same with Map/board setups
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: Tuesday, September 18, 2012 8:29 PM
To: messages@vassalengine.org
Subject: Re: [messages] [Technical Support & Bugs] Moving pieces onto map
and triggers
You have the same setup as me and I have not been able to get it to fail.
Read this topic online here:
https://forum.vassalengine.org/t/moving-pieces-onto-map-and-triggers/5284/13
Thanks, I’ll try that tomorrow! At least it’s encouraging that no one can seem to replicate this. I have been testing on my iMac (OS 10.7.4, 64-bit Java 1.6u35) and just now got a tripled score adjustment when moving a French SCM to the map.
Actually I tried fleshing out the PME just now to specify CurrentMap, CurrentBoard, OldMap, and OldBoard. I still get the occasional doubled or tripled score adjustment, at least on my Mac here. Grrr. Am I this big of a klutz at dragging and dropping things?
What’s wrong with my proposed fix, anyway? Just make sure the triggers don’t fire if the piece name and direction is the same as the latest stored SCM’s names and direction…
Unless it’s the GCK itself firing multiple times by itself, for unknown reasons, that should cure it…
I’m trying your idea today.
Unfortunately the method of using a variable to store the name of the previous map and checking against that doesn’t work. Somehow the GKC sent to the VP marker that tells it to increment/decrement the VP Global Property is only sometimes occurring more than once. I’m stumped.
Of the previous map? My suggestion was to store the name of the previous SMC itself, assuming they have an unique BasicName. If the latter is not the case then store their PieceId but careful that won’t work if they came from the same game piece palette slot. In that case you gotta make sure they get an unique id (use a Dynamic Property called ID or something) when drawn from the palette (use a global property to keep track of all SMCs drawn). Moreover, you should also store the direction (increase or decrease) requested by the previous SMC.
Do you mean you are sure it’s the GCK itself misteriously duplicating himself while the trigger invoked to run it is only firing once? That sounds very surprising, if so. Make sure by adding a report action on the triggers…?
These square control markers all have the same BasicName–it didn’t occur to me to give them different names, they are all functionally identical. They aren’t in any palette at all, so never get drawn from one. They are items in At-Start Stacks.
I’ll pop a Report in to see if it’s the Trigger that’s actually firing 2+ times. I guess it would have to be.
If so, and if it’s confirmed that it’s the trigger firing 2+ times as most likely, then no need to assign different names but do try storing the PieceId and “direction” of the last SMC used and make a check vs those in the SMC triggers.
Storing and checking the old map only won’t work. You need to make sure your triggers can discern if the current SMC is not the same as the latest used before or, if it is, that the direction (increase/decrease score) is not the same.
Check the IRC channel. The problem is in the VP Markers and its prototype.
You inadvertently create a loop that sometimes fire
I’m not sure how there is a loop. What you suggested in the chat was that the Trigger on the VP Marker that listens for Alt-Ctrl-Shift-V is triggering Alt-Ctrl-Shift-R…but there is a property match expression on this, so it only happens when the piece is not in the VP Track zone. I put this in here to return VP markers to the player’s current score if someone tried dragging it off the track entirely.
Alt-Ctrl-Shift-R is making the VP marker to go to whatever the current score is. That’s supposed to happen either after the Global Property is incremented/decremented, or if the player manually moves it off the track. It should not be triggered by movement of the marker within the zone of the VP Track.
barbanera, I may not be understanding the implication of why you think storing the direction of the last SCM’s move is important, but to be clear: movement of SCMs does not necessarily alternate between to/from the map. It’s entirely possible that there would be 2 or more consecutive movements of SCMs from the Power Cards to the map.
Very interesting–i put in a test Report Action on the Trigger that is set off by movement between the boards. Played around until I saw a doubled score adjustment, but the test message only came up once. It’s obviously the key commands that the triggers fire (Ctrl-K does a Ctrl-1/Ctrl-2/Ctrl-3–depending on whose marker it is–if increasing the score, Alt-K does Alt-1/Alt-2/Alt-3 if decreasing the score) that are being repeated somehow.
Here,
Make a mod copy and try with this buildfile.I’ve made a few slight changes and it no longer jumps extra spaces on the VP track for me like it did before as you described. See if it still jumps for you