Cannot register new packet in states.go

[luiz-otavio]

Currently, I'm working on a different session handler after login state to listen incoming Flying packets.
But for some reason, I cannot register some packets in Server and Client bounds due to duplicate packet id.

I made a FallStatus packet which is designed with ID 0x03 in Play state for Protocol Version 47 (1.8.8), but when I try to register it, gate crashs and a panic message is sent with a specific message about a duplicate ID from Protocol Version 335 (1.12) of Packet.Chat.
Can not register packet type packet.Chat with id 0x33 for protocol 335 because another packet is already registered
I'm registering those packets like that:

Play.ServerBound.Register(&p.FallStatus{},
  m(0x03, version.Minecraft_1_8))

[robinbraemer]

You cannot register a packet with the same ID on the same registry.
Play.ServerBound is a registry and in your case Chat conflicts with your FallSatus packet.

gate/pkg/edition/java/proto/state/states.go

Line 93 in af0e0b8

m(0x03, version.Minecraft_1_12),

Are you creating a custom FallStatus packet that does not officially exist? Try to use a higher ID like 0x64 so it never conflicts with an actual existing packet ID. Here is a conversion table for your convenience http://cactus.io/resources/toolbox/decimal-binary-octal-hexadecimal-conversion.

Does this solve your issue?

[luiz-otavio]

I will try it later, thanks

[luiz-otavio]

Seems like I have no time to test, sorry. I will close this due to inactivity.

[luiz-otavio]

You cannot register a packet with the same ID on the same registry. Play.ServerBound is a registry and in your case Chat conflicts with your FallSatus packet.

gate/pkg/edition/java/proto/state/states.go

Line 93 in af0e0b8

m(0x03, version.Minecraft_1_12),

Are you creating a custom FallStatus packet that does not officially exist? Try to use a higher ID like 0x64 so it never conflicts with an actual existing packet ID. Here is a conversion table for your convenience http://cactus.io/resources/toolbox/decimal-binary-octal-hexadecimal-conversion.

Does this solve your issue?

No, I'm really trying to listen for 0x03 packet from protocol 47.
I tried to change the packet ID to 0x66, but it didn't work well.

[luiz-otavio]

I will try to use another packed instead of 0x03.

[luiz-otavio]

Unfortunately, the same packet ID which I have choice is already registered in protocol 335 (1.12), it looks like I cannot register it.
What about we check those entries per protocol version? I think BungeeCord/Velocity works like that for each incoming-packet.

[luiz-otavio]

Unfortunately, the same packet ID which I have choice is already registered in protocol 335 (1.12), it looks like I cannot register it. What about we check those entries per protocol version? I think BungeeCord/Velocity works like that for each incoming-packet.

I think we could add a one more check at here about the PacketType of the ID?

[robinbraemer]

Unfortunately, the same packet ID which I have choice is already registered in protocol 335 (1.12), it looks like I cannot register it. What about we check those entries per protocol version? I think BungeeCord/Velocity works like that for each incoming-packet.

Yes, we already check entries per-protocol version here

gate/pkg/edition/java/proto/state/registry.go

Line 139 in 6c8ba60

registry, ok := p.Protocols[protocol]

[robinbraemer]

Unfortunately, the same packet ID which I have choice is already registered in protocol 335 (1.12), it looks like I cannot register it. What about we check those entries per protocol version? I think BungeeCord/Velocity works like that for each incoming-packet.

I think we could add a one more check at here about the PacketType of the ID?

I don't think type checking wouldn't work because on the wire the packet ID matters, not the Go type. Otherwise, when receiving a packet with an ID that has two packet types registered in the same state & protocol version, Gate wouldn't know which type to choose.

[robinbraemer]

This is the bit that matters to you I think

gate/pkg/edition/java/proto/codec/decoder.go

Lines 192 to 208 in 6c8ba60

	// Read packet id.
	packetID, err := util.ReadVarInt(payload)
	if err != nil {
	return nil, err
	}
	ctx.PacketID = proto.PacketID(packetID)
	// Now the payload reader should only have left the packet's actual data.
	// Try find and create packet from the id.
	ctx.Packet = d.registry.CreatePacket(ctx.PacketID)
	if ctx.Packet == nil {
	// Packet id is unknown in this registry,
	// the payload is probably being forwarded as is.
	return
	}

[robinbraemer]

Could you explain your use case why you want to register two packet types for the same id? Maybe I can help you better understand what your goal is and or what confusion you might have.

[luiz-otavio]

Could you explain your use case why you want to register two packet types for the same id? Maybe I can help you better understand what your goal is and or what confusion you might have.

Sorry for late response.

I'm working on a client-side world for the player to check about what packets he's sending to the server. Basically, I want to listen for alot of specific packets to ensure if a player is a BOT or however. But, when I was trying to register some packets like 0x04 and 0x03 from Protocol 47, it looks like that they have changed their PacketID in higher versions, so I cannot register them.

[luiz-otavio]

I got an example video here.
I'm just trying to send the normal login sequence for the client to starting the session about handling packets.

[luiz-otavio]

Fun fact: The same idea was commented in #47

[robinbraemer]

I understand. If I were to do this I would go with a different approach and make Gate again more aware of the state of the player. I suggest registering a "virtual server/client-side world" hosted by a Gate plugin that moves every joining player to it. Use event listeners to restrict the boundaries of the player (e.g. cannot switch servers, chat or use commands until the player did the cracked authentication and so on). This way Gate works much more predictable and as is used as intended, by plugins. After joining handshake on the "virtual server" your code can do everything you want with packets.

My plan is to sort out Minecraft packet processing from Gate into a reusable library for writing highly composable Minecraft servers into another repository. But until then, I cannot give much support for very hacky stuff ;D.

[luiz-otavio]

I understand. If I were to do this I would go with a different approach and make Gate again more aware of the state of the player. I suggest registering a "virtual server/client-side world" hosted by a Gate plugin that moves every joining player to it. Use event listeners to restrict the boundaries of the player (e.g. cannot switch servers, chat or use commands until the player did the cracked authentication and so on). This way Gate works much more predictable and as is used as intended, by plugins. After joining handshake on the "virtual server" your code can do everything you want with packets.

My plan is to sort out Minecraft packet processing from Gate into a reusable library for writing highly composable Minecraft servers into another repository. But until then, I cannot give much support for very hacky stuff ;D.

Alright then, I will make it as plugin if possible.
Closing it and thanks <3