Add support for disabling gamepad inputs in the Input class

[Raftatul]

Fixes: godotengine/godot-proposals/issues/12259

gamepad_enabled.mp4

[Calinou]

Tested locally, it works as expected.

Note that setting this at startup will not defer controller initialization, so it won't sidestep #20566 on Windows. This is not critical to address the core need mentioned in godotengine/godot-proposals#12259, but I thought I'd mention it regardless.

This PR also doesn't implement a command line argument for games that don't expose an in-game option to toggle gamepad support. As mentioned in godotengine/godot-proposals#12259 (comment), I'd like to have this as not all games will expose an option to disable gamepad support (especially smaller/gamejam projects).

Lastly, controller vibration is not disabled when gamepad support is disabled. This should be done by adding an early return to Input::start_joy_vibration() and Input::stop_joy_vibration().

[Raftatul]

Tested locally, it works as expected.

Note that setting this at startup will not defer controller initialization, so it won't sidestep #20566 on Windows. This is not critical to address the core need mentioned in godotengine/godot-proposals#12259, but I thought I'd mention it regardless.

This PR also doesn't implement a command line argument for games that don't expose an in-game option to toggle gamepad support. As mentioned in godotengine/godot-proposals#12259 (comment), I'd like to have this as not all games will expose an option to disable gamepad support (especially smaller/gamejam projects).

Lastly, controller vibration is not disabled when gamepad support is disabled. This should be done by adding an early return to Input::start_joy_vibration() and Input::stop_joy_vibration().

I’m not sure how to implement command lines yet, but I’ll look into it.

[Raftatul]

Tested locally, it works as expected.

Note that setting this at startup will not defer controller initialization, so it won't sidestep #20566 on Windows. This is not critical to address the core need mentioned in godotengine/godot-proposals#12259, but I thought I'd mention it regardless.

This PR also doesn't implement a command line argument for games that don't expose an in-game option to toggle gamepad support. As mentioned in godotengine/godot-proposals#12259 (comment), I'd like to have this as not all games will expose an option to disable gamepad support (especially smaller/gamejam projects).

Lastly, controller vibration is not disabled when gamepad support is disabled. This should be done by adding an early return to Input::start_joy_vibration() and Input::stop_joy_vibration().

Okay, I implemented the --disable-gamepad command line option and added the gamepad_enabled setting under input_devices/controller/gamepad_enabled in the project settings. I'm not sure if it's the right way to do it, though.

[MJacred]

@Raftatul: don't forget to squash your commits into 1

[AThousandShips]

There's no need to squash until the PR is ready and approved

[MJacred]

Personally, I also prefer squashing at the very end.
But then you might get an approval and merge in quick succession, before you can squash it…
And I've been told before by core maintainers to squash right away (maybe that changed over time?)

[AThousandShips]

The PR will be squashed by maintainers if needed, or it can just be squashed by the author at request by maintainers, but we allow contributors to have separate commits for their own organization, but it's up to each contributor how they want to do things

But we prefer to not ask that contributors squash before the PR is ready, to avoid unnecessary work if the PR needs further changes, or gets rejected, and that's why we wait until it is ready

But regardless it's best to leave up to maintainers to handle requesting that

[Raftatul]

• Implement gamepad_enabled in Project Settings
• Implement command line to disable gamepad inputs
• Implement gamepad_enabled in start_joy_vibration and stop_joy_vibration

[MJacred]

For consistent naming, please use joypad instead of gamepad

EDIT: and add a note that this does not stop Godot from capturing/connecting to the joypad itself. For that, you need a per-platform implementation. See this proposal for information

[Raftatul]

For consistent naming, please use joypad instead of gamepad

EDIT: and add a note that this does not stop Godot from capturing/connecting to the joypad itself. For that, you need a per-platform implementation. See this proposal for information

Should I also rename the project settings category from Controller to Joypad ?

[MJacred]

Should I also rename the project settings category from Controller to Joypad ?

That's a really good question… While the tutorial mostly uses the term Controller, the API uses Joypad. I'd say conforming to the API is more important, so changing it to Joypad is the way to go

EDIT: in the xml files, it should be does not instead of do not

[MJacred]

This should be added to the docs in ProjectSettings.xml:

To control this at runtime, use [member Input.joypad_enabled].

apart from that, LGTM

[Raftatul]

This should be added to the docs in ProjectSettings.xml:

To control this at runtime, use [member Input.joypad_enabled].

apart from that, LGTM

Done

[Raftatul]

Is this PR still relevant since #106218 ? Is there a way to disable gamepad inputs with SDL3 ?

[Mickeon]

The SDL3 integration, by itself, does not expose any new methods to the API. So it's still relevant, actually, regardless of how it's done.

[Nintorch]

Tested on Windows 11, this PR mostly works as expected, but I have some suggestions:

• I think this PR should also handle the newly added Input.set_joy_light() that changes the LED light on a controller:
  

  godot/core/input/input.cpp

  Lines 1007 to 1014 in 78c6632

  	void Input::set_joy_light(int p_device, const Color &p_color) {
  	Joypad *joypad = joy_names.getptr(p_device);
  	if (!joypad || !joypad->has_light || joypad->features == nullptr) {
  	return;
  	}
  	Color linear = p_color.srgb_to_linear();
  	joypad->features->set_joy_light(linear);
  	}

• If you use Input.is_action_pressed() to check for action presses, hold the button on your controller that activates the action and then disable the joypad input while still holding the button, the action will stay pressed.
  There's an Input method called Input::release_pressed_events(), but it will also release the non-joypad events too, so I'm not too sure if we can use it.
  I made a PR that saves the action event types ( #115099 ), maybe it's possible to use that functionality to check if an action is being pressed only because of a joypad press/axis movement, and if it is, release the action.