Celeste64 confusing buttons or on screen information?

[tiagobugarin]

After downloading the 1.1.1 from Celeste64's Itch.io page I noticed Nintendo Switch controllers are inverting the functions (B is Confirm/Jump and A is Cancel/Back/Dash)

Went looking in the commits and found the swithing happening in commit https://github.com/ExOK/Celeste64/commit/af97562c24552e3470db947af11baa05174dc390

If the new placement is intended then information on screen must be updated accordingly to reflect the new functions; if not than I believe this commit is the key for the strange behaviour.

[NoelFB]

What should happen for Switch is:

• A is confirm, B is back/cancel
• B is Jump and A or Y for Dash

This is the behavior and prompts I see when using a Switch Pro controller on my Linux PC. If this is what's happening then yeah that's correct. If not then something is weird.

[tiagobugarin]

OK, so here is what is happening to me using a Swtch Pro controller on my Linux PC:

• A is Back/Cancel, B is Confirm
• B and X are Jump, and A and Y are Dash

[NoelFB]

Do you happen to have Steam running?

[tiagobugarin]

I do not have Steam running at the time of my tests.

And I am using Daniel Ogorchock's Joycond deamon to pair the Switch Pro controller to the PC (https://github.com/DanielOgorchock/joycond)

[NoelFB]

Hmm, I wonder if that daemon is trying to be useful by automatically remapping the buttons (since most applications will just treat it like an xbox controller, but we actually try to switch stuff around based on the Nintendo controller)? On my Linux Fedora PC my Switch Pro controller behaves normally (but it's also plugged in and not using any extra software like that).

Edit: I notice that some users of that daemon have had this happen, and their fix is something Foster (what Celeste64 uses to run) actually already does internally, which is set SDL_GAMECONTROLLER_USE_BUTTON_LABELS=0 when the game launches.

[tiagobugarin]

Interesting to learn but I don't think it is something like that. What bugs me is that only half the behaves are wrong. See, the buttons actions are correctly bound at the game but switched at the menu.

Using the SDL_GAMECONTROLLER_USE_BUTTON_LABELS=0 has no change but setting it to 1 does exactly what is expected and switches everything and makes the buttons correctly bound at the menu and switched at the game.

Even more, prior to that commit, every button was correctly bound to the opposite actions, witch works well if switched by the SDL envvar set to 1.

[tiagobugarin]

On my Linux Fedora PC my Switch Pro controller behaves normally (but it's also plugged in and not using any extra software like that).

@NoelFB, if you allow me to ask, how are your controller working without any helper like that of mine? I am running kernel 6.7.4 but when I plug the Switch Pro controller it is irresponsive.

[NoelFB]

Hmm OK my next thought is maybe my code to detect if a controller is a Switch controller is incorrect. I think this would also describe the behavior you're having.

If you're able to build the game and add this to Controls.Load(), what values does it print out:

Console.WriteLine($"{Input.Controllers[0].Name}, {Input.Controllers[0].Vendor:X}, {Input.Controllers[0].Product:X}: {Input.Controllers[0].Gamepad}");

Ideally I don't want to turn on SDL_GAMECONTROLLER_USE_BUTTON_LABELS because I do want to treat buttons as their hardware locations and be able to decide at the game end of things how to handle different controllers.

[tiagobugarin]

Soo, I figured it out!

It was not your controller detection code that was the culprit. Was, after all, joycond. It is not needed anymore but if one only stops it with systemctl stop joycond.service settings put out by the package are still in place and messes up SDL2. What was needed was to completely uninstall the package. After that the controller is working as intended both in menu and in game.

From the Gamepad entry at Arch Linux Wiki: "If you have joycond, then delete it, because it is useless for such Switch-like gamepads, moreover joycond has a udev rule that disallows Steam to provide its own user-space driver."

Closing the issue as it was not a issue at all with Celeste64 and the underlying issue is solved and explained.

[NoelFB]

Glad you were able to figure it out, and this is good to know for the future! :)