I'm currently working on a CreateResponse class, which is even more
distinct from LoginResponse - so I've decided to separate it. For
consistency, separating the JS5 login responses seems sensible too.
Signed-off-by: Graham <gpe@openrs2.org>
The client's UI makes it easy to submit invalid dates not supported by
LocalDate. Rather than throwing an exception in a codec, it'd be good to
support representing these for:
* Allowing the development of a debugging proxy server that sits between
the client and game server.
* Making it easier to send the invalid date of birth response to the
creation request.
We'll still switch to LocalDate as early as possible in the packet
handler in the future.
Signed-off-by: Graham <gpe@openrs2.org>
There are now three additional abstract PacketCodec classes:
FixedPacketCodec, VariableBytePacketCodec and VariableShortPacketCodec.
The PacketLength class has been removed, as it is no longer required.
The main reason for this change is that the create suggested names
packet is a bit of an oddball: its length field measures the size of the
packet in longs, not bytes. The codec for this packet will be able to
inherit from PacketCodec directly to implement the custom length logic.
Signed-off-by: Graham <gpe@openrs2.org>
I've also removed the comment - I'm going to have to do something
similar for CREATE_DOWNSTREAM, and I think it's a bit more obvious with
the more distinctive name.
This allows us to deal with a single corner case of the same opcode
being used for two slightly different login response packets, depending
on the request.
For most packets we know (or have a very good guess at) the official
Jagex name, based on the NXT/TFU leaks.
The document will be fleshed out with the payloads and a more detailed
description of every packet in the future.
Signed-off-by: Graham <gpe@openrs2.org>
There's no UPDATE_ZONE_FULL_ENCLOSED packet, so clearing and then
populating a zone actually requires two packets -
UPDATE_ZONE_FULL_FOLLOWS followed by UPDATE_ZONE_PARTIAL_ENCLOSED.
Signed-off-by: Graham <gpe@openrs2.org>
We fsync the temp file before doing the atomic move, which I think is
necessary if the underlying filesystem re-orders the operations (e.g. if
the atomic move is performed before the writes to the temp file have
been flushed to disk).
Similarly we fsync the parent dir before returning. For a single atomic
write in isolation this probably isn't important, but probably is useful
if a sequence of atomic writes is performed in order.
Signed-off-by: Graham <gpe@openrs2.org>
