Using a piece on the main map for setting a global property named ParaAlert ouside the main map via the piece trait “Set Global Property,” neither of the follwing (all approved by the expression builder) works:
However, “Prompt user to select from list” (containing the list values true and false) works fine.
Obviously I’m lacking the proper syntax to change a global property (ParaAlert which is non-numeric) in relation to another global property (1stDropDone which is numeric) when both of them are at the same level (the highest) of the module.
You don’t say where 1stDropDone is defined: is it another Global Property, a Dynamic Property on the same piece, or what? If a GP, is it defined at the module level, map level (which map?), or zone level (which zone?)?
(As an aside, the levels of redundancy in those expressions make my head hurt! All those parentheses except the ones around ”1stDropDone” are unnecessary, as in fact is the entire ternary expression: you’re saying “if this returns true, return true, otherwise, return false”. A simple {GetProperty(“1stDropDone”) == 6} should give the same result, but on the other hand, all 3 of those versions should still work.)
I built a little vmod to test this and to check some things because I was unsure of a couple issues. In mine, I set a dynamic property instead of a global one, and mine worked. I think your syntax a bit overwrought. You really like parentheses, don’t you? Anyhow, here’s what my expression looked like:
( firstDropZone == “6” )
This worked. My comments.
I’m old. When I started programming Fortran back in the day, parameters had to start with a letter (no digits!) and maxed at 8 characters. The “no digits” rule lasted a long time and probably still does today. You’d have to point a gun at me to write “1stDropZone” (shudder). When I tried starting my property with a digit (shudder), Vassal bitched “bad syntax” every time.
You don’t need GetProperty in this case. It’s overkill.
You don’t need to test against true or false because what’s to the left of “?” evaluates itself to true / false.
I used “6” instead of 6 because firstFropZone was non-numeric, and I wanted to emphasize and remember that later. Also, I don’t know if it makes a difference to Vassal, but generally I don’t use numbers unless I’m expecting numbers.
I suggest you report 1stDropZone (ugh) before you use it to ensure it holds 6.
Of course not, and I should have never mentioned it. I was testing syntax. Where I stored the result didn’t matter. I was not suggesting you use a dynamic jproperty.
My mistake. I’d then write the expression as ( firstDropZone == 6 )
No, no, no. You miss the point. When you use the syntax, (x == y)? a : b, the x==y part is a test. When you resolve x==y, the result is true or false. What you are writing is if x==y is true, then it is true. It’s all redundant. You only need { firstDropZone == 6 } to set your true/false result. Furthermore, it’s unnecessary to use GetProperty. You can just referense firstDropZone directrly.
But the big problem is all you say is “it doesn’t work.” But how? What happened? What did you see that said it was wrong? You don’t provide any error information.
The most obvious first step would be to add a report trait on the command. It would print both globals. That would confirm that the command was called and the global value was truly 6. After that, I don’t know.
Too big. Too convoluted. But I will try building a tiny example module - to see if the behavior is the same and to allow helping hands to look at the problem.
And then? I have a tiny vmod, which I set up to test this using exactly the syntax (2nd one) you said. I had trouble with the red x on the input line because of the wrong kind of double quotes. Once I fixed it, it worked for me. I think I’m done here. There is just too much I don’t know.
I’m fairly sure I determined in an email exchange with him that the root of the problem was doing testing with a predefined setup that pre-dated the changes and wasn’t refreshed.
It should still do so. You are on the safe side when you stick to the golden rule that parameters have to start with a letter. And you were exactly right with your gut feeling that my bad syntax could be causing my problem. When I changed the name of this property to FirstDropDone, everything worked as intended. Listening to your first advice to begin with would have saved me a lot of time. Many thanks, indeed.