this is not actually recommended, as it _technically_ does "mess up"
the sequence (1-3 zero-bytes are being encrypted along with your 1-3
remaining bytes in non-dword-sized data buffers, but those additional
encrypted zero-bytes are not being given back to you at the end).
however, in my opinion, this is quite unlikely to pose a problem for
anyone. for dealing with PSO packets, i'm pretty sure all of those end
up being dword-sized anyway, so no issue there. for encrypting and
decrypting offline quest data, the compressed bin/dat data _could_
technically be non-dword-sized (as i actually encountered today) so you
would otherwise need to pad the input data before calling crypt()
anyway. and in this case you are not going to be using that very same
Crypter instance to do any further encrypting/decrypting ... so it's
actually no problem at all.
so, to me, the convenience of having crypt() just automatically be able
to deal with any arbitrary size of data was worthwhile.
meh.
get rid of the generalized traits that the read/write methods were
located in. now those methods are just located directly in the struct
impl itself
also cleaned up quest bin/dat errors
added validation checks in quest bin/dat reading
since we're doing offset/length checks regardless, calling memcmp here
instead of doing a slice comparison is at least twice as fast during
non-release builds. this is nice, as prs_compress can be quite slow
during non-release builds. and obviously during release builds, this
would be compiled down to a memcmp-equivalent anyway.
use individual error types for both bin and dat modules instead of
all three modules sharing the same error type. maybe marginally better
this way? at least should generally be more clear about whether the
error is related to a bin, dat or general quest processing now
Gered