andrewrk/node-minecraft-protocol — pull request #77 by roblabla (2014-03-16 17:29:26+00:00)
Title: Allow sending and listening for packets by "name" v2

This is the followup of #70 . Big thanks to @deathcap for the original work.

PR Breakdown
============

Adds descriptive names for each packet and changes to allow using the name as an alternative to state/number.

- Is this a worthwhile feature? I think so, makes it easier to use the API without knowing intricate specifics of the protocol, for example from mineflayer:
```javascript
bot.client.on(0x38, function(packet) {
```
would have to change to "0x26" for the 1.7 update, trading one "magic number" for another. But with this PR, you can simply write:
```javascript
bot.client.on('map_chunk_bulk', function(packet) {
```
and the code is much more descriptive and maintainable. node-minecraft-protocol already decodes field names, so I'd say decoding packet names is well within the scope of this module. Also it mitigates the complexity of having to listen on a stringified array "[state, id]", since the names are unique across all protocol states — the name infers both the state and id. (Or at least should be... I hope this proves to be maintainable in the future)

- Are the names themselves alright? They are from [ProtocolLib](https://github.com/aadnk/ProtocolLib/blob/master/ProtocolLib/src/main/java/com/comphenix/protocol/PacketType.java) , so they shouldn't ever change. The convention used is simply to lowercase protocollib's names. (Should we change convention to camelCase ? I tried it, but I found the end result to be harder to read).

- lib/client.js setSocket() now emits up to 4 events per packet: packetName, [state,id], id, 'packet' - is this too much? Benchmarking might be a good idea. In the event it slows down too much, I think fusing id and [state, id] into one would be a good idea, in a "State.ID" string. Such a string could very easily be decoded, and would be very easily readable. Another idea would be to overload the .on() method to translate everything into a single event. The on method should be called less often than the emits

- How about the data structures in lib/protocol.js? I added packetIDs, packetStates, packetNames, in addition to the existing 'packets' object which maps to the fields. Could be worthwhile to merge packetIDs and packets so the field names and packet names are defined together, but I wasn't sure of the best way to do this.

- Listening/sending by state/id still works as before.

- Updated the examples to demonstrate this new API (plus a few minor unrelated changes: client_chat.js offline mode, fix the server.js example to send the given message, and remove unsupported '§e' styling).