the sprite to contain more than just the image. I didn't go all the way
though because I started looking at the stuff to handle render origin and
render offset and couldn't bring myself to add another offset into the mix
so it'll have to wait until I can give it some more serious thought and
perhaps simplify what we've got.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1264 542714f4-19e9-0310-aa3c-eee0fc999fb1
server by entities that are vaguely impersonating a client. Specifically
they need to fill in the event's source oid because their events are not
going through the client networking layer which takes care of filling that
in for real clients.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1261 542714f4-19e9-0310-aa3c-eee0fc999fb1
between two screen coordinates. The screen coordinates are "projected"
into isometric space and the vector between them is calculated (except we
don't actually do the projection because we can tell just by looking at
the points what the projected orientation will be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1257 542714f4-19e9-0310-aa3c-eee0fc999fb1
paths one node at a time and add their desired orientation to the nodes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1256 542714f4-19e9-0310-aa3c-eee0fc999fb1
view or remain fixed relative to the scrolling view (the default and also
the old behavior).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1253 542714f4-19e9-0310-aa3c-eee0fc999fb1
sprite was following a path is going to scroll; fixed bug in
getDirection(); added setDuration() which computes the path velocity based
on the time that the sprite should spend following the path.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1252 542714f4-19e9-0310-aa3c-eee0fc999fb1
became necesssary when *Codes were moved out of .client and into .data.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1247 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead we say that we want to scroll by a certain amount in a certain
amount of time. This allows the animated panel (who knows about this
stuff) to figure out when to stop scrolling without overshooting by a
pixel or two.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1244 542714f4-19e9-0310-aa3c-eee0fc999fb1
as they are intended to represent codes shared between the client and the
server. Made correspondingly necessary changes throughout.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1240 542714f4-19e9-0310-aa3c-eee0fc999fb1
start processing on the server so that we don't want for the IN_PLAY
attribute change to be processed before calling gameDidStart() because we
don't want to do that when resetting the game (because someone could come
along and end the game in between gameWillStart() and gameDidStart() which
would be annoying and bad), so we need to be consistent and run straight
through both when starting the game for the first time and when resetting
it.
This means that game managers that really need to wait until their events
are processed and do some game start processing at that point will have to
listen for the IN_PLAY transition themselves *and* they'll have to be
aware that someone could have come along and ended the game in between the
call to gameDidStart() and the dispatch of the IN_PLAY event. Sketchy, but
unavoidable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1235 542714f4-19e9-0310-aa3c-eee0fc999fb1
message events) to a transaction already started on a particular object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1233 542714f4-19e9-0310-aa3c-eee0fc999fb1
ends in Set as a DSet. This is not optimal, but writing a full blown
parser so that we can analyze the inheritance hierarchy of the files we're
processing to determine for sure that something extends DSet would be at
least an order of magnitude greater pain in the ass than just doing simple
textual processing. We'll leave that up to future people.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1232 542714f4-19e9-0310-aa3c-eee0fc999fb1
Clearing a base tile sets it to a random tile from the default tileset.
setBaseTiles() now takes a tileset and fills the rectangular area with
random tiles from that set.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1227 542714f4-19e9-0310-aa3c-eee0fc999fb1
If fringing an entire scene, you must pass in a randomization seed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1226 542714f4-19e9-0310-aa3c-eee0fc999fb1
Quoth the java.awt.Polygon documentation:
The first and final pairs of (x, y) points are joined by a line
segment that closes the polygon.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1222 542714f4-19e9-0310-aa3c-eee0fc999fb1
since the autofringer can create any fringe now anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1219 542714f4-19e9-0310-aa3c-eee0fc999fb1
fucking serialization crapping out when the class was recompiled and its
panties got into a bunch.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1216 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne