search

drwhut / tabletop-club

An open-source platform for playing tabletop games in a physics-based 3D environment for Windows, macOS, and Linux! Made with the Godot Engine.
https://tabletopclub.net
MIT License
1.27k stars 55 forks source link

Rotate keybind #162

Closed elmodor closed 1 year ago

elmodor commented 1 year ago

Fixes/Solves Fixes #113

Default key is T. Please let me know if I should change this to a different key.

Since I included mouseovers this includes/depends on #154 . Will update this once #154 is merged.

GrimPixel commented 1 year ago

I assume this “rotate” means yaw+. I first thought Q and E (on QWERTY layout), then I realize they might be better for the camera's rotation. For the object, if there are also keys of their movements like WSAD, then the corresponding QE are more suitable. Maybe Caps Lock can be utilised: when it is on, WSAD and QE control the object; when it is off, WSAD and QE control the camera.

elmodor commented 1 year ago

I assume this “rotate” means yaw+. I first thought Q and E (on QWERTY layout), then I realize they might be better for the camera's rotation. For the object, if there are also keys of their movements like WSAD, then the corresponding QE are more suitable. Maybe Caps Lock can be utilised: when it is on, WSAD and QE control the object; when it is off, WSAD and QE control the camera.

If @drwhut wants such an extensive object and camera control this should be done in a separate PR. This implements the basic functionality to rotate an object via keybinding.

Also I don't have a capslock since no game ever uses that. But there could be a difference if shift(or capslock) is active to differentiate between camera and object - if needed.

elmodor commented 1 year ago

This PR introduces a keybind to rotate an object. Rotation is disabled for cards in hand.

The code for the tooltips (at least the other section) needs some kind of refactoring. This is getting messy in there to figure out all possible/different scenarios and what should be displayed.

drwhut commented 1 year ago

I assume this “rotate” means yaw+. I first thought Q and E (on QWERTY layout), then I realize they might be better for the camera's rotation. For the object, if there are also keys of their movements like WSAD, then the corresponding QE are more suitable. Maybe Caps Lock can be utilised: when it is on, WSAD and QE control the object; when it is off, WSAD and QE control the camera.

This seems more complicated than it needs to be - having one button + scroll wheel to rotate an object is fine.

The code for the tooltips (at least the other section) needs some kind of refactoring. This is getting messy in there to figure out all possible/different scenarios and what should be displayed.

Yeah, I agree. I think it could be a case of adding more auxiliary functions, like you did for checking if a piece is modifiable. Feel free to open an issue about this if you want.