This commit adds initial support for negotiating the ISAAC session key,
creating accounts, and checking world suitability.
Signed-off-by: Graham <gpe@openrs2.org>
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>
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.
If the future is not successful the channel may have been closed. The
pipeline of a closed channel is empty, so attempting to remove handlers
from it would cause an exception.
Signed-off-by: Graham <gpe@openrs2.org>
There are two main reasons for this change: by default, logback uses
stdout (!) and not stderr. This caused problems in programs like
packclass/unpackclass, where the packclass or JAR files were mixed in
with Netty's debug logging.
Secondly, the debug logging from lots of third-party libraries was
annoying (as it made it difficult to pick out OpenRS2-specific log
messages), so I've disabled lots of it.
Signed-off-by: Graham <gpe@openrs2.org>
This fixes a 1 in 2^32 chance that we'll fail to fetch the world list on
startup.
Of course, updating the player counts will still be borked if we get a
collision, but at least the client won't break entirely.
Signed-off-by: Graham <gpe@openrs2.org>
This commit adds support for:
* Version negotiation.
* HEAD requests.
* Friendly error messages.
* More robust reference counting.
Signed-off-by: Graham <gpe@openrs2.org>
This prevents the archive module from failing on a machine without the
cache installed (like the archive.openrs2.org server).
Signed-off-by: Graham <gpe@openrs2.org>
I'm going to try to minimise use of this (as per
https://github.com/google/guice/wiki/Avoid-Injecting-Closable-Resources).
For example, I'm going to inject a pooling DataSource rather than
Connection objects, as per the advice at the end of the page. However,
HikariCP's DataSource implementation is itself Closeable.
Signed-off-by: Graham <gpe@openrs2.org>
This already caught some cases of public members that should have been
private and one case where the inferred type was too specific.
Signed-off-by: Graham <gpe@openrs2.dev>
