Open fivedashthree opened 7 years ago
Hmm, yeah AllianceStream
of the client's clan is sent when it logs in and am pretty sure ChatAllianceStreamEntry
's implementation is correct. It inherits the AllianceStreamEntry
class which virtually implements the ReadStreamEntry
method which only reads the header.
I do have 24312
implemented as AllianceStreamEventMessage
and I do send AllianceStreamEntry
objects individually when needed to appropriate clients (In a very hackish manner though).
And for the clan management messages we will definitely use an enum something like a ClanActions
enum or something else.
I don't really understand what do you mean by though
extend
Message
somehow, and use theID
field for24312
rather than the entry type.
I do like the idea of the 'looking for the next entry with a sort of signature scan' but I don't think its a good idea to add it to the read methods itself, but use it more as a helper method to help debug and figure out the boundaries of entries and implement the reading of the entry type properly.
Upon client connection, message
24311
(AllianceStream
) is sent to the client, containing a list of 100AllianceStreamEntry
s. The library has partly implemented support for these messages, however all the message types still need to be implemented correctly.I've been spending a while looking at dumps of these messages to decode the formula, and only just now discovered that you already had a chunk of it in
ChatAllianceStreamEntry
. As far as I know that code is either out of date or just wrong anyway, but I'll look at it more and probably write up a class for the other message types.The problem with reading through the AllianceStreamMessage is that there's no fixed separator between messages - they're all just bundled together. This means that if we can't read one message properly, then we likely can't read any of the messages after that. Until we manage to implement all the message types, I've written a hacked-together function to heuristically find the next message. It scans through the message one byte at a time, looking for 3 consecutive lettters (? the minimum for a username), then skipping back 36 bytes (where the start of the message would be) and attempting to read a message. If that doesn't work, it skips forward and tries again. It's worked great for me (because I have no idea where to start with reading troop request messages) but it would skip more messages if anybody's username didn't start with 3 letters.
Anyway, that's that. I'll get to work on the other message types. How do you suggest we implement administration messages? (e.g. kicking, promoting). They all fall under one 'primary' message type ("0x04") but after the header they have a secondary message type that seems to cover everything from clan war searching, accepting a join request or leaving the clan. Regardless of the type, these messages all have the same format, so in my implementation I used an
AdministrationAction
enum.Finally,
AllianceStreamEntry
s can be sent in anAllianceStreamMessage
upon initial connection but they can also be sent individually, which the library has no support for. I'll leave it up to you to decide how to implement this because it's your library, but you'll first off need to make it also extendMessage
somehow, and use theID
field for24312
rather than the entry type.Fun fun :)