I’ve built intricate Vassal modules with advanced features but one simple thing I have yet to master is the placement of Report Action. The headaches begin when I have Trigger Actions and GKCs that go back and forth between multiple pieces. I frequently wind up with a “rogue” Report Action that triggers in the wrong sequence no matter where I place it in the traits list - top, middle, or bottom. It defies all logic. Sometimes I waste hours on trial-and-error and IF I find the correct placement, I often see no rhyme or reason for it. Is the sequencing documented in detail somewhere?
I recently learnt that the Report Trait always executes AFTER everything else on the same piece/key command, even a Delete. Perhaps this is the cause of your confusion, as it was mine. I think the Vassal trait order documentation hasn’t quite captured that point.
The solution if you want something else is to use a Trigger to control precisely when the Report Action will fire.
So with the particular situation I’m struggling with, a Trigger Action (Ctrl-I) performs a (Shift-I) keystroke. A GKC is triggered by that (Shift-I). The Report Action reports with that (Ctrl-I) keystroke, so one would think that it would occur before any Shift-I command. But no matter where the Report Action trait is placed, it reports AFTER the GKC changes a $Property$ that is used in that report.
For some context, players are picking a location on the map to take a resource. They can only take one on their turn. The menu command to take a resource is hidden when I change a Dynamic Property to “None”. So after they take a resource, the Property changes to “None” and they cannot take any more resources. But what’s happening is it reports “None takes 1 oil from Ploesti” instead of “Germany takes 1 oil from Ploesti”. I found a workaround so this problem is solved but it’s maddening that the Report Action seems to defy all logic…
Yup. I’m aware of that. So I tend to place Trigger Actions on them as well. What’s maddening here is that it seems that they occur AFTER GKCs nested Trigger Actions. So I wound up in a situation that it is impossible to achieve what I want because it happens after the keystrokes further downstream on the Trigger Action list. I’m starting to think the existing Report Action should be deprecated and replaced with one that follows the sequencing of all other traits. Leave a tick box to use legacy reporting sequence but default to new method going forward. It’s really archaic in its present state…
Your situation is behaving as I would expect. Report Action is after all other actions, including Triggers. So, this is happening, regardless of Trait order:-
(Ctrl-I) is Triggering (Shift-I)
(Shift-I) triggers the GKC
(Ctrl-I) finally triggers the Report
As you have found, to get the Report first it must be performed by a different keystroke (say Ctrl-Shift-I) from within the Trigger prior to (Shift-I).
Yes, a more flexible Report trait would be nice. I recently asked for something similar for the GKC Report field, which currently seems to do the reverse i.e. the GKC Report actions before that GKC action is performed, unless I am mistaken.
Yeah I see your point. The maddening thing is I’ll spend hours constructing an intricate sequence then worry about the reporting after it is working. That’s the way I’ve programmed my whole life. In Vassal, I have to retrain my brain to plan around reporting before anything even works because it’s not flexible at all. If you construct all your logic around Restrict Commands (cannot), the whole thing might be useless if you can’t sequence the reporting properly. Then you need to rebuild everything around Trigger Actions (can) just to cater to the silly reporting limitations.