• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

csTimer released

Is there a way to delete my sessions. Once, I was kinda exploring different scramble types and didn't realise made a new session every time. Now I have like over 20 completely useless sessions and can't figure out how to delete them.

I don't use cstimer as my main timer, just when I want to use multi-phase (multi-blind) or special scrambles (2x2x3). So less than 5 sessions is all I need, but now everything is just messy.
 
Is there a way to delete my sessions. Once, I was kinda exploring different scramble types and didn't realise made a new session every time. Now I have like over 20 completely useless sessions and can't figure out how to delete them.

I don't use cstimer as my main timer, just when I want to use multi-phase (multi-blind) or special scrambles (2x2x3). So less than 5 sessions is all I need, but now everything is just messy.

Yeah, just navigate to the session you want to delete and click the delete button here:

upload_2017-10-28_8-58-35.png
 
so today cstimer stopped recording my solves. When I start a new session my times get deleted as soon as I click to a different session. Is there some kind of glitch?
 
Hi all,
I'm going to release the latest version of cstimer to the main version on about next weekend.

Key Features:
1. customizable statistical indicators
2. scramble image for all WCA events
3. inverted time list and optimized ui for mobile devices
4. performance optimization, especially for large sessions, e.g. >100,000 values

The latest version of cstimer can be tested at: https://cstimer.net/new/

Since I use a different storage (IndexedDB) to store the session data, I'm not sure whether all of your data will be successfully move to the latest version. If you are going to help me test the latest version of cstimer, you'd better backup your data externally to avoid data loss, e.g. export your data to a local file or the server of cstimer.
Feel free to contact me or reply this thread if you have any suggestions or find any bugs, e.g. display error, data loss, unexpected behavior, etc. I will try to fix most of bugs and then release the latest version.

Notice: https://cstimer.net/new/ will always be the latest version of cstimer and synchronized with the source code, while https://cstimer.net/ is considered as the main version of cstimer.


Here are all updates in detail:
Function updates and bug fixes
  1. Customizable statistical indicators. Now you are able to statistical indicators calculated, which is mo3, ao5, ao12, ao100 by default. You can set it to any values you like, e.g. mo5, ao25, ao30, ao42, mo100, ao10000000, etc. See "Options -> Statistics -> Statistical indicators."
  2. Add Redi cube scramble. Since I do not have plenty of time to write a random-state scrambler for Redi cube, it only generates random-move scrambles.
  3. Add scramble image for clock and megaminx. Then, scramble images of all wca events are available now.
  4. Add M moves in virtual rubik's cube mode, which is binded to key '5' and '6.'
  5. Fix multi blindfold scrambles and clock scrambles.

User interface optimization
  1. The time list is inverted, e.g. the average label is displayed at first, with the latest time next to it, and then the second latest time.
  2. Only 50 values are displayed by default. Even though, when you scroll down to the end of time list, the next 50 values will automatically loaded and displayed. In this way, cstimer will not get frozen due to time list loading during conventional solvings.
  3. We optimize the mobile user interface of cstimer. The statistics area and time list area are displayed in the same row, then they won't cover the current time displayed behind them.
  4. The "option" and "about" dialog are optimized.
  5. We add huge amounts of color schemes at "ABOUT -> Color Schemes", totally 99 different color schemes. Most of them are collected from Internet and the uploaded data.

Performance optimization
  1. The calculation duration of 3x3x3 scramble and SQ1 scramble are optimized.
  2. We add a simple scramble cache. In previous versions, cstimer will generate scrambles immediately when you finish timing, which might cause a tiny UI freezing. While in the latest version, cstimer will cache one scramble, and when you finish timing, the cached scramble will be displayed, and the generation of the next scramble will be executed a moment later.
  3. The calculations of the statistics are optimized. If you only append values to the time list, the whole update of all statistics data are extremely fast even when you have huge amounts of values. According to my test, even you have 100,000 values in your time list, the calculation duration is less than 0.05 seconds. However, if you did some modification on the time list, the calculations are much slower, e.g about 1 seconds in a session with 50,000 values.
  4. We decide to use IndexedDB as the storage of the session of cstimer due to the limit of localStorage. According to the documentation, the storage quota of localStorage is only 5MB, which only supports about less than 50,000 values. Instead, the storage quota of IndexedDB is dependent on your disk size, which can be considered unlimited.

