Packet Handling in JS

[giwo]

I've begun working on adding the ability to create outgoing packets and overload incoming packet handling, and thus wanted to field some discussion on the topic.

First, outgoing packet creation in JS.

My plans, as they stand, are to mimic the "Gump" JS handling to a degree. Creating a new packet would be simple as

Code: Select all

var myPacket = new Packet;

The Packet class would then have some accessors and mutators similar to how we handle packets now in the source, IE:

Code: Select all

var myPacket = new Packet;
myPacket.WriteByte( 0, 0xBF );
myPacket.WriteShort( 1, length );
etc

The current mutators include WriteByte(), WriteShort(), WriteLong(), and WriteString(). I am still considering if we need a WriteArray() function.

This brings me to one question, do we actually need accessors? If there is a need, I am happy to add them, but otherwise, I don't see the point.

Lastly, we need to send the packet, which would be a Socket function, something liket his

Code: Select all

socket.Send( myPacket );

Second, Incoming Packet handling in JS

This one is a bit more fluid of an idea, at the moment, but I have some initial ideas.

My thoughts, at the moment, are to mimic our command handling to an extent. When a packet is received we give the JS an option to fire first, and it can then return a value telling the code wether or not to execute its handling (if any).

Basically we would associate it by the packet number (which in the case of the 0xBF packet would be a combination of the packet ID and the subcommand, so the unsigned short storage we currently use for commands and such will work fine).

Each packet handler would have its own file, and be responsible for registering itself. This would create a map that associates a given packet ID with the script number, allowing for quick searches to see if an overload is present in the JS.

Upon finding an overload, the JS would be fired, a function similar to onPacket() which would be passed with a socket. From there all the information (character, bytes, etc) can be pulled from the socket and used at the JS scripters discretion. Finally, a return false; would tell UOX3 to NOT use its default packet handling, where a return true; (or no return value) would assume it should handle the packet as usual.

Questions, comments, thoughts are very welcome, as this will likely be implemented for the next release (0.98-3.2) and I would like to make it as fully-featured and easy to use as possible.

[Sydius]

Sounds great, but how about an option to skip that step for people who do not need it? It would also make debugging easier if you can just turn off all custom packet handling with the flip of a config value.

[giwo]

That's a good idea, and simple enough to implement with a uox.ini entry.