Since December 2020 (v1.1.0) there have been patches for 24 subsequent OS builds and 10 for CN builds, respectively. During this time, I only got to know of one ban, which was caused by an automation tool. In overall that is a positive surprise in itself.
As some of you might already have noticed (Issue #404); as of version 3.5.0, Genshin now starts without relying on the kernel-level service which previously caused the application to abort due to missing dependencies (because Wine cannot implement them).
The game servers (CN/NA/EU/Asia/SAR) can check whether the service is active (directly or indirectly) using checksums or as I have recently discovered - callbacks. There are many more ways and yet the game is currently playable without modifications. The server approves the checksum, so to say.
Short term roadmap
For version 3.6.0 I will provide the same patch as usual so that the vulkan-1.dll workaround can be applied for those who need it. Depending on the results from that version, the long-term strategy will be applied.
Long term roadmap
If the original/vanilla/unpatched 3.6.0 installation turns out stable (i.e. no error 31-4302 or bans), I will then thin out subsequent patches up to the point where it becomes a no-op script to preserve 3rd party launcher compatibility [1].
As a result from that, Wine-Staging-based builds will become mandatory in order to support Vulkan child process rendering. For details, see TROUBLESHOOTING.md.
[1]: Afterwards, patches will only be done on demand (i.e. if necessary).
TL;DR: 3.6.0 patch will be provided, thinning out patches if 3.6.0 is stable
EDIT: If there are any issues in the "migration process", please let me know so that a solution can be found and documented.
## Situation
Since December 2020 (v1.1.0) there have been patches for 24 subsequent OS builds and 10 for CN builds, respectively. During this time, I only got to know of one ban, which was caused by an automation tool. In overall that is a positive surprise in itself.
As some of you might already have noticed (Issue #404); as of version 3.5.0, Genshin now starts without relying on the kernel-level service which previously caused the application to abort due to missing dependencies (because Wine cannot implement them).
The game servers (CN/NA/EU/Asia/SAR) can check whether the service is active (directly or indirectly) using checksums or as I have recently discovered - callbacks. There are many more ways and yet the game is currently playable without modifications. The server approves the checksum, so to say.
#### Short term roadmap
For version 3.6.0 I will provide the same patch as usual so that the `vulkan-1.dll` workaround can be applied for those who need it. Depending on the results from that version, the long-term strategy will be applied.
#### Long term roadmap
If the original/vanilla/unpatched 3.6.0 installation turns out stable (i.e. no error 31-4302 or bans), I will then thin out subsequent patches up to the point where it becomes a no-op script to preserve 3rd party launcher compatibility [1].
As a result from that, Wine-Staging-based builds will become mandatory in order to support Vulkan child process rendering. For details, see TROUBLESHOOTING.md.
[1]: Afterwards, patches will only be done on demand (i.e. if necessary).
----
TL;DR: 3.6.0 patch will be provided, thinning out patches if 3.6.0 is stable
EDIT: If there are any issues in the "migration process", please let me know so that a solution can be found and documented.
My knowledge about the server-side checks is incomplete or outdated.
After 48 hours, the 2nd patch became necessary. However the last error 31-4302 was effectively tested in version 1.0.1 when it happened ~10 days after release.
The policy "Never touch a running system" has worked so well so far that it happens that I have not further investigated into this matter.
As for now I can tell that the patches will be continued until further notice.
#### Update as of 3.6.0 (2023-04-15)
My knowledge about the server-side checks is incomplete or outdated.
After 48 hours, the 2nd patch became necessary. However the last error 31-4302 was effectively tested in version 1.0.1 when it happened ~10 days after release.
The policy "Never touch a running system" has worked so well so far that it happens that I have not further investigated into this matter.
As for now I can tell that the patches will be continued until further notice.
Not sure if this is the right place, but I just wanted to report that I played on 3.6 for 6+ hours without any issues. I was able to log in afterwards just fine.
Tag: 0ff770aef6
Lutris GE-Proton7-42-x86_64
With both patsh.sh and patch_anti_logincrash.sh
Not sure if this is the right place, but I just wanted to report that I played on 3.6 for 6+ hours without any issues. I was able to log in afterwards just fine.
Tag: https://notabug.org/Krock/dawn/commit/0ff770aef65e7699cd585c338f516c2533510d61
Lutris `GE-Proton7-42-x86_64`
With both `patsh.sh` and `patch_anti_logincrash.sh`
@casper_5rC Thank you for your report, although #407 would be the correct place for that. This issue is about follow-up plans related to unpatched installs as reported in #404.
@casper_5rC Thank you for your report, although #407 would be the correct place for that. This issue is about follow-up plans related to unpatched installs as reported in #404.
Situation
Since December 2020 (v1.1.0) there have been patches for 24 subsequent OS builds and 10 for CN builds, respectively. During this time, I only got to know of one ban, which was caused by an automation tool. In overall that is a positive surprise in itself.
As some of you might already have noticed (Issue #404); as of version 3.5.0, Genshin now starts without relying on the kernel-level service which previously caused the application to abort due to missing dependencies (because Wine cannot implement them).
The game servers (CN/NA/EU/Asia/SAR) can check whether the service is active (directly or indirectly) using checksums or as I have recently discovered - callbacks. There are many more ways and yet the game is currently playable without modifications. The server approves the checksum, so to say.
Short term roadmap
For version 3.6.0 I will provide the same patch as usual so that the
vulkan-1.dllworkaround can be applied for those who need it. Depending on the results from that version, the long-term strategy will be applied.Long term roadmap
If the original/vanilla/unpatched 3.6.0 installation turns out stable (i.e. no error 31-4302 or bans), I will then thin out subsequent patches up to the point where it becomes a no-op script to preserve 3rd party launcher compatibility [1].
As a result from that, Wine-Staging-based builds will become mandatory in order to support Vulkan child process rendering. For details, see TROUBLESHOOTING.md.
[1]: Afterwards, patches will only be done on demand (i.e. if necessary).
TL;DR: 3.6.0 patch will be provided, thinning out patches if 3.6.0 is stable
EDIT: If there are any issues in the "migration process", please let me know so that a solution can be found and documented.
Update as of 3.6.0 (2023-04-15)
My knowledge about the server-side checks is incomplete or outdated. After 48 hours, the 2nd patch became necessary. However the last error 31-4302 was effectively tested in version 1.0.1 when it happened ~10 days after release.
The policy "Never touch a running system" has worked so well so far that it happens that I have not further investigated into this matter.
As for now I can tell that the patches will be continued until further notice.
Not sure if this is the right place, but I just wanted to report that I played on 3.6 for 6+ hours without any issues. I was able to log in afterwards just fine.
Tag:
0ff770aef6Lutris
GE-Proton7-42-x86_64With both
patsh.shandpatch_anti_logincrash.sh@casper_5rC Thank you for your report, although #407 would be the correct place for that. This issue is about follow-up plans related to unpatched installs as reported in #404.
Patch removed until further notice. The remaining "patch" script code is used to block logging servers if desired.