It's more concise and I suspect Kotlin's implementation is better than
Java's, as it seems to take available() into account.
Signed-off-by: Graham <gpe@openrs2.org>
This has the convenient side effect of us no longer needing to exclude
the byteunits dependency from minimisation.
Signed-off-by: Graham <gpe@openrs2.org>
I've decided to reverse my decision in
e3e0094b43.
If you treat empty loc groups as valid, some OSRS caches do have 100%
valid keys. Being able to pick these out in the list of caches will be
useful.
Signed-off-by: Graham <gpe@openrs2.org>
The group unpacking code exposes a fastutil type. (In the long run this
might be replaced with an array, allowing us to revert this commit or
drop the fastutil dependency entirely.)
Signed-off-by: Graham <gpe@openrs2.org>
This speeds up the resolved_* views by a reasonable amount, though it
does mean we won't be able to use the smarter resolution logic (which is
far too slow anyway at the moment, so I'm not sure what I'm going to do
about that in the future...)
Signed-off-by: Graham <gpe@openrs2.org>
This doesn't fix all cases, as a master index can have multiple sources,
each with a distinct copy of the same (archive, group, checksum,
version) tuple. However, it's probably as good as we'll be able to do
automatically - and it'll work particularly well for master indexes
downloaded directly over JS5, where we won't have done multiple imports
of the same cache.
Signed-off-by: Graham <gpe@openrs2.org>
These functions reduce the amount of group resolution logic
significantly, concentrating it in a single place. In addition to the
usual code de-duplication benefits, many of the queries are now much
simpler as the complexity is hidden behind the function calls.
This change also allows us to make the group resolution logic more
complicated. The first change is that the functions are guaranteed to
only return a single row, which was not true with the old JOIN-based
approach. The row that is chosen is chosen deterministically.
The resolution logic will probably be improved in the future, so we can
make a better decision where there are multiple possible groups, due to
collisions.
Signed-off-by: Graham <gpe@openrs2.org>
