Mod Loader (Required)

Fabric

Minecraft Version (Required)

1.19.2

Mod Version (Required)

4.2.9

Notes (Required)

The issue I'm facing is that when connecting to a fabric backend via velocity, the server settings package of the create mod never seems to make it to the client. E.g. if the max rail placement distance is increased on the server, the client still behaves as if it was at default, the preview shows an error beyond the default length. However, longer rails can still be placed up to the server side limit despite the display. This is quite annoying to deal with as one can't tell where the actual length limit is. Players also can't see each other on journeymap, which may or may not be related.

I've dug into the code and spoken to @IThundxr (Dev of Create:Steam'nRails), which has resulted in me noticing that the relevant variable maxTrackPlacementLength is already set to the value in the server config when the client tries to draw the track overlay for the first time, and then seemingly cached on client side. This seems to imply that said variable is set by ForgeConfigApiPort on world load/login, and that on the setup with velocity this communication is what fails.

Please refer to PaperMC/Velocity#1191 where I have detailed all my research and also included relevant logs.

This is all I've been able to figure out so far. Thanks in Advance for Help!

latest.log (Optional)

No response

4drian3d analyzed the issue on velocity side and found some things you can see here: PaperMC/Velocity#1191 (comment)
Do you think this is something that could be fixed on forge config lib side until the changes are available?
Perhaps a config option that one can enable, with which the client requests the server config again if it failed during LOGIN?

Thanks for reporting. I'm not familiar with any of those server proxies.

I can only tell you that FCAP uses native Fabric Api methods for syncing those configs, meaning Fabric's networking for sending the packets and Fabric's event callbacks for deciding when to send them. No custom Mixins or anything alike.

I've updated the issue over on velocity. I'm finding a bunch of "incorrect key.xxx was corrected from null to its default" errors in my client log, which seems to confirm to me that somewhere along the way those specific packets are getting lost.