Merchant of Venus: Critical Bug--> HELP!

I recently published my first module: Merchant of Venus.
I’m in playtesting with 4 other people and I encountered a critical bug:
When one of the “First Contact” markers is revealed, the first player who set up the game can do it fine, while no one else can.
When the action is called, the token is supposed to be flipped over, a different token is sent to the same spot and the “First Contact” marker is sent to the player’s hand.
BUT only the first player can do it. If anyone else tries, it simply flips the marker over without doing any of the other tasks.

Steps to recreate bug:

  1. Start new game, join any side
  2. Click “Random setup”
  3. On the Main Map, right-click any “first contact” marker and select “reveal culture” → This is how the behavior should look.
  4. retire and become an observer
  5. Go to preferences and change your personal password
  6. rejoin as a different side
  7. Right click on any “first contact” marker and select “reveal culture” → this is the problem behavior

I know that it has something to do with gamepiece ownership, but I have no idea of ANYWHERE to begin to fix this.
Any help would be appreciated: I’m starting to get desperate!

I’ll take a look at it and get back to you.

As I was looking at some of your game pieces in the editor, the first thing I noticed is that you have the trait order backwards. Traits are activated from the bottom of the list upward …not from the top downward. For example:

Culture Token - Nillis

You have the “Trigger Action - Culture Revealed Script” above the traits this trigger should activate. The traits on the piece should be listed in this order

SGP - Say 1a has been revealed [Triggered on CTRL SHIFT Z]
SGP - Define location of 1a Factory Goods [CTRL Z]
SGP - Define location of 1a Factory [CTRL Z]
STL - Send to Calling Piece [CTRL S]
TA - Culture Revealed Script [Sends triggers CTRL S, CTRL Z, CTRL SHIFT Z]
Then the two Markers.

Until you get the trait orders fixed on all your game components, you’re going to have all kinds of problems so I won’t be able to address your problem above as I’m not sure if it’s a trait order or not …or if it’s even a problem.

I was also wondering why you would switch user name and passwords in a game. If you’re just trying to playtest the game, then start the game and when you get the splash screen, click Cancel. The game will still open and you can use any player side without having to create a username and password.

When I tried this, I had no problems with switching sides and revealing the cultures.

Well after finals and wedding planning and starting the new semester I FINALLY got to take another look at this.
Sure enough, after switching up the order, revealing and replacing counters works like a charm.
Now the next question: I need every player to be able to peek at every counter and have it still be hidden information from the rest of the table.

For example. A player lands in the Desert World system. They can peek at the IOU to see if they want to land there. If they don’t want to land, they move on. The next player comes in and wants to know what player 1 missed out on. They peek, think it’s a good idea and land, taking the IOU.
Is there a way to open up peeking on each token to every player?

I’ve never been able to find a way to have this work properly. I have a similar situation in a game and what I’ll probably do is put a right-click “Peek” command that will send it to a player’s private window. Once they’ve viewed it, they can put it back on the board.

If someone knows how to get this to work, I’d like to know too.

I think the real problem here is that you are trying to use masking when it is the inappropriate tool. (Cardshark, I think you posted this at BGG too. I answered you there in a private message.) Masking adds the characteristic that whoever masks a piece or card becomes the owner, and by default, only the owner can see the card. For example, if I draw a card and put it masked (face down) on the board, vassal knows I’m the owner, so it shows me the card’s face. (There are caveats to this statement because it depends how the module mask trait is set up. I might have to peek to see it, but other options let me see the face straightaway.) My opponents, who don’t own the card, only see the back of the card. Vassal knows to render it this way for them because it knows they don’t own it.

In many games, you don’t want or need this extra behavior. Instead of masking, replace it with the Layer trait. (This is not the same as the Layers characteristic that you see in Maps.) When you edit the Layer trait, substitute “Flip over” (for example) for “Activate” and change control A to control F (if you like that better). Blank out the increase and decrease controls because you don’t need them. (They are useful when you have a number of substitute images such as a counting piece that goes for 1 to 10, for example.) You don’t need reset either. Blank out the control R.

Then down below, double click on the image spot and import the image for the back of your piece. Now when you play, hitting control F will toggle the image between the front and back, and it won’t demand any special ownership traits. This is a very handy way to deal with double-sided counters and numbered counters.

That is not the issue.
The whole point of why they are using mask is because they require or want to invoke ownership during actual game play (either by player or by side, depending on settings) and your proposed solution removes that factor altogether defeating the purpose.

Personally I think this should be an RFE in which we provide some sort of checkbox feature to the toolbar GKC trait that allows dealing/setup of masked components without invoking ownership, as it is a common thing to setup games (without use of predefined setup) with random components (i.e card drawn from a deck) and also wish to use player sides / ownership.

A possible (clunky and not very tidy) work around until then could be the addition of a 2nd mask that always reveals. Because it would be the “outer” mask trait ownership is applied to it only, leaving the “inner” mask status ownerless and still functional - in theory. You would have to test this out though with each mask using a different key.

Perhaps I misunderstood his message, but I did not see that he wanted to retain or invoke ownership during game play. If it’s just a matter of a face-down piece that anyone can flip over at any time, then the Layer trait is more appropriate than Mask. If a player needs to be able to peek at a face-down without revealing it to others, then that’s another matter, but I didn’t see that in his note and I don’t remember enough about the game either. In short, I guess I don’t understand what he is trying to do.

