Field for manual switching of controller button prompts in Input

[LAN021 0]

Hey, has anybody thought about adding a feature/field to the input infobox for manual switching of controller button prompts, under additional? It could be called "Manual Controller Button Prompt Switching" (or "Manual Switching of Controller Button Prompts") and the tooltip could read "The controller button prompts can be changed manually in the game's settings, regardless of the type of controller used."

This feature was included in many 2022 games, like Death Stranding DC, Tiny Tina's Wonderlands, Ghostwire, Elex 2, Monster Hunter Rise, Stranger of Paradise, Rogue Legacy 2 and probably a few others, too. It's becoming more common and may be deserving of its own field. It could probably be hidden if not set since it has only really been included in 8th/9th gen games and a select few 7th gen games (mostly had to rely on mods for those). I use a third-party PS3 controller myself and always look for this feature in newly released games. It's also great for people who actually use Steam Input's controller configuration with their DS4's and want DS4 icons (if the game doesn't have that Steam auto-assignment function).

A related change that may be needed as well is for the sub-fields of the controller types, such as icons, to be visible even if the main field is set to False. There are a few games that have DualShock 4/Switch icons without actually having native support for those controllers (mostly Switch). So if one or more sub-field is set to true and the main field is set to false, the expandible sub-fields are still visible.

[dinaallred 0]

On 6/15/2022 at 12:48 AM, LAN021 said:

Hey, has anybody thought about adding a feature/field to the input infobox for manual switching of controller button prompts, under additional? It could be called "Manual Controller Button Prompt Switching" (or "Manual Switching of Controller Button Prompts") and the tooltip could read "The controller button prompts can be changed manually in the game's settings, regardless of the type of controller used."

This feature was included in many 2022 games, like Death Stranding DC, Tiny Tina's Wonderlands, Ghostwire, Elex 2, Monster Hunter Rise, Stranger of Paradise, Rogue Legacy 2 and probably a few others, too. It's becoming more common and may be deserving of its own field. It could probably be hidden if not set since it has only really been included in 8th/9th gen games and a select few 7th gen games (mostly had to rely on mods for those). I use a third-party PS3 controller myself and always look for this feature in newly released games. It's also great for people who actually use Steam Input's controller configuration with their DS4's and want DS4 icons (if the game doesn't have that Steam auto-assignment function). mapquest driving directions

A related change that may be needed as well is for the sub-fields of the controller types, such as icons, to be visible even if the main field is set to False. There are a few games that have DualShock 4/Switch icons without actually having native support for those controllers (mostly Switch). So if one or more sub-field is set to true and the main field is set to false, the expandible sub-fields are still visible.

I second this suggestion.

[LAN021 0]

An updated suggestion half a year later. I don't know if the admins didn't think this was worth having or they simply didn't see it (probably the former).

I think my second suggestion is worth having on the site, as I've noticed that controller support is often set to true, even though the games don't support the controllers (DualShock 4/DualSense/Switch Pro Controller) natively and instead rely on Steam Input or a wrapper. The editing guide even says that it should be limited in that case. I think it should simply be false, but the controller prompts should still be visible if the game has it somehow (Control, for instance). The old button prompt field is deprecated, as far as I know, since it's not even in the guide or the template anymore (but still works and sometimes shows duplicate prompts). Simply allow the prompts fields to be visible if set to true, even if main controller type is set to false, as I wrote here:

Quote

A related change that may be needed as well is for the sub-fields of the controller types, such as icons, to be visible even if the main field is set to False. There are a few games that have DualShock 4/Switch icons without actually having native support for those controllers (mostly Switch). So if one or more sub-field is set to true and the main field is set to false, the expandible sub-fields are still visible.

In that case, the other fields should probably be hidden if they are set to false and the main field is as well. Only the prompts field should be visible. I suppose you could program it so that the prompts fields are moved to their own row instead of being sub-fields to the main field. It could even be a new field altogether.

