Field for manual switching of controller button prompts in Input

[LAN021 0]

9 hours ago, al2009man said:

It's not perfect, tho.  I'll need to figure out the way how to add "a Expand/Collapse" so I can put both Steam Deck/Controller prompts onto "Button prompt detection support" (as it's very much tied to Steam Input as a whole). also, formatting errors, as you can see on the bottom.

after that: I'll need to find a way to build a modes pages for "Steam Input Prompts Modes" (will be renamed later on), just so we can define what type of Button prompt helper the game will be using. 

That's really good so far. You don't want to use any of the suggestions from my post above? I think the tooltip for the field "Button prompt detection support" needs to be a little more thorough, see my proposed tooltip. And what about my first point, adding a field for switching controller button prompts in general to Additional information? (I think we can have it under that category instead of controller types.) Also, can't you have the Steam Input Prompts Modes in the comment, wouldn't that be enough?

An admin should also be able to help you with the issues you're having, but, according to Mr Aemony's post above, that's not their responsibility here.

Edited April 9 by LAN021

[al2009man 6]

On 4/9/2024 at 7:09 AM, LAN021 said:

That's really good so far. You don't want to use any of the suggestions from my post above? I think the tooltip for the field "Button prompt detection support" needs to be a little more thorough, see my proposed tooltip.

the idea for "[Steam Input] Button prompt detection support" (pending name) is that it'll be a dropdown where it shows you the Type of Button prompt detection system SteamInput will be using it for, similar to PlayStation Controller modes. But right now: a dedicated page document will be needed- but last I looked around: I don't think I got access to it.

In addition: this is where Steam Controller and Steam Deck prompts will be on the dropdown. (remember: it's increasingly tied towards Steamworks SDK/SteamInput, it makes sense to put it there.)

However, I am having issues getting the dropdown to work. 
 

If I can figured out how to solve this problem: there a likely chance that this idea will be temporarily dropped and will be leaving the setup be the same.

 

Quote

Also, can't you have the Steam Input Prompts Modes in the comment, wouldn't that be enough?

hence: "[Steam Input] Button prompt detection support" (pending name).

 

 

Quote

And what about my first point, adding a field for switching controller button prompts in general to Additional information? (I think we can have it under that category instead of controller types.)

I'm considering it, probably putting it under "Additional information". But it'll be reserved for later.

 

----

 

For now: I'll be taking a break from messing around. I may come back later on, with a more refreshed minds. (plus: was occupied with learning HDR Video Editing)

[LAN021 0]

8 hours ago, al2009man said:

the idea for "[Steam Input] Button prompt detection support" (pending name) is that it'll be a dropdown where it shows you the Type of Button prompt detection system SteamInput will be using it for, similar to PlayStation Controller modes. But right now: a dedicated page document will be needed- but last I looked around: I don't think I got access to it.

In addition: this is where Steam Controller and Steam Deck prompts will be on the dropdown. (remember: it's increasingly tied towards Steamworks SDK/SteamInput, it makes sense to put it there.)

However, I am having issues getting the dropdown to work. 

Isn't it enough to have separate fields instead of a dropdown? One called "Controller type button prompts" (new name to match the others) and then "Steam Deck button prompts" and "Steam Controller button prompts". Steam Deck and Steam Controller prompts are not that common, are they? (At least not Steam Controller any more.) They therefore don't need to be in the dropdown list and marked as false if button prompt detection is true. They can sometimes also be set manually whereas the controller type detection is only automatic. Either way, I think all three fields should be hidden if set to unknown.

So, in other words, I think it looks fine the way it is in your first example video. Just change the name of the button prompt detection field and update the tooltip to be more thorough and it could be added to the main template as is.

Here's my updated tooltip suggestion: "Steam Input's helper function can detect the type of controller being used and automatically show the correct prompts in the game (or the closest equivalent). Steam Input emulates XInput as normal if Steam Input API isn't used. The controller type can be changed in Steam's controller settings for certain XInput and DInput devices."

8 hours ago, al2009man said:

I'm considering it, probably putting it under "Additional information". But it'll be reserved for later.

Maybe you can start with that, see if it can be added to the main template, then continue your work with the Steam Input category.

I really like the work you're doing with this and hope you can solve the issues you're having. Maybe see if you can get help on Discord with them, if an admin cares enough to help (it's what they should do).

Edited April 12 by LAN021
Corrections/additions.

[al2009man 6]

On 4/12/2024 at 5:52 AM, LAN021 said:

Isn't it enough to have separate fields instead of a dropdown? One called "Controller type button prompts" (new name to match the others) and then "Steam Deck button prompts" and "Steam Controller button prompts". Steam Deck and Steam Controller prompts are not that common, are they? (At least not Steam Controller any more.) They therefore don't need to be in the dropdown list and marked as false if button prompt detection is true. They can sometimes also be set manually whereas the controller type detection is only automatic. Either way, I think all three fields should be hidden if set to unknown.

So, in other words, I think it looks fine the way it is in your first example video. Just change the name of the button prompt detection field and update the tooltip to be more thorough and it could be added to the main template as is.

 

ultimately decided to Dropdown that idea in favor of a Connection/Controller Models-style method.  Once again: these will be revised a bit for extra clarify. (and I might look into actually documenting that part the most.)

Right now: I only got these, and after getting the Sandbox template to go thru the main one: it now works and will be able to show the change in action.

Right now: I'm happy with the end-results, and I might be able to start with the pull request once the features I wanna implement gets finalized. (also able to fix formatting problems, yay!)

 

Quote

Maybe you can start with that, see if it can be added to the main template, then continue your work with the Steam Input category.

Done. (working name tho)

 

now I'm off to work on adding Motion Sensor information.

[LAN021 0]

On 4/14/2024 at 12:29 AM, al2009man said:

ultimately decided to Dropdown that idea in favor of a Connection/Controller Models-style method.  Once again: these will be revised a bit for extra clarify. (and I might look into actually documenting that part the most.)

Outstanding work. I see now what you mean by having modes. I would perhaps change the descriptions to be a tooltip for the text "SIAPI Buttons" and "In-Game Buttons", if that is possible. I'd also change "buttons" to "button prompts", so "SIAPI button prompts" and "In-game button prompts". So when both modes are set, you have text that says "SIAPI and in-game button prompts", with a tooltip of its own. I hope that's possible.

On 4/14/2024 at 12:29 AM, al2009man said:

Done. (working name tho)

Outstanding work again. I'd change the name to include controller, just to clarify it's for controller prompts. My suggested name, "Manual selection of controller button prompts" would work, but "Manual controller button prompt selection" works just as well.

You just need to polish the wording and grammar a little and I think it's ready for implementation. I can help with updating the editing guide and adding a new/expanded section to the Steam Input page for this.

Edited April 15 by LAN021

[al2009man 6]

13 hours ago, LAN021 said:

Outstanding work. I see now what you mean by having modes. I would perhaps change the descriptions to be a tooltip for the text "SIAPI Buttons" and "In-Game Buttons", if that is possible. I'd also change "buttons" to "button prompts", so "SIAPI button prompts" and "In-game button prompts". So when both modes are set, you have text that says "SIAPI and in-game button prompts", with a tooltip of its own. I hope that's possible.

Not needed due to the title itself telling you exactly what it's meant to do.

 

Quote

Outstanding work again. I'd change the name to include controller, just to clarify it's for controller prompts. My suggested name, "Manual selection of controller button prompts" would work, but "Manual controller button prompt selection" works just as well.

main reason is because certain games like Death Stranding and Metal Gear Solid: Master's Collection Volume 1 lets you forcefully change Keyboard/Mouse button prompts even if you use a Game Controller. Thus: it's a catch-all title.

It also accounts for certain Input devices like Wooting Keyboard or Azeron Gaming Keypad, both of which has a Analog Joystick, and having the ability to have the WASD output as a Analog Joystick (because Controller Input API Hell is a thing) and make the game only use Keyboard prompts because the game *lets* you stick to a specific Button prompt is neat for accessibility!

 

Quote

 I can help with updating the editing guide and adding a new/expanded section to the Steam Input page for this.

you're happy to handle the SteamInput Button Modes variables documentation portion if you want. I already planned to handle that part myself.

[LAN021 0]

8 hours ago, al2009man said:

Not needed due to the title itself telling you exactly what it's meant to do.

To clarify, I meant the text underneath "SIAPI Buttons, In-Game Buttons" that says "Uses In-Game button prompts while SIAPI button prompts are used as a fallback." in the first picture of the second group. That text is auto-generated when the fields are set, correct? I meant that you can change that to a tooltip (displayed on mouse hover) instead of always showing it in the comment section. It could perhaps also be added to the main tooltip for the feature. It would be a long tooltip then, but it's a feature that requires a thorough explanation. Perhaps this was unclear due to the part I quoted, but I thought that the last sentence was enough.

8 hours ago, al2009man said:

main reason is because certain games like Death Stranding and Metal Gear Solid: Master's Collection Volume 1 lets you forcefully change Keyboard/Mouse button prompts even if you use a Game Controller. Thus: it's a catch-all title.

It also accounts for certain Input devices like Wooting Keyboard or Azeron Gaming Keypad, both of which has a Analog Joystick, and having the ability to have the WASD output as a Analog Joystick (because Controller Input API Hell is a thing) and make the game only use Keyboard prompts because the game *lets* you stick to a specific Button prompt is neat for accessibility!

You need to change the name to just "prompt" instead of "button prompt" then, as "button prompts" usually refer to controller prompts. As for games that have an option to lock the prompts to one type, either controller or KB/M, regardless of input, I think noting that in the comments is enough. Otherwise, you would need to note in the comment for each game what prompts can be changed, or, alternatively, have modes there as well. Lockable prompts are relatively rare and I know of a handful of games (some Team Ninja games, some The Legend of Heroes and Ys games ported by PH3 Games), which I can set quickly if this is implemented.

8 hours ago, al2009man said:

you're happy to handle the SteamInput Button Modes variables documentation portion if you want. I already planned to handle that part myself.

Ok, I'm still willing to assist with the wording and grammar. I'll include all the details about in-game and SIAPI prompts, of course.

I would like to hear what Aemony thinks at this point. Care to post, since you are watching the thread?

[al2009man 6]

14 hours ago, LAN021 said:

To clarify, I meant the text underneath "SIAPI Buttons, In-Game Buttons" that says "Uses In-Game button prompts while SIAPI button prompts are used as a fallback." in the first picture of the second group. That text is auto-generated when the fields are set, correct? I meant that you can change that to a tooltip (displayed on mouse hover) instead of always showing it in the comment section. It could perhaps also be added to the main tooltip for the feature. It would be a long tooltip then, but it's a feature that requires a thorough explanation. Perhaps this was unclear due to the part I quoted, but I thought that the last sentence was enough.

I recently tested the tooltip/abbr setup, and it actually works. I've added it.

 

Quote

You need to change the name to just "prompt" instead of "button prompt" then, as "button prompts" usually refer to controller prompts. 

that's been changed.

 

Quote

 

Ok, I'm still willing to assist with the wording and grammar. I'll include all the details about in-game and SIAPI prompts, of course.

I would like to hear what Aemony thinks at this point. Care to post, since you are watching the thread?

 

going forward: further discussion when it comes to merging should be moved to https://www.pcgamingwiki.com/wiki/Topic:Y2zpdr3b199gx303, 

[al2009man 6]

sorry for the long-winded two weeks wait. I've been busy.

Been in the polishing and editorial phases for a while. A lot of changes was made since then, like a ton of abbreviates changes (mouse hover) and added more stuffs (such as Keyboard/Mouse and Controller prompts section).

but to remained on-topic: the original name for "Manual controller button prompt selection" is now changed to "Input Prompt Override" based on community feedback over at PCGW discord server, and I like the name better. Going forward: this will become the official name. This also applies to "Steam Input prompt modes", as it also got a new name!

In addition: I added the documentation regarding "Steam Input prompt modes". I opted to go for a "hey, before you use those values: here's how you can properly test and verify them!" for this one. Don't expect a image highlight until I learned how to insert images. :P

Thus: everything is now officially locked in and further changes will not be needed (if needed: it'll be reserved for the Nintendo Controller Type update after merge request is finished, or a mod request that ask for assistence), it is now ready to be officially reviewed, be verified and be merged to the main Input section.  

I can't guarantee how long it'll take (due to the magnitude of changes)...but if it's anything like PlayStation Controller upgrade: it might take...time.

[LAN021 0]

I have given this some more thought and have come to the conclusion that setting the Steam Input API field to limited really is the best and simplest way to show that games use the Steam Input API's helper function only for button prompt display. Games that have SIAPI set to true and limited will consequently both appear on the auto-generated list of games and it will be easy to see which ones have full SIAPI support and which ones only use it for button prompt display. I have updated my post and made some other changes as well, I hope al2009man and Aemony--and hopefully some other admin--can have a look. The suggestions are now essentially finished and are exactly as I would implement them.

My changes differ from al2009man's in two regards:

1. Manual selection of controller button prompts, my proposed field, should only be for controller button prompts, as the name implies. There are so few games that have in-game options for locking the prompts to KB/M that this can easily be put in the notes.
2. Prompts provided by Steam for games that have SIAPI support should also be put in the notes. According to the list on Google docs, only 19 games use this, which are so few that you don't need a specific value for this. If a game only uses SIAPI prompts, which most do, it already has a consistent style for the prompts in the game and I don't know if that even needs to be noted. The few games that use both in-game and SIAPI prompts can have this noted in the comments (Alien Hominid HD, Alien Hominid Invasion, Crypt of the NecroDancer, No Man's Sky and Prey). Finally, many of the games that use SIAPI prompts are Valve's own games.

I also think a new prompt type for Steam Deck should be added and be listed under Generic/Other.

I don't know anything about al2009man's other suggestions, of course, this is only for manual selection of button prompts and SIAPI button prompt display.

EDIT Jul 28 2024: It's perfectly fine to have a separate field for button prompt display as well, of course. I'll post my updated text for the Steam page and the tooltips for the proposed fields below. As I said before, I can update the editing guide (I would also need to clarify some things about controller support via Steam) and even write the update in the changelog if I'm allowed.

Quote

Button prompts (Steam page, under Steam Input API)

Games that use Steam Input API can automatically display button prompts that match the type of the controller being used, or, as an alternative, the type that is the closest equivalent (e.g. DualShock 4 prompts instead of DualSense prompts). Games can use both their own internal button prompt assets and the ones provided by Steam, the latter either as a fallback in case of missing button prompt assets for a specific type of controller or as a full replacement of the game's own assets. PlayStation controller support with DualShock 4 and/or DualSense button prompts is common, while Nintendo Switch Pro Controller support is rarer. The controller type can be set manually for certain third-party controllers.

This feature also works for standard Steam Input profiles, i.e. ones that emulate XInput and/or keyboard/mouse input. Games that do not have full Steam Input API support can still make use of this feature to display button prompts from their own assets.

Games that use Steam Input API in this manner are marked as having limited support on game pages.

Alt for separate fields:

Games that use Steam Input API in this manner have the field "Steam Input API" set to false, but the field "Button prompt display helper function" set to true.

Steam Input API tooltip (one field)

The game uses Steam Input API. If set to true, the game has action-based remapping via the Steam Input API profile found in the game's controller settings (the actual implementation varies from game to game). Button prompts can also be displayed for different controller types automatically (e.g. DualShock 4, DualSense and Nintendo Switch Pro Controller). If set to limited, the game only uses Steam Input API for the button prompt display helper function when a standard Steam Input profile is selected (i.e. one that emulates XInput and/or keyboard/mouse input). The type of button prompts that are supported are shown in the Controller section.

Button prompt display helper function tooltip (separate field)

The game can display non-Xbox controller button prompts that match the type of the controller that is used through Steam Input, or, alternatively, the type that is the closest equivalent (e.g. DualShock 4 prompts instead of DualSense prompts). This feature does not require full Steam Input API support; it also works with standard Steam Input profiles. The supported types of button prompts are shown in the Controller section above. Native support for the controller type is not required.

Steam Input API tooltip (separate field)

The game uses Steam Input API. If implemented correctly, it has action-based remapping via the Steam Input API profile found in the game's controller settings.

 

Edited July 29 by LAN021

[al2009man 6]

2 years later: Input Prompt Override and Steam Input Prompt modes (including Steam Deck prompts row) are rolling out to PCGamingWiki articles as we speak!

I've been slowly updating some of the articles to use the new Input template, you might start seeing them on the Additional Info and Steam Input row.

[Kobi Blade 3]

PCGamingWiki often lists certain games as having “Full Controller Support” when, in reality, these games do not offer native controller support. Instead, they rely entirely on the Steam Input API to function with controllers. This distinction is crucial for users who may be misled into believing that their controllers will work seamlessly with these games out of the box.

The Steam Input API is not a substitute for native controller support. Games that depend solely on the Steam Input API may require additional configuration and do not provide the same level of integration and performance as those with built-in support.

I can confirm this behavior with Xinput Controllers where they become somewhat erratic, fail to load custom presets from Xbox Accessories, and suffer from severe input latency compared to native Xinput support.

[al2009man 6]

8 hours ago, Kobi Blade said:

PCGamingWiki often lists certain games as having “Full Controller Support” when, in reality, these games do not offer native controller support. Instead, they rely entirely on the Steam Input API to function with controllers. This distinction is crucial for users who may be misled into believing that their controllers will work seamlessly with these games out of the box.

the way how "Full Controller Support" is handled is entirely based on whenever or not Menu Navigation, Configuration tool and Third-Party launchers (Ubisoft Connected, Rockstar Launcher, EA Play) be fully navigatable with a Game Controller.  It's actually consistent with how Valve defines general Controller Support.

and since Steam Deck, that specific field has became far more important to the Steam Deck Verified status than anything.

key example: Baldur's Gate 3 originally claimed to have "Full Controller Support", but launching the game will open up Larian Launcher instead and cannot be navigated with a game controller unless the end-player use a launch command to skip the launcher. In addition: launching it via Steam Big Picture mode still opens the Larian launcher (but not on Steam Deck...?). This is unlike recent Nixxes Software ports (such as Ghost of Tsushima: Director's Cut) where the Configuration launcher does get skipped over if launched via Steam Big Picture Mode.

I forwared that feedback via the Discord servers pointing out the description, but since October 7th, 2024: both the description and the dropdown tooltip has been updated to clarify on what that field is meant to be used for.

 

Quote

The Steam Input API is not a substitute for native controller support. Games that depend solely on the Steam Input API may require additional configuration and do not provide the same level of integration and performance as those with built-in support.

In these cases: you can set Controller Support field to "always on" and specify the reasons. There are some exceptions, like Horizon Zero Dawn - Complete Edition depends on Steam Input API, but it only applies on Steam version and not GOG/Epic Games Store versions.

[Kobi Blade 3]

1 hour ago, al2009man said:

the way how "Full Controller Support" is handled is entirely based on whenever or not Menu Navigation, Configuration tool and Third-Party launchers (Ubisoft Connected, Rockstar Launcher, EA Play) be fully navigatable with a Game Controller.  It's actually consistent with how Valve defines general Controller Support.

and since Steam Deck, that specific field has became far more important to the Steam Deck Verified status than anything.

key example: Baldur's Gate 3 originally claimed to have "Full Controller Support", but launching the game will open up Larian Launcher instead and cannot be navigated with a game controller unless the end-player use a launch command to skip the launcher. In addition: launching it via Steam Big Picture mode still opens the Larian launcher (but not on Steam Deck...?). This is unlike recent Nixxes Software ports (such as Ghost of Tsushima: Director's Cut) where the Configuration launcher does get skipped over if launched via Steam Big Picture Mode.

I forwared that feedback via the Discord servers pointing out the description, but since October 7th, 2024: both the description and the dropdown tooltip has been updated to clarify on what that field is meant to be used for.

 

In these cases: you can set Controller Support field to "always on" and specify the reasons. There are some exceptions, like Horizon Zero Dawn - Complete Edition depends on Steam Input API, but it only applies on Steam version and not GOG/Epic Games Store versions.

As I already stated, while the Steam Input API provides a versatile solution for controller compatibility, it does not equate to native controller support.

Full Controller Support designation should be reserved exclusively for games that inherently support controllers without the need for third-party software or extensive configuration.

The Steam Input API counts as third-party software, since the Controller Support is coming from Steam itself and does not function if you disable the Steam hook (overlay).

PCGamingWiki has Game Pages, not Steam Pages, so claiming a game that relies on the Steam Input API as having Full Controller Support is beyond misleading.

[al2009man 6]

30 minutes ago, Kobi Blade said:

PCGamingWiki has Game Pages, not Steam Pages, so claiming a game that relies on the Steam Input API as having Full Controller Support is beyond misleading.

Given the intended purpose of "Full Controller Support" is meant for external game launchers outside of Steam client, and Configuration tools (example: Unity config launcher for older Unity-based titles like...YIIK: A Postmodern RPG) that can't be navigatetd with a Game Controller (not counting recent Proton versions that relies on Xalia for specific games) , I believe making Steam Input API usage be apart of the Full Controller Support as opposed to being a "Controller Type" wouldn't worked out.

if I consider that logic: setting "Full Controller Support" because it only has PlayStation Controller support or DirectInput Controller support and not XInput-compatible controllers could also hypothetically be "beyond misleading", and it something like this has happened before (see: No More Heroes 1 and 2's PC port). However: I do understand Steam Input API baked-in scenarion has happened, but that why I use Controller Support field for it.

I consider Steam Input API to be it's own Controller Type in the same veins as PlayStation, Xbox, Nintendo (soon!) Generic/Other Controllers types...given former PCGW developers once said that they're leaning towards the direction of Controller Types, i'm more or less respecting that wishes.

In reality: it's a fundamentals misunderstanding on how both PCGamingWiki and Valve considers and treats "Full Controller Support", as it's focused far more around Home Theater PC and PC Handheld configurations than "does this game supports my Nintendo Switch controller".

So: changing the name of "Full Controller Support" to something that actually fits the intended purpose 'might' require internal discussions between PCGW Staff/Editors/Developers on how to best move forward.

side-note: you might wanna create a new thread about that. This thread is about manually changing button prompts, afterall.