Gradle seems to re-run this every time, so Drone ended up building the
KDoc twice (once in the build stage and again in the publish stage).
Removing it from the build stage ensures Drone only builds KDoc once.
Signed-off-by: Graham <gpe@openrs2.dev>
The output is significantly nicer.
External documentation links don't seem to work correctly at the moment,
so I have commented those out for now.
Signed-off-by: Graham <gpe@openrs2.dev>
I'm not yet convinced we have all the files - I've since realised the
"complete" 550 cache floating around is probably modified and includes
some files from a later revision.
Signed-off-by: Graham <gpe@openrs2.dev>
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>
Unit tests to follow - I've been working on these classes for a few days
now, so I wanted to make sure they get backed up in the repository.
Signed-off-by: Graham <gpe@openrs2.dev>
Will be used by the packclass implementation. Like Cp1252Charset, the
JDK isn't guaranteed to provide an implementation of this charset.
Signed-off-by: Graham <gpe@openrs2.dev>
Slightly different to the standard implementation, as like the client it
considers NUL to be an unmappable character. (Furthermore, the standard
implementation isn't in StandardCharsets.)
It also provides fast methods for encoding/decoding a single byte/char
at a time.
Signed-off-by: Graham <gpe@openrs2.dev>
This allows us to make them private (rather than internal) and the type
as a whole is immutable.
It does mean we need to convert the key to an IntArray every time we use
it now. However, I hope that the JVM will be smart enough to inline the
toIntArray() method and also smart enough to realise it doesn't escape,
allowing it to allocate it on the stack rather than the heap.
This commit also adds methods for converting XteaKeys to hex, and
converting from hex/integer arrays to an XteaKey object.
Signed-off-by: Graham <gpe@openrs2.dev>
