really copies everything to an ArrayList and sorts it,
let's just throw the elements into a TreeSet and iterate over that.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@942 c613c5cb-e716-0410-b11b-feb51c14d237
Does anyone know if these colorization names can indeed be null?
Otherwise we can remove the null-safe comparator.
It was previously calling ObjectUtil.compareTo() which leads
me to think it needed null-safety.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@939 c613c5cb-e716-0410-b11b-feb51c14d237
If it's public, we try to shadow it in a subclass & wind up still
getting THIS one.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@932 c613c5cb-e716-0410-b11b-feb51c14d237
has a *newer* version of the scene than the server, we assume it's an error
and make them redownload the full scene.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@918 c613c5cb-e716-0410-b11b-feb51c14d237
already cached, but what about those poor new folks?
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@917 c613c5cb-e716-0410-b11b-feb51c14d237
The @Generated annotation showed up in JSR-250 and then was bundled into
Java 1.6. For those of us stuck in a 1.5 world, there's fortunately a
nice tiny little jar with the necessary classes, so slurp that in.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@909 c613c5cb-e716-0410-b11b-feb51c14d237
exact same API. So if you ship with GC instead of Guava, nothing will break.
Eventually we'll want to ship with Guava instead of GC so that we can use
Guava-specific methods, but projects can make that switch at their leisure.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@903 c613c5cb-e716-0410-b11b-feb51c14d237
Requesting N bits on certain types of events was enough to tickle timing
issues with events between client & server so I got those cleared up,
and in a roundabout way made piece prediction harder, BUT it wasn't
actually doing what I'd really intended. I'd originally done things this
way (call something on the RNG N times) and then in a brief moment of
brilliant stupidity went "gee, next() does different stuff based on the
number of bits you asked for, so clearly it'll mix things up"
Man, this hairshirt is itchy.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@899 c613c5cb-e716-0410-b11b-feb51c14d237
Since the client & server share RNGs, many puzzles (e.g. yohoho's
swordfighting) wind up lending themselves to easy piece prediction; the
board is set up with a seed, and the RNG is only ever used to generate
pieces. Someone snooping that could (and people have) pre-generate all
the pieces in order, letting you snoop ahead.
Now, Board implementations can choose to use certain events to pull bits
from the RNG so that the actual ACTIONS taken perturb things, making
things branch to the point that prediction is prohibitively hard.
A while back, I'd wanted to do this across the board for all actions,
but unfortunately in yohoho we have various non-board-altering events
that come in and are executed in different orders on client and server,
so things fell out of sync pretty quickly. The thought rattled around in
my head again, so I'm doing it again. This time, Boards have to
explicitly opt in on each event, so they can be sure to restrict it to
those that are safe to use.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@896 c613c5cb-e716-0410-b11b-feb51c14d237
Ray Greenwell