Hide dragged items while over hidden container. #576

Closed
opened 2026-02-20 10:18:49 -05:00 by deekerman · 8 comments
Owner

Originally created by @flackr on GitHub (Oct 13, 2022).

Consider https://virtualtabletop.io/vga5 where while seated player1 can move tokens around on their mat. They may want to arrange things that only they should have visibility of (i.e. onlyVisibleForSeat prevents other players from seeing them). I think it would make sense if by default as long as the tokens are over their hidden board, they are not be revealed to players not in that seat as once they are dropped they would also not be visible.

To reproduce, open the above game in two different browser instances (e.g. one incognito window). In one window, sit down in the player slot. Then, drag the token to move it around on that player's secret mat. The other player can see the item while dragged. Given that specific seated player only containers may be used to organize tiles I think they should not be revealed until they are dragged over a non-hidden container.

Here's a video of the current behavior:

https://user-images.githubusercontent.com/366761/195745687-2b9ba7b8-ec55-4690-838d-23fc0688c7d7.mp4

Originally created by @flackr on GitHub (Oct 13, 2022). Consider https://virtualtabletop.io/vga5 where while seated player1 can move tokens around on their mat. They may want to arrange things that only they should have visibility of (i.e. `onlyVisibleForSeat` prevents other players from seeing them). I think it would make sense if by default as long as the tokens are over their hidden board, they are not be revealed to players not in that seat as once they are dropped they would also not be visible. To reproduce, open the above game in two different browser instances (e.g. one incognito window). In one window, sit down in the player slot. Then, drag the token to move it around on that player's secret mat. The other player can see the item while dragged. Given that specific seated player only containers may be used to organize tiles I think they should not be revealed until they are dragged over a non-hidden container. Here's a video of the current behavior: https://user-images.githubusercontent.com/366761/195745687-2b9ba7b8-ec55-4690-838d-23fc0688c7d7.mp4
Author
Owner

@flackr commented on GitHub (Oct 13, 2022):

Arguably other players should also not know the cursor position while it is over a private widget, however this is less distracting / revealing than dragged items popping in and out.

@flackr commented on GitHub (Oct 13, 2022): Arguably other players should also not know the cursor position while it is over a private widget, however this is less distracting / revealing than dragged items popping in and out.
Author
Owner

@96LawDawg commented on GitHub (Oct 13, 2022):

Consider https://virtualtabletop.io/vga5 where while seated player1 can move tokens around on their mat. They may want to arrange things that only they should have visibility of (i.e. onlyVisibleForSeat prevents other players from seeing them). I think it would make sense if by default as long as the tokens are over their hidden board, they are not be revealed to players not in that seat as once they are dropped they would also not be visible.

To reproduce, open the above game in two different browser instances (e.g. one incognito window). In one window, sit down in the player slot. Then, drag the token to move it around on that player's secret mat. The other player can see the item while dragged. Given that specific seated player only containers may be used to organize tiles I think they should not be revealed until they are dragged over a non-hidden container.

I don't think this is an "issue" that requires any change. Just make the mat a "hand." You do that by adding "childrenPerOwner": true. Then only the player that owns that mat can see the widgets until they are dragged outside of its borders.

@96LawDawg commented on GitHub (Oct 13, 2022): > Consider https://virtualtabletop.io/vga5 where while seated player1 can move tokens around on their mat. They may want to arrange things that only they should have visibility of (i.e. `onlyVisibleForSeat` prevents other players from seeing them). I think it would make sense if by default as long as the tokens are over their hidden board, they are not be revealed to players not in that seat as once they are dropped they would also not be visible. > > To reproduce, open the above game in two different browser instances (e.g. one incognito window). In one window, sit down in the player slot. Then, drag the token to move it around on that player's secret mat. The other player can see the item while dragged. Given that specific seated player only containers may be used to organize tiles I think they should not be revealed until they are dragged over a non-hidden container. I don't think this is an "issue" that requires any change. Just make the mat a "hand." You do that by adding ` "childrenPerOwner": true`. Then only the player that owns that mat can see the widgets until they are dragged outside of its borders.
Author
Owner

@96LawDawg commented on GitHub (Oct 13, 2022):

Arguably other players should also not know the cursor position while it is over a private widget, however this is less distracting / revealing than dragged items popping in and out.

We recently made some changes that modified the appearance of the cursor. But we haven't undertaken the task to do that while it is over a hand. That would be a fair amount of coding. Of course it can be done and PCIO allows that. Eventually we should make it an option, but it hasn't risen up the priority list yet. See issue #249.

With my observation above and noting that your second comment is a duplicate issue, can we close this?

@96LawDawg commented on GitHub (Oct 13, 2022): > Arguably other players should also not know the cursor position while it is over a private widget, however this is less distracting / revealing than dragged items popping in and out. We recently made some changes that modified the appearance of the cursor. But we haven't undertaken the task to do that while it is over a hand. That would be a fair amount of coding. Of course it can be done and PCIO allows that. Eventually we should make it an option, but it hasn't risen up the priority list yet. See issue #249. With my observation above and noting that your second comment is a duplicate issue, can we close this?
Author
Owner

