methods they were looking for.
Since it's probably impossible to have proguard generically skip renaming
for these generated method names, let's update the fields in a different way.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3434 542714f4-19e9-0310-aa3c-eee0fc999fb1
that authentication is processed on the dobjmgr thread rather than
requiring the caller to do the right thing (or not as the case happened to
be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3433 542714f4-19e9-0310-aa3c-eee0fc999fb1
be used by sprites and animations. Ray is now thinking, "Why do we have
this wacky difference between sprites and animations?" but changing it now
would be a massive amount of typing that I'm not super interested in
doing. In any case factoring out the "effects" into separate classes is
still useful because frequently one wants to combine them in crazy ways
that would not be possible with a FadeSprite or FadeAnimation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3426 542714f4-19e9-0310-aa3c-eee0fc999fb1
different things in. Created FadeImage and FadeLabel derivations.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3425 542714f4-19e9-0310-aa3c-eee0fc999fb1
push-back buffer that prevents sounds from blarching when we reset the
stream.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3422 542714f4-19e9-0310-aa3c-eee0fc999fb1
implementations do a fucking DNS lookup on the host of the URL. The degree
to which that violates expectations about the "expense" of calling
hashCode() is so astronomical as to be unexpressible without complicated
metaphor.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3421 542714f4-19e9-0310-aa3c-eee0fc999fb1
condition between the omgr thread and the conmgr thread. Now when the omgr
thread processes an event that is going out to the clients, it flattents
the message itself for each client that is to receive the message and the
flattened data is posted to the conmgr outgoing queue.
This means that once an event is finished processing, no further
modifications to any of the data associated with the event can effect the
data queued up to be sent to the client. This is a good thing, it will
eliminate or illuminate a very baffling class of bugs that we've sort of
been ignoring because we knew this could be the cause.
We used to take an event and flatten it directly into the direct buffer
from which we would do our socket write. Now we flatten it into a
temporary byte array. This means a metric shitload more garbage generation
and collection. We used to do the flattening on the conmgr thread, now we
do it on the omgr thread. This means a big redistribution of CPU demand.
Either of those things could result in a significant negative impact on
our performance, but we'll just have to deploy this stuff and find out.
Whee! If it turns out to be a serious problem, there are potential
optimizations that could be done by keeping a pool of direct buffers
around and flattening messages into them, relying on the fact that the
outgoing conmgr queue generally doesn't grow too large and we could
allocate tens to a hundred megabytes of memory for the outgoing queue if
we really needed to.
I'd also like to test the overflow handling stuff more. It didn't really
change in that everything just deals with arrays of bytes now instead of
unflattened messages, but I'll be more comfortable once I've seen all this
in action on ice where there may be few users, but they are just as likely
to experience lag and receive an overflow queue as users on the higher
traffic servers. There is code to log when overflow queues are created and
finally flushed and how much use they got while they were around, so that
should give us an indication of whether things are operating properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
freaking out in standalone mode where the server is started, and shutdown
and started again repeatedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3418 542714f4-19e9-0310-aa3c-eee0fc999fb1
whether or not we're already shutdown as it may have shutdown
unexpectedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3415 542714f4-19e9-0310-aa3c-eee0fc999fb1
isometric rendering) and modified it to allow it to consider different
potential move sets than just moving by one in the eight cardinal
directions.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3411 542714f4-19e9-0310-aa3c-eee0fc999fb1
response telling them to upgrade. Note to self, do the thing where the
server immediately writes the version number to the auth stream so that we
don't have to worry about this sort of legacy crap.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3410 542714f4-19e9-0310-aa3c-eee0fc999fb1
the first 80 characters if this every actually discovers an anomaly rather
than just dutifully reporting every time someone updates really lengthy
crew news.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3409 542714f4-19e9-0310-aa3c-eee0fc999fb1
'iterator()' name and deprecate the old 'entries()' method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3405 542714f4-19e9-0310-aa3c-eee0fc999fb1
new turn holder. Log a warning. This is how we do things here.
Additionally, something I didn't change that is redundant is checking
to see if the player name is null, when the default implementation of
the active player check will return false if the name is null. It seems
to me that the movement of the active player business into the base game
package can result in some cleanup that hasn't been done, but I don't
want to look into it any further.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3398 542714f4-19e9-0310-aa3c-eee0fc999fb1
to write a simple board game for gamegardens, they shouldn't have to
explicitly set up an array indicating that all the players are active
(or worse, waste 45 minutes tracking down why the game is freezing up
suddenly).
If the playerStatus array is null, all players are active.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3397 542714f4-19e9-0310-aa3c-eee0fc999fb1
load resources to load from the default sets.
(A normal url would be "resource://<set>/<path>", one using the default set
would be "resource:///<path>". Goofy.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3396 542714f4-19e9-0310-aa3c-eee0fc999fb1
because we'd like to use the same TileSet over again when possible, but
we don't want to forevermore hold onto a TileSet if it could be gc'd.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3392 542714f4-19e9-0310-aa3c-eee0fc999fb1
is still actively playing the game. The delegate now uses this when
incrementing turns to skip over players not a part of the game (rather
than needing this same code in the derived classes).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3390 542714f4-19e9-0310-aa3c-eee0fc999fb1
for an error icon, just whip one up on the fly when needed (almost never).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3389 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to observers when an OccupantInfo was updated or removed. This
functionality is now built-in to the dobj system, so just use
getOldEntry() on those two events.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3387 542714f4-19e9-0310-aa3c-eee0fc999fb1
games. Updated the PLAYER_KNOCKED_OUT variable name to prevent some
namespace contention issues.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3386 542714f4-19e9-0310-aa3c-eee0fc999fb1
you had logged on to one ocean and then moved to another, the previous
ocean's sceneIds are still in the scene cache.
Fix: Clear the scene cache both when we log off and when the scene repo is set.
Also, I made the cache be a LRUHashMap holding a measly 5 scenes.
Why are we filling up memory on the client with scenes that may or may not
ever be revisited?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3385 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell