I’m trying to use the new beanshell map-level reporting, and it doesn’t seem to be working as intended.
{CurrentMat==“Commander” ? “” : PlayerId+" – “+pieceName+” moves from “+previousLocation+” to “+location+” *"}
As I understand it, this should be exactly the same as the default move within map reporting, except that if the piece is on a Mat named “Commander”, there will be no report or the report will be blank.
The full report is generated regardless.
To do a sanity check, I tried:
{CurrentMat!=“Commander” ? PlayerId+" – “+pieceName+” moves from “+previousLocation+” to “+location+” *" : “”}
This also generates the full movement report regardless of whether or not the piece is on a Mat named Commander.
CurrentMat… I think that gives you the field that’s in the Mat trait. Is that what you’re expecting? Note that there is also CurrentMatBasicName and CurrentMatPieceName if you need instead to use part of the name of the mat piece?
This is the box where “CurrentMat” gets its value from:
It sounds like the Mat names start with “Commander”, but that isn’t their full name, correct? In that case, try CurrentMat.startsWith("Commander") instead of CurrentMat=="Commander". If the word “Commander” is somewhere within the name, but not necessarily at the start, you can use CurrentMat.contains("Commander") instead. Keep in mind that capitalization must match.
OH. I’ve figured out what the problem probably is. The reporting stuff in the map uses the MAP as the property source – so you can check properties of the Map and of the Module there, but not of any particular piece. So in other words CurrentMat in other words is probably “” in that context if you print it out in that line, because map doesn’t have a CurrentMat property.
I agree it would be nice if the piece auto-reporting could use the piece as the property source. I’ll at least have a look to see if it could be switched over.
Edit - to answer your above question – I just meant adding CurrentMat into that expression e.g.
{CurrentMat!=“Commander” ? PlayerId+" – “+pieceName+” moves from “+previousLocation+” to “+location+” *" + CurrentMat : “”}
I looked at the code for a bit, and it looks like the display of any particular line of that move reporting could have multiple pieces? Is that true in your experience? i.e. if you grab several pieces in the same space and move them you get one report for “this, that, the-other” moved? If it’s multiple pieces then obviously making a single piece the property source would be problematic.
By the way, the CurrentMat apparently would work in the “changed on this map” field.
I don’t really see the problem. In my experience, a report is generated for every piece that moves. In other words, if you drag select 5 pieces and move them, each generates a report. If you move a mat with 5 pieces on it, the mat and each piece of cargo generates a report.
I don’t know how you go about one report for multiple pieces, or even if it is possible.
So, with my limited understanding, I see no problem with tying the reporting to a piece.
Okay I did an experiement – when a build labeled “PieceAsMovementPropertySource” (or approximately that) comes up at vassalengine.org/builds in a few minutes, give it a try and see if that makes the expression work the way you want it to?
Side note: if all this doesn’t work out, I’d be interested in a “restrict reporting” trait to achieve the same result. GKCs and the like can already do this, so that might be easier?
FWIW I achieve the same kinds of stuff in my modules by turning off all the Map level autoreporting (except for the “changed” field left at $Message$ as that’s what does Report traits), and then the apply-on-move key from the Map triggers checks on each piece and it can decide (with full access to its properties) whether it wants to display a message. So then I can have logic like some pieces moves are displayed in different colors, or in bold, or whatever, in addition to the Mat logic and so forth. And I screen out all the stuff where e.g. LocationName == OldLocationName so I don’t get reports of all the little fidgets.
But anyway this new PR might get things where you need to go. Just mentioning that there’s a way to achieve the same result with traits.
Yeah, I have heard of things like that, but reporting is pretty low priority for me, as long as it is “good enough”, and that sounds like a lot of work.
I think having better movement reporting be cleaner and easier to set up would help a lot of people.
Tried the new Vassal, no changes to module. I just get:
Bad Data in Module: Source: {CurrentMat==“Commander” ? “” : PlayerId+" – “+pieceName+” moves from “+previousLocation+” to “+location+” *"} Error: Expression evaluation error. Turn on the Audit Trail preference to generate more details in the errorlog.
