-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide dragged items while over hidden container. #1356
Comments
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. |
I don't think this is an "issue" that requires any change. Just make the mat a "hand." You do that by adding |
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? |
Ah nice! Yeah that works in the single ownership case but I'm guessing doesn't work if you have a holder that is Made an example to show this case and how |
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. |
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 |
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. |
While dragging, inherit the onlyVisibleForSeat property from drag targets (and their ancestors) using hoverInheritVisibleForSeat to hide visibility for drags made over a hidden widget. Fixes #1356.
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:
dragtest.mp4
The text was updated successfully, but these errors were encountered: