It was solved before by just guessing between a few numbers, because thats simply faster for us than to record the packet and look at its length.
But I don't like guessing and especially not when it can in fact be avoided.
There are 2 ways to do this:
- we can let kore dynamically find the block size from the known range of charBlockSizes
here's the proof of concept: note: kRO recently started using:
note: we do need the correct position of charList in 006B with this approach...'006B' => ['received_characters', 'v C3 C L3 a7 a*', [qw(len max_slots available_slots premium_slots unknown1 code time1 time2 unknown2 charList)]], # PACKETVER >= 20100413
- charBlockSize is bound to serverType, so there is no need to let the user specify it...
In fact, it uses a list of the same structure thats found in 006D,
so we can just look at that packet and use the appropriate block size/unpackstring.
If we were to implement dynamic struct unpacking, we could use the struct used in 006D for 006B. (this would ofcourse be the ideal solution)
note: some similar approach can already be implemented in kRO, due to its timeline-like properties.
So thats how to ban charBlockSize from user configuration.
The charBlockSize myth is Busted!
Tho I can see use in the charBlockSize configuration option for servers other than kRO/eA,
since there is nobody to support those servers by src, maybe its better to let users support it by conf...