Another related change that I think should be added is a field in the Steam Input section for controller type detection and button prompt display. This is in practically every Sega-published game with controller support and was recently in Crisis Core and Sackboy, for instance. Some info about this could, of course, also be added to the Steam page on the site. I could try to write it myself if the admins allow it. The field could be called "Button prompts for controller type" and the tooltip could read "The game can detect which controller type is being used in Steam Input and show the corresponding button prompts in-game." I suppose one could also add this information to the Steam Input API field with it set to false and the note that it is only for showing button prompts, but I'd like a separate field myself.

[LAN021 0]

Bumping this again in the hopes that an admin, or at least a senior editor, can show enough interest to comment. I have no interest in getting on Discord to get into a potentially contentious discussion with an admin or senior editor, if they really are unwilling to accept suggestions from outside their inner circle. I'd rather post the suggestions in full here to get comments. These are objective improvements I'm suggesting, not something of debatable or minor use. I have written featured articles on Wikipedia and contributed to some templates there, so I know how the process goes.

There are two new fields I think should be added and one change to the Input box made. I'm posting them in full as they would appear on the site.

1. Manual selection of [break] controller button prompts
Where: Bottom of "Controller types" category under the Input box. Could also be in the "Additional information" category, at the bottom. Should be hidden if not set or set to unknown.
Tooltip Desc: The game has an in-game option for manually selecting the controller button prompts.

2. Button prompts for [break] controller type
Where: Below "Steam Controller button prompts" field in "Steam Input" category under the Input box. Should be hidden if not set or set to unknown. This is Steam Input's helper function.
Tooltip Desc: 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.

3. Make it possible to see the expandible fields for "XInput-compatible controllers", "DualShock 4 controllers" and "Generic/other controllers" even if they are set to false, if the prompts below are set to true.
This is needed for games that have options to change prompts without supporting any other controllers than XInput.

These kind of options are common enough now to warrant their own fields. Just have a look at the four popular games under the search field. Three of those have manual selection of button prompts (Resident Evil 4, TLOU and Dead Space) and I think that Hogwarts Legacy uses Steam Input's helper function for correct prompt display (suggestion #2). Two recently released games also have manual selection of button prompts (Front Mission and Ghost Trick). You could add this info manually to the fields' descriptions, but you then have to repeat it in every button prompt field, so simply having a separate field is preferable.

Manual selection of button prompts can be seen in setting images and added in the fields' descriptions, but there is no real way of knowing if a game uses Steam Input's helper function for prompt display. I've only ever seen this in one game, No Man's Sky, which has it under "Steam Controller button prompts":

Quote

Uses Steam Input API's Button prompt detection for both In-Game and Steam's built-in Button prompts, based on Controller Type.

This feature is also in enough games to warrant its own field, it's much more common than Steam Input API, for instance. If added, I know of a few games that have this feature and could add it quickly. It's in most games published by Sega and a few by Sony, also in at least Hades, Ender Lilies and Crash Bandicoot N. Sane Trilogy, from the top of my head. Setting the "Steam Input API" field to true for this feature, which I've seen on numerous articles, is quite misleading as Steam Input API should only be for the actual remapping features, not the prompt display feature, which is a separate feature. Steam Input still uses XInput for that helper function, not Steam Input API. It's also easy to check if a game supports this feature by looking at the Controller tab in the game's properties. Here's a comparison between two games, one that has the Steam Input helper function (Persona 4 Golden, right) and one that doesn't (Bloodstained, left).   Well, I hope I can at least get an admin to comment this time. I spent some time writing this and there is absolutely no reason to not have these fields on the site.

Edited Friday at 10:00 AM by LAN021
Corrections/small additions.

[LAN021 0]

It's certainly a little bit frustrating how not a single moderator bothered to comment with a single line saying that these updates aren't necessary or something similar.

Anyway, since nobody wants these features added, could you at least make a change or allow something for the Steam Input API field?

Concering this:

Quote

Uses Steam Input API's Button prompt detection for both In-Game and Steam's built-in Button prompts, based on Controller Type.

[...]

Setting the "Steam Input API" field to true for this feature, which I've seen on numerous articles, is quite misleading as Steam Input API should only be for the actual remapping features, not the prompt display feature, which is a separate feature.

