LAN021
-
Posts
14 -
Joined
-
Last visited
Content Type
Blog
Screenshot Slider
Forums
Downloads
Gallery
Calendar
Posts posted by LAN021
-
-
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.
-
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).
-
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.
-
I would also like my Wiki username changed to LAN021, as on the forum.
-
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.
-
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.
-
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).
-
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.
-
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:
QuoteUses 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?
-
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":
QuoteUses 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. -
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:
QuoteA 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.
-
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.
Field for manual switching of controller button prompts in Input
in Development
Posted
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.
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.
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?