Closed elmodor closed 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.
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.
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.
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.
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.