Language support
  1. We add Danish and Croatian. Thanks to the translation works by Alexander Mortensen and Dominik Vidaković
 
Last edited:
Any chance of adding the following changes?
1. Have a timer update mode where it displays "solving" for the first split and displays the timer for the second split? (Thinking of BLD solving, with multi-phase set to 2.)
2. Have each session remember the multi-phase number. Each time I switch to a sighted session from a bld session, I forget to switch back to multi-phase 1.
 
Any chance of adding the following changes?
1. Have a timer update mode where it displays "solving" for the first split and displays the timer for the second split? (Thinking of BLD solving, with multi-phase set to 2.)
2. Have each session remember the multi-phase number. Each time I switch to a sighted session from a bld session, I forget to switch back to multi-phase 1.

I've just implemented the second suggestion. It's not difficult to implement the first one, however, can you explain in detail why you request the timer displays "solving" for the first split and displays the timer for the second one? Since when you are competing with a stackmat timer, you may see the timer during inspection and see nothing during solving.
 
I've just implemented the second suggestion. It's not difficult to implement the first one, however, can you explain in detail why you request the timer displays "solving" for the first split and displays the timer for the second one? Since when you are competing with a stackmat timer, you may see the timer during inspection and see nothing during solving.
Thanks!
What I had in mind for the first was uploading videos to youtube. I don't want to see the time during memo because it's distracting to me, but it would be nice to have it displayed during execution for those watching the video. Especially for something like multi-BLD where the video is always sped-up and you don't have a good sense of how much time is passing.
(Alternatively the time could be displayed as a sub-title of the video during editing, but I can't figure out how to do that in the video editor I use.)
Anyway, it's not a big deal if this is added or not; I was a lot more concerned with my second point, so thanks for adding that!
 
Add Redi cube scramble. Since I do not have plenty of time to write a random-state scrambler for Redi cube, it only generates random-move scrambles.
Anything I can do to help with this? (It "should" be pretty simple: first phase solves the bottom layer, second phase solves the rest.)
 
Anything I can do to help with this? (It "should" be pretty simple: first phase solves the bottom layer, second phase solves the rest.)
Well, I'm going to write an optimal solver or single-phase solver. However, I cannot find a appropriate subgroup or subset to obtain acceptable average pruning length within limited space (due to limited initialization time). Have you tried some other subgroup or subset that can speedup your optimal solver? e.g. solve more than 20 randomly scrambled states within 1 second.

Or would you mind sharing how your optimal solver works (10000 cubes solved in an hour as you mentioned in a Redi Cube thread), which pruning table(s) are used by your optimal solver, are there the same as the phase1 pruning tables used in your two-phase solver? And maybe it can be further optimized by many techniques that you might not familiar with, e.g. symmetric reduction
 
Last edited:
Well, I'm going to write an optimal solver or single-phase solver. However, I cannot find a appropriate subgroup or subset to obtain acceptable average pruning length within limited space (due to limited initialization time). Have you tried some other subgroup or subset that can speedup your optimal solver? e.g. solve more than 20 randomly scrambled states within 1 second.

Or would you mind sharing how your optimal solver works (10000 cubes solved in an hour as you mentioned in a Redi Cube thread), which pruning table(s) are used by your optimal solver, are there the same as the phase1 pruning tables used in your two-phase solver? And maybe it can be further optimized by many techniques that you might not familiar with, e.g. symmetric reduction

Ah, I see. My optimal solver was written in Java and uses a single pruning table applied for the different faces. The pruning table is similar to the larger of the two tables used in the phase 1 solver: solve all the corners (3^8 = 6561) and move the face's edges to the correct face with the correct parity (C(12,4)×2 = 990).

Replacing this with a larger table to fully solve the first layer + all corners (77944680) makes it fast enough to do ~32 solves per second. (Average pruning distance 9.8 moves per face; 10.9 moves with all six faces.) Symmetry reduction should make the table small enough to be quickly generated, I think. Also, if you solve a layer you can only use the symmetry group D_8, but you get D_8×Z_2 if you solve a "slice" of edges. I haven't tried this out, and while initialisation should be faster, the solving might be a bit slower because there are only three slices, compared to six faces.
 
Last edited:
Back
Top