Item Printer RNG Bugs

[spark thunder]

I ran into a couple issues with an earlier version of the Item Printer RNG program. I haven't tested the latest release but these issues should still be present

• Not enough delay to start reading the Set Date/Time UI, OCR issue about a third of the time because the UI was not fully loaded/opaque. Increasing the previous button release time from 30 to 35 ticks fixed the issue.
• If the time to set is the same as the current time, the program backs out of the UI instead of clicking OK. Backing out doesn't seem to reset the clock seconds to 0 like clicking OK does
• For the timing to be correct, my delay is set to 0 which translates to a little over a second wall clock.

[real sable]

Why “should” they till be present?

Please try the newest version and report back.

[spare thicket]

The 2nd bullet doesn't make sense. Our code has always pressed A to exit. It never backs out even if the date doesn't change. And no earlier version of the date setter ever did that.

The 1st bullet I'll fix using inference.
The 3rd bullet should be impossible.

[spark thunder]

These were tested in commit 15b4eda which looked to be the last commit that directly modified the Printer RNG program prior to release. I've pulled the latest changes, recompiled, and attached a video for reference.

The test case I have here is using 0 delay and two sequential rows of the same seed with a decently low wait time. The first of the two 5 prints is timed correctly, the second one goes to change the time and exits without confirming here. It works fine with 0 as the delay, I just included that bullet point for awareness.

[spare thicket]

The date change at 0:20 looks wrong. It does it much faster than that and it always moves the cursor all the way to the right side.

Do you see any errors in the log?

I have a feeling that once the program gets off track from this point, it screws up the timings afterward which may be causing the zero delay.

[spark thunder]

Are the logs dumped to ErrorLogs? I just have things related to the previous OCR issue there

[spare thicket]

There's a file that records everything that shows up in the Output Window.

[spark thunder]

I stopped it after the 1 round, I'll see if it goes off course

[spare thicket]

If you're building from source, try pulling latest. I pushed the change that makes it wait for the date change to be fully visible before trying to read/set the date.

[spark thunder]

Here's the log for a single round

2024-04-28 18:55:04.508651 - [Console 0]: Receive: PABB_MSG_ERROR_WARNING - error code = 1 (Device was slow to respond to USB request.)

Sidenote: SerialPrograms.log on Mac only generates if the executable is called via command line instead of the app

[spare thicket]

Don't see anything in that log.

I don't know how Mac works, but perhaps the current directory is different when you run it differently and the log is being put there instead.

[spark thunder]

Yea with Mac, since you're running the .app, the CWD is the path of the .app so it's trying to write it there which is read-only space. Calling the executable via terminal from outside the .app directory gets around that read-only problem.

I moved the check for current.second.year.x == date.x to after the switch statement that handles the setting logic. It fixes the problem but would that cause issues elsewhere?

What seems to be happening is that it only moves the cursor all the way right when the date is adjusted and then confirms after a second pass though verifies the date is correct. If the date is correct in the first pass, the cursor never moves all the way right since that logic is bundled with the date setting logic.