- println output cleaned up a fair bit
- now actually handles scenarios where multiple PSO packets are sent in
single TCP packets. whoops!
- removed intermediate PsoPacket struct ... just use GenericPacket
- somewhat better way of managing changing client/server "peers" as
the client connects to different servers within the same pcap capture
- removing some old unused functions
- not borrowing fields from a packed struct (PacketHeader)
- minor things that will likely be changed again when i clean things up
more later on ...
doing this because i figure this quest info display stuff is _probably_
generally useful, and at the very least i will be re-using it for the
separate gci extraction tool that is going to be committed here next ...
this is probably not an exhaustive set of potential errors, but it
accounts for all the possible ones i've seen as i've been working on
this, that are basically always a result of "bad data".
still a bit worried about potential panics also resulting from bad data
related to overflows and such things ...but have not seen any so far
i don't know how much better or worse either one is really, but i think
i like to_array() better overall. guessing to_array() is probably a bit
better overall, as it should only be one allocation in all cases
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.
Gered