Beanshell support in Report fields

Module Design
1

On the topic of the whole “beanshell support in report fields” thing, I’ve recently been working on a module where cards work a lot differently from how I’m used to them working in games I’ve worked on, so there has been a certain amount of head scratching about how to wrestle “decks” to do the things I want them to. And it has had me resorting to funky logic e.g. to allow me to add a Deck Global Key Command to draw but not let opposing players use it and not “misreport” when they try:

image
image992×251 19.8 KB

Feels like an ugly hack but it does work :slightly_smiling_face:

Here’s another simpler example where it saves me an extra put-something-into-a-property step by letting me compute a numeric value on the fly:

image
image824×250 19.1 KB

Just thought I’d post these as examples of what you can do with this, since many users may not have even noticed this capability.

Brian

3 Likes
2

What version was this introduced? I’m hoping it wasn’t available until fairly recently because I kluged together solutions in 3.4 to work around that assumed limitation until I noticed the feature after upgrading from 3.4.13 to version 3.6.5…

3

Oh that definitely didn’t exist in 3.4. I can’t remember if it came in with 3.5 or 3.6 but I’m kind of thinking it was 3.6.

Before that you could use a CalculatedProperty to work around that, but obviously that was more cumbersome.

4

It’s this item, from 3.6.0-beta6:

9391: Beanshell can now access $$ variables in Report Formats

1 Like
5

Yup I kluged together a bunch of CPs. Much more troublesome was where to place a report in the traits list. Sometimes I wasted hours rearranging the location of reports or triggers so that it wouldn’t report an old or interim value. Now that you can evaluate an expression within the report, I can suppress all those spurious reports without playing the whack-a-mole report placement game…