There is something about masking I forgot to add. We know that if one player puts masked cards or pieces face down on the table, then he owns them, and no one else can look at them. There is a checkbox in personal preferences that says something like “allow others to unmask my pieces.” This allows anyone else to unmask my pieces, and this might be a clunky solution. That is, if I knew what the problem was.

We are kind of both off :slight_smile: here’s the key bit of info I think

If we go with a layer, revealing the piece (turning the layer off temporarily) reveals the piece to all players so that wont work. The peek option on the mask trait was specifically designed to handle this, but the ownership of the piece presents a problem if not set up properly. That may be where we are

I still think there is another issue here though. It is impossible to deal a card off a deck without becoming the owner of the card and I can see a case where you would not want to become the owner - Think of a blackjack table in a casino where the dealer deals all the cards to the players at the table. He should not by default become the owner (and be able to see through the mask) just because he dealt the cards out in this situation. The owner in this case should be the person in posession of the card not who dealt it

Ok, I missed the peek requirement, and that’s a problem with the layer trait. I don’t know if the personal preference “let others unmask my pieces” helps, but I would check it out if I were desperate. If one did use the Layer trait, one would have to move the piece to a private window to view it, and that’s not ideal. The problem with mask too is that once I control it, not only can no one else peek but no one else can even flip it over (with that preference flag).

As for giving control and ownership to other players, I am well aware of that one. I have made many modules for block games, and I would LOVE to be able to set up the starting positions with the blocks masked, but I can’t. You state a general case, and I agree. It is just not possible to give control/ownership to someone else.

As for his problem, if it were me, I would dump masking (which adds a control element and control problems that he does not need) and use Layer instead. To peek, I would send the piece (better yet, a clone) to a private window where I could view it. At least anyone could flip the piece, which gets gnarly with masking.

Ahh …sending a clone of the piece to a private window. Then they can delete the clone after peeking. Hadn’t thought of that angle. Thanx for the tip.


I’m also thinking about a layer + Mask trait to manage this …

Well, i’ll use a trigger to simulate a Peek founction :

1- Desactive the Layer (because the guy who has made the setup could see all counters if no layer with the back side is not shown)
2- Unmask the token and Mask it in the same time to have the ownership [Using Plain Mode into the Mask Trait]

Indeed, the layer is mandatory activated and the global option to allow to unmask pieces is set to yes …

I’m in contact with Aaron and i need to experiment this …




actually I had a problem with the ‘Retire’ function within my VBFG 2.0 as well while testing the ‘Invisibility’ function.
And yes, just retireing to observer, changing the password and joining again on a differt side solved the problem.

During the tests with two players online I found out that both players start at Side 1.
Retireing Player 1 from Side 1 and joining Side 2 resulted in Player 2 joining Side 2 as well !!
So this looks like a general problem of the engine.

Maybe the engine uses the password only to distinguish between two players.
Playing with a blank password or indentical passwords may cause this problem.

However pulling up the game, retiring to observer, changing the password to a rather unique one and joining back to the choosen side resolved the issue for me. Cloaking a Ship using the ‘invisibilty’ function does work properly now. So should any other function depending item ownership.

Hope that helps.

Harlekin Simplex


Just did a quick confirmation.
The engine distinguishes between sides (item ownership) ONLY by the password.
Two Players with the same password automatically are synchronized if one of them retires to observer or any othe side.
That means that item ownershiop ist shared by all players using the same password!

This might be not a bug but intended behavior.


You are right about two players having the same password. This is not a bug, it’s deliberate.

Passwords are used to encrypt game save logs and possibly for other stuff too. Different players should never have the same password, because it’s how Vassal identifies you.

Like it says in the user guide, always use a password that no one else is likely to use.

Setting NO Password leads to ambigous and rather unexpected behavior throughout the whole system, especially when NO password is set in a multiplayer setup and one of those player uses the ‘Retire’ function.
What about being more descriptive about the Password entering dialog here?
Not everybody reads the manual in detail.
Having Username and Password within the same dialog, as it actually is implemented, suggest just an ‘Account’ like usage of the password. But the ‘Password’ is not only used as en authentication token only but as a shared Item ownership token amoung accounts as well! Nobody would expect that in the first place.

Easiest way to work around that would be to use Name + Password as the passwordphrase to encrypt things.
But this would dissalow for shared ownerschip or logs.
Best would be to use Name + Password as authentication token and a 2nd password for session or side specific data that might be shared amoung several players.

For now I’m fine to know how to work around that item owenership problem caused by that password issue.


Yes, this is a known problem and source of confusion. I believe that
there is some plan to change this in the future and use a combination
of name and password, so the developers are aware that this is not the
best solution.

First, thank you all for your kind support on this project.
I think, with soft-bug’s help, I figured out a workaround:
I created a Trigger that would “flip” the piece twice in a row (which transfers ownership to the player who issued the command) then peek.
The flip happens instantly, so it’s never seen by the player. Yet ownership is transferred, allowing for a simple peek command to be utilized.

The only artifact from the player’s point of view is that there are two “peek” commands; this is because there isn’t any option to take it off of the right-click menu without removing functionality.

Aside from the ubiquitous “peek” command, the game is, (as far as I know), FULLY FUNCTIONAL!!!
Thanks again!