@Wisecrack Actually, yes! The buffer class 'InputActionTrace' seems to work without apparent framerate drop. In addition, all the input errors within the game often differ by just one millisecond, meaning it's not frame-locked anymore.

My use case is music games, in which framerate-locked input detection may disadvantage players. osu! already solves that by multithreading the input detection, so I thought there ought to be a way to pull it off.

Plus, I'm using the new input system, which has a method to change the polling rate of the devices. So I thought I could just read the value from the API in a non-main thread because that poll rate modification API seemed to make input detection no longer framerate-locked somehow.

Well, it turned out I was dumb as f*<k not to research this through. The idea was not to read the value in the non-main thread; it's thread-unsafe and would inevitably crash the game. Instead, the right idea appears to be to create a buffer where the input system could queue the polled actions so that I could foreach on them in the main thread later. It seems each action comes with a timestamp, so that sounds like the way to go for me.

All those at-mentions that the bot has put into that comment, but GitHub still did not filter that out? Wow.

At least they show that they follow a good code of conduct with this notification, though! This notification will never be considered anything but for testing purposes.

Unfortunately, some people put questionable things when testing notifications without thinking they might accidentally leak into the production environment like this.

Not too long ago, there was a news app whose notification system the devs wanted to test. Of all things they could have entered as a message, they put the following: "[notification test][dev] we are under attack by guerrilla or special forces."

Well, the notification somehow leaked to the production. Of course, Twitter went bonkers that day, and the devs had to apologize for the upset they had caused.

Never put weird s#!+ to test your code. It will eventually leak into your production environment.

Well, maybe I suck at switching language (whatever language it may be) quickly after all. I just remembered that one time I accidentally spoke Japanese in English accent to Japanese people and confused the f*<k out of them.

@Oktokolo I don't know too well about the general set-up of learning machines (or building PC in general,) but it looks like there are two GPU-looking cards, one of which does not produce any output. So maybe that is the one where learning happens?

@AnxiousADHDGuy Indeed, and that's what threw me off. I thought it was a borked firmware or something, and I was this close to sending the entire thing off to the support.

Oh, did I say that the server does support regular SSH apart from the stupid IP address restriction thing? That is, you can save an SSH public key in remote $HOME/.ssh and log in with private key. So I thought CD was possible. I remembered the IP restriction a little too late before I was about to connect my CD scripts to the server. FML.