As a normal end-user / gamer - I dont think you get a lot out from knowing which resource created the keybind. Only the description seems interesting.
So my suggestion is simply, that the resource name is hidden, unless you are on canary.
Alternatively, in the RegisterKeyMapping native add a parameter which tells whether or not resource name should be shown. But that, I guess, seems like unnecessary complication.
The resource name is relevant as it is related to persistence: the binds will persist based on the resource name, even on different servers, so as a âend userâ it is in fact relevant information.
Iâm rather wondering what use case there is for hiding it at all- do people actually get confused here or is this just a nitpick?
(mainly as Iâm actually expecting user confusion if âshowing/hidingâ is somehow tied to an arbitrary toggle like canary - as then itâs suddenly inconsistent!)
From my experience, itâs just not as convenient for the eye to look for a certain keybinding on a long list thatâs alphabetically ordered when the actual beginning of each string is not the word used for sorting (does this even make sense? idk, itâs late)
Maybe switching â(resource name) Descriptionâ to âDescription (resource name)â makes it more convenient to find the wanted key bind in a longer list.
(Other than that I donât see any reason to hide this information.)
This was the case originally until tweak(input/five): formatting for key binding settings ¡ citizenfx/fivem@3bd1596 ¡ GitHub likely as people put âweirdâ formatting characters in their key binding name in an attempt to try to hide the resource name, which would be an unintended implementation detail that already got resource developers confused at the time.
Putting the name at the end would require covering all possible invalid characters for a Scaleform text string and this is not a known/defined set.
Oh this makes sense then. As I regularly play FiveM on different servers this was just one thing that got me âconfusedâ sometimes as this makes it a little bit harder to go through that list (from a visual perspective).
But I guess the thing mentioned by you def. has higher priority.
How about instead take the âresource nameâ part, and move it to a new column furthest to the right then?
So you have:
Action/Description | Primary | Secondary | Resource
My âproblemâ is that it quickly becomes fuzzy and loses user-friendliness with current state. Typically the user doesnt care about which resource created the bind (or the name of it) - but only what it does.