A bunch of fellows from the AAGL discord are "hard at work" confirming this, but there may be a change of behaviour from upstream, at least for PC (unless this is a sign of worse things to come).
At least on fresh installs right now (first reported over a Reddit thread) presumably from Epic, but likely from any official PC installer as well, we are seeing unpatched builds being allowed to connect and play. Nobody knows whether this is transient behaviour (are the anticheat servers just malfunctioning?) or if there's something bigger happening, but right now, an unpatched game with a clean hosts file jst works?
This new behaviour needs to be observed.
(Note: official launchers inject a config.ini file into the game's directory, and may be doing additional registry shenanigans as well)
A bunch of fellows from the AAGL discord are "hard at work" confirming this, but there may be a change of behaviour from upstream, at least for PC (unless this is a sign of worse things to come).
At least on fresh installs right now (first reported over a Reddit thread) presumably from Epic, but likely from any **official** PC installer as well, we are seeing unpatched builds being allowed to connect and play. Nobody knows whether this is transient behaviour (are the anticheat servers just malfunctioning?) or if there's something bigger happening, but right now, an unpatched game with a clean hosts file jst works?
This new behaviour needs to be observed.
(Note: official launchers inject a config.ini file into the game's directory, and may be doing additional registry shenanigans as well)
There was some indication earlier that they might be be adding some Wine support so they can also run on the Steam Deck, but I really didn't expect the game to switch over to that in the middle of a patch... Can you try to check which kernel module is loaded, if any? Think it might show up on Process Explorer.
(Oh, meant that on a windows native install, I don't think Wine can load .sys libraries...)
There was some indication earlier that they might be be adding some Wine support so they can also run on the Steam Deck, but I really didn't expect the game to switch over to that in the middle of a patch... Can you try to check which kernel module is loaded, if any? Think it might show up on Process Explorer.
(Oh, meant that on a windows native install, I don't think Wine can load .sys libraries...)
Building on Krock's wish that Hoyo would strenghten the server side instead of client-side anticheat, we have observed that
Launching the game EXE directly once, loads into the game and works, but yells about data corruption. Then subsequent attempts to launch load mhyprot, fail, and the game exits
Launching the upstream launcher, however, forces hoyokprot mode - which fails - then launches into the game anyway.
Unless they broke their own integration (which is possible - HI3rd AUG2022 comes to mind), our current theory is the following:
mhyprot fails ->
hoyokprot fails ->
report to server side ->
server enables experimental account hardening ->
player authorized
(Please keep in mind that the above is only theorycrafting, and is here as an observation. While we don't want to speculate too hard, it is difficult not to.)
We have a wild theory.
A ***very*** wild theory.
Building on Krock's wish that Hoyo would strenghten the server side instead of client-side anticheat, we have observed that
* Launching the game EXE directly once, loads into the game and works, but yells about data corruption. Then subsequent attempts to launch load mhyprot, fail, and the game exits
* Launching the upstream *launcher*, however, forces hoyokprot mode - which fails - then launches into the game anyway.
Unless they broke their own integration (which is possible - HI3rd AUG2022 comes to mind), our current theory is the following:
```
mhyprot fails ->
hoyokprot fails ->
report to server side ->
server enables experimental account hardening ->
player authorized
```
(Please keep in mind that the above is only theorycrafting, and is here as an observation. While we don't want to speculate too hard, it is difficult not to.)
CN: failed to load mhyprot3.sys -> process terminates (But this happens only on my device so far. I've re-set prefix so many times
OS: failed to load HoYoKProtect.sys -> just works
Have tested both CN and OS client
CN: `failed to load mhyprot3.sys -> process terminates` (But this happens only on my device so far. I've re-set prefix so many times
OS: `failed to load HoYoKProtect.sys -> just works`
Wine cannot and will never be able to run kernel-level Windows services. Ever since, Genshin refused to start due to WDFLDR.sys. That is a largely undocumented Windows component for dealing with kernel services, see MSDN for a better description.
If and only if it happens that this dependency (and hence the services) are no longer enforced by upcoming game builds, the game should start and function as expected out of the box [*]. Historically speaking that was not always the case, requiring additional patchwork to fix up runtime crashes.
Even if this compatibility turns out to be true and reliable, it will (yet) come at a noticeable CPU usage uplift compared to applying the secondary patch which is definitely undesirable on low-end devices such as the Steam Deck.
EDIT: Please refrain from speculations until this is a confirmed persistent behaviour.
EDIT2:
[*] 1. ignoring server-side checks, 2. ignoring event/feedback button crashes, 3. assuming Wine supports Vulkan child window rendering (vulkan-1.dll workaround or Proton/Wine-Staging), 4. assuming the MS fonts are installed (ZFGameBrowser crash)
EDIT3: To figure out whether this is explicitly supported, rename a binary file (e.g. crashreporter.exe) after which the server login must return error 31-4302, also on Windows. Anything else indicates that the checks were entirely disabled on server side (accident or not).
Wine cannot and will never be able to run kernel-level Windows services. Ever since, Genshin refused to start due to WDFLDR.sys. That is a largely undocumented Windows component for dealing with kernel services, see MSDN for a better description.
If **and only if** it happens that this dependency (and hence the services) are no longer enforced by upcoming game builds, the game should start and function as expected out of the box **[\*]**. Historically speaking that was not always the case, requiring additional patchwork to fix up runtime crashes.
Even if this compatibility turns out to be true and reliable, it will (yet) come at a noticeable CPU usage uplift compared to applying the secondary patch which is definitely undesirable on low-end devices such as the Steam Deck.
EDIT: Please refrain from speculations until this is a confirmed persistent behaviour.
EDIT2:
**[\*]** 1. ignoring server-side checks, 2. ignoring event/feedback button crashes, 3. assuming Wine supports Vulkan child window rendering (vulkan-1.dll workaround or Proton/Wine-Staging), 4. assuming the MS fonts are installed (ZFGameBrowser crash)
EDIT3: To figure out whether this is explicitly supported, rename a binary file (e.g. `crashreporter.exe`) after which the server login must return error 31-4302, also on Windows. Anything else indicates that the checks were entirely disabled on server side (accident or not).
I assume that if this is indeed intentional and in preparation for the game officially running on the Steam Deck, they'll also fix any obvious issues with it.
Now, does anyone around here have a Steam Deck to check if/how the game is running unpatched?
I assume that if this is indeed intentional and in preparation for the game officially running on the Steam Deck, they'll also fix any obvious issues with it.
Now, does anyone around here have a Steam Deck to check if/how the game is running unpatched?
EDIT3: To figure out whether this is explicitly supported, rename a binary file (e.g. crashreporter.exe) after which the server login must return error 31-4302, also on Windows. Anything else indicates that the checks were entirely disabled on server side (accident or not).
Well. I renamed crashreporter and this happened. Restoring the name lets me back in.
> EDIT3: To figure out whether this is explicitly supported, rename a binary file (e.g. crashreporter.exe) after which the server login must return error 31-4302, also on Windows. Anything else indicates that the checks were entirely disabled on server side (accident or not).
Well. I renamed crashreporter and this happened. Restoring the name lets me back in.
I tried to rename vulkan-1.dll, and it also returned error 31-4302. I can only enter the game (without anti-cheat patch) if I revert any renaming.
But the cpu_skining patch can work without problem.
I tried to rename vulkan-1.dll, and it also returned error 31-4302. I can only enter the game (without anti-cheat patch) if I revert any renaming.
But the cpu_skining patch can work without problem.
When logging since this evening, I can no longer get past the initial door loading, once it gets to the Geo symbol it crashes my system (whole computer). Tried a bunch of different wine versions and repairing the game, but nothing really fixed it. (Game was loading well this morning and prior to that).
Until I tried to launch the game from the app itself, instead of Lutris. The game starts, but it looks totally graphically shattered. I am not sure what are the possible repercussions of loading the game like this either.
Not sure if this is helpful at all, but letting you know, in case it can assist on understanding better what is going on server-side.
When logging since this evening, I can no longer get past the initial door loading, once it gets to the Geo symbol it crashes my system (whole computer). Tried a bunch of different wine versions and repairing the game, but nothing really fixed it. (Game was loading well this morning and prior to that).
Until I tried to launch the game from the app itself, instead of Lutris. The game starts, but it looks totally graphically shattered. I am not sure what are the possible repercussions of loading the game like this either.
Not sure if this is helpful at all, but letting you know, in case it can assist on understanding better what is going on server-side.
As for myself, my current test bench is an EOS-enabled install via Heroic, launching the game via its upstream launcher. Runner is Proton7-52. I have just validated that it still runs on my side today (31mar23) - I'm in game (on a trash account, for testing, of course) and able to play.
@watkyn the game LSD trip is a DXVK issue.
As for myself, my current test bench is an EOS-enabled install via Heroic, launching the game via its upstream launcher. Runner is Proton7-52. I have just validated that it still runs on my side today (31mar23) - I'm in game (on a trash account, for testing, of course) and able to play.
Game was playable without a patch for quite a while (if memory serves me well, at least since 3.2.0). The only thing you needed to do is to remove or rename mhypbase.dll from the game folder.
The main problem here is the server-side anti-cheat algorithm. Due to, well, recent events it was studied a bit more thoroughly and there're quite a few points of failure that can give us a headache.
One of such problems is server-issued "challenges" for a client which it should perform in order to prove being genuine. Some of those challenges require AC driver being functional. While failure to complete one or two of such challenges won't get you in much trouble, it'll raise your account "security threat level" to a certain extent.
If this level goes too high, your account might get auto-banned for a limited time (usually a month) or subjected to a manual moderation.
There're some ways to lower this indicator, the simplest one being logging and playing on another device (Windows / Android).
My current guess is that miHoYo knows about this Linux workaround (maybe not as the project itself, but as a phenomenon) and just turns the blind eye for a high threat level if it registers a game being started on Wine and no other abnormal behaviour registered.
Just to add my two cents here.
Game was playable without a patch for quite a while (if memory serves me well, at least since 3.2.0). The only thing you needed to do is to remove or rename `mhypbase.dll` from the game folder.
The main problem here is the server-side anti-cheat algorithm. Due to, well, _recent events_ it was studied a bit more thoroughly and there're quite a few points of failure that can give us a headache.
One of such problems is server-issued "challenges" for a client which it should perform in order to prove being genuine. Some of those challenges require AC driver being functional. While failure to complete one or two of such challenges won't get you in much trouble, it'll raise your account "security threat level" to a certain extent.
If this level goes too high, your account might get auto-banned for a limited time (usually a month) or subjected to a manual moderation.
There're some ways to lower this indicator, the simplest one being logging and playing on another device (Windows / Android).
My current guess is that miHoYo knows about this Linux workaround (maybe not as the project itself, but as a phenomenon) and just turns the blind eye for a high threat level if it registers a game being started on Wine and no other abnormal behaviour registered.
@Alex72 while the patchless part has been working for a few patches, working patchless beyond the grace period and with mhypbase.dll left as is, is a new behaviour.
On the rest, I tend to agree with you. (We may have some dumb theories on alternate ways to lower the indicator, but these are wishful thinking and will stay in the AAGL discord between the lads)
@Alex72 while the patchless part has been working for a few patches, working patchless _**beyond the grace period** and with mhypbase.dll left as is_, is a new behaviour.
On the rest, I tend to agree with you. (We may have some dumb theories on alternate ways to lower the indicator, but these are wishful thinking and will stay in the AAGL discord between the lads)
Direct report before 20:00 PST on launch: as of 19:17 PST 3.6 does not start through the main launcher yet. Theories as to why are already brewing, but for now, since the patch maintenance officially ends at 2000, we wait.
Direct report before 20:00 PST on launch: as of 19:17 PST 3.6 ***does not*** start through the main launcher yet. Theories as to why are already brewing, but for now, since the patch maintenance *officially* ends at 2000, we wait.
Can confirm that 3.6 is not launching unpatched at this time - game does launch with the typical "rename mhypbase.dll" trick as tested on a trash account.
Can confirm that 3.6 is not launching unpatched at this time - game does launch with the typical "rename mhypbase.dll" trick as tested on a trash account.
Based on my observation: Before 3.6, the game has uncertain chance to switch kernel service (hoyoprot, mhyprot2). There are periods of time where it would use mhyprot2 causing the game to fail to launch, though when it uses hoyoprotect it does launch. (similar to 3Shain's comment)
Game launches:
0130:err:module:import_dll Library WDFLDR.SYS (which is needed by L"C:\windows\system32\HoYoKProtect.sys") not found
0130:err:ntoskrnl:ZwLoadDriver failed to create driver L"\Registry\Machine\System\CurrentControlSet\Services\HoYoProtect": c0000142
Game does not launch:
0158:err:module:import_dll Library WDFLDR.SYS (which is needed by L"C:\users\user\Temp\mhyprot3.sys") not found
0158:err:ntoskrnl:ZwLoadDriver failed to create driver L"\Registry\Machine\System\CurrentControlSet\Services\mhyprot2": c0000142
As of now (3.6) it's always launching with mhyprot2 and I'm not sure when it would "switch" kernel drivers
Based on my observation: Before 3.6, the game has uncertain chance to switch kernel service (hoyoprot, mhyprot2). There are periods of time where it would use mhyprot2 causing the game to fail to launch, though when it uses hoyoprotect it does launch. (similar to 3Shain's comment)
Game launches:
> 0130:err:module:import_dll Library WDFLDR.SYS (which is needed by L"C:\\windows\\system32\\HoYoKProtect.sys") not found
0130:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\HoYoProtect": c0000142
Game does not launch:
> 0158:err:module:import_dll Library WDFLDR.SYS (which is needed by L"C:\\users\\user\\Temp\\mhyprot3.sys") not found
0158:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\mhyprot2": c0000142
As of now (3.6) it's always launching with mhyprot2 and I'm not sure when it would "switch" kernel drivers
The prevailing theory is the upstream launcher was forcing a fail-through into the hoyokprot loader.
Right now, some of us suspect said fail-through is server-controlled, and may not be active until the usual "grace period" is over.
The prevailing theory is the upstream launcher was forcing a fail-through into the hoyokprot loader.
Right now, some of us suspect said fail-through is server-controlled, and may not be active until the usual "grace period" is over.
We've been monitoring the state of AC servers on the 3.6 patch, and yeeting mhypbase.dll still works as of right now. Based on past observations, this SHOULD have stopped.
For the record:
We've been monitoring the state of AC servers on the 3.6 patch, and yeeting mhypbase.dll still works as of right now. Based on past observations, this SHOULD have stopped.
As of noon PDT, 17-apr: with the mhypbase.dll workaround undone, I'm seeing the game launching succesfully in a fully unpatched state.
Except I'm not getting 31-4302 after playing around with the EXEs (I tried crashreporter, upload_crash and blueReporter - none tripped the antitamper).
Others are not reporting a similar experience, leading me to think
The AC servers might be spinning back up right now
They might not be fully back up
There could also be a change in behaviour
I got a luck of the draw
A/B is actually on the table
Further observations
A fresh prefix created after the earlier realization, using pure Wine, leads to failure.
I'm seeing lads having success launching the Upstream Launcher via Proton through Steam directly, meaning it looks like it's "taking" as of 12:45 PDT
ODD BEHAVIOUR: following our curious finding that setting sub_channel to 6 in config.ini leads to Google Play as a payment processor, we have observed that sub_channel=0 stops the game from loading, while sub_channel=6 lets the game through, as does 3. This, however, is NOT uniform; if anything, it's completely accidental.
This lends some credibility to the idea that non-upstream targets (Play [6], Epic [3]) may have the game use alternate AC code that lets Chromebooks (Project Borealis) and Decks (via Heroic) run the game unhampered until further AC work is done on Hoyo's side.
### Circling back.
As of noon PDT, 17-apr: with the `mhypbase.dll` workaround undone, I'm seeing the game launching succesfully in a fully unpatched state.
Except I'm not getting `31-4302` after playing around with the EXEs (I tried `crashreporter`, `upload_crash` and `blueReporter` - none tripped the antitamper).
Others are not reporting a similar experience, leading me to think
* The AC servers might be spinning back up *right now*
* They might not be *fully* back up
* There could also be a change in behaviour
* I got a luck of the draw
* A/B is actually on the table
### Further observations
* A fresh prefix created after the earlier realization, using pure Wine, leads to failure.
* I'm seeing lads having success launching the Upstream Launcher via Proton through Steam directly, meaning it looks like it's "taking" as of 12:45 PDT
* ODD BEHAVIOUR: following our curious finding that setting `sub_channel` to 6 in config.ini leads to Google Play as a payment processor, we have observed that `sub_channel=0` stops the game from loading, while `sub_channel=6` lets the game through, as does `3`. This, however, is NOT uniform; if anything, it's completely accidental.
* This lends some credibility to the idea that non-upstream targets (Play [6], Epic [3]) may have the game use alternate AC code that lets Chromebooks (Project Borealis) and Decks (via Heroic) run the game unhampered until further AC work is done on Hoyo's side.
As of Apr 21st, 2023, AC servers seem to be spinning back up. We're seeing multiple independent confirmations of fully patchless, un-mhypbase-yeeted installs starting to work again. A week later than expected, but nonetheless.
As of Apr 21st, 2023, AC servers seem to be spinning back up. We're seeing multiple independent confirmations of fully patchless, un-mhypbase-yeeted installs starting to work again. A week later than expected, but nonetheless.
Observations of behaviour depending on different sub_channel IDs: (tested 0...10)
All but channel 2 : The driver init failure is (attempted to be) reported to overseauspider.*
5 : No login screen, no news. SDK does not exist.
6 : Prompts for permissions from Google Play
In all cases, mhyprot3 is attempted to register as a service and driverError.log is created. I could not get the vanilla/clean game to start up in any case, hence I wonder whether either certain blocked logging servers are responsible for that or SDK files (below).
@caem I do not know why you removed your message but there is in fact a difference in regard to the Epic SDK:
It is likely that those can change the startup behaviour but I have yet not spent the time to obtain these files and test it.
Observations of behaviour depending on different `sub_channel` IDs: (tested 0...10)
* All but channel 2 : The driver init failure is (attempted to be) reported to `overseauspider.*`
* 5 : No login screen, no news. SDK does not exist.
* 6 : Prompts for permissions from Google Play
In all cases, `mhyprot3` is attempted to register as a service and `driverError.log` is created. I could not get the vanilla/clean game to start up in any case, hence I wonder whether either certain blocked logging servers are responsible for that or SDK files (below).
---
@caem I do not know why you removed your message but there is in fact a difference in regard to the Epic SDK:
```
Plugins/EOSSDK-Win64-Shipping.dll
Plugins/PluginEOSSDK.dll
```
It is likely that those can change the startup behaviour but I have yet not spent the time to obtain these files and test it.
I've had limited luck launching the game depatched from console, though it gave me errors.
Launching it through the official Launcher via Heroic (using Proton as a runner) has shown better luck.
I've had limited luck launching the game depatched from console, though it gave me errors.
Launching it through the official Launcher via Heroic (using Proton as a runner) has shown better luck.
@krock I deleted the original message due to some mistakes on my side. It seems like I am required to run the game repair every time I switch the sub_channel. The diff was from when the game was still on the Epic version, not the default one because I did not repair the files before diffing. Like @cybik mentioned, vanilla wine does not launch the game due to mhyprot3. But I've also had no success with GE-Proton7-55 through Lutris and the official launcher for the same reason. Trying Heroic, it does launch the game but I am unable to log in due to 31-4302. Heroic version has sub_channel=3 and cps=pcseaepic instead of cps=mihoyo in config.ini. Removing Plugins/EOSSDK-Win64-Shipping.dll and
Plugins/PluginEOSSDK.dll did not result in any change in launch behavior for sub_channel=0.
@krock I deleted the original message due to some mistakes on my side. It seems like I am required to run the game repair every time I switch the sub_channel. The diff was from when the game was still on the Epic version, not the default one because I did not repair the files before diffing. Like @cybik mentioned, vanilla wine does not launch the game due to mhyprot3. But I've also had no success with GE-Proton7-55 through Lutris and the official launcher for the same reason. Trying Heroic, it does launch the game but I am unable to log in due to `31-4302`. Heroic version has `sub_channel=3` and `cps=pcseaepic` instead of `cps=mihoyo` in `config.ini`. Removing `Plugins/EOSSDK-Win64-Shipping.dll` and
`Plugins/PluginEOSSDK.dll` did not result in any change in launch behavior for `sub_channel=0`.
For the record, using a small script to launch the Google Play edition launcher via proton (I installed it in a prefix first), then using it to install a fresh game, and then launching said game, it worked on the first attempt, completely unpatched.
For the record, using a small script to launch the Google Play edition launcher via proton (I installed it in a prefix first), then using it to install a fresh game, and then launching said game, it worked on the first attempt, completely unpatched.
I tested it again this day (2023-04-26). In my case, it appears (for now?) to use hoyokprot now and starts with no error. Using the game from the website without channel modifications (directly launched the binary).
Edit: Didn't notice this earlier, but the captcha box shows without workaround when using Wine Staging 8.6. Not sure if it's the game not using vulkan for the captcha or Wine supports it now (no indication in the Wine's news)
I tested it again this day (2023-04-26). In my case, it appears (for now?) to use hoyokprot now and starts with no error. Using the game from the website without channel modifications (directly launched the binary).
Edit: Didn't notice this earlier, but the captcha box shows without workaround when using Wine Staging 8.6. Not sure if it's the game not using vulkan for the captcha or Wine supports it now (no indication in the Wine's news)
i'm playing 370 about 30 minutes with renamed mhypbase.dll method
unpatch previous version
start launcher and update
after update, close launcher and run GenshinImpact.exe directly
if not open, go to folder and rename mhypbase.dll
try run GenshinImpact.exe again
i'm playing 370 about 30 minutes with renamed `mhypbase.dll` method
- unpatch previous version
- start launcher and update
- after update, close launcher and run GenshinImpact.exe directly
- if not open, go to folder and rename mhypbase.dll
- try run GenshinImpact.exe again
Wine 8.8 Staging (or just 8.8 in general) seems to have broken the patchless method, at least on Arch. Got the game to work without patches today (even forgoing mhypbase.dll).
Wine 8.8 Staging (or just 8.8 in general) seems to have broken the patchless method, at least on Arch. Got the game to work without patches today (even forgoing mhypbase.dll).
Tools:
Arch Linux
Wine 8.7 Staging (from https://github.com/Kron4ek/Wine-Builds/releases)
DXVK 2.2
It seems that 3.8 starts on Linux, with without any intervention whatsoever. Tested myself, GE-Proton 8-x.
Continuing from https://notabug.org/Krock/dawn/issues/401 .
It seems that 3.8 starts on Linux, with *without any intervention whatsoever*. Tested myself, GE-Proton 8-x.
A bunch of fellows from the AAGL discord are "hard at work" confirming this, but there may be a change of behaviour from upstream, at least for PC (unless this is a sign of worse things to come).
At least on fresh installs right now (first reported over a Reddit thread) presumably from Epic, but likely from any official PC installer as well, we are seeing unpatched builds being allowed to connect and play. Nobody knows whether this is transient behaviour (are the anticheat servers just malfunctioning?) or if there's something bigger happening, but right now, an unpatched game with a clean hosts file jst works?
This new behaviour needs to be observed.
(Note: official launchers inject a config.ini file into the game's directory, and may be doing additional registry shenanigans as well)
Right now, on one of my alts, i'm logged in and active, with anything handled by the patch all but removed.
There was some indication earlier that they might be be adding some Wine support so they can also run on the Steam Deck, but I really didn't expect the game to switch over to that in the middle of a patch... Can you try to check which kernel module is loaded, if any? Think it might show up on Process Explorer.
(Oh, meant that on a windows native install, I don't think Wine can load .sys libraries...)
We have a wild theory.
A very wild theory.
Building on Krock's wish that Hoyo would strenghten the server side instead of client-side anticheat, we have observed that
Unless they broke their own integration (which is possible - HI3rd AUG2022 comes to mind), our current theory is the following:
(Please keep in mind that the above is only theorycrafting, and is here as an observation. While we don't want to speculate too hard, it is difficult not to.)
Have tested both CN and OS client
CN:
failed to load mhyprot3.sys -> process terminates(But this happens only on my device so far. I've re-set prefix so many timesOS:
failed to load HoYoKProtect.sys -> just worksWine cannot and will never be able to run kernel-level Windows services. Ever since, Genshin refused to start due to WDFLDR.sys. That is a largely undocumented Windows component for dealing with kernel services, see MSDN for a better description.
If and only if it happens that this dependency (and hence the services) are no longer enforced by upcoming game builds, the game should start and function as expected out of the box [*]. Historically speaking that was not always the case, requiring additional patchwork to fix up runtime crashes.
Even if this compatibility turns out to be true and reliable, it will (yet) come at a noticeable CPU usage uplift compared to applying the secondary patch which is definitely undesirable on low-end devices such as the Steam Deck.
EDIT: Please refrain from speculations until this is a confirmed persistent behaviour.
EDIT2:
[*] 1. ignoring server-side checks, 2. ignoring event/feedback button crashes, 3. assuming Wine supports Vulkan child window rendering (vulkan-1.dll workaround or Proton/Wine-Staging), 4. assuming the MS fonts are installed (ZFGameBrowser crash)
EDIT3: To figure out whether this is explicitly supported, rename a binary file (e.g.
crashreporter.exe) after which the server login must return error 31-4302, also on Windows. Anything else indicates that the checks were entirely disabled on server side (accident or not).I assume that if this is indeed intentional and in preparation for the game officially running on the Steam Deck, they'll also fix any obvious issues with it.
Now, does anyone around here have a Steam Deck to check if/how the game is running unpatched?
Well. I renamed crashreporter and this happened. Restoring the name lets me back in.
I tried to rename vulkan-1.dll, and it also returned error 31-4302. I can only enter the game (without anti-cheat patch) if I revert any renaming.
But the cpu_skining patch can work without problem.
When logging since this evening, I can no longer get past the initial door loading, once it gets to the Geo symbol it crashes my system (whole computer). Tried a bunch of different wine versions and repairing the game, but nothing really fixed it. (Game was loading well this morning and prior to that).
Until I tried to launch the game from the app itself, instead of Lutris. The game starts, but it looks totally graphically shattered. I am not sure what are the possible repercussions of loading the game like this either. Not sure if this is helpful at all, but letting you know, in case it can assist on understanding better what is going on server-side.
@watkyn the game LSD trip is a DXVK issue.
As for myself, my current test bench is an EOS-enabled install via Heroic, launching the game via its upstream launcher. Runner is Proton7-52. I have just validated that it still runs on my side today (31mar23) - I'm in game (on a trash account, for testing, of course) and able to play.
Just to add my two cents here.
Game was playable without a patch for quite a while (if memory serves me well, at least since 3.2.0). The only thing you needed to do is to remove or rename
mhypbase.dllfrom the game folder.The main problem here is the server-side anti-cheat algorithm. Due to, well, recent events it was studied a bit more thoroughly and there're quite a few points of failure that can give us a headache.
One of such problems is server-issued "challenges" for a client which it should perform in order to prove being genuine. Some of those challenges require AC driver being functional. While failure to complete one or two of such challenges won't get you in much trouble, it'll raise your account "security threat level" to a certain extent.
If this level goes too high, your account might get auto-banned for a limited time (usually a month) or subjected to a manual moderation.
There're some ways to lower this indicator, the simplest one being logging and playing on another device (Windows / Android).
My current guess is that miHoYo knows about this Linux workaround (maybe not as the project itself, but as a phenomenon) and just turns the blind eye for a high threat level if it registers a game being started on Wine and no other abnormal behaviour registered.
@Alex72 while the patchless part has been working for a few patches, working patchless beyond the grace period and with mhypbase.dll left as is, is a new behaviour.
On the rest, I tend to agree with you. (We may have some dumb theories on alternate ways to lower the indicator, but these are wishful thinking and will stay in the AAGL discord between the lads)
Direct report before 20:00 PST on launch: as of 19:17 PST 3.6 does not start through the main launcher yet. Theories as to why are already brewing, but for now, since the patch maintenance officially ends at 2000, we wait.
Can confirm that 3.6 is not launching unpatched at this time - game does launch with the typical "rename mhypbase.dll" trick as tested on a trash account.
Based on my observation: Before 3.6, the game has uncertain chance to switch kernel service (hoyoprot, mhyprot2). There are periods of time where it would use mhyprot2 causing the game to fail to launch, though when it uses hoyoprotect it does launch. (similar to 3Shain's comment)
Game launches:
Game does not launch:
As of now (3.6) it's always launching with mhyprot2 and I'm not sure when it would "switch" kernel drivers
The prevailing theory is the upstream launcher was forcing a fail-through into the hoyokprot loader.
Right now, some of us suspect said fail-through is server-controlled, and may not be active until the usual "grace period" is over.
For the record:
We've been monitoring the state of AC servers on the 3.6 patch, and yeeting mhypbase.dll still works as of right now. Based on past observations, this SHOULD have stopped.
Circling back.
As of noon PDT, 17-apr: with the
mhypbase.dllworkaround undone, I'm seeing the game launching succesfully in a fully unpatched state.Except I'm not getting
31-4302after playing around with the EXEs (I triedcrashreporter,upload_crashandblueReporter- none tripped the antitamper).Others are not reporting a similar experience, leading me to think
Further observations
sub_channelto 6 in config.ini leads to Google Play as a payment processor, we have observed thatsub_channel=0stops the game from loading, whilesub_channel=6lets the game through, as does3. This, however, is NOT uniform; if anything, it's completely accidental.As of Apr 21st, 2023, AC servers seem to be spinning back up. We're seeing multiple independent confirmations of fully patchless, un-mhypbase-yeeted installs starting to work again. A week later than expected, but nonetheless.
Observations of behaviour depending on different
sub_channelIDs: (tested 0...10)overseauspider.*In all cases,
mhyprot3is attempted to register as a service anddriverError.logis created. I could not get the vanilla/clean game to start up in any case, hence I wonder whether either certain blocked logging servers are responsible for that or SDK files (below).@caem I do not know why you removed your message but there is in fact a difference in regard to the Epic SDK:
It is likely that those can change the startup behaviour but I have yet not spent the time to obtain these files and test it.
I've had limited luck launching the game depatched from console, though it gave me errors.
Launching it through the official Launcher via Heroic (using Proton as a runner) has shown better luck.
@krock I deleted the original message due to some mistakes on my side. It seems like I am required to run the game repair every time I switch the sub_channel. The diff was from when the game was still on the Epic version, not the default one because I did not repair the files before diffing. Like @cybik mentioned, vanilla wine does not launch the game due to mhyprot3. But I've also had no success with GE-Proton7-55 through Lutris and the official launcher for the same reason. Trying Heroic, it does launch the game but I am unable to log in due to
31-4302. Heroic version hassub_channel=3andcps=pcseaepicinstead ofcps=mihoyoinconfig.ini. RemovingPlugins/EOSSDK-Win64-Shipping.dllandPlugins/PluginEOSSDK.dlldid not result in any change in launch behavior forsub_channel=0.For the record, using a small script to launch the Google Play edition launcher via proton (I installed it in a prefix first), then using it to install a fresh game, and then launching said game, it worked on the first attempt, completely unpatched.
I tested it again this day (2023-04-26). In my case, it appears (for now?) to use hoyokprot now and starts with no error. Using the game from the website without channel modifications (directly launched the binary).
Edit: Didn't notice this earlier, but the captcha box shows without workaround when using Wine Staging 8.6. Not sure if it's the game not using vulkan for the captcha or Wine supports it now (no indication in the Wine's news)
Same behavior observed here, was able to run the game without any tweaks today.
i'm playing 370 about 30 minutes with renamed
mhypbase.dllmethodThe renamed
mhypbase.dllmethod also works for me on 370, CN version for now.Wine 8.8 Staging (or just 8.8 in general) seems to have broken the patchless method, at least on Arch. Got the game to work without patches today (even forgoing mhypbase.dll).
Tools: Arch Linux
Wine 8.7 Staging (from https://github.com/Kron4ek/Wine-Builds/releases)
DXVK 2.2
Continuing from #401 .
It seems that 3.8 starts on Linux, with without any intervention whatsoever. Tested myself, GE-Proton 8-x.
Functional as of 4.1.0. The plans are mentioned in #406 and the binary patch is already paused.
Actions taken. This issue served its purpose.