Problem after quick refit was added

[nathanebht]

Found a problem after the quick refit to latest design button was added. If I have anything queued to build, then I can't replace it with a refit. You can only queue a refit to start after.

If your queue is already empty, then this isn't a problem.

[sven]

Found a problem after the quick refit to latest design button was added. If I have anything queued to build, then I can't replace it with a refit. You can only queue a refit to start after.

If your queue is already empty, then this isn't a problem.

Yeah, my current thinking is that if we're going to keep this feature, I probably need to add a way to remove the current set production item (moving down anything that's in the queue to fill the emptied slot). I think making right click a shortcut for "remove current production", rather like right click already removes queue items, might help.

[nathanebht]

Think the current method for choosing between immediate build or add to queue works well. That can't be utilized for refitting?

[sven]

Think the current method for choosing between immediate build or add to queue works well. That can't be utilized for refitting?

The problem, at core, is that we have too many actions, and not enough buttons. Semantics we might want to use for refitting include "set custom refit", "queue custom refit", "instant refit", "mass instant refit", "set default refit", and "queue default refit". That's... 6 different actions, all of which are competing for space on that one refit button.

The current hack (and it is an ugly hack), is to tie "set custom refit" and "queue custom refit" to the main buttons depending on whether you opened the subpane in normal or queue mode. Then expose "queue default refit", "instant refit", and "mass instant refit" as on-hover buttons.

Now that I'm thinking it through, a slightly better approach might be to switch between "queue default refit" and "set default refit" on-hovers depending on whether the pane had been opened in normal or queue mode... That way, we'd at least be exposing all 6 semantics in a way that sortof made sense given the panes. I'll give that a shot in the next 'dev' patch.

edited by sven: Should be "fixed" on "in_development". Let me know if it's still playing oddly.