Jump to content

Recommended Posts

Posted

Upon upgrading my dynamic link panels mod to 1.7.2, it appears my packets are being truncated by netty.

 

I am using slightly modified versions of the simpleimpl packet handlers, only modified gain access to playerentity.

 

This is the code I'm using in my packet:

 

   public void toBytes(ByteBuf buffer, ChannelHandlerContext ctx)
    {
    	if (this.compressedChunkData == null)
        {
            deflateGate.acquireUninterruptibly();
            if (this.compressedChunkData == null)
            {
                deflate();
            }
            deflateGate.release();
        }
    	buffer.writeInt(dimension);
        buffer.writeInt(this.xPos);
        buffer.writeInt(this.zPos);
        buffer.writeBoolean(this.includeInitialize);
        buffer.writeShort((short)(this.yPos & 65535));
        buffer.writeShort((short)(this.yMSBPos & 65535));
        buffer.writeInt(this.compressedChunkData.length);
        int i = buffer.writableBytes();
        buffer.ensureWritable(this.compressedChunkData.length);
        buffer.writeBytes(this.compressedChunkData);
    }

@Override
public void fromBytes(ByteBuf in, ChannelHandlerContext ctx) {
	this.dimension = in.readInt();
	this.xPos = in.readInt();
        this.zPos = in.readInt();
        this.includeInitialize = in.readBoolean();
        this.yPos = in.readShort();
        this.yMSBPos = in.readShort();
        int len = in.readInt();

        if (field_149286_i.length < len)
        {
            field_149286_i = new byte[len];
        }
        
        in.readBytes(field_149286_i, 0, len);
        int i = 0;
        int j;
        int msb = 0; //BugFix: MC does not read the MSB array from the packet properly, causing issues for servers that use blocks > 256

        for (j = 0; j < 16; ++j)
        {
            i += this.yPos >> j & 1;
            msb += this.yPos >> j & 1;
        }

        j = 12288 * i;
        j += 2048 * msb;

        if (this.includeInitialize)
        {
            j += 256;
        }

        this.chunkData = new byte[j];
        Inflater inflater = new Inflater();
        inflater.setInput(field_149286_i, 0, len);

        try
        {
            inflater.inflate(this.chunkData);
        }
        catch (DataFormatException dataformatexception)
        {
            error = true;
        }
        finally
        {
            inflater.end();
        }
}

 

And this is the crash I'm getting on the client side:

 

Caused by: java.lang.IndexOutOfBoundsException: readerIndex(21) + length(2879) exceeds writerIndex(36): SlicedByteBuf(ridx: 21, widx: 36, cap: 36/36, unwrapped: UnpooledHeapByteBuf(ridx: 1, widx: 37, cap: 37/37))
at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1160) ~[AbstractByteBuf.class:?]
at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:668) ~[AbstractByteBuf.class:?]
at com.shadowking97.mystcraftplugin.dynamicLinkPanels.network.packets.ChunkInfoPacket.fromBytes(ChunkInfoPacket.java:131) ~[ChunkInfoPacket.class:?]
at com.shadowking97.mystcraftplugin.dynamicLinkPanels.network.impl.DLPIndexedCodec.decodeInto(DLPIndexedCodec.java:17) ~[DLPIndexedCodec.class:?]
at com.shadowking97.mystcraftplugin.dynamicLinkPanels.network.impl.DLPIndexedCodec.decodeInto(DLPIndexedCodec.java:1) ~[DLPIndexedCodec.class:?]
at cpw.mods.fml.common.network.FMLIndexedMessageToMessageCodec.decode(FMLIndexedMessageToMessageCodec.java:77) ~[FMLIndexedMessageToMessageCodec.class:?]
at cpw.mods.fml.common.network.FMLIndexedMessageToMessageCodec.decode(FMLIndexedMessageToMessageCodec.java:17) ~[FMLIndexedMessageToMessageCodec.class:?]
at io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81) ~[MessageToMessageCodec$2.class:?]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) ~[MessageToMessageDecoder.class:?]
... 18 more

 

The server isn't reporting any errors, so it *appears* buffer.ensureWritable is passing, allowing the packet to send the full chunkData... but the client isn't receiving the 2879 bytes that it's supposed to.

 

If I can just be pointed in the right direction to ensure my packets are being sent and received completely, that would be lovely. Thank you!

Posted

