Keys can shift the screen #537
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: openboe/oboe#537
Reference in New Issue
Block a user
No description provided.
Delete Branch "screen-shift-keys"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This makes it so arrow keys/numpad can control screen shift when it's available.
When this preference is enabled, #482 will not be an issue (Fix #482). But the player will also miss out on cases where adjacent targeting would be a good thing. I haven't done anything smart to determine whether one mode or the other is better on a case-by-case basis.
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>I think this should make it more clear that it's swapping one capability with another. Something like "Directional keys shift… instead of…".
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>How about this?
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>Better, but I think a different word than "squares" should be used. Maybe "tiles" or "spaces"?
And I didn't check what you set the default to be, but right now I think it should default to the legacy behaviour.
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>done and done
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>@CelticMinstrel What if holding shift or option/alt performed the opposite function so both are always available?
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>The dialog could have a parenthetical text explaining this
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>Sure, why not. The only question would be which modifier to pick… what precedent do we have so far? There's also the option of Control/Command (that is, Command on Mac, Control on non-Mac).
Given how "shift" typically means "extend", it seems like that doesn't really fit this kind of use. I guess "alt" fits better. Not sure whether "control" fits.
Hmm. I currently have it implemented it with Shift, which might make less sense but is functional.
Just now I tried changing it to Alt/Option, and ran into a problem. Targeting for Look mode is already checking for the Option key, which makes Look Target mode stay activated after targeting a spot.
@@ -41,7 +41,13 @@<led name='slow' relative='pos pos-in' anchor='med' top='0' left='15'>Slow</led><led name='snail' relative='pos pos-in' anchor='slow' top='0' left='15'>Quite Slow</led></group>replied to this out-of-thread (as a new comment)