stevengreens10 / minecraft-packet-parser Goto Github PK

This includes:

• Spawn Entity
• Spawn Experience Orb
• Spawn Weather Entity
• Spawn Living Entity
• Spawn Painting
• Spawn Player

This includes:

• Boolean
• Byte
• Unsigned Byte
• Short
• Unsigned Short
• Int
• Long

Parse the Burger JSON file to make a map from ID to Name for all types.

JSON file: https://pokechu22.github.io/Burger/1.15.2.json

This includes:

• Ack. Player Digging: 0x08
• Block Break Animation: 0x09
• Block Entity Data: 0x0A
• Block Action: 0x0B
• Block Change: 0x0C

Notes:

• For "Block Change" (0x0C), just display the block state ID as a number for now. We will need to figure out how we will handle these.

https://wiki.vg/Chunk_Format

Entity Metadata format: https://wiki.vg/Entities#Entity_Metadata_Format

Add all parsers for the "status" and "handshake" states.

There are only 5 of these, and they have pretty simple formats.

Ensure state is being correctly changed.

We need to be able to parse arrays of any length for any of the other data types.
It would be great to find a way to do this without adding a ton of methods for each array type.

There should be a corresponding method in the Serializer for every Parser.parse_____ method.

See https://wiki.vg/Protocol#Data_types for reference

... Instead of manually creating byte arrays.

Using decodeHex is much less boilerplate and is much more concise.

Some packets have an identifier and then a byte array. The identifier determines the format of the byte array.

https://wiki.vg/Plugin_channels#minecraft:brand

This includes:

• Float (4 byte)
• Double (8 byte)

Both are using the IEEE 754 standard.

Do not attempt to write the NBT parser. We should be able to grab a Maven dependency or jar file to do this for us.
It is complex enough and has been done enough times to warrant not reinventing the wheel.

Slot format: https://wiki.vg/Slot_Data

This includes:

• String
• Chat
• Identifier

They are parsed the same but are formatted differently.

For chat, ensure proper JSON formatting.
For identifier, ensure proper namespace formatting.

Notes:

• UUID is a 16 byte integer
• Position is a triplet of 3 integers, x, y, and then z
  • X and Z are 26-bit integers
  • Y is a 12-bit integer

By running the command $ java -cp server.jar net.minecraft.data.Main --reports, you can generate blocks.json which has all of the IDs for every block state in the game.

Parse this file and create a map/array to convert ID into a human-readable name.

Bonus points: Map to a Java object that has all of the property information as well as the name

Add all parsers for the "login" state.

There are 5 packet types for clientbound packets, and 3 for serverbound packets.

Add special checks for the "Set compression" and the "Encryption request/response" parser.

Exit the program if compression or encryption is enabled as those will not be supported at first, and will prevent us from parsing the rest of the packets.

Ensure the state is being correctly handled.

It's clunky and a lot of boilerplate.

It's much easier to just add the exception to the test method signature. The test will still fail if the exception occurs.

• Entity Animation (clientbound) ID: 0x06
• Statistics ID: 0x07

Only two parsers because "statistics" appears to take more than the average amount of work.

This includes:

• VarInt (already done)
• VarLong
• Angle

Angle may just be equivalent to an unsigned byte. If that is the case, there is no need to write a separate parser method for it.

Should be able to accept incoming connections via socket and forward traffic to an offline-mode Minecraft server.

Also, send packets from the server back to the client.

Parsers should have a field in their result object for outgoing bytes. This is so that parsers can parse the incoming message and potentially make modifications before forwarding the message to the client/server.

Uncompleted parsers should return incoming bytes.

There is currently a single static "state" variable on the parser, but the state needs to vary on a per-connection basis.

As such, this needs to instead be a map of (client IP?) to state.

Instead of passing the client info all the way down to the individual parser level, I think it'd be best to have the PacketParser.parse function return the new state.

I think as part of this issue, we should also require specifying the server IP as a command-line argument. Then update how we are determining clientbound or serverbound direction to use IP instead of port only. Also applies to isServerPacket