Incomplete support for message 24312 - AllianceStreamEntry

[fivedashthree]

Upon client connection, message 24311 (AllianceStream) is sent to the client, containing a list of 100 AllianceStreamEntrys. 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, AllianceStreamEntrys can be sent in an AllianceStreamMessage 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 extend Message somehow, and use the ID field for 24312 rather than the entry type.

Fun fun :)

[FICTURE7]

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 the ID field for 24312 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.