-
-
Notifications
You must be signed in to change notification settings - Fork 615
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
Create Mod Server Settings Package is not arriving at Client #1191
Comments
I have now tested this with all velocity plugins and mods removed (except for create itself of course), and the issue remains. Here also same as seen above the rail count in the inventory was showing an error even in creative. |
I've done a good bit more research here. I've figured out the following: |
I have now tested this in 1.20.1 with create 5.1d sodium fork, the issue still occurs exactly as it did in 1.19.2. You change the settings on the client, it works, you relog, and it no longer works. |
Testing in 1.20.1 I have found some interesting things in the log. The full log is here: trzrFfK.txt This seems to confirm to me that information is not arriving at the client, as a bunch of values end up as null. Here's a snippet (expand):
|
I have checked, and this issue will probably not be fixed until the mod is updated to 1.20.2+, because currently it seems to send the configuration values via a custom packet in the LOGIN phase, which is not possible because the player is in the PLAY phase at that moment. Changing the configuration from the client is of course possible since it is done in PLAY state |
I wonder if this could be fixed temporarily on the side of forge config porting lib. Until then or 1.21 create mod, I guess I'll have to live with patching all client mods so they assume the values I want are the default values. A bit painful. |
Problem:
My setup is velocity as the frontend with two separate fabric 1.19.2 servers as the backend. When I change the create config through the ingame menu to change the maximum train track placement length from 32 to 128 and click save, the change saves correctly and gets written to file on the server. Players can also place track segments of up to 128 blocks long.
However, the preview of where players can place track still behaves as if the max length was 32. Relogging does not fix the issue. It is really annoying trying to build large curves when one can't tell if it's actually out of range or just showing up wrong. The in-game create configuration menu also shows the default distance of 32 even if the server-side change is applied.
Additionally, I don't know if this is related, but players can not see each other on journeymap.
Testing:
Theory:
A create mod server settings packet is successfully dispatched by the backend server, but lost in velocity before it makes it to the client.
I believe this is the case as the code in create mod that I believe to have identified as responsible for sending the packet (see here) would throw a warning into the log if an exception was thrown in handle() packet. There is no such warn to be found in the server log. I also believe this is not a fabricproxy-lite issue as the mod only handles things during login, while the create menu breaks even when editing them during play (see above: testing:2). I also know it works as expected on my other server, which shares a very similar modpack, with the only major difference being that velocity is not present, without which changing settings works flawlessly.
Setup info:
Minecraft 1.19.2 with Fabric Loader 0.15.0, Fabric-API 0.76.1
Velocity 3.3.0 Snapshot 320
Velocity server bootup log including plugins (expand):
Full server bootup log including full modlist (expand):
The text was updated successfully, but these errors were encountered: