This covers all behaviors that I've been able to find regarding tells. With this, we can safely rewrite the whole subsystem - a conversion to Kotlin, for example.
The edit to the production code
The packets that the testing DSL "send" don't have the packetType field inside set. That field is only set when deserializing the packet in the networking code. There's no other way to set them.
I edited ChatInstantMessageService a bit for that reason, as Objects.requireNonNull(packet.getPacketType()) == PacketType.CHAT_INSTANT_MESSAGE_TO_CHARACTER always evaluated to false.
Perhaps something can be done regarding the statefulness of SWGPacket - that's a problem for another day, though.
An idea that sprung to mind was simply setting the fields inside the packet constructors - a ChatInstantMessageToCharacter packet with the PacketType and/or crc of completely different packet makes little sense, so why make it possible.
This covers all behaviors that I've been able to find regarding tells. With this, we can safely rewrite the whole subsystem - a conversion to Kotlin, for example.
The edit to the production code
The packets that the testing DSL "send" don't have the
packetTypefield inside set. That field is only set when deserializing the packet in the networking code. There's no other way to set them. I editedChatInstantMessageServicea bit for that reason, asObjects.requireNonNull(packet.getPacketType()) == PacketType.CHAT_INSTANT_MESSAGE_TO_CHARACTERalways evaluated tofalse.Perhaps something can be done regarding the statefulness of
SWGPacket- that's a problem for another day, though. An idea that sprung to mind was simply setting the fields inside the packet constructors - aChatInstantMessageToCharacterpacket with thePacketTypeand/orcrcof completely different packet makes little sense, so why make it possible.