RFC: Overlay injection rule spec

[mkrautz]

This is a proposal for an internal syntax for overlay exceptions.

My thinking is that we convert the current radio buttons in the client to a dropdown, containing:

• Blacklist (same as before)
• Whitelist (same as before)
• Game launchers (new default, hard-coded, can't be changed)
• Custom (allows people to write their own rules, uses the 'Game launchers' ruleset by default)

The blacklist and whitelist options will work exactly like they do now.

Game launchers will show the rules in a list like Blacklist and Whitelist do, but will probably make each rule human readable.

<Steam.exe becomes "Parent is Steam.exe"
!<Steam.exe becomes "Parent is not Steam.exe"
steamapps becomes "Path matches steamapps"
D:\MyGames\* becomes "Path matches D:\MyGames*"
hl2.exe becomes "hl2.exe"

Custom is meant for power users, and may contain just a text editor component.
Otherwise, we could do a UI for adding "NOT ", "PARENT IS ", etc.

This supercedes #1953 and #1954

Spec at https://gist.github.com/mkrautz/b0fc8d0c80420b9c1618

WDYT?

[mkrautz]

Mockup

[hacst]

Probably a good idea to beef it up that way. Definitely more robust than the auto-whitelisting I proposed a while ago (will be higher maintenance for the defaults though).

How will this handle updates to the defaults provided by us? Is it basically concatenating whatever the user provides to our defaults (which could be auto-updated)? It seems like the scheme requires us to evaluate the full list every time so I guess that would be viable and would solve the problem.

UI wise I think we should go for a simpler approach. As the default is going to be a whitelist and normal users shouldn't switch away from that (so random stuff doesn't crash) I'm fine with making the blacklist an obscure feature of our syntax (e.g. you have to know that you can do * and then blacklist). Also having the launchers in their own tab you cannot edit doesn't seem very helpful given the way the entries would actually be interpreted.

Basically all I think we need is mockup 2+3 (maybe using a table or a control element group to make it simpler/faster to edit and reorder the list). Our presets would simply be uneditable/movable entries (with a checkbox to disable them) at the bottom with the user entries going on top (reverse of what the file is I guess...but I think it works better in the UI that way).

We will have to think of a easy and discoverable way to add new entries as otherwise people will simply assume the overlay is no longer working for game XYZ that's not in our defaults. One part of that might be to add an explicit drop fields (e.g. for allow/disallow) where games can be dropped so they appear in the list. No really good idea on how to make the user aware of the feature in general....

Format wise:

• I assume this won't allow compound rules/scopes (e.g. <Steam.exe { hl2.exe } or <Steam.exe && hl2.exe )? Do we need them (if yes that makes lots of things very complicated...)?
• Could think about spelling the single character stuff out if we find good words. Otherwise we should probably prefix the user file with a small header explaining them
• Does < also match on the parent itself? If we want easy allow/disallow semantics it might make sense to - by default - add entries as "this and all children" as games usually won't have any and that way it's easier to deal with launchers etc. On the other hand we might crash launchers ;)

[mkrautz]

We probably also need to add a rule to check for DLL presence in the process.

We don't want to inject the default overlay into VR applications. So checking for the presence of OpenVR/SteamVR/Oculus SDK would be nice.

[Kissaki]

I think this was implemented/superseded by the Overlay Exceptions? Or does this look to add something different/additional?

[Kissaki]

Our current Launcher Filter:

[no-response]

This issue has been automatically closed because there has been no response to our request for more information.
With only the information that is currently in the issue, we don't have enough information to take action.

Please reach out if you have or find the answers we need so that we can investigate further (or if you feel like this issue shouldn't be closed for another reason).