Cops move inconsistantly

[FrostyNick]

Describe the bug Cops randomly stand still, skip one space, and sometimes skip two spaces. Reproducible on v1.6.2 and v1.6.3. Not reproducible on v1.6.1.

To Reproduce Steps to reproduce the behavior:

1. Get to v1.6.3 or v1.6.2 or v1.6.1.
   • Locally: git checkout 0fe9b0a (v1.6.3); git checkout bc710db (v1.6.2); git checkout 45b72b0 (v1.6.1), then start a live server or web server.
   • Online: v1.6.3; v1.6.2; v1.6.1
2. Click on Start, then click on Master.
3. Click button to start the round.
4. You should now be able to see the bug as it happens quite frequently.
   • If you are using this locally, type git checkout main to return to the main branch or return to your branch if you are working on another branch; especially if you have a git stash.

Expected behavior Cops are supposed to be moving one tile at a time; not at random intervals.

Desktop (please complete the following information):

• OS: Linux Lubuntu 20.04
• Browser: LibreWolf 113.0 (Firefox-based)

Additional context

• Mentioned on issue #30 "Potential bug" as a header.
• Probably related to Line 1707.

[FrancisTR]

I am currently investigating the issue ever since the release of v1.5.0. It seems that the equation, for the cop to move, is causing the problem, though I can't recall if it was an issue before v1.5.0. Might have to either rework the equation or revert back to the original equation that was before v1.5.0.

[FrostyNick]

I forgot to mention this doesn't happen on v1.6.1 (added to main post as an edit). It's caused by the different math involved with the synchronization existing in v1.6.2, and the cubes are no longer guaranteed to be consistently in the range x2[0] <= 530 && x2[0] > 526.5). It should be updated to work with the new variable values.

[FrancisTR]

@FrostyNick What do you have in mind? Is it simply changing the values accordingly for x2[0] <= 530 && x2[0] > 526.5)?

[FrostyNick]

It doesn't seem that simple, since the numbers are variable. For example, if the red boxes froze for 2 seconds due to lag, then in the next frame, all the boxes would move many pixels to the same location to sync to where the music is. These values could be skipped. That's v1.6.2 in a nutshell.. red boxes are calculated quite differently.

[FrostyNick]

Maybe it should check if the box behind the beat (-x from white area) has reached it, and it does, point to the previous box, check again until it collides to the white area, repeat. That's my thoughts so far.

[FrostyNick]

Maybe I misread the comment. Yeah, it's based on x2[0] .. just checking for bounds on one number instead of two now and the pointer to the previous cube should take care of the lock in theory.

[FrostyNick]

This code seems to fix the problem. It aims at lockPattern = true during only one frame of the cubes cycling.

Before:

if(x2[0] <= 530 && x2[0] > 526.5 && !lockPattern){
    enemyMovePattern = (enemyMovePattern+1)%8;
    if(enemyMovePattern == 0){
        enemyMovePattern = 8;
    }
    lockPattern = true;

}else{
    lockPattern = false;
}

After:

// Below line should be next to lockPattern or a global variable in general.
let lockPatternUsed = false; //!!! In reset enemies 
// ...
// ...
if (lockPattern) {
    lockPattern = false;
    lockPatternUsed = true;
}else if(x2[0] <= 526.5) {
    lockPattern = false;
    lockPatternUsed = false;
}else if(!lockPatternUsed && (x2[0] > 526.5)) { 
    enemyMovePattern = (enemyMovePattern+1)%8;
    if(enemyMovePattern == 0){
        enemyMovePattern = 8;
    }
    lockPattern = true; // only should be true once per red cube cycle
}

[FrancisTR]

@FrostyNick Looks great! If you can, can you make a PR of your solution?

[FrostyNick]

Yes. I revert what I said earlier about one bound instead of two. Somehow I forgot it depends on blue cube? Code is improved in PR.

@FrostyNick Looks great! If you can, can you make a PR of your solution?