Defect in Stack Inspector
Moderators: Ichibrothers, Cambronne
Defect in Stack Inspector
counters added to a stack while the stack is being displayed in the stack inspector don't show the flashing selection indicator, even after shuffling of the contents.
This causes issues with secrecy (cup draw)
1) stack a series of counters
2) double click base of stack to display stack in stack inspector
// notice selection indicator around entire stack
3) shuffle stack
// notice selection indicator around entire stack
4) drag a new counter into the stack (drag to inspector window)
// notice new counter doesn't have selection indication
5) shuffle stack
// notice that the new counter still doesn't have indication
6) draw a new counter into the stack (via stack display on table)
// notice the new counter doesn't have a selection indication (neither does previously added counter)
7) shuffle
// issue continues
// additionally note that the stack displayed on the tabletop during this operation will operate similarly: newly added counters don't flash (this is easiest to see when a "new" counter is at the top of the stack). Hovering over the stack at this point WILL show full selection, dehovering will return to the errant display.
EDIT:
Workaround: you can double-click on the item after adding it to the stack inspector to give it selected status.
Designer thoughts:
Observation: double clicking a stack on table will add the entire stack to the stack inspector, but only the counter double-clicked (and all counters above it) will be selected in the inspector
Should have any drag-added items start off selected in the stack inspector, but not change any other behavior for backwards compatibility (see above observation)
Shuffling should probably either select-all or select-none as part of its operation. Do we really need to see shuffled selections?
This causes issues with secrecy (cup draw)
1) stack a series of counters
2) double click base of stack to display stack in stack inspector
// notice selection indicator around entire stack
3) shuffle stack
// notice selection indicator around entire stack
4) drag a new counter into the stack (drag to inspector window)
// notice new counter doesn't have selection indication
5) shuffle stack
// notice that the new counter still doesn't have indication
6) draw a new counter into the stack (via stack display on table)
// notice the new counter doesn't have a selection indication (neither does previously added counter)
7) shuffle
// issue continues
// additionally note that the stack displayed on the tabletop during this operation will operate similarly: newly added counters don't flash (this is easiest to see when a "new" counter is at the top of the stack). Hovering over the stack at this point WILL show full selection, dehovering will return to the errant display.
EDIT:
Workaround: you can double-click on the item after adding it to the stack inspector to give it selected status.
Designer thoughts:
Observation: double clicking a stack on table will add the entire stack to the stack inspector, but only the counter double-clicked (and all counters above it) will be selected in the inspector
Should have any drag-added items start off selected in the stack inspector, but not change any other behavior for backwards compatibility (see above observation)
Shuffling should probably either select-all or select-none as part of its operation. Do we really need to see shuffled selections?
Last edited by dulcaoin on 28 Oct 2014, 17:03, edited 1 time in total.
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
It's quite critical when the stack inspector is being used as a "draw cup." (wouldn't you know it, the game module I'm working on right now uses that mechanic)Bill Barrett wrote:Yes that's definitely a bug, albeit a non-critical one, but I'm heartened by your fastidiousness![]()
Regards, Bill.
I'm really just using this forum for bug tracking. Since I'm the guy to fix this, I have to get these things down so I'll know to fix them later.
![Smile :-)](./images/smilies/icon_smile.gif)
That was also an example of a well-written bug report.
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
If you guys look back at dates, you might realize that I started putting in defects at the point it looked likely Jerome would approve me to non-end-of-life the 1.x codebase (sneaky, eh?) ![Smile :)](./images/smilies/icon_smile.gif)
While it's important with a product that's basically frozen in time to amelioriate the issues that come up ("that can be worked around -- it's not that important"), once the code base is live again and new users might show up, even the little things matter.
Imagine you have a draw cup mechanic. You have matching backs on all the counters to be drawn, so you put all the counters to draw from in a stack on the tabletop.
When it's time to draw, you double click the stack, shuffle (more than once if you like), and then right click the top counter to do your draw.
Maybe you even put it on the tabletop as a matter of play etiquette, so it sits out as the current action on the board while the turn plays out.
Now it's time for the next draw, and let's say you have a system where you put the chits back in the cup before the next draw. Well, now you've made it so that it either has to be flipped and added to the stack before you inspect the stack, or you have to double click the chit after you put it back in the cup. (Note that I didn't even know there was the double-click workaround when I first wrote up the bug) Now, that's non-fatal, but it's annoying, and it looks like someone wasn't paying attention at design or test time, right? Add that up over the course of the game, and the professional image of ZunTzu (such as it might be) starts to tarnish, little by little.
The thing is, when you get new players to "check out" your program as their potential new toy, they're going to try all manner of weird things, prying at the edges of intuitive behavior in the program. They don't know better... "let's see how this works." If things don't operate in a clean, robust manner, they form little "chinks in the armor", small weirdnesses that make the application feel like an amateur project, even when it isn't. They'll see things that the seasoned player (who is already a fan) wouldn't ever see, because he knows you don't operate things that way. But for the new player trying to decide whether ZunTzu is good for him? He's going to care when things operate abnormally.
Here's the irony: It will likely take me less time to fix this than it just did to explain my approach here.
BUT, I will also be learning the innards of the stack inspector, so when the time to comes to fix crash bugs, or to augment its behavior, I'll know how it operates a whole lot better.
Side note that I HAVE seen a rare crash bug using the inspector, there's definitely an off-by-1 error in the inspector logic; it's just been hard to track down. That WILL be an issue for everyone to care about.
![Smile :)](./images/smilies/icon_smile.gif)
While it's important with a product that's basically frozen in time to amelioriate the issues that come up ("that can be worked around -- it's not that important"), once the code base is live again and new users might show up, even the little things matter.
Imagine you have a draw cup mechanic. You have matching backs on all the counters to be drawn, so you put all the counters to draw from in a stack on the tabletop.
When it's time to draw, you double click the stack, shuffle (more than once if you like), and then right click the top counter to do your draw.
Maybe you even put it on the tabletop as a matter of play etiquette, so it sits out as the current action on the board while the turn plays out.
Now it's time for the next draw, and let's say you have a system where you put the chits back in the cup before the next draw. Well, now you've made it so that it either has to be flipped and added to the stack before you inspect the stack, or you have to double click the chit after you put it back in the cup. (Note that I didn't even know there was the double-click workaround when I first wrote up the bug) Now, that's non-fatal, but it's annoying, and it looks like someone wasn't paying attention at design or test time, right? Add that up over the course of the game, and the professional image of ZunTzu (such as it might be) starts to tarnish, little by little.
The thing is, when you get new players to "check out" your program as their potential new toy, they're going to try all manner of weird things, prying at the edges of intuitive behavior in the program. They don't know better... "let's see how this works." If things don't operate in a clean, robust manner, they form little "chinks in the armor", small weirdnesses that make the application feel like an amateur project, even when it isn't. They'll see things that the seasoned player (who is already a fan) wouldn't ever see, because he knows you don't operate things that way. But for the new player trying to decide whether ZunTzu is good for him? He's going to care when things operate abnormally.
Here's the irony: It will likely take me less time to fix this than it just did to explain my approach here.
![Smile :-)](./images/smilies/icon_smile.gif)
Side note that I HAVE seen a rare crash bug using the inspector, there's definitely an off-by-1 error in the inspector logic; it's just been hard to track down. That WILL be an issue for everyone to care about.
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
I think the stack inspector could use some more "love", feature wise. I've been exercising its use.Bill Barrett wrote:Don't get me wrong - a bug's a bug and every one you find should be treated with extreme prejudice
And, like I said, I am specifically working on a gamebox with draw cup mechanics. Had I not, this probably would not have risen to prominence until later.
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
Well while we're on the subject I'd like to point out that there's a fault with the Stack Inspector when a player uses it to manipulate counters or cards on a "Hidden" tab, namely its contents are visible to all.
I think that it should default to being invisible to other players in this case, but I also think that it would be useful if it had an "Eye" icon as well, so that public visibilty could be toggled on or off. This is an idea that also has a bearing on the "Fog of War" issue with stacks that I alluded to a little while back - I'll expound on it further when I have more time![Wink :wink:](./images/smilies/icon_wink.gif)
And I agree that an enhanced Stack Inspector has a lot of potential for increasing and improving ZT's functionality.
Regards, Bill.
I think that it should default to being invisible to other players in this case, but I also think that it would be useful if it had an "Eye" icon as well, so that public visibilty could be toggled on or off. This is an idea that also has a bearing on the "Fog of War" issue with stacks that I alluded to a little while back - I'll expound on it further when I have more time
![Wink :wink:](./images/smilies/icon_wink.gif)
And I agree that an enhanced Stack Inspector has a lot of potential for increasing and improving ZT's functionality.
Regards, Bill.
I just wanted to chime in here on the idea of a "hidden stack inspector".
In my playtests we sometimes have a game action where multiple players must select a random item from their personal supply (select their stack, open the inspector, shuffle and draw one off the top). As currently implemented, each player needs to tediously take turns doing what otherwise would be simultaneous around a table.
In my perfect world, each client would have their own "private" stack inspector, allowing the players to use it at will on whatever stack they wish without disturbing anyone else. Implementation might work like this:
In my playtests we sometimes have a game action where multiple players must select a random item from their personal supply (select their stack, open the inspector, shuffle and draw one off the top). As currently implemented, each player needs to tediously take turns doing what otherwise would be simultaneous around a table.
In my perfect world, each client would have their own "private" stack inspector, allowing the players to use it at will on whatever stack they wish without disturbing anyone else. Implementation might work like this:
- - Add an icon to the set in the lower right which toggles the stack inspector from public to private.
- Public mode would work as it does now.
- Private mode, however, would not show any public inspector to that client while it is toggled...that client would only see an inspector for stacks he/she has clicked on and these stacks would not be visible to anyone else.
- Toggling back to public would resume displaying the shared inspector.
Thank you, this is a great set of suggestions, and I really appreciate that you've thought out the implementation (solution) as well as describing the problem. This is very helpful.Easy wrote:I just wanted to chime in here on the idea of a "hidden stack inspector".
In my playtests we sometimes have a game action where multiple players must select a random item from their personal supply (select their stack, open the inspector, shuffle and draw one off the top). As currently implemented, each player needs to tediously take turns doing what otherwise would be simultaneous around a table.
In my perfect world, each client would have their own "private" stack inspector, allowing the players to use it at will on whatever stack they wish without disturbing anyone else. Implementation might work like this:Alternatively, a hotkey to shuffle stacks without opening the inspector would be super useful.
- - Add an icon to the set in the lower right which toggles the stack inspector from public to private.
- Public mode would work as it does now.
- Private mode, however, would not show any public inspector to that client while it is toggled...that client would only see an inspector for stacks he/she has clicked on and these stacks would not be visible to anyone else.
- Toggling back to public would resume displaying the shared inspector.
-- joshua