The OnPluginPacketReceived callback has proved to be very useful, however it is lacking an equivalent for the outgoing data.
For a specific problem that can't be solved right now... I tried writing a plugin for parsing a proprietary communication protocol that sits on top of telnet, but hit a brick wall in the form of not being able to control what Mushclient is sending to the server. I need to be able to override option negotiation to allow the use of custom codes, but the client resists all attempts to do so. Since the negotiation doesn't even go through OnPluginSend, the only option I have is world.Send, and that escapes the codes, appending a newline to them, trying to turn them into normal commands. So the best I can do right now is to supress the negotiation altogether, by wiping the initial code sequence from the first incoming packet, but that doesn't achieve my goal of replacing the "stock" set of options with a custom one. If, however, OnPluginSend worked like an opposite of OnPluginPacketReceived, then this, and probably other things, could be possible.
For a specific problem that can't be solved right now... I tried writing a plugin for parsing a proprietary communication protocol that sits on top of telnet, but hit a brick wall in the form of not being able to control what Mushclient is sending to the server. I need to be able to override option negotiation to allow the use of custom codes, but the client resists all attempts to do so. Since the negotiation doesn't even go through OnPluginSend, the only option I have is world.Send, and that escapes the codes, appending a newline to them, trying to turn them into normal commands. So the best I can do right now is to supress the negotiation altogether, by wiping the initial code sequence from the first incoming packet, but that doesn't achieve my goal of replacing the "stock" set of options with a custom one. If, however, OnPluginSend worked like an opposite of OnPluginPacketReceived, then this, and probably other things, could be possible.