Auto Max Lair 2.0 code entry issues (multiple consoles + wireless microcontroller)

[polar smelt]

Title specifies wireless microcontroller (Specifically, two Raspberry Pi Pico 2W) because I believe this is what is causing the issue. Here's a video demonstrating: https://www.youtube.com/shorts/wS2WM2ZJLks

Essentially, the settings for Auto Max Lair's programs dictate that you must use a code even in local host mode, and the code entry happens so fast that a wireless controller will regularly drop inputs. In the example, I use the code 1111 1111, since a code consisting of one repeating number has a higher success rate than other codes (for instance, I've also used 1212 1212, but this often results in an incorrect code). Even with such a simple code, though, it sometimes fails to fill out the code fully or misses the + input, getting stuck on the code entry prompt. This happens with enough regularity that I frequently hit the "failed to start adventure 3 times in a row" error and have to manually restart the program.

Honestly, I think just having the option to perform slower, human-speed code entry would fix this problem. I get why the program enters the code so fast (autohosting for other players), but for my setup (two automatic switches, no human players, local communication only), I would rather have the consistency of slow code entry if it means less errors.

I'll try to catch this happening again with the output window in the video as well, since I imagine that would be more helpful\

[limpid wing]

fyi, the code entry is the same routine that's reused in many places. Not just the auto-host, but also the Fast Code Entry for both SwSh and SV raid joining.

Even though speed isn't important here, it's fast simply because it's using the same function as other places where it is important.

but yes, grab the logs. I'm wondering if the Pico reported any errors.

Wireless code entry has been tested pretty extensively before we ever released it. But some people may be more wireless interference than others. Here it might be interesting because you have 2 of them in close proximity.

[polar smelt]

Yeah I figured it was reused, just was wishing the option for slow entry existed. If you're saying it's been rigorously tested and that this shouldn't be happening though, then maybe I'm just wrong lol

I physically spaced the Picos as far apart as I could given my limited equipment (there are USB sockets on opposite sides of my PC) but wireless interference is certainly plausible, especially since I have to use wireless internet connection rather than ethernet for my PC (our house is very old). I'll share a pic of my setup once I get the next video

[limpid wing]

I'll take a look at this over the weekend. There's more stuff going on here. Like it shouldn't be trying to move the cursor left when all the digits are the same.

[fading solar]

!programlogs

[vale dock]

To help the developers understand the automation problem you're facing, please find the log file and upload it to the help channel.

Where are the logs?

The logs are created in a file called "SerialPrograms.log".
On Windows, it is in the folder where you launch the program. On macOS, it is at /Users/<your_username>/Library/Application Support/SerialPrograms/.

Whenever the log file reaches about 50MB its content will move to SerialPrograms-<timestamp>.log. Depending on how recent the problem is you may need to look for logs in older log files.

You can send the whole log file (which may be large!) or isolate the lines that illustrate the problem you are facing.

Each line in the file has a time and date stamp. Use that to find the portion of the logs where the problem occurred. You can edit the file with any text editor.

If the text editor is too slow to work on large files, choose a modern high-performance text editor like the free Sublime Text Editor.

[polar smelt]

That was what was bothering me the most, it did that consistently regardless of the code entry. Often resulting in completely different codes being entered on each Switch

[limpid wing]

The cursor movement is an optimization since some codes are faster to enter if you can do them say - backwards or something. But here it's a "tie" meaning the tie-breaking procedure isn't correct.

Also, which Pico firmware version are you using? There have been a number of stability updates, but CC never enforced the update since the protocol hasn't changed in a while.

[polar smelt]

That... I'm not sure. I just bought these recently. How can I check that?

[limpid wing]

The blue text next to the reset buttons.

[polar smelt]

2025122802 on each

I got a video of the error occuring with the output window visible in frame. I'm just grabbing the raw text from the output log and putting it in a Pastebin while it uploads

https://pastebin.com/xECMX22h Here's the log (just from the moment I start the program to the moment I end it)
https://youtu.be/gD92syZ5dH8 and the video of the error occurring

And here’s my setup oh god the cable management is so bad

I'll try to unplug all the other wireless devices my PC is using, including the internet, to see if that helps

[limpid wing]

I think I see an issue in the timing of the buttons. I'll double check over the weekend. I think they probably broke in one of the refactors that happened after the initial wireless testing.

[polar smelt]

No worries! I can make do in the meantime. Appreciate the help

[polar smelt]

Yeah so reducing wireless interference didn't seem to help. In the meantime I'm gonna have them running on separate computers in the 'host locally' mode so they can join each other without having to use a link code

[limpid wing]

I pushed a fairly large fix which will be in the next beta/release.

The issue with the cursor movement was a bug in the way the program calculated how fast a path is. This caused scrolling to actually reduce the cost.

The issue with the timings turned out to be some bad assumptions with how to calculate timings for controllers with non-zero timing variation.

[polar smelt]

well, glad I could help you squash some bugs