I think that may have been the wrong thing to do, so I am reposting this to see if anyone has an answer.
In several modules, the entire board is set up as a multi-zoned grid. Anything that is not found in a defined zone is considered “offboard” and the location is listed as such when you hover over the piece (assuming the messages over/under a piece will report a location). This being the case,
Can “offboard” (or != offboard) be used as a legitimate location when testing conditional statements?
If not, can pieces not contained in a defined zone be tested against LocationName (or Zone) = null?
In a general sense, can “null” be used as a legitimate testing item in conditionals, and in what circumstances?
I’ve found situations where testing against “offboard” or “null” would be very handy, but I can’t seem to get that type of comparison to function properly. The conditional doesn’t seem to be evaluated properly, or it’s not recognized at all.
Thanks, everyone!
Rommel14
ADMINS - My apologies if this really should have been left as part of the existing thread. I wasn’t sure what to do.
Hmmm…I guess that did sound somewhat self-evident. Let me try to rephrase.
Are “offboard” and “null” even valid conditions for use in a comparison in any circumstance, or are those “reserved words” that wouldn’t be recognized by the engine no matter how the conditional is constructed?
Just to clarify how I’m constructing the conditional statements, I’ve tried things like:
Sorry if it seems like I’m beating a dead horse. I just don’t want to end up writing some kind of spaghetti code if there’s a simple way to achieve this type of testing. Since I’m still learning the process of module construction, I didn’t want to assume that my programming skills were above suspicion.
well, before you can even test if offboard or null are valid or reserved, you need to write your pme’s properly. In Vassal (as a by product of Java), Character capitalization does matter (for any one else also just in case)
locationName and currentZone means nothing in your expressions because of your capitalization. Fix that - give them a shot and then you will know if offboard or null are valid return types or not
Actually, I did type them correctly into VASSAL when constructing the statements. My fingers were just not connected to my brain when I typed them into my previous post–typing too fast.
Sorry for wasting your time. I guess I do have my answer.
Actually, I did type them correctly into VASSAL when constructing the
statements. My fingers were just not connected to my brain when I typed
them into my previous post–typing too fast.
Sorry for wasting your time. I guess I do have my answer.
a) typed everything correctly (which it appears that I did, at least for the statements in question–the capitalization was OK),
b) coded the items that depend on that statement correctly,
c) have my head screwed on straight regarding how VASSAL is supposed to work, and
d) haven’t exposed a bug or glitch related to this item,
then using “offboard” or “null” on the right-hand side of a conditional is not a valid.
However, I don’t know the inner workings of VASSAL well enough to know if it was designed to respond to those words on the right-hand side of a conditional statement. Further, I haven’t seen any documentation specifically referring to these items which says that they cannot be used. This is why I was asking the question in the first place, to be honest.
No offense intended, but I feel like we’ve been talking in circles here. I thought this was going to be a straight-forward question when I first posted, but I guess I don’t understand VASSAL as well as I thought I did.
Well, it looks like it works some places at least. I was able to put
Type=Terrain && LocationName = offboard
in the property filter for a stack viewer in the module I’m working on, and it did exactly what I expected - the viewer only popped up for Terrain cards that were offboard.
I don’t know of any reason why it’d work some places and not others, but I’m just starting to learn the system myself.
Let me try to rephrase.