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

AdHoc multiplayer compatibility #19930

Open
hrydgard opened this issue Jan 29, 2025 · 3 comments
Open

AdHoc multiplayer compatibility #19930

hrydgard opened this issue Jan 29, 2025 · 3 comments

Comments

@hrydgard
Copy link
Owner

hrydgard commented Jan 29, 2025

This is the new master issue for keeping track of general AdHoc multiplayer compatibility.

AdHoc has the great advantage over Infrastructure that generic servers like socom.cc can be used, so custom "revival servers" are not necessary.

However there are problems with port usage that's not compatible with popular OS:es, and of course also bugs and things like that. It's also quite tricky to configure if you want to switch between using socom.cc or the built-in adhoc server for LAN or multi-instance multiplayer.

Let's collect all the known issues here.

Come to think of it, maybe this issue should be split into multiple parent issues, like regressions, port problems, etc. Because the full list is basically not much different than using the label...

GTA: LCS and GTA:VCS

These are reported to have worked in the past - would be extremely useful to know which commit broke it, or at least a range!

Other issues

See below for sub-issues, a new GitHub functionality that I'm trying out here.

@hrydgard hrydgard added this to the Future-Prio milestone Jan 29, 2025
@anr2me
Copy link
Collaborator

anr2me commented Jan 29, 2025

GTA VCS stuck if it failed to connect to AdhocServer, because it endlessly trying to use Adhocctl while ignoring the error code, and only checked the WLAN state, it's like having a broken wifi adapter the moment it tried to initialize it, and got locked out.
The only way out of multiplayer menu is by disabling WLAN, since the game ignores error code from Adhocctl, but checked the WLAN state.
I think the game was designed that way, since on a real PSP player can easily switched off the WLAN, while on PPSSPP it need to be bound to a controller's button first for easy use.

It used to works in the past, probably because it will fallback to faked success when unable to connect to adhoc server, but this will cause confusion to the player, thinking that they've connected to adhoc server but unable to see anyone, thus ended reporting it as the wrong issue, while the actual issue was either the adhoc server was down or the adhoc server's port was blocked (in the case of built-in adhoc server).

There isn't much we can do if the game only respond to WLAN state, but we might be able to temporarily disable WLAN after a few failed attempts of AdhocctlInit/Connect/Create/Scan/Join, and restore the WLAN state after 1~2 seconds later. This will make the game to kick the player out of multiplayer menu instead of stuck there.

PS: as i remembered during Adhocctl error, the game tried to generate a text regarding the error (while ignoring the error and retry), but i never saw this text outputted anywhere in the logs, just saw it as one of the argument passed to a subroutine, may be that subroutine only print something during development (ie. wrapped in DEBUG definition or something)

@CrunchBite
Copy link

Team XLink would love to work with you on this :)

@anr2me
Copy link
Collaborator

anr2me commented Jan 29, 2025

Team XLink would love to work with you on this :)

PPSSPP doesn't have any syscalls implementation that dealt with raw sockets yet, and since raw sockets need admin/sudo, it might not worked on some platforms (ie. Android) or users with limited account (ie. kids)

PS: i think we have too many Android users :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants