Create + Raknetify train weirdness
Describe the bug General weirdness when playing around with trains while connecting to the server with raknetify. Here are acouple of issues ive encountered (Player A: has Raknetify. Player B: doesnt have Raknetify)
- If
Atries to make a train, it will produce aFake derailedtrain, and the bogeys glitch out either spinning wild or rotated 90 degrees - If
Bmakes a train, it will produce aFake derailedtrain like example 1 - If
Bis riding and moving aFake derailedtrain,Awill see theFake derailedtrain stay still even though its moving for B and other players without Raknetify, and whenBdisembarks, he TPs to where to train is supposed to be - If
Agets on theFake derailedtrain and spam right click fast enuf on the controls, he can control it, but the train will be in a superpossition state ofDerailedandNot derailed, and when moving it stutters because of the state flipping
To Reproduce Steps to reproduce the behavior:
- Make a server with Raknetify and Create
- Have 2 people connect 1 with raknetify and 1 without
- Have both of them make trains, and observe weirdness (if it doesnt show, try having a train in the world, and the raknetify player relog)
Expected behavior Normal create train behaviour
Screenshots

Runtime info (please complete the following information):
- OS: Windows 11, Server on ARM Linux
- Minecraft version: 1.18.2
- Mod version:
0.1.0+alpha.5.4 - Mod branch: (fill this if you are not using the default
verbranches)
Crash reports / logs Pastebin link
Other mods Pastebin link
Checklist
- [
X] I am using the official version of the mod. - [
X] I tried the latest development version but the issue persists. - [
X] I searched for similar open issues and could not find an existing bug report on this.
Additional context If i log on the server without raknetify the train works as normal
i think this has something to do with it, it shows up if i somehow got the train working by spamming the station assemble and dissassemle button
[03:13:01] [Netty Client IO #8/ERROR]: LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records:
Created at:
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:402)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
io.netty.buffer.UnsafeByteBufUtil.copy(UnsafeByteBufUtil.java:436)
io.netty.buffer.PooledUnsafeDirectByteBuf.copy(PooledUnsafeDirectByteBuf.java:216)
io.netty.buffer.AbstractByteBuf.copy(AbstractByteBuf.java:1194)
io.netty.buffer.WrappedByteBuf.copy(WrappedByteBuf.java:882)
net.minecraft.class_2540.copy(class_2540.java:1338)
net.minecraft.class_2658.method_11458(class_2658.java:68)
net.minecraft.class_634.handler$znb000$badpackets_receiveS2CPacket(class_634.java:5417)
net.minecraft.class_634.method_11152(class_634.java)
net.minecraft.class_2658.method_11457(class_2658.java:60)
net.minecraft.class_2658.method_11054(class_2658.java:8)
net.minecraft.class_2535.method_10759(class_2535.java:172)
net.minecraft.class_2535.method_10770(class_2535.java:157)
net.minecraft.class_2535.channelRead0(class_2535.java:55)
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
com.ishland.raknetify.common.connection.FrameDataBlocker.channelRead(FrameDataBlocker.java:18)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
com.ishland.raknetify.common.connection.MultiChannelingStreamingCompression.channelRead(MultiChannelingStreamingCompression.java:142)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
com.ishland.raknetify.common.connection.MultiChannellingEncryption.channelRead(MultiChannellingEncryption.java:76)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:61)
io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:370)
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
java.base/java.lang.Thread.run(Thread.java:833)
any idea on what's happening?
I don't actually know what is causing this problem and I haven't got any time to look into this issue yet.
I'm assuming create uses some packet wizardry for its entities. Of which, raknetify doesn't support.
still persists
I kinda suspect that this might be related to the datatracker, given this isn't the first I've seen of a similar issue; Polysit has similar where the datatracker sends an update only once (the initial update), and if it goes out of order, the seat entity visually remains a full sized armour stand instead of turning into a marker for the client.
On the client, Create's trains has the following packets, as examined by gadget on 1.19.2:
ChunkData
porting_lib:extra_data_entity_spawn
EntityTrackerUpdate
EntityVelocityUpdate
ChunkData
...
porting_lib:extra_data_entity_spawn
EntityTrackerUpdate
EntityVelocityUpdate
porting_lib:extra_data_entity_spawn
EntityTrackerUpdate
EntityVelocityUpdate
...
create:main eventually```
Sorry for the late update but. after that commit everything seems fine, closing now