Would it be ok to set Steam Input API to limited then add a note saying it's for button prompt display only? Could this perhaps be added to the editing guide or tooltip? I don't think the Steam Controller Button Prompts field should be used for this either. There definitely should be a way to display this as it's important information. You need to be able to distinguish between full Steam Input API support (action-based remapping) and just the button prompt display.

And, of course, three games in the list of recently released games have manual selection of controller prompts (Alan Wake 2, Ghostrunner 2 and Metal Gear Solid Master Collection). How common does this feature need to be before it's accepted to have its own field?

[LAN021 0]

I just have to post again to point out that, yesterday, there were no less than five games in the list of recently released and upcoming games with manual selection of controller prompts: Alan Wake 2 (called "Controller Icons"), Ghostrunner 2 ("Controller Platform"), The Invincible ("Select the Controller"), My Time at Sandrock ("Controller Type") and The Talos Principle 2 ("Controller Hardware").  Alan Wake 2 and Ghostrunner 2 were just removed from that list.

I also think that Star Ocean: The Second Story R, Like a Dragon Gaiden: The Man Who Erased His Name, Call of Duty: Modern Warfare III and Salt and Sacrifice (new to Steam) use Steam Input's helper function for button prompt display that matches the connected device.

I'm also pretty sure that Persona 5 Tactica will have one of the two, since it's a Sega-published game.

So the evidence that these features are common enough to get their own fields are certainly hard to ignore at this point (or Steam Input API set to limited for Steam Input's helper function, with an updated tooltip to reflect this).

Anyway, I won't push this beyond this post since this has been entirely ignored, but this certainly warrants consideration, at the very least.

 

[rowenarobel 0]

Any update?

[LAN021 0]

3 hours ago, rowenarobel said:

Any update?

Not that I know of, this has been entirely ignored so either the adminship don't care for the suggestions, don't care for me or both.

Still features worth having, especially for Steam Input's button prompt helper function, since that is something that is not possible to learn from looking at screenshots of the settings, or, in fact, any other way than buying the game and testing it. Players being able to get the prompts they want in games is relevant enough information to warrant inclusion on the Wiki, as is seen by the myriad of threads on game forums on Steam, where players are requesting this feature (manual selection) or asking about how to get PlayStation prompts (with the answer usually being that they have to turn off Steam Input if the game doesn't have either of the aforementioned features). On Dead Cells' forums alone, there had been at least 10 threads asking for this and the developers finally relented--after five years of players begging for it--and added the option to select prompts manually (it's still in beta).

[al2009man 5]

On 10/23/2023 at 7:49 PM, LAN021 said:

It's certainly a little bit frustrating how not a single moderator bothered to comment with a single line saying that these updates aren't necessary or something similar.

Anyway, since nobody wants these features added, could you at least make a change or allow something for the Steam Input API field?

Concering this:

Would it be ok to set Steam Input API to limited then add a note saying it's for button prompt display only? Could this perhaps be added to the editing guide or tooltip? I don't think the Steam Controller Button Prompts field should be used for this either. There definitely should be a way to display this as it's important information. You need to be able to distinguish between full Steam Input API support (action-based remapping) and just the button prompt display.

And, of course, three games in the list of recently released games have manual selection of controller prompts (Alan Wake 2, Ghostrunner 2 and Metal Gear Solid Master Collection). How common does this feature need to be before it's accepted to have its own field?

Hi. I'm the person who wrote that part for No Man's Sky and others that uses Steam Input API to handle button prompt detection, either from Steam Input API directly or provided by the developers.

Personally: I think "Steam Controller button prompts" should be revised. as that toggle, was originally meant for Steam Controller API, was superseded by Steam Input API after DualShock 4 support being added to Steam Controller API while getting a rebrand.

Ideally: the Steam Controller and Steam Deck button prompt should just be moved as part of it's own Controller Type section; alongside XInput and PlayStation Controller Type. Since then: SDL2/SDL3/Linux *technically* have full support for Steam Controller, in addition of Steam Virtual Gamepad (You can see it in action on VVVVVV) and soon: SDL Action Set.

