search

icyflame / cli-cube-timer

Time your solves, without leaving the terminal
https://npmjs.org/package/cli-cube-timer
20 stars 5 forks source link

Include functionality for making solves +2, DNF at the end of the solve #27

Closed icyflame closed 6 years ago

icyflame commented 9 years ago
Jan-Ka commented 6 years ago

Hi, I would like to help you out on this issue but I am not a rubix cube solver myself so I need some clarification on the jargon and what implementation of #12 remains to be done.

I used your gist as reference to prepare a fix for #30 and saw that it contains one "DNF" string.

icyflame commented 6 years ago

Hey @Jan-Ka , sure no problem. I hope that you have installed the module.

  1. When you run solve and then press SPACE the inspection time begins.

  2. The next time the SPACE key is pressed, the solve time will begin (i.e the user starts solving the cube)

  3. Now, there is 15 second inspection time. If the user starts within 15 seconds, then there is no penalty. If the user starts between 15-17 seconds, then a penalty of 2 seconds is added onto the solve time. If the user starts after 17 seconds, then the solve is a DNF (Did Not Finish)

This is implemented

  1. When a solve is over, there are three states:

(a) No penalty (b) +2 = If the cube can be solved with one turn, then 2 seconds is added onto the time (c) DNF = If the cube is not solved, then this solve becomes a "Did Not Finish"

So, the implementation should be something like this:

Once the user presses the space bar to stop the solve, wait for the next key. If the next key is a space, then it is case (a). If the user presses + then 2 seconds is added to the last solve time. If the next key is D then the solve is treated as a DNF.

In the context of this module, you have to essentially wait for the user's key before writing the solve to the file. Let me know if you have any other doubts! Thanks for spending your time on this. :slightly_smiling_face:

Jan-Ka commented 6 years ago

I started working on this issue and got a half decent implementation going. But it's rather crude and does currently break the rendering. However, I'm not sure if it wouldn't be better (as in time better spent) to rewrite/refactor index.js and separate the logic from the output.

Edit: So I started to refactor most of the rendering and utility into an dedicated class and came upon another problem. The charm npm package has an open issue with reporting the current cursor position. I guess that's why your original code spends so much time tracking rows etc. ? For some reason it's quite the task to implement retrieving the current cursor position. Safest bet would probably be to rework the current code into a paint queue - any input/ideas?

icyflame commented 6 years ago

Hey, your approach seems like the one that I was going for, when I initially thought about this feature.

However, I'm not sure if it wouldn't be better (as in time better spent) to rewrite/refactor index.js and separate the logic from the output.

I can't think of a yes/no answer to this. When I first implemented this, I was big on the "console" type interface. I am not anymore. Analyzing index.js now I realize that the only thing that we need overwriting for is the inspection timeout. As I said, I am not so keen on the console type interface anymore.

For now, I think I will probably look out for something that works and provides an easy interface to implement this sort of application in. Admittedly, it will take some time (I am pressed for free time now). If you have some suggestions for packages, I will definitely to check them out!

P.S. I guess that if you can't spare the time, you should probably not work on this issue anymore. This is my screw-up, and I need to fix it. I am haunted by the choices a less-mature me made.

In any case, thanks a lot for the time you did spend working on it! I will decide how to proceed and try to use your code! 👍

icyflame commented 6 years ago

Actually, a progress bar would be a good enough implementation. That would ensure that I won't have to worry about the rendering part!

Candidate: https://github.com/visionmedia/node-progress