
Breaking Polymer's netty thread side detection when present on clients.
Patbox opened this issue ยท 0 comments
Describe the bug
When connecting to servers, client side netty event loop threads use names of the server ones, causing Polymer to incorrectly think it's decoding data that client sent to server.
To Reproduce
Steps to reproduce the behavior:
- Install required mods on a server and a client.
- Join the server.
- Get the polymer-based items, whatever via /give command or other way.
- Notice that it uses "backing"/server item instead of vanilla replacements (if used with Universal Graves, items won't have models).
Expected behavior
VMP not breaking assumptions about thread names.
Runtime info (please complete the following information):
- OS: Linux Mint 21.2
- Minecraft version: 1.21.4
- Mod version: 0.2.0+beta.7.190 devbuild for 1.21.4
Other mods
- Fabric API 0.116.1+1.21.4
- Polymer 0.11.6
- Any polymer-based mod adding items (for example Universal Graves)
Checklist
- I am using the official version of the mod.
- I tried the latest development version but the issue persists.
- I searched for similar open issues and could not find an existing bug report on this.
Additional context
Related code VMP code:
https://github.com/RelativityMC/VMP-fabric/blob/ver/1.21.4/src/main/java/com/ishland/vmp/mixins/networking/eventloops/MixinClientConnection.java#L41
https://github.com/RelativityMC/VMP-fabric/blob/ver/1.21.4/src/main/java/com/ishland/vmp/common/networking/eventloops/VMPEventLoops.java
Related Polymer code:
https://github.com/Patbox/polymer/blob/dev/1.21.4/polymer-common/src/main/java/eu/pb4/polymer/common/api/PolymerCommonUtils.java#L179
This is only issue if VMP, Polymer and polymer-based mods are on client. This can happen with a modpack for example.