OffroadPackets

Offroad Packets

This is a library for sending and receiving custom packets that won't ever conflict. The names of packets are transmitted as strings, which is less efficient, but guarantees you'll have no conflicting IDs and also that the order you register them in doesn't matter.

This library only registers the packet ID `0, because it's not used by the base game. Unless a mod GUID only contains the characters %*/49>@EJOTY^ejoty~`` after a space anywhere, this also won't conflict with iiVeil's PacketHelper. It should actually be completely cross-compatible and you should be able to use both at once if you really wanna. If your GUID's offset evaluates to 0, you have bigger problems such as conflicting with the game if you register so much as 2 packets anyways, and that's why i made this library, as it avoids such issues altogether.

Not on windows?

This library is built against the windows version of Facepunch.Steamworks. If you're not on Windows, install UnifiedSteamworks.

XML Documentation

The download includes an `.xml` documentation file. As an end user, you can just delete this. As a developer, it provides documentation as you're writing your code.

Terminology

• A "Server Packet" is a packet sent by the server, to a client (or multiple clients).
• A "Client Packet" is a packet sent by a client, to the server.
• A "Server Packet Handler" is a method on the client that handles a Server Packet.
• A "Client Packet Handler" is a method on the server that handles a Client Packet.
• A "Request" is a special type of packet which also has a response.
• A "Request Handler" is a special type of packet handler which writes a response to the Request.

Registering packet handlers

There are 2 main ways you can register Offroad Packets. Either you can do it the good-looking way with attributes, or you can register everything manually. Make sure you're `using Terrain.Packets;`

You don't have to patch any methods to register packets. You should add them only once when your mod initializes and it'll be persistent even if the network objects are destroyed.

Handler methods

For both methods of registering packet handlers, every handler must have one of the following signatures:

• `void ServerPacketHandler(BinaryReader reader)`
• `void ClientPacketHandler(int fromClient, BinaryReader reader)`

• `void ServerRawPacketHandler(byte data)`
• `void ClientRawPacketHandler(int fromClient, byte data)`

• `Task ServerRequestHandler(BinaryReader reader, BinaryWriter writer)`
• `Task ClientRequestHandler(int fromClient, BinaryReader reader, BinaryWriter writer)`

• `Task ServerRawRequestHandler(byte data)`
• `Task ClientRawRequestHandler(int fromClient, byte data)`

The raw handlers get a byte array which is exactly the data received. The non-raw handlers are wrapped in a method that manages their readers and writers.

A request handler can be asynchronous.

The manual way

First, you need to create a `new OffroadPackets(string guid) with your mod's GUID. This doesn't have to be your mod's GUID, but generally that's what you'll likely want, as it should be unique anyways and this ID also should be unique. You should keep track of this object in your code, but if you don't, you can access it through OffroadPackets.Instances[guid]. For the remainder of this document, i'll assume you assigned this to a variable named packets`.

To register a packet or request handler on the server or the client, call `packets.Handle(name, handler), where name is a string (usually nameof your handler method) and handler` fits any of the signatures described in Handler methods.

The Beautiful™ way

Create a new class with an `OffroadPacketAttribute. Or don't, i don't care. Fuck it, if you don't wanna create a new class, that's cool too, add your packet handlers in your plugin, why not? If you do add an attribute, the GUID of your mod's packets will be the name` field, or a default value that depends on how exactly you register it.

In the plugin's constructor (or