While delving into the mouse over viewer and the use of Summary Text above pieces using Beanshell expressions (as there appeared to be a problem with what I already have got there) I found a number of issues.
On the ‘Expressions’ page the link to ‘Sum and Count functions’ on the ‘Sum and Count’ Row gives a page error ‘File not found’.
Reference manual; for ‘MouseOver’ at the ‘Summary text for above pieces’ specifies in the ‘NOTE:’ ‘…that when using a Beanshell expression here then you will need to use sumProperties…’. Back to number 1 page, sumProperties is simply not there.
Then I used {SumStack(“propertyname”)}. Propertyname in this case being ‘asw’. Extract from error log follows:
VASSAL.tools.ErrorDialog - Source: {SumStack(asw)} Error: Expression evaluation error. See the errorlog for more details.
Expression Audit:
Source type=
Source name=
Source field=Summary text above pieces
Source Expression={SumStack(asw)}
asw=10
Error=: Command not found: SumStack( int )
2023-06-30 22:37:35,381 [17132-AWT-EventQueue-0] WARN VASSAL.tools.ErrorDialog - Source: {sumProperties(asw)} Error: Expression evaluation error. See the errorlog for more details.
Expression Audit:
Source type=
Source name=
Source field=Summary text above pieces
Source Expression={sumProperties(asw)}
asw=10
Error=: Command not found: sumProperties( int )
Note that {sumStack(“propertyname”)} also does not work.
I found it: This reference page has a link to ExpressionsSumCount.adoc that just has a typo, it should be linking to ExpressionSumCount.adoc in the 3rd row from the bottom in the table of examples.
The second one is towards the top of the 3.7 Mouseover reference, he’s noting that sumProperties is not mentioned on the Expression reference page.
Joel, How about actually going to the online reference manual and navigating to the necessary page. Why ask for ‘precision’ when there is none, except that as cited. Is that so hard to do manually? As in, just what JoelCF25 did.
For me, it was hard–ok, maybe not hard, but not easy. I did not immediately understand that you are referring to 3.7 beta documentation, as the subject line can be read as bundling “documentation problem” with “3.7 bug?” as two distinct things from each other. So I went looking in the current online 3.6 documentation, didn’t find these things, and eventually divined that it might be in the 3.7 beta documentation, which is only in the beta (that I haven’t used) or in Github.
Snark at those trying to respond as much as you care to, but I didn’t connect all the dots immediately.
I tried that. I found neither thing in five minutes of looking.
You found the two errors, so you knew where they were. Rather than expect someone else to track them down, you could have provided URLs. @JoelCFC25 provided exactly the information required, for which I’m grateful.
Approach bug reports with the assumption that the reader doesn’t know what you’re referring to. If you give the reader enough information to go directly to the problem, that increases the chances that the reader will address it.
I’ve fixed the link for ExpressionSumCount (and another nearby for ExpressionRange). I’ve asked Brent about sumProperties, as I don’t know what to do there.
Yes, mea culpa. I should have used the urls as did JoelCFC25. As for ‘did not immediately understand that you are referring to 3.7 beta documentation’ was there something wrong with the heading/title? JoelCFC25, that you put the effort in is much appreciated. I was quite remiss with not using the links (actually did not even think about about, so much for my level of acumen).
Regardless, he’s Don (aka palad0n - the knight in shining armour astride a wonderful mount). Not a non entity.
It’s not clear from the title which version of the documentation this is about—there have been four beta releases to date and numerous development builds, with many documentation changes across them.
As for the problem you’re seeing with SumStack, can you produce a minimal module demonstrating it?
Problem with SumStack? I’m not just ‘seeing’ it, it exists for, presumably, everyone using 3.7 beta 4. Put simply, it’s a non-sequitur and the function does not compute.
Why not do yourself what you are asking me to do? The issue is not my problem, I report a (probable) bug. Not up to me to produce a minimal module to demonstrate that. That, and I am sure you or somebody else, has just such a setup to test these types of errors/bugs. I know I would.
Although not a special bug investigation module (actual version), I refer to a previous post where I mentioned that I found a solution after several hours of ‘what iffing’. To me that is my version of a minimal module - the real ones.
Once I finally get 1 of those modules behaving as I would like, then I’ll definitely using the new copy/paste html functionality to get the changes into the other 2 modules. Many thanks for that innovation.
This functionality also raises a question. What happens if the GPID is different?
You know what you’re trying to test better than I do. If you produce a test case, you can be sure it’s what you intended, whereas I cannot.
I could produce a test case, but I could also be doing development work. I can’t do both simultaneously, so when I choose to create a test case, it directly reduces the development time spent on the project. If you produce a test case, no development time is lost.
Time I spend on V3 is time I don’t spend on V4. If you want me to spend time working on a V3 bug, you won’t convince me to do it by making me do work you could do instead.
If you care enough about the bug, you’ll provide a test case. If not, then not. The time when I would run down problems like this is over.
I could be wrong, but it looks to me like you may be using SumStack() incorrectly. I think the argument to that function is supposed to be a string that specifies the property name, so in your case the correct syntax should be SumStack(“asw”). The Error message suggests that your module instead used SumStack(asw) - without the quotes, so Vassal dereferenced your asw variable to specify the property. However, that variable was set to the integer value 10, and Vassal could not find a SumStack() function which expected an integer variable - hence the error.
Whether or not I’m right in my diagnosis, I think that your description of the issue was not sufficiently clear, and when the maintainers asked for clarification, your responses were unhelpful. Please show respect and remember that they are volunteers doing a service for the entire Vassal community.
Well tickle my whatever with a feather. I do believe you are indeed correct. No damn quotes around asw.
I’ll have another look at that one, as the GetProperty(blah) is just so obsolete (obsolescent?) - for the purpose of the mouse over any way.
I’ve been thinking this was a Text Label the whole time.
The Sum/Count Stack/Mat/Attachment can only be used inside Piece Traits. The Function Builder in 3.7 was updated to only show the correct functions, depending on which type of component you are currently editing.
While you can add SumStack("property") to an expression in the MoV, it will be always return 0 because MoV’s don’t have a Stack.
This was the whole point of adding the sum(property) expressions to the MoV.
I should have twigged when I updated the reference guide. The original note and the updated noted are garbage, you have found the correct way to do this. I’ll update the reference manual again!
Also, why is not the Mouse Over (stack) Viewer not a ‘stack’? MoVs do not have a stack, but they sure as hell display one. I think there is a logical disconnect here.
SumStack (and all new Sum and Count functions) can be used in the ‘Text below each piece’ where they are applied to each piece in the MoV view. This has always worked with the limited set available in 3.6.
Where it won’t work is in the ‘Summary text above pieces’.
Presuming you are talking about the ‘Summary text above pieces’ field. No, the MoV does not display ‘one’ . It displays information for multiple Stacks of pieces on multiple layers and also Non-stacking pieces in that location. It is not possible to apply a stack based function to such a collection without major surgery.
However, in 3.7 you can use one of the non-trait forms of the SumLocation function to achieve the same functionality:
To make this clearer and easier I am converting those two text fields to be Expression Builder (Calculator Icon) fields. The Text Above field will not show the Piece-based functions as an option, The text below fields will.
All Function Builder fields will work this way to help prevent people using the trait-only functions in appropriate places (i.e. other than in a trait, in a Property Match Expression, or in this particular field).