@flackr commented on GitHub (Oct 13, 2022):

Ah nice! Yeah that works in the single ownership case but I'm guessing doesn't work if you have a holder that is onlyVisibleForSeat: ['player1', 'player2']

Made an example to show this case and how childrenPerOwner: "true" isn't sufficient for a shared private state amongst multiple seated players:
https://virtualtabletop.io/fnll

@flackr commented on GitHub (Oct 13, 2022): Ah nice! Yeah that works in the single ownership case but I'm guessing doesn't work if you have a holder that is `onlyVisibleForSeat: ['player1', 'player2']` Made an example to show this case and how `childrenPerOwner: "true"` isn't sufficient for a shared private state amongst multiple seated players: https://virtualtabletop.io/fnll
Author
Owner

@96LawDawg commented on GitHub (Oct 13, 2022):

Ah nice! Yeah that works in the single ownership case but I'm guessing doesn't work if you have a holder that is onlyVisibleForSeat: ['player1', 'player2']

Yes, that is true. You could make it work by setting properties to the widgets so that if they come from the mat, they are only visible to players that own that mat until the widgets are dropped somewhere else. I'll set a demo that shows that. But I can see why you might want to make that an option in the code. If you can make that happen, have at it.

@96LawDawg commented on GitHub (Oct 13, 2022): > Ah nice! Yeah that works in the single ownership case but I'm guessing doesn't work if you have a holder that is `onlyVisibleForSeat: ['player1', 'player2']` Yes, that is true. You *could* make it work by setting properties to the widgets so that if they come from the mat, they are only visible to players that own that mat until the widgets are dropped somewhere else. I'll set a demo that shows that. But I can see why you might want to make that an option in the code. If you can make that happen, have at it.
Author
Owner

@robartsd commented on GitHub (Oct 13, 2022):

The only issue I see is that the idea might not work for every game design. Probably better to create a new property that triggers this behavior rather than assuming it should be applied as a side effect of hiding something from other players.

@robartsd commented on GitHub (Oct 13, 2022): The only issue I see is that the idea might not work for every game design. Probably better to create a new property that triggers this behavior rather than assuming it should be applied as a side effect of hiding something from other players.
Author
Owner

@96LawDawg commented on GitHub (Oct 13, 2022):

The only issue I see is that the idea might not work for every game design. Probably better to create a new property that triggers this behavior rather than assuming it should be applied as a side effect of hiding something from other players.

I agree with that. That is what I mean. It would have to be a new property, or some modification or adjustment to "childrenPerOwner."

I do have a working demo in https://virtualtabletop.io/jg3f of how to get around this without a code change. You need 3 browser views. Changes are enter and leave routines to the 2 holders (they are NOT hands) and a draggingChangeRoutine in the deck's cardDefaults. Could easily be tweaked for many situations. I believe this solves @flackr's problem (at least through the JSON without rewriting the code).

Note, the demo does not perfectly replicate what happens with childrenPerOwner. The dragged widgets are hidden to the other players until it is dropped and then it just appears. It would be possible to more closely simulate the hand behavior using x and y changeRoutines and having the onlyVisibleForSeat property changed when the x/y values moved outside the area of the mat. That would have been a little more work so I decided not to do that, but if help is needed, I could put that together as well. Just ask.

@96LawDawg commented on GitHub (Oct 13, 2022): > The only issue I see is that the idea might not work for every game design. Probably better to create a new property that triggers this behavior rather than assuming it should be applied as a side effect of hiding something from other players. I agree with that. That is what I mean. It would have to be a new property, or some modification or adjustment to "childrenPerOwner." I do have a working demo in https://virtualtabletop.io/jg3f of how to get around this without a code change. You need 3 browser views. Changes are enter and leave routines to the 2 holders (they are NOT hands) and a draggingChangeRoutine in the deck's cardDefaults. Could easily be tweaked for many situations. I believe this solves @flackr's problem (at least through the JSON without rewriting the code). Note, the demo does not perfectly replicate what happens with `childrenPerOwner`. The dragged widgets are hidden to the other players until it is dropped and then it just appears. It would be possible to more closely simulate the hand behavior using x and y changeRoutines and having the `onlyVisibleForSeat` property changed when the x/y values moved outside the area of the mat. That would have been a little more work so I decided not to do that, but if help is needed, I could put that together as well. Just ask.
Author
Owner

@flackr commented on GitHub (Oct 13, 2022):

I put together a PR and modified https://virtualtabletop.io/fnll to show the idea. I think this isn't quite right because it should probably inherit from ancestor holders as well if they have the property specified.

Update: Now inherits from ancestors as well.

@flackr commented on GitHub (Oct 13, 2022): I put together a PR and modified https://virtualtabletop.io/fnll to show the idea. I think this isn't quite right because it should probably inherit from ancestor holders as well if they have the property specified. Update: Now inherits from ancestors as well.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/virtualtabletop#576
No description provided.