Well, it is probably just a programming mistake.  Honestly you're probably making the payload processing a little more complicated than necessary, although your general approach seems workable.  Generally you shouldn't need to access the bytes in the buffer directly, but use ByteBuf and ByteBufUtils to access it.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Posted

They're not odd computations, they're how vanilla minecraft compresses the chunk data that I'm sending to my second dimension renderer. This is a converted vanilla minecraft packet so I can redirected to my instance of theWorld instead of the normal one.

 

Here's my problem:

 

I'm writing to the packet, both the length of the data and the data itself:

 

        buffer.writeInt(this.compressedChunkData.length);
        int i = buffer.writableBytes();
        buffer.ensureWritable(this.compressedChunkData.length);
        buffer.writeBytes(this.compressedChunkData);

 

And then I'm attempting to read it:

 

int len = in.readInt();

        if (field_149286_i.length < len)
        {
            field_149286_i = new byte[len];
        }
        
        in.readBytes(field_149286_i, 0, len);

 

But when I try to read it:

 

Caused by: java.lang.IndexOutOfBoundsException: readerIndex(21) + length(2879) exceeds writerIndex(36): SlicedByteBuf(ridx: 21, widx: 36, cap: 36/36, unwrapped: UnpooledHeapByteBuf(ridx: 1, widx: 37, cap: 37/37))

 

So it SHOULD be sending a packet with the size of 21+2879, but it's only receiving a packet with the size of 36. The server isn't giving me any warnings or errors about the packet being too big when I try to send it (using simpleimpl), but the client isn't receiving it.

 

 

In other notes: I have just switched my packet pipeline to one of the tutorial ones that doesn't use simpleimpl, editing it so I didn't have to mess with my packets (other than switching which classes everything extends), and it started working fine. Other than the fact that the tutorial I used was marked as having horrible memory leaks. But at least now I know it's not anything wrong with my code, but some error or limitation within simpleimpl. At least in 1083.

Posted

They're not odd computations, they're how vanilla minecraft compresses the chunk data that I'm sending to my second dimension renderer.

 

On the contrary; they are odd in the sense that they are useless and out of place where they are. The uncompressed size is readily available to the sender (and when encoded as an integer) to the receiver as well. Computing it is a futile effort that just wastes cycles. See?

Posted

Mrph, thanks. I hadn't tried running optimizations on code I got from vanilla yet.... renamed variables only, basically.

 

But anyway, now I have to track down what's causing the memory leak in my new packet pipeline and fix it. Then I should be good...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I can't figure out if you're looking for help trying to steal someone elses work, or cheat at the game....
    • Title: Why Is It So Hard to Rename and Restructure Mods Like Xray or AntiXray? 🤔 Post text: Hey everyone! I’ve been digging into Minecraft modding for a while and have one big question that I can’t figure out on my own. Maybe someone with more experience could help or give me some advice. Here’s the issue: When I take a “normal” Minecraft mod — for example, one that just adds some blocks or new items — I can easily change its structure, package names, or even rebrand it entirely. It’s straightforward. But as soon as I try this with cheat-type mods like XrayMod or AntiXray, everything falls apart. Even if I just rename the classes, refactor the packages, or hide its identity somehow, the mod either breaks or stops working properly. XrayMod in particular is proving to be a nightmare to modify without losing its core function. So my question is — why is this so much harder with cheat mods like Xray? Is there something fundamentally different about how they’re coded, loaded, or protected that prevents simple renaming or restructuring? And if so, how can I actually learn to understand someone else’s cheat mod enough to safely refactor it without breaking the core features? I’ve already been spending over two months trying to figure this out and haven’t gotten anywhere. It feels like there must be some trick or knowledge I’m missing. Would really appreciate any thoughts, tips, or references — maybe there are guides or techniques for understanding cheat-mod internals? Or if you’ve successfully “disguised” a cheat mod like Xray before, I’d love to hear how you did it. Thanks in advance for any help or discussion. ✌️
    • just started making cinamatic contect check it out on my channel or check out my facebook page    Humbug City Minecraft Youtube https://www.youtube.com/watch?v=v2N6OveKwno https://www.facebook.com/profile.php?id=61575866982337  
    • Where did you get the schematic? Source/Link? And do use an own modpack or a pre-configured from curseforge? If yes, which one On a later time, I can make some tests on my own - but I need the schematic and the modpack name
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.