problem with not being able to rename some, but not all, of the old jar
files prior to patching them.
Also, took out the assume v0.22 hack as we should be good to go on that
front by the next release, the stragglers will just have to download a
full update (which is safer anyway).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2754 542714f4-19e9-0310-aa3c-eee0fc999fb1
frame tick interval 10ms on Windows because any non-multiple of 10 causes
the big fat fuckola in the form of heinously accelerated clock drift.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2751 542714f4-19e9-0310-aa3c-eee0fc999fb1
seconds to pass in between ping/pong latency samples. Additionally, we
resync the clock every 10 minutes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2748 542714f4-19e9-0310-aa3c-eee0fc999fb1
and dobj thread until they're both empty (or it has been passed 50 times)
and then shuts the threads down.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2744 542714f4-19e9-0310-aa3c-eee0fc999fb1
the JNLP versioned resource protocol so that it can download jardiffs
instead of whole new jar files when a resource bundle is updated.
Unversioned http downloads (which we'll probably continue to use for the
dynamically generated island bundles) are currently not working.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2739 542714f4-19e9-0310-aa3c-eee0fc999fb1
SystemMediaTimer is make time stop while we're in the past, whereas in the
FrameManager we can just note that strangeness is afoot and keep on
tickin'.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2736 542714f4-19e9-0310-aa3c-eee0fc999fb1
when I set it to 24? Let's try it like this for a spell.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2734 542714f4-19e9-0310-aa3c-eee0fc999fb1
is a problem with starting a transaction, we don't get an exception
for failing to commit the transaction.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2712 542714f4-19e9-0310-aa3c-eee0fc999fb1
distinguish between uninitialized and various file errors, and hopefully
get us some better logging output. (If there are errors with a file,
lastModified() returns 0, which would have caused resolveJarFile to think
that the bundle just wasn't ready yet and not create the JarFile object,
which resulted in a NPE, and not useful IOEs.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2709 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the low-level invocation services whereby after a disconnect, any
InvocationReceiver registration would be wholly ignored due to the
previous registrations being left in the receivers set and DSet refusing
to add duplicate instances of the registration. This wasn't immediately
apparent because the initial set of registrations always happens in the
same order and thus are equally useful after the reconnect and any other
registrations are removed during the normal course of affairs. But if a
user disconnects *during* a puzzle, they will leave that puzzle's
registration around and be unable to play that (or any) puzzle again until
they log off and back on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2707 542714f4-19e9-0310-aa3c-eee0fc999fb1
circumstances where they aren't around when they should be.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2702 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Require a Comparable key in get() and containsKey().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2698 542714f4-19e9-0310-aa3c-eee0fc999fb1
allowing things to get out of hand. Since getOccupantInfo may normally
return null, doing so in our strange failure case will not cause further
freakout.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2697 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne