More general "Salvager Buttons"

[michaeljb]

As to the requests that we move other troublesome buttons... now that we've proven the concept with End Turn, maybe we can have a longer-term effort to make our own full panel of buttons, with better organization, and just have a "Salvager Buttons" option. It would probably save effort if we do them all at once instead of one or two buttons at a time. I think I'll make an enhancement request on github to discuss details.

• @theblankman on f.ds

I had this very idea last night and found a few minutes to begin throwing something together today, so far there's just a couple commits on my fork: 40bc31c643d74081be40c15fdbc2daaaf0954a79, 70e6601. I have just been trying to make the "betterEndTurn" module more generic before actually adding more buttons. There are still some significant refactorings I'd like to do the module, but I left my scratch notes at work and didn't have much more time to hack on it this evening.

If anyone wants me to, I can add the branch to @aiannacc's repo (recently I've been using branches on my own fork mainly for temporary online storage, then squashing them to one or two commits before submitting a pull request, which would not work well with other people trying to pull from the repo; tldr I wouldn't suggest pulling from michaeljb/Goko-Salvager).

[theblankman]

Might as well add the branch here, I'm up for collaborating on this if you want.

Design-wise, where on screen were you thinking of putting all the buttons? I think way up in the corner is okay with just End Turn, but having the full set of buttons up there would be awkward imho.

For the bigger group of buttons, maybe in the sidebar between the log and chat window? That would be reasonably close to where the non-Salvager buttons are, but take space away from the other sidebar components. Or, right on top of where the Goko buttons live, if that's possible?

Another possibility: Put our buttons in a non-modal dialog, then the user can move them wherever s/he likes, or even show/hide the dialog at will. If we did this, we'd need a "Show/Hide Buttons" control somewhere, I guess in the sidebar is simplest.

[serakfalcon]

I like the semi-modal dialog with a 'pop-out' buttons control on the sidebar. That is, if we 'pop-in' the buttons goko's buttons show as normal, but 'popped-out' all the buttons are in the dialog.

[theblankman]

So instead of choosing their buttons as a User Setting, the user could switch between Goko and Salvager buttons at any time during the game? I'm not sure about that. Considering the "problem" we're addressing is accidental clicks of poorly-placed buttons, I think the users requesting this feature would rather have the Goko buttons totally gone. And I doubt very many will want to use both sets of buttons in the same game, so my vote is for a User Setting to have one button-set or the other.

I am also leaning a bit toward the non-modal dialog. It occurs to me that maybe Play Treasures and End Turn should be in the sidebar directly, since they are by far the most commonly used, and the rest could go in the dialog. It's not too much clutter to have three buttons in the sidebar: Play Treasures, End Turn and Show Other Buttons.

[aiannacc]

Why not just use some of the extra real estate that Goko so kindly reserved for us? Examples?

Ordinary end of turn:

End of turn with coin tokens available:

After playing Count:

After buying Stonemason:

As I see it, screen real estate isn't a problem. The problem is that there are quite a few situations where Dominion demands extra buttons. We'd need to add a fair amount of game logic to identify all of those cases and treat them each separately.

PS: Should I release this into the beta already? Or do we want to nail down our plans a bit more first?

[allanjackson]

If you're looking at redoing all the buttons, what about adding the buttons that goko "forgot" to implement? I'm thinking any situation that forces you to drag a card to a specific location.

So with Survivors, for example (one of my least favorite online cards), we would have a "Discard" and a "Return to Deck" button (and then a cartographer style way to choose the order of putting them back).

[theblankman]

@allanjackson the code to "move" an existing button is already written, and would be very different from the code to make a whole new button. The new End Turn button just simulates a click on the hidden Goko button, so there's no game-logic-related code attached to it directly. New buttons would require that kind of code, customized to each new button. Not saying it can't be done, just that it should probably be a separate issue from this one.

@aiannacc Release what into beta? I don't think we've got anything beyond better-end-turn yet. I thought that was already in beta but if it's not, I'd say release it.

Also, I don't think we need to implement any game logic. We just need to discover every button Goko can present, listen for when those buttons would become visible-and-enabled, and when that happens, enable our corresponding button instead. @michaeljb already wrote this logic for End Turn, we just need to make it generic, and have it run on the list of buttons we compile.

[aiannacc]

@aiannacc Release what into beta? I don't think we've got anything beyond better-end-turn yet. I thought that was already in beta but if it's not, I'd say release it.

It's in the beta branch, but not the beta release of the extension. At the moment, I alone have the power to do that (something I think we ought to change, fyi).

[theblankman]

This didn't release it?

[michaeljb]

I made the logic more generic and changed the name of the module to "alternate buttons" so that it's not necessarily tied to the sidebar. I also included an "End Actions" button. https://github.com/aiannacc/Goko-Salvager/commit/ded7af1a13e4c5dbbd1bb10618abd16066a92172

I don't think it would be that difficult to just move the Goko buttons around. In updateButtons(), when the "gokoView" is captured, I think we could modify gokoView.center to place it wherever we want. It probably gets trickier/more annoying when dealing with resized screens and correctly repositioning multiple buttons, but there might be an easy way to do it.

I do agree that the top right of the sidebar isn't the best spot for buttons to go; my initial thinking was at least it makes darn sure you won't accidentally click "End Turn" :smile:

[michaeljb]

So in alternateButtons.js, if you put a breakpoint at the beginning of updateButtons() and in the console investigate the panels returned by this.dominionWindow._getAllPanels(), you'll see we basically have access to the whole UI, so I think we could eventually make a full alternative interface (like iso) and even hide the <canvas> element.

After a bit of playing around, I chose which cards to discard to Warehouse via commands entered in the console and it worked perfectly. It also let me rearrange the cards in my hand, so it should be easy to implement AdamH's request for consistent card ordering. The one restriction I see is not being able to easily control dragging things around, but I bet there's a way to do it--probably just need to find the right events and call the listeners to simulate the dragging actions.