in the front layer which is generally what we want.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3190 542714f4-19e9-0310-aa3c-eee0fc999fb1
action cleared was ungood. It really only worked for the delegates. Now we
do it in a way that works for the controllers themselves and the delegates.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3189 542714f4-19e9-0310-aa3c-eee0fc999fb1
both destroyed without any intervening event processing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3186 542714f4-19e9-0310-aa3c-eee0fc999fb1
behave differently (if necessary) when processing an event that has an
associated board state.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3185 542714f4-19e9-0310-aa3c-eee0fc999fb1
return a tile with an error image so that the caller doesn't freak out and
we achieve maximal "continue to work as much as possible."
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3177 542714f4-19e9-0310-aa3c-eee0fc999fb1
because that will do things like queue up score events and whatnot that
cannot be ignored. It will also queue up the next drop sprite, etc. but
that's fine as we can safely end the action in such circumstances.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3165 542714f4-19e9-0310-aa3c-eee0fc999fb1
Kormanian wackiness. Let's just make clone() public and use it like
civilized people.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3163 542714f4-19e9-0310-aa3c-eee0fc999fb1
Windows where it wigs out and behaves as if the connection was reset by
the peer ("An existing connection was forcibly closed by the remote host")
if one writes messages bigger than about 25k. I can't imagine how we would
be sending such big messages to the server, but it's worth a check.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3159 542714f4-19e9-0310-aa3c-eee0fc999fb1
things like not render "targets" as filled until they actually arrive.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3156 542714f4-19e9-0310-aa3c-eee0fc999fb1
bundle cache if it fails to locate the data for a character action. Also
updated wipeBundle() signature.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3147 542714f4-19e9-0310-aa3c-eee0fc999fb1
out Getdown's "verified" marker file so that Getdown will recompute the
jar file's MD5 hash and then wipe it out and redownload it only if it is
actually corrupted.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3146 542714f4-19e9-0310-aa3c-eee0fc999fb1
is gone, that I'll disable the action debugging. Yay optimism!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3144 542714f4-19e9-0310-aa3c-eee0fc999fb1
by being incorrectly used by the duty report system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3142 542714f4-19e9-0310-aa3c-eee0fc999fb1
1. Modified the performance metric code to use hundred microseconds rather
than milliseconds as millis are not sufficiently fine grained.
2. Switched from using an ObserverList to a hand-rolled mechanism for
frame participants. It is unfortunate that we're not reusing code (though
this turns out to be 55 fewer lines of code) but the FrameManager needs to
allow tick participants to be removed from the list while in the middle of
processing another participant's tick.
With the ObserverList we have to use SAFE_IN_ORDER_NOTIFY which adds
undesirable overhead to each tick, or FAST_UNSAFE_NOTIFY which is
efficient, but freaks out if an as-yet-unticked participant is removed
during another particpant's tick.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3140 542714f4-19e9-0310-aa3c-eee0fc999fb1