Initial values for analog L and R

[JonnyHaystack]

Hi, was just wondering why analog L and R are set to 31 (0x1F) in defaultGamecubeData https://github.com/NicoHood/Nintendo/blob/master/src/GamecubeAPI.h#L30

Does an official GameCube actually send that as the initial value? If so, do you have any idea why? I'm a bit confused about how stick/trigger calibration works, and have seen people having some issues with hardware-based NintendoSpy input viewers showing incorrect analog stick positions when used with a controller that runs on this library.

[Skuzee]

My analog triggers have a physical range of roughly 30 to 240. 31 seems like a decent resting position. The Gamecube isn't the one who sends the initial values, it sends a command to the controller and it reads the return data. This is used to calibrate the origin. See gc_origin in Gamecube.c That said, I don't believe the controller calibrates the analog triggers, only the sticks, but I might be wrong.

Every time you write to the console it initializes the data with default values, but then immediately rewrites it with the report you send it. This shouldn't really be an issue either, assuming the data you're sending it is valid. See CGamecubeConsole::write in GamecubeAPI.hpp

This library stores data in a different order/format than NintendoSpy uses. The newest version of NintendoSpy has support for this library, but you have to download the source and compile it yourself with visual studio. (community version has a free trial.) I had a lot of teething issues trying to make it work at first, but I currently have no issues with this library with NintendoSpy now that the newest version supports it.

[JonnyHaystack]

My analog triggers have a physical range of roughly 30 to 240. 31 seems like a decent resting position. The Gamecube isn't the one who sends the initial values, it sends a command to the controller and it reads the return data. This is used to calibrate the origin. See gc_origin in Gamecube.c That said, I don't believe the controller calibrates the analog triggers, only the sticks, but I might be wrong.

Sorry, I did actually mean to say GameCube controller. Triggers are definitely calibrated too. It's a fairly common thing in the SSBM community to "trigger trick", meaning you hold down a trigger when plugging your controller in so that the trigger doesn't yield an analog input but still gives a digital input when fully pressed. I'm not sure there's any particular reason why this library should initialise the triggers to a specific value based on the official GCC's physical range.

This library stores data in a different order/format than NintendoSpy uses. The newest version of NintendoSpy has support for this library, but you have to download the source and compile it yourself with visual studio. (community version has a free trial.) I had a lot of teething issues trying to make it work at first, but I currently have no issues with this library with NintendoSpy now that the newest version supports it.

So you just need a newer version of the NintendoSpy desktop program? No firmware update needed on the input viewer device? If so I will get someone to test that, thank you.

[Skuzee]

NintendoSpy sends ascii 1s and 0s (each a full byte) over serial. This lib stores controller data in bits and sends full bytes. It means it's more efficient (8 times as much). The last compiled release of NinSpy is from 2014 and does not support this library, but the current github version (if you compile it yourself) will. If you intend to use this library on your input viewer, that's what you'll need.

[JonnyHaystack]

Ah so the change in NintendoSpy (presumably this one jaburns/NintendoSpy@0e557d9) is to make it compatible with input viewer firmware that uses this library? And not to fix problems with NicoHood-powered controllers being used with input viewers that run the NintendoSpy firmware?

[JonnyHaystack]

If so, how exactly would you use this library for an input viewer? Wouldn't you then have both the Arduino and the GameCube console sending poll commands to the controller at the same time over the same data line? That kinda sounds like it would be problematic?

[NicoHood]

What @Skuzee says is true. I've just used the physical defaults, as this library can also act as controller itself and I try to send realistic data. You are free to overwrite it, it should not cause a problem.

[JonnyHaystack]

Gotcha, that's fair enough. Sorry I forgot discussions are a thing otherwise I would've opened one instead of an issue.

[vin2890]

I am really set on remapping a set of keys to a few button clicks. Recently with smash ultimate, Several of Kazuya's move's are inputted with the Shoryuken motion, from Street fighter( Forward, Down, Forward-Down), is there anyway to program these motions into a single button press. I haven't figured out how to send frame data, as these inputs have to be done in 2 frames...Any help with this would be helpful!

https://dashfight.com/ssbu/characters/kazuya-1399/movelist