Restrict Commands & PlayerSide

I am working on a module where cards are drawn from common decks into private player decks. When a card is moved into the players private hand, a Dynamic Property called ‘Owner’ is set to his number. It is possible for other players to steal cards from the current owner. I am trying to hide the menu command to do so for the person that currently owns the card - the owner trying to steal the card from himself does nothing (as intended).

Here is the restrict command logic I am using (once i get it working for Player 1, I will OR it with identical statements for the other players). The restrict commands trait is the bottommost one of the Prototype:
PlayerSide = Player 1 && Owner = 1

A similar restrict command that constrains a player to buying cards for his own deck (and not those of his opponents) is working fine as:
PlayerSide != Player 1

Also a separate command related to discarding constrained by the owner is working perfectly as well:
Owner = 1

Its only the combination of PlayerSide and the dynamic property Owner that I cannot get to work.

Thanks in advance,
Jeffrey

I have been attempting something similar for commands on a piece I am designing.

I have a set of commands which I want visible/usable only to the playerSide corresponding to the command.

So I tried a Restrict Commands trait with the test: playerSide != abcxyz

This produced no result. To function a Restriction must come below the command it restricts, isn’t that right? I made sure of this. Just in case I’d got it wrong, though, I switched their relative positions. No change.

Help!

mac

One thing I noticed right off is the internal Vassal command you are using here is capitalized. Proper use is

playerSide

with a lowercase “p” and a capital “S”. Try that.

What I am trying to do is restrict a command to just TWO players on a piece whose commands generally are accessible to all players.

In other words, there’s a piece with a whole lot of commands. All players have access to the piece (and thus all the commands), but there are a few commands which need to be accessible to just certain players.

What I found is that while I can restrict to one player, I can’t restrict to more than one. For example:

A Restrict Commands [Hide] trait with the test expression: playerSide = Player 1

Affected command is: CTRL A

means that only Player 1 sees (and can use) whatever it is on the piece which has CTRL A as its shortcut (what the command is specifically is not relevant here).

This works fine, but what I really need is for both Player 1 and a Referee (also defined as a playerSide) to be able to access the command. However, when I try the expression:

playerSide != Player 1 || playerSide != Referee

This doesn’t work. The affected command does not appear to either of said players now.

I can’t figure out what I’ve got wrong in that -OR- expression versus the single “is not Player 1” test.

mac

The expression you’re using here is incorrect if you want these players to have access

It should be

playerSide = Player 1 || playerSide = Referee

Putting a “!” in front of a equal sign means “does not equal”

No, that is incorrect, and will have the opposite effect of allowing acces to all but those two sides. What I want is to BLOCK all but those two sides.

Don’t forget that the trait itself is essentially already putting “not” into the expression, since it blocks anything which tests true against the properties it is given.

So, by my expression (leaving aside the question of whether my syntax is correct for VASSAL), the trait should block anything which is NOT Player 1 or NOT Referee.

There’s either a functional problem with the syntax (as opposed to the logical intent thereof), or there’s a bug of some sort at play.

When I use just one half of the expression, thus:

playerSide != Player 1

It has (half) the intended effect of blocking all players EXCEPT Player 1.

Logically, I should merely have to add in “or playerSide not Referee” to expand the effect to blocking all sides EXCEPT Player 1 OR Referee.

…and then Satan was given to say, “well, you know, I always lie: I never tell the truth…”

mac

not Player1 AND not Referee

not OR.

not Player1 OR not Referee will block everything.

An OR expression will return TRUE if either of the conditions is TRUE. If you check:
NOT P1 OR NOT Ref, with P1 => FALSE OR TRUE => TRUE
NOT P1 OR NOT Ref, with Ref => TRUE OR FALSE => TRUE
NOT P1 OR NOT Ref, with P2 => TRUE OR TRUE => TRUE
P1 OR Ref, with P1 => TRUE OR FALSE => TRUE
P1 OR Ref, with Ref => FALSE OR TRUE => TRUE
P1 OR Ref, with P2 => FALSE OR FALSE => FALSE

What you want is the NOT ( P1 OR Ref ), and when you merge the “NOT” into the bracket you have to invert the OR to an AND to get what you want.
NOT P1 AND NOT Ref, with P1 => FALSE AND TRUE => FALSE
NOT P1 AND NOT Ref, with Ref => TRUE AND FALSE => FALSE
NOT P1 AND NOT Ref, with P2 => TRUE AND TRUE => TRUE

I haven’t read the whole thread very well, so if I’m not helpful ignore this. :wink:

Mac,

See this thread
test.nomic.net/oldforum/view … ght=#17676

What the Doc is getting at, which I explain in that thread is that Restrict
Command does not like the “!=” operator for some reason.

Instead use the opposite operator “=” and use the other player sides in the
PME instead of Player 1 and Referee

Post generated using Mail2Forum (mail2forum.com)

Thanks, Tim. bdgza, though, hit the nail on the head. I was indeed thinking in terms of a GREP style expression, whereas VASSAL doesn’t see things that way.

AND (not OR) is the solution. No “!=” issue (in the “bug” sense) whatsoever. Problem solved. Hats off to bdgza for pointing out what should have been too obvious to an old binary programmer :blush:

mac

I have a question about sides.

I have made three sides - A, B and Single. When I create a scenario file I started as Single, when I have saved the file and later returned to it, I could only chose A or B side… what has happened :open_mouth: ?

What’s happening in your case is, since you saved the game file whilst still logged in as “Single” every time you open that file, you are automatically “Single”.

Instead, before saving the game file to be used as scenario set up, you should retire the side you “played” to do the set up, becoming . Then save the file and add it as a pre-defined set up in the module editor.

mac