Some things I've noticed with this

I grew fascination when I saw this from the subreddit, and would like to make some comments on how I feel about this.

• I realize that there tends to be some drops, as in it'll stall out the control and instead of outright waiting for an affirmative to hold a button, it will hold it by itself. For example, during a specific lag drop, if I move the stick around (circle pad), I will only hold it for a second, however it will hold it longer than it should whilst waiting for another input instead of letting go until then. This seems like it's past a lag optimization, however I may be wrong.

• I seem to be having a little bit of an issue, particularly on my end, and I think it'd be convenient if in some way this can be solved. On my adapter, it always reads my analog inputs for my L/R as moving rapidly. I can tell in the log window in Python that it sees those moving a lot, and tries to interpret them. I'm guessing this is making the game hold L/R, or something different. However, on the other end, I realize that after I drop the connection, I still saw my Dr. Mario holding shield in training, which was rather odd. Point being that L/R seems to stick, at least my analog input of them, which I believe is being picked up as it's own stick or something similar.

• This is a suggestion; perhaps make some sort of way to report ping? I'm not sure if this can be done, however it'd be neat if it could report the ping between the 3DS and the system after each second, or on each button press to tell you if it spikes. This way you can perhaps monitor where the best spot for you 3DS is by moving it around and monitoring the ping as it moves, instead of moving it until it gets the spot just right.

• And finally, some thoughts. I'm not sure if this can be done, however; it'd be nice if it could have a simple UI. Meaning, a preliminary UI of some sorts to use the basic features, and for easier configuration. This could be very good for the remapping, and make it a lot more convenient than having to edit the list yourself. Some thoughts for one could be a simple console window and an area to change configurations or devices, such as disabling certain ones or disabling others.

I think I may learn some Python to hopefully help this project, because I think it can be greatly improved. Thank you for your work so far, and I hope I can help by testing or coding in the future!

[hlixed]

Your 3rd bullet point, the ping request, would require changing the protocol that GCIR (and TPPFLUSH) use to communicate with Luma3DS. While a nice thought, this is currently impossible without changes to Luma3DS. I've added a feature request on the Luma3DS Rosalina feature request issue for this topic.

+1 for an UI, though. Good luck learning python, JBoughter!

Shame we can't log pings (for now). Thanks anyway, and thanks for adding it to the request thread for me!

[MissingNO123]

Hey JBoughter, thanks for opening an issue! To address your concerns:

1. This is probably caused when the 3DS receives the first stick input, but doesn't receive the second. This may be an issue with the 3DS, Python, or the network itself but without more info I really can't say for sure.
2. The analog triggers being interpreted rapidly is simply because they're read at an extremely high precision, which I didn't really bother to round off (though I'm planning to fix soon). The L/R sticking after disconnecting is a weird bug and I'm still trying to figure out whether it's my program, Python, or Luma causing that.
3. What hlixed said.
4. A UI is planned once I can figure out how to either get a GUI running alongside PyGame, or some similar alternative.

[hlixed]

Perhaps a GUI could be implemented by using PyGame sprites.