If two people are connected to a game, is it possible for the value of a Global Property to be different between the two players?
The reason I ask, is because I’m making a module of the old French card game, Mille Bornes and I’ve run across an interesting glitch.
Each player has an area on the table top to place their mileage cards. When a card is placed, a trigger automatically updates the total miles among all the cards in his mileage area and displays the total. This display uses a label trait that displays the global property of that player’s current miles traveled.
It works fine. However, if I place a mileage card in my mileage area, the total updates and displays properly. But, what my friend sees is a quick flash of the total mileage and then it resets back to zero. Vice versa, if he plays a mileage card, his display is fine but I still see zero miles. Since this label is directly linked to the value of a Global Property, how can the display be different on the two machines?
If two people are connected to a game, is it possible for the value of a
Global Property to be different between the two players?
The reason I ask, is because I’m making a module of the old French card
game, Mille Bornes and I’ve run across an interesting glitch.
Each player has an area on the table top to place their mileage cards.
When a card is placed, a trigger automatically updates the total miles
among all the cards in his mileage area and displays the total. This
display uses a label trait that displays the global property of that
player’s current miles traveled.
It works fine. However, if I place a mileage card in my mileage area,
the total updates and displays properly. But, what my friend sees is a
quick flash of the total mileage and then it resets back to zero. Vice
versa, if he plays a mileage card, his display is fine but I still see
zero miles. Since this label is directly linked to the value of a Global
Property, how can the display be different on the two machines?
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
Fairly simple. There is some automation as far as keeping track of miles traveled and keeping track of player’s scores but nothing too complicated.
In this case, when a mileage card is placed on the table top, it’s given a command to add it’s dynamic property value (the number of miles) to a global property called “Player[x]Miles” with x being the player side. There’s a text label that sits above the mileage area that displays the value of “Player[x]Miles”. That’s it …except that what it displays to me is different that what it’s displaying to my buddy.
I have changed the manner in which miles are kept track of but I haven’t caught my buddy online to playtest it yet. I’ll give you and update later.
Just to inform you that MilleBorne … is not an old game … The publisher Dujardin is always providing Deluxe Edition and Boardgame edition of this game.
Fairly simple. There is some automation as far as keeping track of miles
traveled and keeping track of player’s scores but nothing too
complicated.
In this case, when a mileage card is placed on the table top, it’s given
a command to add it’s dynamic property value (the number of miles) to a
global property called “PlayerMiles” with x being the player side.
There’s a text label that sits above the mileage area that displays the
value of “PlayerMiles”. That’s it …except that what it displays to
me is different that what it’s displaying to my buddy.
I have changed the manner in which miles are kept track of but I haven’t
caught my buddy online to playtest it yet. I’ll give you and update
later.
I planned on that. I was just making it for personal use at this time. Once I get a smooth running version, I’m going to contact the owners. I hadn’t researched who to contact yet so thanx for the link.
mkiefte said:
I’ve probably overwritten the problem copy with changes and the new version hasn’t been tested yet to see if the aberration is still present. My buddy would have the problem copy as it was the last one we played with online. Soon as I catch him online, I’ll get that copy from him and post it.
It just occurred to me that I should probably provide this info in case it has some bearing on the problem. Tests between myself and my friend used the following:
It just occurred to me that I should probably provide this info in case
it has some bearing on the problem. Tests between myself and my friend
used the following:
I’m not 100% sure if this should be considered a bug or not. It may
certainly be unintuitive, but I’m not sure how one would fix it other than
change your module.
In your Tally Score Properties global key command, you have the matching
properties as:
CurrentMap = Main Map && CurrentZone = Player$playerSide$Stack
When this command gets sent to the opponent, then $playerSide$ is
interpreted differently, and so it tallies the wrong zone.
This shouldn’t be in the prototype definitions as each button is actually
triggering a different thing: one button does player 1’s zone and the other
does player 2’s zone. Instead, the global key command should come out of
the prototype and into the individual button traits and the CurrentZone
should be different for each.
M.
On 2 December 2010 12:24, Michael Kiefte mkiefte@dal.ca wrote:
I’ve been able to confirm the bug. Now I am trying to figure out what the
source is.
It just occurred to me that I should probably provide this info in case
it has some bearing on the problem. Tests between myself and my friend
used the following:
Well peeked my interest after Mike’s comment and took a look and the first problem I see in is that you deliberately allow it to get out of whack.
Usually I would say, whenever you depend on movement and location to help do things like tally points, you need to add in a silent fail safe switch to prevent it from going out of whack. This is simply an i/o or true/false DP that changes when the criteria of what the piece is supposed to do has been met. If it ever needs to add again when moved (again based on movement / location), a secondary routine must reset this switch before it is allowed to perform its add routine again.
Having done this, I’m doubtful the error you have found will occur and agree with Mike that this may not be a bug but design problem
I can’t look at the code right now (I’m actually in the middle of teaching a
class), but I was surprised to see that Global Key Commands don’t just send
the result of the Key Commands instead of the Key Commands themselves.
That’s what’s causing the problems, the Key Commands were interpreted
differently on either side because of the use of $playerSide$ which, of
course is different for either player.
The discussion you point to refers to the problem that the KeyCommands are
not guaranteed to execute in the same order on either side.
I’m undecided as to whether this is a problem or if there should instead be
warnings. Certainly Global Key Commands are going to be hard to encode if
you want to sent the result instead of the intention. Ultimately, you would
have to send the entire game state if you wanted to avoid this problem. I
think anything that requires KeyCommands from separate units to be executed
in a deterministic order is going to get you into trouble. What happens
with $playerSide$ is somewhat unexpected, quite surprising, but is otherwise
perfectly reasonable!
I agree with all you responses as far as using the $playerSide$ variable. Updated versions of my mod have changed a lot of how I operate things. I’m still having a problem but I’m becoming more aware of the causes and will find ways around it.
The sample mod I sent was just to demonstrate the problem when it first occurred and my intention was to point out that the Global Property can be different on both machines …which, in my mind, should not happen regardless of what a designer does.
The $playerSide$ variable will work fine in other contexts, but not this
one. It’s a quirk with how global key commands are encoded and sent to the
opponent. It should actually work fine almost anywhere else!
I agree that it should be more intuitive than that, but this one is tricky.
The global key command can result in almost any behaviour imaginable and to
encode the effect rather than the command would be very difficult to do
without synchronizing the entire game state.
I agree with all you responses as far as using the $playerSide$
variable. Updated versions of my mod have changed a lot of how I operate
things. I’m still having a problem but I’m becoming more aware
of the causes and will find ways around it.
The sample mod I sent was just to demonstrate the problem when it first
occurred and my intention was to point out that the Global Property can
be different on both machines …which, in my mind, should not happen
regardless of what a designer does.