“Baby’s First Custom Class!!!”
Yeah not happening anytime soon. I have 2 games I need to build Vassal modules for and my programming background led me unrealistic timeframes as to how quickly I could finish them. I recognize now that Brent and others have done a standup job of morphing Vassal to do things it was never intended to do, but this whole BeanShell vs. Classic learning curve has probably put me at 100 hours for stuff I could have accomplished in 20 hours if it wasn’t a total newb. I figured it would have divided my normal output by about 2-3X, but it’s been about 5X. The real pain was going back and completely rewriting stuff that I thought would work, once I found out the hard way it wouldn’t…
I have had no problem with putting global properties at different levels as long as I obey the scoping rules it forces. I suppose selectively restricting commands would work, but I’m not looking for a different solution to my credits problem. I am looking for an answer on alert(), and the credits problem is just an example to better illustrate what I want to do.
An expression is converted into a small program fragment and ‘compiled’ which returns a list of undeclared variables. The undeclared variables will be references to Vassal properties. At run-time when the expression is evaluated, the undeclared variables are created as temporary variables and set to the value of the corresponding Vassal property before evaluation.
Writing values back into Vassal properties is beyond the scope of the ‘Expression evaluation’ use case and Vassal is (mostly) not built to handle it.
Regards
Can alert include $$ strings, or global properties in some way? Or should I use ? : with unique alerts?
$$ strings work just fine.
Oh wow, I do like alerts. Old me would have just assumed a player would look to the reports to see what happened, but now I think that alerts are a very nice way to avoid player confusion due to a set sequence of consequences being resolved instantly. For example, you can pause mid-trigger to tell a player exactly what will happen next, just after a visual layer change on a piece and just before the piece gets deleted.
Just one question: What is the best low-impact way to trigger an Alert() from a key command, independent of a calculation? Currently I have a pointless “send to location” trait with the destination being a Zone {0+Alert(“text here”)} to trigger the Alert, but is there a better way to do it?
That’s probably the most inconvenient part of this, actually getting the Alerts to trigger at the right time.
Possibly using a Dynamic Property. You can set up different commands to set the value directly and the value to set could then just be {Alert(“a message”)}. Then you can set up all of your alerts in one place with different Named Key Commands and fire them off when needed from triggers.
I see, thanks. So there’s no need for the new value to be a value? Each key command would just change the dynamic property from null to null?
Yep. It’s the side effect of the Alert() function we are interested in, not the action of the actual command. It’s not going to generate a Command to send to other players since the DP value doesn’t change, but that’s fine, since they don’t see the Alert box anyway. So it’s a pretty good solution.
I’ve pretty much figured out how to place an alert anywhere a Beanshell expression is allowed. The trick is that Alert has a null value so you can add it to pretty much anything without impacting the rest of the expression. Combined with the recently discovered ? function and you can do some pretty neat stuff like:
{(Resources==0)?0+Alert(“You have insufficient resources”):-1}
The possibilities go on and on…
I’d also add that Alert() can handle expressions. Since I’m using them extensively, I created a generic Alert prototype to assemble them quickly and without typos. I just need to insert the prototype then define three variables called Restrict, Message, and Value that are typically Calculated Properties or Markers. The Prototype then uses the expression:
{(Restrict==true)?0+Alert(Message):Value}
Message contains any concatenated text I want.
Pretty interesting thread, much to learn and experiment with.
So far my Alert usage was doing things like:
-
a Trigger trait fires on some command when some condition is met, issuing a reportError command
-
the reportError command is just firing a Report Action trait set to display $Error$
-
Error is a calculated property set to "Alert(“Stupid! Stupid!”) or something such
Pretty convoluted, I gather.
“I was able to get this working, but don’t have a second computer handy. Do you know who sees these alerts? Is it the active player? Everybody? Or is it map-based?”
Guessing you got the answer to this already. This is based solely on my experience and interpretation:-
The Active Player (only) sees the alert.
Also, the alert must be acknowledged before the Active Player’s session will proceed.
I’ve been finding Alert() it very usable/useful, typically as a component of conditional statements using “?”.
Here’s a simple example of an Alert placed in a Trigger conditional expression. The Trigger Key executes this test along with
other triggers that fire for the other values of gblDeckChoice. The conditional tests would be further development for situations where commands need to fire within the trigger itself.
{(gblDeckChoice<1 || gblDeckChoice>3) ? Alert(“Deck Setup Error. Try restarting & report error to maintainer.”):0 }
Mark,
I can confirm all the behavior you describe. I’d also add that the placement of the Alert within traits has a UI aesthetic. The alerts can feel disjointed if they appear midstream in a process, like after a piece is removed, but before it has been replaced. Thus sometimes triggers are not the best place to insert Alerts. In that case, I’ll create a Dynamic Property called Alert (although name is irrelevant) and place it wherever I want.
Thanks for the tip. I think the trigger in the example (above) is ok as it is an alternative path and not an interrupt within a process but I had noticed the issue elsewhere, so I will consider Dynamic Property as an alternative.
Might be worth mentioning that Alert() can be a useful debugging tool. I am using it at the moment to trace the path of a loop through a sequence of Triggers.
Also, surprisingly (to me), all the output up to the point of the Alert() is also completed. Without the Alert() the output would just be held back until the entire operation completes.
Yup. That makes it useful as a debugging tool which I certainly used it for that, but I’d prefer if it didn’t cause Vassal to come to a screeching halt. It would be a great way to distract players while you execute a ton of GKCs in the background. Sadly, if anything, it accentuates the delays if you put Alert in the wrong place…
So, you’d like an extra argument to the Alert function to be able to create non-modal dialogs (Ones that don’t halt progress and stuff still happens in the background)? You would want to be extremely careful in their use or you will end up with a hundred dialog boxes on top of each other before you know it. Obviously would not be useful for debugging.
The current
Alert (“A message”)
would continue to function as it is, but your could use the alternate
Alert (“A message that appears while stuff still happens”, false)
where the second parameter specifies whether to halt Vassal execution or not.
Is that it in a nutshell?
What about a parameter to auto-disappear the box after so many seconds?
Don’t hold back 