BcatService: Return InternetRequestDenied for CmifCommand 10101

[Yohoki]

Implementation for BcatService.RequestSyncDeliveryCacheWithDirectoryName()

Instead of trying to connect to official servers, returns BcatResult.InternetRequestDenied.

This fixes #6769 , causing the game to be playable without "Ignore Missing Services". Skips the crash after Chapter 1-1. Also prompts an error message on trying to play online, alerting the user that internet access is not available.

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+3b42ba5-linux_arm64
• ryujinx-Release-1.1.0+3b42ba5-macos_universal
• ryujinx-Release-1.1.0+3b42ba5-linux_x64
• ryujinx-Release-1.1.0+3b42ba5-win_x64

Old GUI (GTK3)

• gtk-ryujinx-Release-1.1.0+3b42ba5-linux_arm64
• gtk-ryujinx-Release-1.1.0+3b42ba5-linux_x64
• gtk-ryujinx-Release-1.1.0+3b42ba5-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+3b42ba5-linux_arm64
• sdl2-ryujinx-headless-Release-1.1.0+3b42ba5-macos_universal
• sdl2-ryujinx-headless-Release-1.1.0+3b42ba5-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+3b42ba5-win_x64

Only for Developers

• ryujinx-Debug-1.1.0+3b42ba5-linux_arm64
• sdl2-ryujinx-headless-Debug-1.1.0+3b42ba5-linux_arm64
• gtk-ryujinx-Debug-1.1.0+3b42ba5-linux_arm64
• ryujinx-Debug-1.1.0+3b42ba5-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+3b42ba5-linux_x64
• gtk-ryujinx-Debug-1.1.0+3b42ba5-linux_x64
• ryujinx-Debug-1.1.0+3b42ba5-macos_universal
• sdl2-ryujinx-headless-Debug-1.1.0+3b42ba5-macos_universal
• ryujinx-Debug-1.1.0+3b42ba5-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+3b42ba5-win_x64
• gtk-ryujinx-Debug-1.1.0+3b42ba5-win_x64

[Yohoki]

Quick note, some testing was done in Endless Ocean.

Returning Result.Success works to load main menu, but gives infinite loop on selecting online play.

Returning BcatResult.NotFound also woks. Tries to load stage on selecting online play mode, but fails quietly back to main menu.

Returning BcatResult.InternetRequestDenied gave the best results, allowing entry to main menu and prompting an error message before returning to main menu when online play is selected.

[gdkchan]

I think we should be consistent with what we do on RequestSyncDeliveryCache. It does not look like RequestSyncDeliveryCache returns an error.

We should probably implement both as if there was no internet connection available, but I'm not sure what it is supposed to return in this case. Also I'm not sure if that could have some undesirable side effect on a game that is currently working.

[gdkchan]

This is missing the DirectoryName argument, see https://github.com/gdkchan/Ryujinx/blob/horigen/Ryujinx.Horizon/Sdk/Bcat/Ipc/BcatService.cs#L19

[Yohoki]

I would assume it would behave similarly if both return InternetRequestDenied. In Endless Ocean's case, it fails quietly in some cases and prompts an error message in others. I'm actually not sure why Result.Success is used here, since there is a BcatResult class that seems more appropriate.

I have updated the code now to include a directory parameter, although it was not failing without one. It's better to have it fleshed out completely for the future. Thanks!
public Result RequestSyncDeliveryCacheWithDirectoryName(out IDeliveryCacheProgressService deliveryCacheProgressService, LibHac.Bcat.DirectoryName arg1)

[gdkchan]

You should add a new DirectoryName type instead of using the LibHac type. On the branch that I linked you can find a DirectoryName struct (although you can also "port" the one from LibHac if you want). The struct should be located on src/Ryujinx.Horizon/Bcat.

[Yohoki]

I tried to quickly implement that, but it caused a lot of build errors. I'll have a better look at it when I get home.

'DirectoryName' is an ambiguous reference between 'Ryujinx.Horizon.Sdk.Bcat.DirectoryName' and 'LibHac.Bcat.DirectoryName'

[Yohoki]

Ok. I've set up the blank DirectoryName struct and pushed for that in the arguments. I also resolved the conflicts between Bcat.DirectoryName and LibHac.Bcat.DirectoryName . The old functions that may rely on LibHac still use it, so nothing should be broken there.

The LibHac version looks well made, but I don't think it's my business to touch something that complex. :)

[gdkchan]

I think it's better to do the same as RequestSyncDeliveryCache and return Result.Success. As I said before, I think those functions should be consistent, and the change with lowest risk here is returning Success (as we don't need to change RequestSyncDeliveryCache implementation then).

[Yohoki]

I think it's better to do the same as RequestSyncDeliveryCache and return Result.Success. As I said before, I think those functions should be consistent, and the change with lowest risk here is returning Success (as we don't need to change RequestSyncDeliveryCache implementation then).

I will not change RequestSyncDeliveryCacheWithDirectoryName to return Result.Success. It causes infinite loop/loading screens in the game I have tested it with. If there are other games that use this call, I would test them, but I don't know any. The lowest risk here, in my opinion, is to assume that the game does not have internet connectivity and allow it to fail gracefully.

The options, at least for this game are as follows:

• Result.Success
  Results in infinite loading screen.
• BcatResult.NotFound
  Results in failed load, and return to main menu.
• BcatResult.InternetRequestDenied || BcatResult.Success
  Results in failed load, a user friendly prompt that there was a connection error and returns to same menu. (Not main menu)

I can provide screenshots/recordings of these outcomes if requested.

-Edit- Confused BcatResult.Success with Result.Success. Fixed.

[gdkchan]

You originally said

Returning Result.Success works to load main menu, but gives infinite loop on selecting online play.

Which makes it sound like that returning Result.Success works, except for online play (which will not work anyway, so it's not a big deal).

[Yohoki]

Ah. You're right. It's been a week and I confused BcatResult.Success and Result.Success anyway. If you're good with it, I will change it to BcatResult.Success, because that mimics the no internet result. If not, I can change it to Result.Success and deal with the loop. At least the game boots now.

I've tried dumping another game that uses this method for testing, but it crashes before loading the menu (even on main branch) if lan/ldn is enabled. It ends up crashing trying to write to an invalid address. So can't really test that one and compare the results.