As for button prompts: Given selected Valve games relies on SIAPI's built-in button prompts: I argued it make sense to only mention "it uses SIAPI's built-in button prompts [you'll see on Big Picture Mode/Steam Deck]" given it'll automatically give you Steam Controller-specific button prompts like Touchpads while everything else is just..."Shared Button prompts". It's redundante to say "it support Steam Controller button prompts" that way.

remember: SIAPI Button prompts has become more about modularity after the release of Steam Deck.

Thus: I'll suggest the old "Steam Controller button prompts" should be turned into "Steam Input Button Prompts", it should come with it's own Expand field that will let users inform what type of Button prompt detection does Steam Input will be using.

Will the API be relying on the button prompts provided by Steam Client? (selected Valve games, Teardown, Spin Rhythm XD) Will the API be relying on the dev-provided prompts? (most of Nixxes Software ports that uses SIAPI), will it use both? (Prey 2017, Crypt of the NecroDancer) or will it rely on the SteamInput's helper functionality to tell the game "you know what? let me handle your Button prompt detection instead"? (Like A Dragon series, selected Persona games, Hades, Hogwarts Legacy). 

Basically: there's three methods of handling SteamInput's button prompt systems.

 

[LAN021 0]

13 hours ago, al2009man said:

Will the API be relying on the button prompts provided by Steam Client? (selected Valve games, Teardown, Spin Rhythm XD) Will the API be relying on the dev-provided prompts? (most of Nixxes Software ports that uses SIAPI), will it use both? (Prey 2017, Crypt of the NecroDancer) or will it rely on the SteamInput's helper functionality to tell the game "you know what? let me handle your Button prompt detection instead"? (Like A Dragon series, selected Persona games, Hades, Hogwarts Legacy). 

Basically: there's three methods of handling SteamInput's button prompt systems.

Hey, al2009man and thank you for the very informative post, as always. I doubt anybody here cares enough about this issue to address this, however. This post has been entirely ignored by the adminship and I even suspect it's on purpose. I personally have no interest in being active in or contributing to a community where the admins can not show the basic courtesy to comment on an issue after someone has spent time writing a well-founded and well-argued post, even if they disagree with the proposal. So I'll leave this to you.

My proposal was to have the third thing you mentioned be marked by having the main Steam Input API field set to limited. The tooltip would then be changed to say that if it's set to true, the game has full action-based remapping through Steam Input API (with details in the comment) and if it's set to limited, it uses normal XInput emulation with button prompt display (the types are shown above in the controller field). That would be added useful information for players, which the admins here seem to not care much for. The first two things could also be noted in the comments.

[al2009man 5]

3 hours ago, LAN021 said:

Hey, al2009man and thank you for the very informative post, as always. I doubt anybody here cares enough about this issue to address this, however. This post has been entirely ignored by the adminship and I even suspect it's on purpose. I personally have no interest in being active in or contributing to a community where the admins can not show the basic courtesy to comment on an issue after someone has spent time writing a well-founded and well-argued post, even if they disagree with the proposal. So I'll leave this to you.

My proposal was to have the third thing you mentioned be marked by having the main Steam Input API field set to limited. The tooltip would then be changed to say that if it's set to true, the game has full action-based remapping through Steam Input API (with details in the comment) and if it's set to limited, it uses normal XInput emulation with button prompt display (the types are shown above in the controller field). That would be added useful information for players, which the admins here seem to not care much for. The first two things could also be noted in the comments.

you know, I sorta recall suggesting the idea elsewhere on making a entirely new website dedicated to PC Gaming Controller Support, using SteamDB's Controller Support tag as a basis-- but anyone can contribute to it. This becomes important when more games are getting either Steam Input API Support or even Gyro Aiming supoprt.

and after Valve overhauled the Controller Support tag, I really wanna commit to that idea-- but don't have the ability to do so.

[Aemony 141]

21 hours ago, LAN021 said:

I doubt anybody here cares enough about this issue to address this, however.

Hi,

It's more that nobody has noticed / put much thought to this suggestion since nobody is actively monitoring the forum except for filtering out spam posts and approve uploaded files. I highly recommend joining the Discord server where the main community resides as any proposals or comments are 1000 times more likely to get a response there, than in this thread.

We are nowadays heavily dependent on the community implementing the necessary changes in a test template, and fixing all of the bugs and whatnot, before we can move it into the main namespace. As with everything else related to PCGamingWiki, all of us are unpaid volunteers and contribute on our own free time if possible, and most of us has families or other responsibilities nowadays that take the focus.

Anyway, the input template can be found here: https://www.pcgamingwiki.com/wiki/Template:Input . Everyone can hit View Source on it and then copy the template text to their own user subpage (e.g. User:Aemony/Sandbox in my case) and then invoke and start testing it on a game article by replacing the existing "{{Input" call with using "{{User:xxx/Sandbox" instead.

You can see how for example the user Henrebotha implemented their suggested/desired "digital movement supported" parameter on ther user page, https://www.pcgamingwiki.com/wiki/User:Henrebotha/Sandbox/Template:Input, which was then later merged by me into the main template a few months later.

Regarding this suggestion, or a larger revamp of the button prompt related parameters, I doubt people are necessarily against the idea but as hinted at earlier it requires someone from the community to actually take charge and implement and properly test the necessary changes.

 

21 hours ago, LAN021 said:

My proposal was to have the third thing you mentioned be marked by having the main Steam Input API field set to limited. The tooltip would then be changed to say that if it's set to true, the game has full action-based remapping through Steam Input API (with details in the comment) and if it's set to limited, it uses normal XInput emulation with button prompt display (the types are shown above in the controller field).

That sort of differentiation is not necessary. The existing "steam input api" parameter in the input template is used to indicate actual support for the Steam Input API (regardless of how button prompts are handled). The secondary "steam hook input" parameter is used to indicate if Steam can work in its legacy mode where it hooks input and makes use of XInput and/or regular mouse/keyboard input.

A game that relies on Steam Input's legacy mode (aka the basic "Steam Input" functionality, without the "API" part of it) should not have that parameter set to anything but false, basically.

[LAN021 0]

On 4/8/2024 at 5:37 PM, Aemony said:

Hi,

It's more that nobody has noticed / put much thought to this suggestion since nobody is actively monitoring the forum except for filtering out spam posts and approve uploaded files. I highly recommend joining the Discord server where the main community resides as any proposals or comments are 1000 times more likely to get a response there, than in this thread.

We are nowadays heavily dependent on the community implementing the necessary changes in a test template, and fixing all of the bugs and whatnot, before we can move it into the main namespace. As with everything else related to PCGamingWiki, all of us are unpaid volunteers and contribute on our own free time if possible, and most of us has families or other responsibilities nowadays that take the focus.

I have mentioned this on Discord, perhaps two times, but am not going to post this entire write-up there and try to grab an admin's attention, as you may understand. Your community is not very inviting for newcomers. I also find it hard to believe that no one has noticed this thread for one year and nine months, so your copy-pasted excuses and explanations are rather disingenuous. If you don't like the idea, simply say so--no need for dissimulation. You have posted on the forum yourself many times since June 2022, so you have seen my posts and neglected to comment, until al2009man posted in support (with modifications) as well, which must have given the ideas some sort of legitimacy in your eyes, since al2009man usually writes high-quality comments. I emphasize that you (or any other admin) didn't have to write anything extensive, a simple comment in acknowledgement of the suggestion would have been enough. It's not hard to share it with other admins through Discord, either, to just make them aware of it.

I am not going to go through the steps you outlined, as I have no knowledge of that particular thing. The suggestions in my post above cover everything already, there is absolutely nothing any personal testing from my side would be able to accomplish. That could have been tested by the admins, had they cared enough to comment. How would I be able to fix bugs myself when I am not knowledgeable about this? Why do you even accept proposals if you tell contributors to fix it themselves? If admins need something like that as proof that something is worth implementing, they should just stop with community contributions entirely, outside of the admin circle. What I proposed was also just two new fields, not a revamp of existing fields, except a small change for the third point, which I am not able to test myself in any way.

On 4/8/2024 at 5:37 PM, Aemony said:

That sort of differentiation is not necessary. The existing "steam input api" parameter in the input template is used to indicate actual support for the Steam Input API (regardless of how button prompts are handled). The secondary "steam hook input" parameter is used to indicate if Steam can work in its legacy mode where it hooks input and makes use of XInput and/or regular mouse/keyboard input.

A game that relies on Steam Input's legacy mode (aka the basic "Steam Input" functionality, without the "API" part of it) should not have that parameter set to anything but false, basically.

The distinction is necessary since it conveys discrete information. Wiki's are made for such things, if you can believe that, same as with repeating a name in the publisher field if a game is published by its developer or its publishing arm--it's not what someone thinks that it is or how they feel that it looks, it's simply useful information worth having for visitors.

As I wrote before, there are also editors who set the Steam Input API field to true even when it's only for button prompt display.

On 7/1/2023 at 6:28 PM, LAN021 said:

This feature is also in enough games to warrant its own field, it's much more common than Steam Input API, for instance. If added, I know of a few games that have this feature and could add it quickly. It's in most games published by Sega and a few by Sony, also in at least Hades, Ender Lilies and Crash Bandicoot N. Sane Trilogy, from the top of my head. Setting the "Steam Input API" field to true for this feature, which I've seen on numerous articles, is quite misleading as Steam Input API should only be for the actual remapping features, not the prompt display feature, which is a separate feature.

I suggested having the SIAPI set to limited for prompts only as an alternative to adding a field, which is still my ideal solution. It was simply something I suggested as a secondary solution, which you can see if you read the thread, since no one had commented on what I had written before. I also see no issue with having it set to limited, if there is a clear explanation of what that means (in the tooltip and guide), same as controllers being able to be set to limited if they have support only through Steam Input (which is almost all controllers) and being marked as such in Steam.

There are three modes, with additional variations outlined by al2009man above:

• Steam Input API with action-based remapping (it's not always action-based because of faulty implementation).
• XInput emulation.
• XInput emulation + button prompt display. It is the button prompt display that is not visible on the Wiki in any way.

Thank you for taking the time to comment after one year and nine months, at least.

Edited April 10 by LAN021

[al2009man 5]

7 hours ago, Aemony said:

Hi,

It's more that nobody has noticed / put much thought to this suggestion since nobody is actively monitoring the forum except for filtering out spam posts and approve uploaded files. I highly recommend joining the Discord server where the main community resides as any proposals or comments are 1000 times more likely to get a response there, than in this thread.

We are nowadays heavily dependent on the community implementing the necessary changes in a test template, and fixing all of the bugs and whatnot, before we can move it into the main namespace. As with everything else related to PCGamingWiki, all of us are unpaid volunteers and contribute on our own free time if possible, and most of us has families or other responsibilities nowadays that take the focus.

Anyway, the input template can be found here: https://www.pcgamingwiki.com/wiki/Template:Input . Everyone can hit View Source on it and then copy the template text to their own user subpage (e.g. User:Aemony/Sandbox in my case) and then invoke and start testing it on a game article by replacing the existing "{{Input" call with using "{{User:xxx/Sandbox" instead.

You can see how for example the user Henrebotha implemented their suggested/desired "digital movement supported" parameter on ther user page, https://www.pcgamingwiki.com/wiki/User:Henrebotha/Sandbox/Template:Input, which was then later merged by me into the main template a few months later.

Regarding this suggestion, or a larger revamp of the button prompt related parameters, I doubt people are necessarily against the idea but as hinted at earlier it requires someone from the community to actually take charge and implement and properly test the necessary changes.

If that's going to be the case: then I shall look into it.

Heck, it might give me an opportunity to expand "Tracked motion sensor" or add a "Gamepad Motion Sensors" setup there.

 

edit: created a sandbox template page, took me an while to get everything setup. Here's a sandbox page for anyone to view. Do note that I haven't started working on replacing Steam Controller prompt naming scheme *yet*

Edited April 8 by al2009man
Updated sandbox link. turns out: I'm suppose to type "User:AL2009man" and not just "AL2009man".

[al2009man 5]

Spend some time learning how Input Page templates works (and a lot of troubleshooting), and I think I've able to get it working the way how it is.
 

 

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.