Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

input/overlays: add option to lock overlay input to player one #14100

Merged
merged 2 commits into from
Jun 27, 2023

Conversation

Megamouse
Copy link
Contributor

probably fixes #14095

@Darkhost1999
Copy link
Contributor

I got a chance to test this. It'll solve the root issue and is acceptable.
Seems to work nicely and serves the purpose requested. I'm a little bit sad that we can't detect the user to open the overlay but if that isn't something we can do then that isn't something we can do. The only time this presents anything with having removed the home button from my kid's pad settings is when selecting a user account when joining the session. It now mandates that Player 1 selects the user account for all other players. Which only encourages communication and patience so it is a non-issue.

@Megamouse
Copy link
Contributor Author

I said "we can't detect the user who opens ingame dialogs".
We can easily detect the user who opened the home menu.
I don't really know how this improves your situation though.
I thought you wanted to prevent your child to fiddle with the overlays.

@Darkhost1999
Copy link
Contributor

Yea, the goal is that only 1 pad controls the home menu at 1 time. I'm not sure about what other overlays there are.
I already have a solution to prevent my child from opening the home menu by right-clicking the ps button in the pads settings unassigning the key.
So, if I open the menu, then I control the menu.
But if they try to join the game, it would be nice to select their user profile from the controller joining the game. This is where detecting the controller to open the menus was thought about instead of complete full control from all pads connected at all times.
I'm thinking, is on screen keyboard an overlay? Cause that'd be another scenario where it'd be nice the controller/user to open the osk controls the osk. By limiting it strictly to player 1 the current solution solves the parsec or streaming request side just feels too restrictive for a family and friends environment.
As is this current solution ultimately satisfies the request sufficiently enough to restrict access and can/will be used if merged.

@Megamouse
Copy link
Contributor Author

Every single native dialog which is not the home menu is an "ingame dialog". This includes the OSK, the regular message dialogs, the savedata dialogs, the user selection dialogs, the media selection dialogs, etc.
There is no way of knowing whether the second player or the first player caused the game to open those dialogs.

Unless I'm misunderstanding something, the "join game" dialog should also be such an ingame user selection dialog.

@Darkhost1999
Copy link
Contributor

Yea It is something like this screen here.
image
My priority is blocking only all of these
image
On screen keyboard isn't a priority for me personally to be restricted as I have yet to experience a need for it to be restricted. I don't build signs in Minecraft. The current Streaming/Parsec option would help those users there.

@Megamouse Megamouse merged commit 7b64cd2 into RPCS3:master Jun 27, 2023
4 of 5 checks passed
@Megamouse Megamouse deleted the overlay_parental_issue branch June 27, 2023 19:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature request] Parental controls
2 participants