Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slice moves recognition #3

Open
tussosedan opened this issue Aug 23, 2018 · 5 comments
Open

Slice moves recognition #3

tussosedan opened this issue Aug 23, 2018 · 5 comments
Labels
enhancement New feature or request

Comments

@tussosedan
Copy link

Please add slice M/E/S moves recognition (currently it's R L' or similar). Perhaps using a short time threshold e.g. 30ms to differentiate between slices and simultaneous moves.

@hakatashi hakatashi added the enhancement New feature or request label Aug 28, 2018
@tussosedan
Copy link
Author

tussosedan commented Sep 7, 2018

@hakatashi do you think you will implement this? This would be a huge thing for Roux solvers, and I know many are waiting for this before buying the giiker.

@hakatashi
Copy link
Owner

hakatashi commented Sep 8, 2018

Not soon. I don't conceived the proper way to detect and handle slice moves yet.

I prioritized this task because of your comment, but still no real roadmap is here.

Pull requests and suggestion are welcomed.

Note:

  1. Detection: I don't prefer depending on times to detect slice moves. Adjusting threshold is annoying and inconsistent. Maybe I will implement slice moves detection in non-time-dependent ways. (e.g. treat all R L' moves as M move)
  2. Handle: Technically M move is equivalent to x' R L', which includes whole cube reorientation. The current codebase cannot handle reorientation of cubes between moves and I'm still struggling to find how to implement this.

@tussosedan
Copy link
Author

tussosedan commented Sep 9, 2018

allisio on reddit uses 30ms as a threshold, and it seems to work great! Here's an example (slices shown around the middle of the video):
https://streamable.com/xbprq

About handling the implementation, hmm, if you can reorient before the first move, then I think you can do the same in the middle, treating the rest of the solve kinda like a new solve? If it's helpful, maybe keep both the original move recognition and the one that keeps being rotated. Sorry I can't write the code, I know nothing about web development.

@tussosedan
Copy link
Author

tussosedan commented Sep 9, 2018

@hakatashi I wrote some Python code that takes a given reconstruction and changes all R L' etc. to slice moves. It also optionally translates L moves to r wide moves, and can rotate the whole reconstruction as well.

It's not nearly optimal, but it works great! While it's still a work in progress and I'll add some more stuff to it, I wanted to share it with you in case it can give you ideas or maybe even the code can help.

Here's the code:
https://eval.in/1055757

@tussosedan
Copy link
Author

@hakatashi gentle reminder :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants