forked from apace100/calio
-
Notifications
You must be signed in to change notification settings - Fork 0
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
ClientHelper.isServerContext returns false in singleplayer worlds #4
Comments
Confirmed that this does not occur on 1.20.1. Seems this is limited to 1.19 (or even that specific version of Forge). Leaving this open for now in case you want to take another look at it anyway. |
MerchantPug
added a commit
to EdwinMindcraft/origins-architectury
that referenced
this issue
Mar 13, 2024
The commits above aren't the true fix I feel, I'm going to keep the original logic, but also include a check for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
Confirmed on 1.19.x/forge aece46e, buildscript 1.19.x/forge e4f58032
Not yet confirmedDoes not occur on 1.20.x/forge.Problem
When in singleplayer, the
RegistryAccess
used by the internal server appears to be obtained fromRegistryAccess.BUILTIN
. The code inClientHelper.isServerContext
assumes that this is not the case, and thus always returns false. This can cause datapack reloads in singleplayer to unexpectedly fail as the server will attempt to send the client's registries to the client.Potential Solutions
Aside from one instance in origins-architectury:PartialOrigin.Builder.powers, the
access
argument is always null. As such, it may be possible to remove the comparison toRegistryAccess.BUILTIN
and just use the null check. This may have some regressions, and I suspect that a better solution exists.The text was updated successfully, but these errors were encountered: