*** Starting logfile /usr/home/dan/gizmoball.log
IRC log started Mon Apr 26 21:35:51 2004
*** Value of LOG set to ON
<Amthrax> Heh, y'know what we forgot?  A way to make a new, blank board.
> We did?
> Oh, right, we did.
> I thought about it when I was designing the GameBoard interface, but that doesn't help so much.
<aleung> i assumed a new GameBoard() was a new blank board
> So do we want a GameBoard.getDimensions() that returns a Vect?
<Amthrax> It is, but there's no way to do it from the UI
<aleung> true
<Amthrax> Hmm, come to think of it, new GameBoard() should create the OuterWallGizmo
<aleung> so what i've been finding is that the gameboard sets but it seems to have 0 gizmos
<aleung> and the paint method finds these 0 gizmos and doesn't draw them
<aleung> since there are 0 of them
<Amthrax> That's interesting.  It certainly knows them because it tick's them.  Dan?
<aleung> which is why we don't see a ball drop
> It's ticking gizmos that it doesn't show? Hmm.
<aleung> is it ticking the ball?
<Amthrax> Yes.  I logged it
<aleung> maybe it's my fault then, something with the setting the gameboard
<aleung> i thought i checked that though
> Well, it shouldn't be ticking the gizmos if it doesn't return them in getGizmos.
<aleung> eh, i guess i'll run through all this one more time
> How do I run the test? gizmoball.Gizmoball with the sample XML file?
<aleung> yeah
> hmm.
> I see ticks running... someone has verified that they're ticking the ball?
<Amthrax> Yes
<Amthrax> The ball tick log is in now
> ok, got it.
> I also have a new version of GameBoard that logs to log4j, I should probably commit that.
<aleung> so now i've place a ball into the initial GameBoard for the AbstractGBCpt
<aleung> and it's displaying correctly
<Amthrax> And the plot thickens
<aleung> it's possible the colors just suck and we can't see it
<aleung> maybe i'll make the ball cyan or something
<aleung> but that wouldn't explain why the gameboard shows 0 gizmos in the drawing loop
> Committed a log4j'd GameBoard (the only difference is that it uses log4j instead of SOP)
<Amthrax> In AbstractInteractionMode, add an error dialog to the IOException catchers
<aleung> via log4j?
<Amthrax> No, a regular JOptionPane
<aleung> ah, ok
<Amthrax> We want to report that to the user, and I get a feeling that might be related to the problem...
<Amthrax> Tack the exception message in there, too (I make sure to give useful messages with everything the loader throws)
> It certainly is ticking the ball.
<aleung> now is it ticking the ball because of the gameboard's natural tick or is the timer ticking the ball?
<Amthrax> The gameboard doesn't have a natural tick
> There aren't any walls in the GB, are there?
<aleung> nope, no walls
<Amthrax> Not currently
> OK, that'd explain why it's not checking any collisions.
<aleung> eh, then that's very weird
<aleung> the timer can only tick the same gameboard that the gameboardcomponent draws
<Amthrax> It's just-a-ball, afterall
<Amthrax> Yeah...
<Amthrax> This is confusing
> I can poke at GameBoard some more, but I have a hard time believing that it would fail in this way (especially in light of the tests I ran)
> Could it be a drawer issue?
<aleung> what's the ball position
<aleung> i'll test that in the drawer test
> That was one of the other things I was wondering about... could it be going offscreen?
<aleung> but it seemed to work right
<Amthrax> The paint method is definitely not iterating over any gizmos
<aleung> yup
<aleung> plus, i checked the size on the getGizmos and it returns 0
> Oh. Uh.
<Amthrax> Time to pull out....  The Debugger!
> Right, you have a working debugger.
<Amthrax> No, but I have a more working debugger
> That'll do.
<aleung> i've confirmed that the position will properly draw
* dan nods
<aleung> eh, why don't i just hard load the ball drop and see if that works
<Amthrax> Hmm, the debugger isn't enlightening me much
<Amthrax> Though, what I mentioned about the error dialog before was wrong.  It should probably get in the LoadListener in GizmoballFrame
<aleung> yeah, i'll have it dispatch on the return value of the load
> I'm doing some debugging myself, but I don't have any theories yet.
<aleung> well, i hard loaded the gameboard from the xml file
<aleung> the ball shows up and doesn't move
<Amthrax> Is it ticking?
<aleung> yup
<Amthrax> That's interesting
<Amthrax> Does it claim it's moving?
<aleung> lemme get the updated logging stuff and i'll let you know
<aleung> it claims it's moving
<Amthrax> That's also interesting
<aleung> it also claims it's repainting the gizmo
> That's interesting too.
> Oh, this could be it...
<aleung> and apparently within .3 secs, it's dropped out of the bounds of the board
<aleung> but it looks fixed
<Amthrax> Yeah, they fall pretty quickly
<Amthrax> Gravity is 25 L/sec^2
> That's a lot of gravity.
<Amthrax> Yes
<Amthrax> Especially for "resembling a pinball game with a slightly tilted playing surface
> OK. I found the bug.
<Amthrax> Ooh ooh
<aleung> enlighten us
> GizmoballFrame makes two R2GameBoardComponents
<aleung> ah, i see
<aleung> damn
> Apparently one was getting ticked and the other drawn or something like that.
<Amthrax> That it does.  Nice catch
> It still goes awfully quickly.
<aleung> yeah
<aleung> it behaves as expected though
<Amthrax> Which is always a good thing
<Amthrax> Let me make the walls real quickly..
> Yeah, I wasn't suggesting that that was wrong. Just surprising.
<aleung> you'd never have guessed from that animation
<aleung> but i suppose it naturally distorts sense of time
<aleung> so will cvs be able to mediate between all our different versions right now?
<Amthrax> CVS is magical.
<Amthrax> Speaking of which, the repaint() call in the timer should probably be gameboardComponent.repaint
<aleung> yup
<aleung> just that way wasn't working before (because apparently, gameboardComponent wasn't being shown anywhere)
> bah. Damn WAP.
<Amthrax> That needs to be fixed.. as soon as we have time
> Yeah, exactly.
> As for CVS, I was just going to revert my changes and let Albert commit the fix.
<Amthrax> OuterWallsGizmo should be constructed by new GameBoard().  The ctor expects a Vect dimensions.
<Amthrax> Same here
<aleung> alright, the fix should be in
> OK. Should new GameBoard take a dimensions Vect?
<aleung> that would be nice
<Amthrax> Mm, I'd say give it a default ctor for now that assumes 20x20
<aleung> if not, they're implied by the dimensions of the outerwalls
> hey, this is going to make GameBoard even longer!
<Amthrax> Whee!
<Amthrax> OuterWallsGizmo ci'd (along with some other gizmos)
<aleung> the drawer should handle polys ok, but haven't tested
<aleung> setPosition isn't translating the polygon?
<aleung> and is the polygon origin the upper left corner or the center?
> I'm not sure I like the idea of new GameBoard constructing the OuterWallsGizmo
<aleung> ok, R2PolygonDrawer has been tested for squares, triangles, various orientations
<aleung> the polys seem to be center origin, but i guess we can correct that on one side or the other
<aleung> i'll be back in a few hours
<Amthrax> setPosition isn't translating the polygon?
> c-entry.Albert just proposed using Gizmoball as a thermodynamic simulator.
<Amthrax> Uh
<Amthrax> I.. suppose
> Now he's going to sleep so he won't come up with any more sick ideas.
<Amthrax> Good
<Amthrax> getDimensions ci'd
> oh, cool, I just finished writing the test case.
> GameBoard with OuterWallsGizmo support ci'd.
<Amthrax> Does it work?
> It passes GameBoardTest, is there an integration test to run?
<Amthrax> Nope
> Let me give it a try with the just-a-ball.
<Amthrax> Uh, it would appear not..
> Let's see what happened.
> well, that's unsatisfying. I'll debug.
> I assume you have a working timeUntilCollisionWith?
<Amthrax> AFAIK
<Amthrax> I just ci'd a just-a-ball that doesn't fling it off the board quite as quickly
> Let me put in a little more debugging code.
> hmm. Is BallGizmo ticking correctly?
> It looks like it's not taking the tick length into account.
<Amthrax> In theory
<Amthrax> That's always possible
> DEBUG BallGizmo: Tick: new p=<12,6> new v=<3,1>
> INFO  R2GameBoardComponent: painting gizmo Outer walls
> INFO  R2GameBoardComponent: painting gizmo Ball
> DEBUG GameBoard: doTick 0.05
> DEBUG GameBoard:   event: 0 @ 0.2
> DEBUG BallGizmo: Tick: new p=<15,8> new v=<3,2>
<Amthrax> You're right
<Amthrax> New one ci'd
<Amthrax> Heh, right.  I was lazy in my test case and used 1 second ticks
> Heh
<Amthrax> Still doesn't hit the wall, though
> Right. I'm working on figuring that out.
> DEBUG GizmoballReader: Adding gizmoball.game.BallGizmo@3d285f to the board
> DEBUG GameBoard:     TimeToCollision between Outer walls and Ball is 32.5
> DEBUG GameBoard: doTick 0.05
> DEBUG GameBoard:   event: 0 @ 0.05
> DEBUG BallGizmo: Tick: new p=<2,9> new v=<0,0>
> DEBUG GameBoard:     TimeToCollision between Outer walls and Ball is Infinity
> Something funny's going on there.
<Amthrax> o.O
> I'll commit the GameBoard that prints that debug message if it helps you any.
<Amthrax> 'Kay
> ci'd
<Amthrax> That's interesting
> Yeah. I'm reading over AGizmoWPolyGeometry now.
<Amthrax> I think I found it, though I'm not sure where
> What's going on?
> (If it can be described)
<Amthrax> All of the corners and edges are at 0,0
<Amthrax> At least, once it gets to computeBallCollision
> Oh. Well, that'd certainly be a problem.
> It's interesting that it only happens after the first tick.
> (or does it?)
<Amthrax> No, it's like that the whole time
<Amthrax> Which I also can't quite figure out
<Amthrax> Oh, wait...
> But we do get a TimeToCollision of 32.5 before the first tick.
<Amthrax> Maybe those points are correct, just non-obviously represented in polar
> IIRC, the ball has a slight upward initial velocity, but that goes away after the first tick. Could that have something to do with it?
<Amthrax> Quite possibly
*** You have new email.
<Amthrax> Oops, found it
<Amthrax> It bounces!
> It bounces?
<Amthrax> It bounces!
> Squark!
<Amthrax> Fix ci'd
<Amthrax> just-a-ball is now more interesting
> I'm just seeing a green square. Is it painting the outer walls?
<Amthrax> Those are the outer walls.
<Amthrax> They're a polygon, remember?
> Right. I'm not seeing the ball.
<Amthrax> (Should I ci my tweak that makes that just the edges?)
<Amthrax> Try restarting it.  I think the set sometimes winds up drawing the outer walls over the ball
> Oooh!
<Amthrax> Yay, they don't provide a method for converting degrees to radians
> Of course not.
> Totally unrelated note: EL wire glows brighter if you crank up the voltage.
<Amthrax> Ooh
> (I should probably check if it's rated for that)
<Amthrax> I'd be more worried about the inverter
> That's what I meant.
<Amthrax> Square bumper officially works
> Cool. Which means all polygonal bumpers will presumably work too?
<Amthrax> I believe so
<Amthrax> Uh, well, the ball can get stuck in the triangle gizmo if you happen to place both in the same place...
<Amthrax> Which I guess is a good thing
> Revised specifications!
> What's left gizmo-wise?
<Amthrax> Finish absorber, circle bumper, flippers
<Amthrax> Updated ci'd (including new some-bumpers.xml)
> Hmm. I wonder if I can usefully help with those, or if it'd be more effective for me to start writing things up.
<Amthrax> You should probably start writing things up
> Yeah. I'm also going to make a couple more minor changes.
<Amthrax> 'Kay
> (I might as well make collision triggers work)
> Bumper collisions look good, this is really coming together.
<Amthrax> It's rather amusing to see the game suddenly halt when the ball falls in the absorber as it throws a NIE
> Heh.
> One wonders if there's a way to handle a NIE gracefully. Flash 'NOT IMPLEMENTED!' and make the ball disappear?
> (</sarcasm>)
<Amthrax> Invalid XML!
<Amthrax> Woah.  Our ball is restless.  If kept in the absorber too long it starts bouncing up and down
> Are we trapping it somehow?
<Amthrax> No
<Amthrax> I hadn't thought it necessary
> What does it bounce against? The bottom of the absorber?
<Amthrax> I think so
<Amthrax> Hmm.  This time it's not bouncing
> What does a collision with the absorber do? Set the position of the ball?
<Amthrax> And its velocity
> Right.
> It seems like gravity would always pull it down and make it bounce against the bottom.
<Amthrax> Which will cause me to set its velocity to 0 again
> Sure, but the UI might redraw while it's in motion
<Amthrax> No, because it never gets a chance to move, I think
<Amthrax> I'll deal with this better late
<Amthrax> r
> Oh, wait, the ball is touching the corner of the absorber.
<Amthrax> Yes
> (I had a radius/diameter confusion problem and thought it was floating slightly offset from the corner of the absorber)
> Then yeah, it'll never move. I wonder why it was bouncing.
<Amthrax> The other thing I can think of is that something caused it to hit the game wall before I had a chance to nullify its velocity
> Do the absorber and the game wall share the bottom edge?
<Amthrax> In this layout, yes
> I wonder if it might be unpredictably colliding with the outer wall instead of the absorber wall.
<Amthrax> That might be
> Everything in the GameBoard is a Set, so there's no guarantees about the iteration order.
* Amthrax nods
<Amthrax> There, now I'm more forceful about setting its position and velocity
<Amthrax> Hmm.  I can't find where Albert actually wires up his interaction mode listeners for keyboard and mouse
> My checkRep actually caught a bug!
<Amthrax> *gasp*
> ...of course, it was a bug in placing checkRep calls.
<Amthrax> Oh
<aleung> mmm, it seems the interesting dialogue has ended for a while
<aleung> but progress looks good
<aleung> lemme get the keypress stuff working
<aleung> and then i guess figure out drawing order
<aleung> keypresses in soon
<aleung> keypresses ci'd
<aleung> can we make settings to shut off logger messages from classes selectively?
<aleung> hmm, i'm watching two balls bounce around, it seems they collide selectively
<aleung> depending on the glancing angles
<aleung> usually not at all
<aleung> for the flippers, if you pass me the centers of the two circles, i'll be able to draw them with the renderer
<aleung> other than that, i think all our drawers are pretty much done
*** You have new email.
<aleung> i'll be back around 1
<Amthrax> Yes, one of the strengths of log4j is its ability to control different flows of the log
<Amthrax> I assume you mean two balls colliding with eachother?  I haven't written that yet because we don't need it for the prelim
<Amthrax> Okay.  How 'bout a Circle getEndpoint1() and Circle getEndpoint2()?
*** You have new email.
<Amthrax> Oh!  Now I understand the keypress triggers.  We did them slightly wrong.  The XML file specifies whether a trigger triggers on press or release.
<Amthrax> We'll ignore that for now
<aleung> alright, i'm back
<aleung> if you haven't written it yet, it works surprisingly well?
<aleung> the getEndpts will do
<aleung> as for the log4j thing, how do i do flow control?
<aleung> it was hard to pick out keypress logs from all the other stuff
<Amthrax> Uh, that's interesting.  Can I see the test file you were using?
<aleung> sure
<aleung> it looks very much like collisions
<aleung> i'll ci in a sec
<Amthrax> For now, edit Gizmoball.java at the end of initLog4j and add, say:
<Amthrax> Logger.getLogger("gizmoball.game.GameBoard").setLevel(Level.INFO);
<aleung> cool
<aleung> i guess the collisions might just look like collisions
<aleung> but there's this kinda of choppiness around it that seems to be a change of direction
<aleung> i don't know what the log is reporting
<Amthrax> Hmm
<aleung> the file is in the tesfiles dir
<Amthrax> 'Key
<Amthrax> s/e/a/
<Amthrax> Hmm.  I don't think they're actually colliding.
<aleung> eh, ok
<Amthrax> Of course, I'm probably biased about that, since I'm the one who didn't write the code.  ]:--8)
<aleung> you could definitely fool someone into thinking that
<aleung> arg, there's some error with l&f for JFileChooser in Windows
<aleung> seems to unreliably break
<aleung> and throw an NPE
<Amthrax> Gah
<Amthrax> Hmm.  Could you use Math.round instead of casting to double in the poly drawer?
<Amthrax> I'm getting some weirdnesses with fp error
<aleung> ok
<aleung> you mean casting to int?
<Amthrax> Er, yeah
<Amthrax> Oh, and I'm confused by the choppiness.  It's simulating at the right rate, but I think Swing is doing some redraw optimization or something.  It appears much smoother on Dan's laptop
<aleung> i don't know how you see it, it seems pretty smooth to me, i think
<aleung> besides the thing with the balls going over each other
<Amthrax> Oh, it might just be my VM then
<aleung> but i've changed the casting, so it rounds before casts
<Amthrax> Thanks
<aleung> which aspect of connections aren't in yet?
<Amthrax> In a moment.. basically nothing
<Amthrax> ci'd
<aleung> great
<aleung> tested?
<Amthrax> Yes
<Amthrax> (though not formally much)
<aleung> so we've met the preliminary release except for the flippers?
<Amthrax> and circle bumpers
<aleung> mmm
<aleung> ok
<Amthrax> Now the only aspect of connections that isn't in is triggering based on press or release, but I think we should ignore that until after prelim
<aleung> well, as long as we can trigger the basic flipper action
<Amthrax> Which we will be able to
<Amthrax> (and the absorber)
<aleung> yup
<aleung> but based on press or release we can do with parametric triggering (which we have?)
<Amthrax> You mean loaded from the XML file?
<aleung> well, i guess we don't have to worry about it for now
<Amthrax> Yes (modulo honoring the keyDirection attribute)
<Amthrax> No, it's there.  That's how I'm getting the triggers now
<aleung> it's interesting that didn't make it into the requirements
<Amthrax> Yes
<aleung> like for the most part it seemed ambiguous what to do on press or release
<Amthrax> Stuff like that makes me wonder just how much people are going to be hardcoding things for the prelim release
<Amthrax> Oh, yes, that.
<Amthrax> I think the only place that's mentioned is in the detailed description of the XML format
<aleung> yeah
<aleung> i was reading it this morning
<aleung> to test if you guys did connections
<aleung> and then i realized they did spec the behavior
<Amthrax> But we'll ignore that for now
<aleung> agreed
<aleung> do you have a connections test board?
<Amthrax> some-bumpers has a connection to the absorber
<Amthrax> space key
<aleung> ok
<aleung> btw, keycodes translate across platforms?
<Amthrax> Yes
<Amthrax> .. essentially
<Amthrax> They're constants in java.awt.event.KeyEvent
<aleung> ah, right
<aleung> odd, it doesn't seem to fire for me
<aleung> though it's logging the keypresses
<Amthrax> Uh...
<aleung> ah, lemme rebuild
<Amthrax> Oh, that would do it
<aleung> it's awfully fun to watch the ball go up and down...
<Amthrax> Heh
<aleung> i think i'll do an ascii renderer sometime
<Amthrax> Heh, that could be interesting
<Amthrax> BRB
<aleung> ok
<Amthrax> Now that I've found a nice place right outside w20...  time to write flippers!
<aleung> lol, i got the impression you were in your room
<Amthrax> Until 1, I was.  From 1 to 2, I was in 10-250.  Now I'm here  ]:--8)
<aleung> oh, right, 004
<Amthrax> Yeah
<aleung> it's amazing how seemless you move
<aleung> seamless
<Amthrax> Heh, thanks
<Amthrax> Once I have time I intend to make it moreso.
<aleung> btw, we assume flippers are .5 thick?
<Amthrax> I still have to reconnect to my desktop as I roam on wireless because my IP changes
<Amthrax> Yes
<Amthrax> But I need to write a roaming deamon (for other reasons, too) that I intend to make set up an IP tunnel to my desktop so I never loose my connection to it
<Amthrax> I suppose I really should make the gizmo parameters (like FlipperGizmo.RADIUS) public
<Amthrax> But I'll do that after prelim
<Amthrax> Alternatively, you could use the radius of the endpoint
<aleung> ah, the endpoint is a circle
<aleung> eh, for now i'm just using L/2
<Amthrax> I could make it a not circle.  It doesn't really matter
<aleung> i'll make it more general later
<Amthrax> 'Kay
<aleung> eh, just a heads up
<aleung> the Documenting a Software System format is rather annoying
<aleung> we have to write the reflection section etc.
<Amthrax> Oh
<aleung> or are we not following that format still?
<Amthrax> I.. don't know
<aleung> some of these things are not currently producible
<aleung> like the user manual
<aleung> since we don't have a full interface yet
<Amthrax> It seems odd to do a reflection.. in the middle of the project
<aleung> yeah
<aleung> we ought to ask her later
<Amthrax> Yeah.  I was under the impression that it was basically the same stuff they wanted for the PDD, plus validation/testing
<aleung> alright
<aleung> do you know if our code/specs are checked for this checkpoint?
<Amthrax> They probably are glanced at, but I don't think they have much influence
<Amthrax> Since they don't really fit into the 20%/80% rubrik 
<aleung> ok
<aleung> eh, i'll spec up my stuff more anyway
<aleung> gotta do it sometime
<aleung> soon as you finish the flippers, i should be ready to support them
<Amthrax> Cool
> Back to the world of 6.170...
<aleung> ah, so we're all here finally
> Yep, I'm done with classes for the day.
> AbstractGizmoWithPolygonalGeometry seems to be missing a setGeometry(Vect[]) method, it doesn't build for me.
<Amthrax> Um...
<Amthrax> Hmm
> OK if I commit the fix?
<Amthrax> One sec
<Amthrax> Oh, is this in the test?
> (It is, after all, trivial enough)
> Yeah
<Amthrax> Sure
> I ran into it during 033 recitation today, I just made a setGeometry that uses the origin as a default center.
<Amthrax> That works too
> ci'd.
> btw, I'm in W20.
<Amthrax> Heh, me too
> Heh, where?
<Amthrax> Though probably in a much squishier part
<Amthrax> The second floor lounge
> You're right, that is squishier. And probably a lot more comfortable.
> Is there power?
<Amthrax> Nope
<Amthrax> At least, not that I see
> Bah. If there were, I'd come down and join you.
> And the keyDirection bit in the keypress triggers is annoying.
<Amthrax> Yes
> How did they manage to write that so I was able to totally miss that after scrutinizing the specs.
> s/\./\?/
<Amthrax> Very, very carefully
> Fortunately, my design is extensible enough to handle that!
<Amthrax> The bigger problem is coming up with same way to enter that into the editor
<Amthrax> But we probably shouldn't deal with that yet
> Yeah.
*** You have new email.
> Anything (besides docs) you need me to work on?
<Amthrax> Not that I can think of
<Amthrax> (flippers are almost done, BTW)
<aleung> cool
> cool. That's everything for the demo, right?
<Amthrax> Just need circle bumpers (ugh)
> Oh, right, those.
<Amthrax> But those should be trivial
<aleung> ok
<aleung> i'll switch the drawer to use draw and not fill for consistency
> Circles do have that nice, uh, circular geometry that makes things easy to deal with.
<Amthrax> This is true
<Amthrax> Okay.  We really should draw things solidly, but then we have to deal with the outer walls sanely
<aleung> yup
<aleung> or we can always treat them separately in the drawer from other AGWPG
> Yeah. Maybe make it (and color?) a property of AGWPG?
<Amthrax> A solidness property?
<Amthrax> Hmm, maybe
> (That was, of course, a 'later' suggestion, not a 'today' suggestion)
<aleung> i suppose we can do "shade" or something
> Yeah
<Amthrax> (Not Property property, that is)
<aleung> btw, does absorber handle multiple balls correctly?
<Amthrax> Nope
<aleung> (i can imagine difficulties firing two balls at once)
<aleung> or with your forced position thing
<Amthrax> Actually, it
<Amthrax> 'll fail more catastrophically than that
<Amthrax> I think
> It could be a Property, or it could just be a property.
<Amthrax> Though, really, I have no idea what it'll do
<aleung> that's very reassuring
<Amthrax> Actually, it might fail so catastophically that it may even work...
<Amthrax> Though I know they won't be positioned very well while in it
<Amthrax> Feel free to try it
> Now that would be impressive.
*** You have new email.
<Amthrax> gizmoball.NotImplementedException
<Amthrax>         at gizmoball.ui.r2.R2DrawerFactory.getDrawer(R2DrawerFactory.java:45)
<Amthrax>         at gizmoball.ui.r2.R2GameBoardComponent.paint(R2GameBoardComponent.java:63)
<aleung> one sec
<aleung> what's it painting, do you know?
<Amthrax> Oh, right.  Flippers
<aleung> oh, ok
<Amthrax> (FlipperGizmo)
<aleung> is it ci'd?
<Amthrax> Nope, but I can if you want
<Amthrax> ci'd
<aleung> ok, i'll throw those in
<Amthrax> I don't know whether or not they actually work yet
<aleung> no prob
<aleung> which is which endpoint?
<aleung> like which one is the pivot?
<Amthrax> 1
<Amthrax> (see specs)
<aleung> ah, right
<aleung> from what i see, i think i don't have the second endpoint (it's giving me the 1st one as the 2nd)
<Amthrax> Uh
<aleung> unless i'm using something wrong
<Amthrax> Let me check it
<aleung> oops
<aleung> nm
<Amthrax> Okay
<aleung> ok, it looks like it draws
<aleung> did you make the length L or 2L
<Amthrax> 2, in theory
<Amthrax> Oh, wait
<Amthrax> 1.  I'll fix that
<aleung> great
<aleung> in that case the drawers are working
<Amthrax> Cool
<Amthrax> Fixed length
<Amthrax> Circle bumpers are almost done
<aleung> ok, i guess we're just about set for the demo then
<Amthrax> Yep
<aleung> lemme test key firing of the flippers
<aleung> will it load flipper handedness?
<Amthrax> Yes
<Amthrax> In theory
> excellent
<Amthrax> It just transforms it into a reasonable XML tag.  ]:--8)
<Amthrax> Circle bumper ci'd
<aleung> care to rename it CircleBumperGizmo?
<Amthrax> Oh, good point
<Amthrax> Done
<aleung> ok
<aleung> it seems the flipper is moving unpredictably?
<Amthrax> Okay.  I haven't actually looked at it yet
<aleung> alright
<aleung> check that out
<aleung> i'll throw in the circlebumper stuff
<Amthrax> Ooh, they dane
<Amthrax> *dance
> They're flippering in an interesting way.
> Random thought: do we need to handle flipper-flipper collisions?
<Amthrax> Uh, no
<aleung> can you also shift the endpoints so that they fall within the discrete L squares?
<Amthrax> Okay
<aleung> technically, flippers occupy the 2x2 box, so you should be able to place them so they hit
> That issue can rest comfortably under the rug.
<aleung> i've just loaded the example boarded
<aleung> board
<aleung> seems it's treating all flippers as left flippers?
<aleung> and they all dance synchronized
<Amthrax> Yeah, I'm working on that
<aleung> cool
> Oh, they do specifically state in the specs that flippers shouldn't be placed in such a way that they'll hit anything else.
<aleung> did we get collision triggers to work, btw?
<Amthrax> They work
<Amthrax> (I just tested them with flippers)
> They work in the GameBoard, does the XML loader load them?
<Amthrax> Yes
> Cool.
<aleung> ah, collisions seem a bit weird
<aleung> the ball seems to hit things before it actually contacts them or sometimes goes through them
<Amthrax> Going through them shouldn't happen
<aleung> that may have to do with drawing precision
<aleung> well, going through them glancing
<Amthrax> But if the collision happens between redraws, it will look like it didn't actually hit
<aleung> ko
<aleung> ok
> flippers aside, collisions look good in some-bumpers.xml for me
<aleung> yup
<aleung> i'm still using the board on the requirements site
> I get NotImplementedExceptions from the R2DrawerFactory on that (maybe because of the CircleBumper?)
<aleung> oh, maybe i didn't ci
<aleung> got it
<aleung> seems the collisions with those are a bit coarse
<aleung> actually, i guess it's ok
<Amthrax> Okay.  Flipper handedness and rotation are now working
<Amthrax> I'll fix the endpoint positions and ci
<aleung> ci'd?
<aleung> ok
<aleung> i'll handle the revised mdd for now
> ok. I'm writing up the collision detection/resolution procedure.
<Amthrax> Fixed flippers ci'd
<Amthrax> Now to fix circle collisions
<Amthrax> Oh, and can anyone get the absorber to eject in example.xml?
<aleung> when i ran it, it ejected on collision
> So it did. Is the orientation of the triangles wrong in example?
<aleung> i thought it matched the gif
<Amthrax> Have you rebuilt in the case four minutes?
<aleung> oh, hmm
<aleung> one of them seems wrong now
<Amthrax> I thought I fixed it..  Maybe I unfixed it
<aleung> also, it seems the flippers are inverted
<aleung> i also should've connected the space to the absorber
<Amthrax> The hell?  Does the geometry library rotate CW?
<aleung> ok, the absorber's definitely not firing now
<Amthrax> It was running for me for a long time, then it suddenly caught it.
> There's something funny going on there. It worked fine the first time I loaded it, then I reloaded the same file, and it suddenly stopped working.
<Amthrax> That doesn't have to work yet, though, so let's ignor eit
> Right.
<aleung> eh, the absorber has to fire somehow
<Amthrax> Key presses fire it fine
<Amthrax> AFAIK
<aleung> i can't get that to work either
<Amthrax> Fixed circle bumpers ci'd
<aleung> cool
<aleung> what key to fire the absorber?
<Amthrax> Supposedly delete for example.xml
<aleung> eh, the collide is now working...
<aleung> what's up with the orientation
<aleung> of the tri bumper?
<aleung> and the flippers?
<aleung> brb, i'm coming to w20, so i guess i'll find you
<Amthrax> Oh, sorry.  Fix ci'd
<Amthrax> I'm at 16% battery, so I'll be on the fifth floor soon
<aleung> ok
> I'm at one of the black linux machines, on the row to the right side of ajax as you walk in.
<aleung> are the flippers fixed?
<aleung> i seem to get no collisions with them, and they're still reversed (left is right and vice versa)
> Well, collisions with flippers aren't scheduled to be implemented today.
<Amthrax> You won't get collisions with them
<Amthrax> I'm working on the orientation
<Amthrax> (I'd misinterpreted the specs on that)
<aleung> great
<aleung> i'll be over in a sec
<aleung> well, on to the FDD
<aleung> i guess i'll eat first
<Amthrax> *ping*
<Amthrax> Hmm.  I wonder about the problem analysis section
<aleung> what's this?
<Amthrax> It's under requirements
<Amthrax> the requirements section, that is
<aleung> eh, we can make something up
<Amthrax> We could also fill all 20 pages with that...
<aleung> how is the fdd looking
<aleung> that's very true
<Amthrax> Decent.  I just ci'd the properties stuff and some changes to the XML stuff.  I haven't seen any other checkins recently.
<aleung> alright
<Amthrax> I'm now rewriting the requirements overview
<aleung> i will update the renderer stuff and some ui stuff, i guess
<aleung> i'm about to put the new mdd on the blog
<Amthrax> We should be sure to address all of the comments she made to our PDD
<Amthrax> Ah, cool
<Amthrax> I think I'm going to throw together the glossary, too
<Amthrax> I thought Dan was going to, but he appears to be temporarily dead
<aleung> alright
<aleung> i will address the comments in my sections then i can bring up the pdd if you'd like to see it again
<Amthrax> Sounds good
<Amthrax> Hahaha, I like the decorations
<Amthrax> I wonder if she'll understand
<aleung> eh, i had an even more colorful one
<aleung> but it was too busy
<Amthrax> Do you have a higher resolution copy?
<aleung> one sec
<aleung> how should i get it to you?
<Amthrax> Email is fine
<aleung> cool
<aleung> it's not much better, about twice the resolution
<aleung> i guess that's not bad
<Amthrax> That's fine.  I was just worried that some of the text would get lost in the eps translation
<aleung> ah, yeah
<aleung> it seemed alright last time
<aleung> btw, you might wanna glance over it for correctness
<Amthrax> Okay
<aleung> what with the runtime model or whatever?
<aleung> and i think i'm done with the pdd, most of my sections were ok
<aleung> the hi res mdd has been sent
<Amthrax> The object model?  We'll ignore it
<Amthrax> I don't think it would be especially enlightening anyways
<aleung> well, at least textual description
<Amthrax> Yes, that we probably should have
<aleung> hah, for some reason i think it'll look much like the mdd
<Amthrax> This is also true
<Amthrax> Ah, that should eps fine
<aleung> ok
<aleung> lemme bring you the pdd
<Amthrax> 'Kay
<aleung> btw, have you seen the 18.06 yet?
<Amthrax> From yesterday?
<Amthrax> Oh, the pset?
<aleung> yeah, the pset
<Amthrax> Nope
<aleung> alright
<aleung> can't be too bad
<Amthrax> Pfft, yes it can.  But hopefully it won't be
<aleung> alright, i emailed the fixed mdd
<aleung> the dotted arrows are now really dotted
<aleung> btw, how do the $id tags work in version?
<aleung> ci'd the javadoc fixes, i think
<aleung> if there were 3, i couldn't find one
> If you put a $Id$ in your file anywhere, it magically gets updated.
<Amthrax> The remaining one is in R2FlipperDrawer
<Amthrax> Ah, they are really dotted
<aleung> alright
<aleung> i'll ci soon
<Amthrax> Glossary ci'd (along with structure changes to fdd.tex)
<Amthrax> May I resection ui.tex, or is someone working on it?
> I just saw the MDD'. I'm still chortling.
<Amthrax> I want to move it under revised specs and split off the use cases into a requirements subsection
<aleung> ah, btw, i think we're supposed to note changes in the mdd
<Amthrax> That's probably a good idea
<aleung> so you may want to include both versions somehow, although i can see how that'd get confusing
<Amthrax> I think that should be textual
<aleung> you may resection ui.tex
<Amthrax> There's not that much to say other than "completely replaced the X system"
<aleung> ah, ok
> Maybe put the old one in an appendix if we really want to include it.
<Amthrax> ui section chanages ci'd
<aleung> the r2, ui-design, and ui stuff should all be done
<Amthrax> Er, will be ci'd once uid 44267 is done
<Amthrax> Now ci'd
> That's me, and it's done now. (Why'd it take so long?)
<Amthrax> (Were you getting the MDD update, too?)
> Oh. In EPS form.
<aleung> i'll be back in 20 mins, lemme know if i need to do anything
<Amthrax> According to Petra the pseudo-9 on the PDD is a European 9
> I knew it was a 5-ish 9 not a 9-ish 5.
<Amthrax> (as is the rest of Magdelena's writing, apparently)
> I'd forgotten just how many changes we made to the game system.
<aleung> i was unaware europe had its own standards for numbers
<Amthrax> We might want to remove the "I \heart Austin. \smiley" from the MDD.  As Petra pointed out, our TA may be a bit too "weired out" by that
<Amthrax> s/weired/weirded/
> Especially since it's right next to the DOM cloud.
<Amthrax> Oh, and along those lines, the editor mock-up should probably be up-to-dated (including removing the color frobber, as pretty as it is)
<Amthrax> New design overview ci'd
<aleung> lol, sure thing
<aleung> what are the current frobbers?
<Amthrax> Dan, did you remove the property system stuff from game system?
<Amthrax> Connect, rotate, delete, (move?)
<aleung> it seems move is gone, rotate i'm considering possible alternatives
> Yeah
<aleung> eh, connect, rotate, delete it is
<Amthrax> Sounds good
<aleung> how about making it "I \heart DOM. \smiley"?
<Amthrax> There's still useful stuff in the old property system section, but it doesn't belong in the new property system section
<Amthrax> Hahaha
<Amthrax> Should I check in the GameBoard logger disabler?
> Sure.
<aleung> should i redistribute the remaining pie items?
<aleung> i guess quadrants looks nicer (and probably easier to implement
<Amthrax> Yeah
> Should I keep some of the old property stuff in the game system section?
<Amthrax> Probably.  At least a list of standard properties
> (I saw you wrote a property section, but I haven't read it yet)
<aleung> ah, having changed the pie menu, i will have to alter some of the use case stuff
<aleung> i'll email the new mdd and ui sketch
<Amthrax> 'Kay
<aleung> sent
<Amthrax> May I rename R2DrawerTest to R2DrawerTestApp so ant doesn't get confused?
<aleung> sure
<Amthrax> Build, javadoc, and junit tests all officially work
> You got ant to run junit?
<Amthrax> Yes
<Amthrax> ... apparently
> Impressive.
<Amthrax> That's odd.  I don't remember doing anything
* Amthrax shrugs
<aleung> aah, the eps is very large
> They tend to be like that.
<Amthrax> Back on the property thing, the game system section should probably mention that Gizmo's use the property system to export foo properties
> *nod*
<aleung> do single quotes work in tex?
> Yes, and they even do the right thing.
> But use a ` if you want an opening single quote
<aleung> mmm, ok
<aleung> alright, use-cases and ui have been updated
> Game simulation is performed by a \emph{modified dynamic adaptive
>   continuous-time discrete-event simulator}\footnote{Buzzword bingo!}. 
<Amthrax> New MDD and UI are up (another big cvs update to pull)
<Amthrax> Oh, crud
<Amthrax> cvs [commit aborted]: error closing lock file /mit/6.170/groups/se064/cvsroot/gizmoball/doc/fdd/,mdd.eps,: Disk quota exceeded
> Gah!
<Amthrax> They suck
> Uh.
<Amthrax> The hell?  We're only using 37 megs
<Amthrax> Luckily, I don't feel bad about directly prodding cvs roots.
> So, uh, what are we going to do? I really don't want to clean out the repository.
> Oh, You have more of a stomach than I do.
<Amthrax> I'm going to delete the old fdd/mdd.eps stuff (11 megs)
<Amthrax> Alternatively, that probably just shouldn't be checked in.  I've got a makefile in there to generate it from mdd.jpg
> That makes sense.
<Amthrax> Nobody cvs for a while
<Amthrax> Alright, it should be clean.  cvs up from the root to be sure
<Amthrax> Now we're only using 25 megs
<aleung> any idea what the limit is?
<Amthrax> Probably 40
> We should ask for more.
<Amthrax> We also shouldn't keep generated files in there...
<Amthrax> How's the testing section?
> Finishing the game system is taking longer than I expected.
<Amthrax> Okay
<Amthrax> Especially with having to type "modified dynamic adaptive continuous-time discete-event simulator" repeatedly?  ]:--8)
> The
> simulation of each gizmo is performed in continuous time in the
> intervals between discrete events.
<Amthrax> ci'd
> Oh no! A merge conflict!
<Amthrax> *gasp*
> It's in fdd.tex, so it can't be non-trivial.
> Oh, I should mention the AGWPG
<Amthrax> Ah, yes
<Amthrax> Be sure to mention that we thought about not having it
<Amthrax> Since we're supposed to mention alternatives we considered
<Amthrax> I suppose that should also apply to the collision system
> Right. Maybe a footnote for that.
<Amthrax> I'm putting it directly into the property system stuff
<Amthrax> It's more of an "alternative approach" than a history
> I should probably also mention that we eliminated the fixed-translatable dichotomy.
<Amthrax> Yes
<Amthrax> ZKS is now in the glossary
> Excellent.
<aleung> shall i change all references to pie menus to frobber menus?
<Amthrax> Hmm.
<Amthrax> I suppose they technically aren't pie menus because they aren't transient.
<Amthrax> Change the references and add a footnote (or something) explaining that?
<aleung> how about a reference to the glossary?
> Be sure to mention that to use a frobber menu is to frobnicate the gizmo.
<Amthrax> So.. what happens when edit mode is switched to while a flipper is flippering?
<aleung> i assume it freezes
<Amthrax> In place?
<aleung> sure
<Amthrax> Okay
> I don't see any reason not to do that.
<aleung> it'd be annoying to have the drawers in editing mode draw in standard position
<aleung> or wait till it returns
<Amthrax> Neither do I.  And waiting could be difficult to implement without much user benefit
<Amthrax> Alright, so they'll come to a dead halt
<aleung> btw, i was thinking the editing mode would have a different refreshing strategy for the gameboard than the playing mode
> That makes sense.
<aleung> eh, so where to put the repainting...
<Amthrax> Oh, be sure to mention the 50ms timer thing
<Amthrax> I'm adding a bit to Possible changes about possibly changing that
<aleung> alright
<aleung> i'll throw that into the renderer part, i guess
> Upon further reflection\footnote{Not the kind
>   used by the properties system}, we concluded that this dichotomy did
> not provide significant benefits.
<Amthrax> She'd better enjoy this document.  ]:--8)
<Amthrax> Do we have a design section about the editor that I can point a \ref to?  If not, I'll just remove the reference
<aleung> what aspect of editor design?
<Amthrax> The design aspect of the editor design
<aleung> well, there's design as in interface and feature design, and design as in implementation design
<Amthrax> Implementation design
<aleung> hmm, i don't think we really discuss that much yet
<Amthrax> Okay.  I can just remove the ref
<aleung> ok
> \begin{itemize}
> \item the gizmo's name (a string used by the editor to identify a
>   specific gizmo to the user)
> \item the gizmo's position on the board
> \item the gizmo's orientation, if appropriate
> \item for a ball, its current velocity
> \end{itemize}
> Am I forgetting any properties?
> flipper handedness?
<Amthrax> Yeah, technically, though I'm still not sure how we're presenting that to the user
<Amthrax> The size of the absorber
<Amthrax> Can I get a ref on the collision system?
> Sure, ref sec:collision-system
> (I'm changing the structure of the game system docs around, it was getting kinda unwieldy)
<Amthrax> Okay
> Bobby is playing annoyingly upbeat Japanese anime music. I'm playing annoyingly angry German industrial music. They go so well together.
<Amthrax> Should I mention frobber menu in the glossary?
> Isn't it already mentioned?
<Amthrax> Frobber is
<Amthrax> As if frobnicate
<Amthrax> But not frobber menu.  I want to mention its similarity to a pie menu
> Sure, why not?
<Amthrax> Ah, now sections 1.1 and 1.2 fit nicely on to the first page
<Amthrax> Lotsa ci's
> I'm going to commit the game system stuff.
> Still need to talk about alternatives for collision stuff.
<Amthrax> Is cryptosystem one word?
> I think so
<Amthrax> Google appears to think so, too
<Amthrax> Gah!  Footnotes don't work in description environments
> Really? I didn't know that.
<Amthrax> Well, they don't work if they're in the item brackets
> oh
<Amthrax> Gah!  I don't have underscore.sty
> I thought it was standard!
<Amthrax> That doesn't mean anything
<Amthrax> Oh well, now I do
> Apparently not... /sw/share/texmf-local/tex/latex/other/misc/underscore.sty
<Amthrax> Oh
<Amthrax> On page 11 you have a "for a flipper, " item
> Oh. Right.
> I don't anymore.
<Amthrax> aleung: Still around?
<aleung> yup
<Amthrax> Feel like editing?  ]:--8)
<aleung> sure
> Heh. I like the Machiavelli reference.
<Amthrax> I'll send a PDF
<aleung> cool
<Amthrax> Thanks  ]:--8)
<Amthrax> Sent
<Amthrax> We should probably try to wrap this up by 1:30
<aleung> got it
> OK
<aleung> do we have a runtime model text description?
> I don't believe in those either.
<Amthrax> That's basically spread throughout the module descriptios
> which is why I don't believe in them.
<aleung> ok
<aleung> shall we alphabetize our glossary?
<Amthrax> (Dan, I'll be sure to use lots of \emph's so it fits in well with the rest of your section ]:--8)
* dan grins.
<Amthrax> I was thinking about that...  Currently I have it kind of grouped, but I'm not sure that's at all clear
<aleung> btw, our system supports even invalid gizmo placements
<aleung> like overlaps and such
<Amthrax> Well, that's true, but the editor won't let you put something somewhere where you can't put something
<Amthrax> Unless we want it to, of course.
<Amthrax> But I think that's too much user empowerment.
> You can't put something where you can't put something? That's very profound.
<Amthrax> Wouldn't want them to get any ideas.
> Those uppity users.
<aleung> how to handle gizmo placement collisions?
> Both top-down, bottom-up, and
> inside-out testing methodologies are used, comprising both black-box
> and glass-box tests.
> I'm not mentioning no-box testing.
<aleung> i thought both could apply to three?
> Oh, right.
> I originally said top-down and bottom-up, then I realized I needed inside-out too.
<Amthrax> Uh, it should probably be mentioned which parts of the system use which types of testing...
> Sure, that's the next part.
<Amthrax> Okay, just checking  ]:--8)
*** You have new email.
> Are there any junit tests for ui stuff?
<aleung> only r2drawerfactory
<aleung> which tests that it correctly dispatches on type and returns singletons
> ok
<Amthrax> Didn't you also have a test application for something?
<aleung> yeah, but that doesn't count as junit
<Amthrax> But it's still testing
<aleung> that was to test the actual drawers
> But it wouldn't hurt to tell me about it. :)
<aleung> r2drawertestapplication?
<Amthrax> Just app
<Amthrax> I think
<aleung> k
<Amthrax> R2DrawerTestApp
<Amthrax> Oops, I probably shouldn't have left that shell in the cvs root directory...
<aleung> it used to use stubs to test that the drawers could draw the right gizmos, but now for the most part, it uses the real gizmos
> Good! Both unit and integration tests!
<Amthrax> And, of course, our "scripted" tests of the whole UI, which certainly test the real gizmos and integration
* dan nods.
> I was just writing about those.
<Amthrax> Alternative collision systems ci'd
<aleung> how do i get the math r2?
> $\R^2$
<aleung> the for a flipper item is removed?
> The sentence got finished
> (Or phrase, I guess)
<Amthrax> Oh, cool, the MDD figurizes now
<Amthrax> Though now the TOC goes onto the second page
> Put the TOC on its own page and center the title?
<Amthrax> Oh, wait, there's no implementation overview section in DSS
<Amthrax> Hmm
<Amthrax> Should I move the MDD to the end of the design section?
> Hmm.
<Amthrax> It would make sense
<Amthrax> Then make project plan its own section
> Sure.
> (And Validation will still be a section?)
<Amthrax> Yes
> OK
> Almost done with it.
> I referred to my play, too.
<aleung> edits ci'd
<aleung> there were just small grammatical things
<aleung> it reads fine
<Amthrax> Cool
<Amthrax> Figure pushing-arounding ci'd
<Amthrax> Currently the MDD and the timeline stomp on eachother, but that should go away with a testing section
> Yeah. It's going to be in shortly.
<aleung> very good...
> I'm in the process of sectioning it now.
<aleung> the mdd looks surprisingly nice in the pdf
<Amthrax> I'll compose the email
<aleung> email?
<Amthrax> To Magdalena
<aleung> ah, what's this complicated checkin and tagging thing we have to do?
<Amthrax> It's just them being weird
<Amthrax> I'll get the tagging once we're all ready
> Fighting with the figure...
<aleung> what's this email being composed?
<Amthrax> Just to tell her where to look for the PDF and how to run the demo
<aleung> ok
> OK, let me see if this formatted right...
> I stuck a \newpage in to make sure the MDD displayed in the right place.
<Amthrax> Okay
> ok, that's it. Committing.
> ci'd.
> Want me to build the PDF?
<Amthrax> I got it
> OK
<Amthrax> I'm gonna tag...
> ok
<Amthrax> Tagging
<Amthrax> Which is, of course, linear time with the size of the repository...  Yay cvs
> That's totally broken.
> (Like so much of CVS)
<Amthrax> Ooh, actually it might be literally with the size of the repository (ie, history any everything)
<Amthrax> Email sent
<Amthrax> And that's that
> Cool.
*** You have new email.
<aleung> great
> I guess I ought to take Zack off the mailing list.
<Amthrax> Er, yeah
<aleung> time to die for a little while
<Amthrax> Heh, 1:36 past two hours past midnight.  ]:--8)
<Amthrax> Happy dying.  I think I'll do the same after finishing (and starting) 18.06..
<aleung> eh, i don't think i could start if i wanted to at this point
<Amthrax> This is the time I usually start 18.06
<aleung> ah, i usually start it in a couple hours
<Amthrax> HEh
<aleung> see you in the morning
<Amthrax> G'night
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
<aleung> amendments are up
<aleung> from looking just at the contents, it looks ridiculously easy (in fact, we already have them)
<aleung> lol, multiple balls
<aleung> and polygon gizmos
<aleung> eh, how disappointing
<aleung> we can probably check off that milestone tonight
*** Global -- from OperServ: Macman is now an IRC operator.
<aleung> eh, we should discuss how the standard gizmo classes are gonna be stored so the palette can get them
<aleung> are custom cursors safe for mac and linux?
> Yeah. I was hoping they might actually throw something interesting at us for the amendment.
<Amthrax> Oh, that's cute (just read the amendment)
<Amthrax> I like the poly-gizmos.  It's still trivial (though editor support for that would be interesting), but cool
> So what do we call those? ConcreteGizmoWithPolygonalGeometry?
<Amthrax> Oh, and I thought of a new, possibly better way to do the collision stuff today.  ]:--8D
<Amthrax> Unfortunately, we probably call them PolyGizmoGizmo unless I want to define another transformer...
<Amthrax> Though I suppose the loader will need special support for those anyways, since they completely break its reflection assumptions.
> Yeah, with the vertices and all.
> You'll have to tell me about your new collision idea. But I reserve the right to ignore you and to throw heavy objects at you.
*** Notice -- Ambs (~dan@AMBULATORY-CLAM.MIT.EDU) is now operator (O)
*** Global -- from OperServ: Ambs is now an IRC operator.
> Heh. The antichess amendment adds undo!
<Amthrax> And with the things-not-overlapping bit.  Though maybe that could be ignored for poly gizmos
<Amthrax> Right granted.  It doesn't change the game loop itself, just the location of canCollideWith/collide
<Amthrax> Ooh, undo.  That's something that would actually be hard.. for most gizmoball games.
> Where would you put them?
*** You have new email.
<Amthrax> It's similar to the old collision manager, except that each gizmo would register collision resolvers with the manager.  The resolver would consist of the two gizmo types it dealt with and an implemented method for resolving collisions between gizmos of those types.
<Amthrax> It's fairly similar to what we do now, but I think somewhat less cluttered.
<Amthrax> And it's a lot of generic programming, except that the implementations of these things are now out in the gizmos instead of in a central manager
<Amthrax> s/of/like/
> Oh, I thought about something like that too...
> I was thinking of defining them in terms of CollisionPair classes.
<Amthrax> What would a CollisionPair include?
<Amthrax> API-wise, I was thinking along the lines of CollisionManager.registerResolver(BallGizmo.class, AGWPG.class, new CollisionResolver { .. collide .. }) where CollisionResolver would be an interface and the register method would be static
> The ability to handle collisions between two types of gizmos, but separated out from the gizmos.
<Amthrax> Okay, so essentially the same thing as the CollisionResolver I was thinking of?
> Sounds like it.
<Amthrax> Oh, and that snippit would probably be put in a static { } block
> I was thinking it would just make things more complex without giving us any extra power.
<Amthrax> I don't think it would give us extra power, but I do think it would concretify our currently rather fuzzy CAN/NEVER/DEFER system, since resolvers would just be registered out-right, instead of the game board having to figure out what the type collision pairs are
<Amthrax> Plus, you could point to a resolver and say "this is where it resolves foo-bar collisions"
> Yeah, it does package things up nicely.
<Amthrax> Feel free to throw large objects now
> (Into ravioli!)
<Amthrax> It probably would add a bit of complexity because of the CollisionManager class, but that might also be leveragable to pull out some of the collision resolution stuff from GameBoard
<Amthrax> Refactoring!
> Yeah, the GameBoard internally converts things into CollisionPair records, we might be able to avoid some of that complexity
<aleung> what i'm hoping for is a collision system universal enough to handle collisions for the gizmo placing in the editor
> In any case, I'm not implementing it. :P
<Amthrax> Yeah, we do have to figure out the collisions-in-the-editor thing
<Amthrax> The obvious approach is to use bounding boxes (though that doesn't work well with poly gizmos)
> Bounding polys?
<aleung> circles and things are still annoying
> Yeah, you'd have to bound them with a box/poly. That's not so bad, but it still feels less than ideal.
<Amthrax> Perhaps each gizmo could returns its geometry in terms of polys and circles, then those could be intersected?
> That could work. A set of bounding, uh, shapes?
<Amthrax> Yeah
> And the obvious intersection algorithm would work fine, it doesn't need to be efficient.
<Amthrax> Yeah
<aleung> make sure we can also account for what gizmo is currently being clicked
<aleung> it seems that should be part of the editor collision handling too
<Amthrax> *nods*
<Amthrax> With the bounding shape sets, that would certainly work
<aleung> have we decided on where and how to represent the gizmo set?
> hmm.
<aleung> is gizmo orientation working?
<aleung> ah, i mean flipper
<aleung> nevermind
<aleung> i just noticed that setting the orientation to something like 1 rad results in it not drawing, was wondering why that was
<aleung> also, what's with absorbers having a 2 height?
<Amthrax> It has a 2 height?
<aleung> yeah, i think you hard coded that into the constructor
<aleung> for a sec, i thought it might be to prevent collisions with the bottom of the absorber
<Amthrax> Oh.  I guess that's the default size.
<Amthrax> Though nothing's stopping that from changing...
> I thought they had a 1 height?
<Amthrax> Can't their size be set to anything?
<aleung> sure
<aleung> as long as balls in them don't touch the walls?
<Amthrax> Actually, that's fine too
<Amthrax> Actually, the size is required by the XML file, so it'll always get set
<aleung> ok
*** Notice -- Ambs (~dan@AMBULATORY-CLAM.MIT.EDU) is now operator (O)
*** Global -- from OperServ: Ambs is now an IRC operator.
*** You have new email.
*** Notice -- Ambs (~dan@AMBULATORY-CLAM.MIT.EDU) is now operator (O)
*** Global -- from OperServ: Ambs is now an IRC operator.
*** You have new email.
*** Notice -- Ambs (~dan@RLE-13-049.MIT.EDU) is now operator (O)
*** Global -- from OperServ: Ambs is now an IRC operator.
<aleung> can i get the editor collision system sometime soon?
<aleung> i'm gonna be out this weekend starting tomorrow night till sunday night
<aleung> or at least if it's spec'd
<Amthrax> Oh, right, we should spec that
<aleung> btw, can we do a quick tetris implementation?
<aleung> you could have a gizmo that assimilates pieces that collide and checks for row fills
<aleung> another one that spits out random pieces with keypress triggers: something to rotate, something to make it drop
<aleung> and then just regular AGWPG that can move and collide
<Amthrax> That would be surprisingly easy
> The only problem might be that you'd have to have multiple kinds of keypress triggers. And the collision code would be a bit scary. But neither is insurmountable.
<aleung> yup
<aleung> so, our next milestone is far off (the deadline, no?)
<aleung> we should probably set goals before that
<aleung> flipper collisions would be very cool, gizmoball is rather deterministic without them
<aleung> i'm aiming to have basic gizmo adding in the editing mode done by tomorrow night
<aleung> still wondering how to do the frobber menu
*** You have new email.
<Amthrax> Yeah, we should at least have an internal schedule
<Amthrax> It really shouldn't take long to implement flipper collisions (maybe I'll do that tonight if I can't sleep again)
<Amthrax> The frobber menu should work through the properties system, which should actually make it fairly easy to implement (at least, for changing things and determinging which frobbers to display).
<Amthrax> Feel free to ask questions about the properties system.
<aleung> eh, not the frobber system
<aleung> the actual thing itself
<aleung> maybe we can pop something up
<Amthrax> Why not just draw stuff in the component?
*** You have new email.
<Amthrax> For example, component.showRotateFrobber(true) (and, of course, stuff like component.setSelectedComponent(foo))
<Amthrax> Oh, I guess you'd probably need a frobber listener thing, too
<Amthrax> Ooh, ooh, an enumerate class for frobber types, then component.showFrobber(FrobberType, boolean) and component.addFrobberListener(FrobberListener) where FrobberListener would be a typical listener interface, but the method would take a FrobberType
<Amthrax> And I guess you'd need some mechanism to indicate when the user "dragged" frobbers, so probably three methods in the FrobberListener..
<aleung> the problem with that is the off the screen issue
<aleung> objects on the borders will have frobbers off the displayable area
<aleung> i could always divide up the quadrants that can display, but that gets kinda messy
<aleung> is there an online copy of our specs?
<Amthrax> Eh, the component knows how big the frobbers are, so it can reposition them if necessary.
<Amthrax> http://awakening.mit.edu/~amthrax/gizmoball/
*** You have new email.
<aleung> hmm, how bout we sweep all the awards?
<aleung> this project is haunting me
<aleung> sucking up all my free resources
*** Signoff: Amthrax (Quit: leaving)
*** Amthrax (amthrax@AWAKENING.MIT.EDU) has joined channel #6.170
<aleung> so i've gotten to the point where you can place square gizmos
<aleung> but i have to leave soon, and it's not quite ready, i guess i'll have it in good shape by sunday
<aleung> (night)
<aleung> there's one issue, which is that i have a thing in the component tracking the mouse to display where the gizmo is being placed
<aleung> and it lags quite a bit
<aleung> it's about half a second delay
<aleung> hah, this is rather fun
<aleung> apparently the circle drawer snapped to grid by default cause of an order of ops error
<aleung> so i'm watching balls collide with seemingly invisible things and going through other things
<aleung> aah, i gotta stop working on this
*** You have new email.
*** You have new email.
<aleung> ah, the lag is solved
<aleung> apparently, drawing things with dash patterned strokes is extremely slow
<Amthrax> Heh, cool ]:--8)
*** Darren (Jinxster@user213040191159.dial.netline.net.uk) has joined channel #6.170
<Darren> ?
*** Darren has left channel #6.170
*** dan is dan@clamshell.ambulatoryclam.net (Dan Ports)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** dan is an IRC Operator
*** dan has been idle 3762 minutes, signed on at Thu Apr 15 03:43:10 2004
*** dan : End of /WHOIS list.
#6.170	Amthrax   H%  amthrax@AWAKENING.MIT.EDU (0 Amthrax Arlan)
#6.170	Amthrax   H%  amthrax@AWAKENING.MIT.EDU (0 Amthrax Arlan)
#6.170	aleung    H%  ~aleung@MACGREGOR-THREE-SIXTY-ONE.MIT.EDU (0 Albert Leung)
#6.170	aleung    H%  ~aleung@MACGREGOR-THREE-SIXTY-ONE.MIT.EDU (0 Albert Leung)
#6.170	dan       H*  dan@clamshell.ambulatoryclam.net (0 Dan Ports)
#6.170	dan       H*  dan@clamshell.ambulatoryclam.net (0 Dan Ports)
*** clamshell.ambulatoryclam.net #6.170 :End of /WHO list.
*** clamshell.ambulatoryclam.net #6.170 :End of /WHO list.
*** Mode change "+aA" for user dan by dan
*** ispectre (~dan@CPE000a278d2a22-CM014120010486.cpe.net.cable.rogers.com) has joined channel #6.170
*** Signoff: ispectre (Quit: ispectre)
*	Amthrax   H%  amthrax@AWAKENING.MIT.EDU (0 Amthrax Arlan)
*	aleung    H%  ~aleung@MACGREGOR-THREE-SIXTY-ONE.MIT.EDU (0 Albert Leung)
*	dan       H*  dan@clamshell.ambulatoryclam.net (0 Dan Ports)
*	DevNull   H   services@netmug.org (2 /dev/null -- message sink)
*	HelpServ  H   services@netmug.org (2 Help Server)
*	StatServ  H%  services@netmug.org (2 Statistics Server)
*	MemoServ  H*  services@netmug.org (2 Memo Server)
*	ChanServ  H*  services@netmug.org (2 Channel Server)
*	NickServ  H*  services@netmug.org (2 Nickname Server)
*	Global    H*  services@netmug.org (2 Global Noticer)
*	OperServ  H*  services@netmug.org (2 Operator Server)
*** clamshell.ambulatoryclam.net * :End of /WHO list.
<aleung> what's everyone's status?
<aleung> i got back about an hour ago
<aleung> hopefully we have flippers, saving, the poly gizmo, editor collisions?
<Amthrax> Uh, we have flippers (not checked in yet because I'm not entirely convinced they work)
<Amthrax> Dan and I have basically spec'd out how to do editor collisions (using a blob mechanism)
<Amthrax> And, of course, the poly gizmos been just about done for some time now.
<aleung> great
<aleung> btw, my editor uses reflection to decide how gizmos should be created based on their constructors
<aleung> so for the poly one, it'll go through a submode where you click and define the points
<aleung> but other potential types are ones where you click and drag to define the size of the gizmo, etc.
<aleung> or the simple clicking and placing
<Amthrax> Wow.  How did you determine that through the ctor?
<aleung> well, i'm just assuming that types are indicative of what kind of constructor it is
<aleung> so if you have a vect[], that's a poly
<aleung> which is quite an assumption
<Amthrax> Oh.  I just gave them all default ctors
<aleung> yeah, i know
<Amthrax> Wouldn't it be better to check which properties they have?
<aleung> that would work too
<aleung> in fact, i should do it like that
<aleung> but the poly is a property?
<Amthrax> Since that was part of what the property system was designed for  ]:--8)
<Amthrax> Ah, yeah, that.
<Amthrax> Um, I'm still working on how to express the poly thing
<aleung> ok
<Amthrax> I'm thinking the best way is to add collection support to the properties system
<aleung> we can definitely reflect off the properties
<Amthrax> (Something I was thinking of doing from the start, but had decided against)
<aleung> not hard to change either
<Amthrax> Cool
<aleung> and i was considering already since i had the issue of distinguishing between a dimension and a velocity vect
<Amthrax> Uh, since it's sort of undocumented, I recommend looking the XML loader for the assumed property names
<aleung> btw, i wanted to abstract out the triggered actions
<Amthrax> That's true
<Amthrax> How so?
<aleung> well, it seems that when triggered, gizmos only have such a set of things they can do, so we might as well let the user control that too
<Amthrax> Oh, you mean the ability to have multiple types of triggers?
<aleung> yeah, that too
<aleung> but for the most part, triggering will just set some property
<Amthrax> Currently it's assumed each gizmo has only one type of trigger (which is all that's necessary by their specs)
* Amthrax nods
<aleung> yeah, but if we're to do anything like have gizmos that you can move around
<Amthrax> And once collections are added to the property system, the triggers will be available through it
<Amthrax> Move around during gameplay?
<aleung> yup
<Amthrax> Hmm
<aleung> you'll have to treat different keypress triggers differently
<Amthrax> We should probably ask Dan about that, since he wrote the trigger system
<Amthrax> Right
<aleung> which means you'll probably want different triggerable actions
<Amthrax> Yeah..  I'm not sure what could be added to most of the triggers
<aleung> btw, can we refactor a lot of the stuff?
<aleung> it seems the default packages are getting awfully cluttered
<Amthrax> Maybe.  What are you thinking of?
<aleung> just throw all the standard gizmos into their own package
<Amthrax> Yeah, that's what just came to my mind, too  ]:--8)
<aleung> all the drawers into their own package, things like that
<Amthrax> My code's easy to change for putting the gizmos into their own package
<aleung> well, eclipse can do it automatically ^_~
<Amthrax> Ah, not quite!
> *poked*
<aleung> really?
<aleung> it seems to cover most of the bases
<Amthrax> Nope.  The things that reflect into the Gizmos would have to be changed by hand because it's a runtime thing.  Eclipse is none-too-good about dealing with runtime things
<aleung> ah, right
<Amthrax> Automatic tools are great, but only if you know exactly what's going on ]:--8)
> I kinda like the idea of making the trigger action customizable, but that would require some fairly serious changes to how the trigger system works.
<aleung> you could just associate triggers with parameters, then on the triggered gizmo end, have a map from parameters to the actions?
<aleung> with actions stored as property-value pairs or something and then various special types
<aleung> to do flippering or ball release
<aleung> although those could even be properties too, i guess
<aleung> i guess that's not really that customizable, but it would be a step up from now
> I guess. You'd need a way to specify the action of the trigger (we don't currently have that, we just fireTrigger on the gizmo). And we'd need to come up with editor and/or XML interfaces for it.
<aleung> on another note, how are we implementing undo?
<Amthrax> Via the properties system, presumably
<Amthrax> Keep track of the stack of property changes
<aleung> hmm, but not every change is a property
<Amthrax> Then just pop them
<Amthrax> Other than triggers (which will be soon) and creation/deletion, which aren't?
> Are there non-propertified changes?
<aleung> that's true
<aleung> alright, there goes that issue
<Amthrax> Yay for unissues  ]:--8)
> hey, if we've got collections, we could propertify the GameBoard and make adding/deleting gizmos a property change too.
<Amthrax> Woah
<aleung> hah, nice
<aleung> we always wanted gameboard properties
<aleung> like topology
<Amthrax> *world stops spinning*  I think that'd work quite well
<aleung> i'll handle some undoing stuff internally, like undoing placing points when defining a polygon
<Amthrax> Maybe have "undo groups" so a single undo can represent multiple property changes in some sane way?
<aleung> hmm, why undo multiple property changes at once?
> And if we're talking about giving triggers nifty new features, it sounds like we're heading towards propertifying them too.
<aleung> definitely
<aleung> well, since we have a property framework
<aleung> that's good enough to support most things
<aleung> we might as well capitalize
<Amthrax> Well, for instance, adding a gizmo to the board would consist of two property changes: adding the gizmo to the gameboard gizmo list and, say, setting its position
<aleung> mmm, that's true
> Right. Sounds like you'd want to separate them into 'UI actions' which would be grouped property changes that happen at once.
> (Atomically!)
<Amthrax> Though, let's not implement redo, because adding things to collection properties goes screwey if you undo it then redo it
<aleung> hah
<aleung> so you don't want the one stage undo where undoing your undo is a redo?
<Amthrax> I personally prefer infinite undo (Emacs style!  Wait.. no, let's not kill ourselves and our users with hyper-undo)
<aleung> i wouldn't mind an infinite undo and redo
<aleung> but considering this is all beyond the scope of what's needed
<aleung> we'll stick with the rational choice
<Amthrax> Heh, sounds good
<Amthrax> Infinite undo should be pretty easy
<aleung> yup
<Amthrax> Redo should be pretty hard
<Amthrax> Let's not do redo ]:--8)
<aleung> i'm assuming you shut off this property tracking system in play mode
<Amthrax> Well, sort of.  There shouldn't be any listeners while playing
<aleung> ah, ok
<Amthrax> If there are no listeners, then, yes, the property system basically shuts down
> But it would be really cool if you could undo the gameplay all the way back to the start of simulation...
<aleung> in very small ticks...
<Amthrax> Ooh
<aleung> it would be nice though
* dan forces that thought out of his mind.
<aleung> hah, you could rewind and change the course of history!
<Amthrax> Continuations!
<aleung> continuations?
<Amthrax> Continuations!
<aleung> i never thought i'd hear that again
<aleung> but i just heard it twice
<Amthrax> Mmm, continuations
<aleung> so please justify?
<Amthrax> Well, if we're going to support changing the course of history via an infinite undo that captures the game state at every point, we might as well be able to wrap up these undo checkpoints and be able to hand them to the user
<aleung> ah, true
<Amthrax> (And, no, I'm not really suggesting this.  It goes along with the higher-order editor)
> Continuations!
<aleung> continuations!
<aleung> anyway, prioritizing
> Right.
<Amthrax> Progress document, anyone?
<aleung> what has our progress been?
<Amthrax> Implemented multiple balls
<Amthrax> Flipper collisions.. I think
<aleung> i have the bulk of gizmo placement and snap done
<aleung> so ui side, we just need the property table and frobbers
<Amthrax> I noticed you have a lot of the editor drawing stuff, too
<aleung> yeah
<aleung> eh, it's not so bad
> I haven't done much of anything except make cynical comments this week, but that can be changed.
<aleung> actually, i need to make the trigger drawer handle self-triggers and other weird things
> One thing I was going to do was make the trigger mechanism deal with keyup/keydown triggers. Unless we're going to totally change the trigger system in a way that makes it silly to do that, I'll implement that tonight.
<aleung> well, dealing with keyup keydown could be a subset of the new trigger system
<Amthrax> If you make that look like a property, then it should be easy to shift later
> *nod*
> What else am I working on?
<aleung> ah, can we go for: saving and editor collisions sometime soon?
<aleung> that would make being able to build in the editor a bit more fun
> (I ask, as I break out a copy of the timeline for the next progress document)
<Amthrax> Hmm.
<Amthrax> I was planning on doing the collections properties thing next
<Amthrax> Since that will affect a number of things
<aleung> ok
<Amthrax> Once that's done I can do saving
<aleung> saving shouldn't be too difficult?
<Amthrax> No
> I'll do the editor collisions.
<Amthrax> But it'll use the collections properties
<aleung> ah, ok
<aleung> for the triggers
<Amthrax> (Dan, are you writing up the timeline?  I'm working on the rest of the progress document now)
<Amthrax> I guess polygonal gizmos should come after that
<Amthrax> (Not that that'll take much work)
> oh, you are? cool, I don't have to do that, then. I'll do the timeline.
<aleung> sounds good
<Amthrax> 'Kay.  Uh, want me to check in the skeleton so you have something to write on?
> Sure.
<aleung> then we can go for the abstracted trigger system
<aleung> and then we can build games!
> remote triggers! WormholeGizmos!
<Amthrax> (progress document ci'd)
<aleung> mmm, i guess we know what's happening for the next couple of days
<aleung> there's only like a week left...
<Amthrax> Spec'ing the blob mechanism and the property collection support should probably go in the timeline, too
> Right.
<Amthrax> Those should probably be due 5/3
> *nod*
<aleung> do we have any issues?
<Amthrax> Uh, that we haven't had a conflict yet?
<aleung> true
<aleung> we're running out of time
> I'm making a point of listing that we implemented the amendment before it was released.
<Amthrax> Ooh, could it be over the new collision system that I want?  ]:--8)
<Amthrax> Excellent
<aleung> sure
> s/Plan and schedule amendment/Plan and *retroactively* schedule amendment/ ?
<aleung> i don't have much a stance in the new collision system
<Amthrax> Heh, sounds good
<aleung> only cause i probably won't have any part in implementing it
<aleung> though you could try to force it on me
<Amthrax> That's true.  Though, finding a conflict that conflicts all of us could be difficult with how well we've split up the system
<aleung> and i can threaten to not do the editor
<Amthrax> Ooh
> Ooh, I'm putting in 'Polygonal gizmos' as implemented with 'Standard gizmos'
<aleung> in any case
> (as in AGWPG)
<Amthrax> Heh, okay.
<aleung> gizmo placement will be done by tomorrow night
<aleung> along with support for poly gizmos
> The timeline lists me as implementing the editor display. But, uh, it looks like you've got that covered.
<Amthrax> So, the parts of the amendment that still need to be done are the multi-ball absorber, and loader support?
<aleung> i thought you were doing the property table
<aleung> but i don't mind taking all the ui stuff
<aleung> since i'm doing it already
<Amthrax> not-Zack was on the property table  ]:--8)
<aleung> ah, ok
<aleung> i wasn't sure what editor display was
> Yeah, I guess we should decide who's doing that. (Maybe table that issue until later?)
<Amthrax> Bad Dan
<Amthrax> I think that, for that, you should do it ]:--8)
* dan grins
<aleung> eh, there's not much to do
<Amthrax> For?
> sure, I guess I can do it.
<aleung> editor display?
<Amthrax> The editor display is the whole frobber menu and arrows and stuff and such, which is mostly done anyways, it seems
<aleung> oh, frobber menu
<Amthrax> And the gizmo palette, I suppose
<aleung> that's separate
> Oh, that's what it is.
<aleung> the gizmo palette is almost done
<Amthrax> Er, well, that's what _I_ thought it was...
<aleung> i guess you can take the frobber menu
<Amthrax> Isn't that part of your whole artifact system, though?
<Amthrax> Or was that not meant for that...
<aleung> yeah, i suppose we could do it using artifacts
<aleung> that was initially how it was to be done
> I thought that was what the artifacts were for?
<aleung> anyway
<aleung> well, that's part of it. the artifacts also handle things like build transients (a gizmo hovering and following the mouse around)
<aleung> but i suppose i should take the editor drawing
<aleung> or display rather
<aleung> since i've already taken it
<Amthrax> That would be a good reason to take it  ]:--8)
> Seems so
<aleung> mmm, if we're set, i guess i'm leaving now
<Amthrax> Want to look over the progress document first?
<aleung> it's rare that we're all here
<aleung> oh, is it completed?
<Amthrax> (Or tomorrow, that's fine)
<Amthrax> Uh, pretty much
> Timeline is almost ready
<Amthrax> What's our upcoming plan?
<aleung> ah, i think i looked over it
<Amthrax> Follow the schedule?
> Sounds good to me
<aleung> looks good
<aleung> we really have no issues?
<aleung> that should be an issue
<Amthrax> ci'd
<aleung> and make an issue that our only issue is self-contradicting
<Amthrax> Haha
> OK, we have to do that.
<aleung> which would of course snowball
<aleung> then we could have an existential conversation for our meeting
<aleung> and petition for hass credit!
>       Plan and (retroactively) schedule amendment & & 4/28 & \done \\
>       Specs for collection properties & Austin & 5/3 \\
>       Specs for editor collisions (Blobs) & Dan & 5/3 \\
>       Collection properties & Austin & 5/7 \\
>       Editor collision detection & Dan & 5/7 \\
>       XML saver & Austin & 5/7 \\
>       Finish flippers & Austin & 5/7 & \done \\
>       PolyGizmos and multi-ball absorber support & Austin & 5/7 \\
>       Editor display & Albert & 5/7 \\
>       Editor interaction mode & Albert & 5/7 \\
>       Property table & Dan & 5/7 \\
>       Prettify $\R^2$ drawers & Albert & 5/9 \\
>       Undo support and other nifty extensions & & 5/10 \\
<Amthrax> Maybe split up 5/7 a bit more?
> Yeah, I was thinking it probably should be, I just hadn't figured out how to do it.
<Amthrax> s/Blobs/Blob system/ ?
<Amthrax> Or blob support?
> Blob system, I think
<Amthrax> Issues ci'd
> Move collection properties and blobs to, say, 5/5 or 5/6 so we at least nominally have them first?
<Amthrax> Yeah
> Timeline ci'd
<Amthrax> Implement multi-ball collisions?  Support really includes absorber support
> Good point, I forgot about that when I wrote that line.
> Fixed
<Amthrax> Anything else for issues (namely, unissues) you can think of?
> That sounds about it, unless we want to mention editor artifacts or something there.
> (Which doesn't sound much like an unissue, but...)
> Now I guess we just need to implement all this.
<Amthrax> Yep
> (But that's the easy part, right? ;)
<Amthrax> Yep
<aleung> ah, i guess i will do frobbers through the artifacts after all
<aleung> anyway, i'm gone
* Amthrax waves
* dan waves too
*** You have new email.
*** Signoff: aleung (Ping timeout)
*** Signoff: Amthrax (Ping timeout)
*** Amthrax (amthrax@NONE-FOUR-FORTY-THREE.MIT.EDU) has joined channel #6.170
<Amthrax> Stupid power
<Amthrax> We need wireless power!
*** Signoff: Amthrax (Quit: Leaving)
*** Amthrax (amthrax@AWAKENING.MIT.EDU) has joined channel #6.170
<Amthrax> *desperate ping*
*** Amthrax is amthrax@AWAKENING.MIT.EDU (Amthrax Arlan)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** Amthrax has been idle 48 minutes, signed on at Mon May  3 13:06:18 2004
*** amthrax : End of /WHOIS list.
> *useless pong*?
*** aleung (~aleung@MACGREGOR-THREE-SIXTY-ONE.MIT.EDU) has joined channel #6.170
* dan waves.
> Damn power outages.
<aleung> hah, yup
<aleung> wow, i just saw you walk by outside
<aleung> which was completely unexpected
*** Global -- from NickServ: Warning: Repeated bad password attempts for nick STL
<aleung> eh, i got snap to grid to work
<Amthrax> Cool.  I'm going to start on collection properties shortly
<aleung> stupid upper left corner oriented positions
<aleung> i guess i'll snap with mod or something rather than ieeeremainder
<aleung> arg, but why does the ball have to be different
<Amthrax> Oh, sorry about that
<Amthrax> That's another thing that came from the wonders of their specs
<aleung> eh, don't worry about it
<aleung> the ball will just snap funny, i suppose
<Amthrax> Maybe the ball shouldn't snap at all?
<aleung> yeah, i just thought of that
<aleung> it'd be annoying to treat different gizmos differently though
<aleung> i guess i'll see
> Blob specs ci'd
<Amthrax> Collection properties spec'd
<Amthrax> It's backwards compatible.  New methods are: Propertyified.addToCollection, removeFromCollection, addCollectionProperty, and isCollectionProperty and Property.getCollectionValue
*** You have new email.
<Amthrax> Oh, and I think I thought of a good way to reconcile our totally general collision mechanism with our TA's insistence that we use a completely different approach.  Make all of the standard gizmos derive from AbstractStandardGizmo, which would implement the current collision mechanism to the game system (though I still think we should repackage that with the CollisionManager), and present the abstract geometrical interface to the standard gizmos.
<Amthrax> Of course, I still take issue with abstracting the geometry because the physics library is far from complete
<Amthrax> But that would probably pacify her (which, sadly, might be necessary if we want to be in the running for design award), since that was the only real problem she thought our design had
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
<aleung> maybe we can complete the physics library while we're at it
<Amthrax> Gaaaah.  No.
<aleung> hah, alright
<aleung> build mode and gizmopalette basically work now
<aleung> i'll ci later tonight after it's polished up
*** You have new email.
<aleung> aah, i think i just figured out the S in SVM
<aleung> the stupid problems our minds solve in idle
<Amthrax> Haha
<Amthrax> I wonder what Magdalena will think if she asks us for the copy that we're using that magically works... considering the code I was reading is just the one on the course web site.
> Yeah, the idea of having an AbstractStandardGizmo occurred to me too. Maybe using the blob system. I don't actually want to do it, but it could be done.
> It also occurred to me as I was taking a shower this morning that we could probably even implement Traffick in Gizmoall.
> (Whether we'd *want* to is a totally different question, but we *could*)
<Amthrax> Hmm.  So, a super-set of the blob system that allows you to specify the dynamics of the components?
> Yeah, you could specify the blob shape of the gizmo, and its velocity, and compute time to collision from that.
> (It also has the nice property that collisions in the editor are handled using the same geometry as the simulator collision mechanism)
<Amthrax> That's true
<Amthrax> Though the gizmo should probably be told whether or not it's in being in editor mode, because some of them may way to have different bounding behaviours (ie, flippers)
> I forgot about that case, but yeah.
<aleung> yup, i always dreamed of a collision system universal to both modes
<aleung> austin, doesn't the magickeylistener work for unix?
<aleung> ah, i see that's what your email was about
<aleung> but yes, i meant to ask you yesterday, having looked at the code again myself
*** You have new email.
<aleung> about the traffick thing, something about incoming and outgoing triggers reminded me of bipartite graphs
<aleung> ::shudder::
*** You have new email.
*** You have new email.
> bipartite graphs? No! We will not speak of those again!
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
<aleung> wow, i managed to get your checkrep to assertion fail
<aleung>             Assert.assertTrue(event.type !=
<aleung>                 SimulatorEvent.END_OF_TICK); 
<aleung> that one in particular
<aleung> in GameBoard
<aleung> it's apparently also possible to add enough balls to crash the system
<aleung> (and no, i really don't know why i'm doing this)
> huh, that's an interesting one to have fail. I can't think of how you'd make the simulator break in that way.
*** You have new email.
*** Global -- from OperServ: Macman is now an IRC operator.
<aleung> ack, it seems the fall's stuff is all about custom look and feel
<Amthrax> Hahaha, you've checked in the file for that screenshot, right?  ]:--8)
<Amthrax> (The flipper code is still rather messy and largely untested, BTW)
<Amthrax> Collection properties ci'd
<Amthrax> Ah, yeah.  I can confirm flippers aren't working quite right (it looks like collisions with either endpoint are correct, but not with the flat part)
<Amthrax> Alright, I moved the gizmos into gizmoball.gizmos.standard.
<Amthrax> It's a trivial but awe-inspiring checkin.
<Amthrax> I recommend doing an ant clean after checking it out
<Amthrax> (Mind you, this was after at least two hours of heated battle with Eclipse and its refactor utility [I don't know how you do it Albert -- you must have much more stamina than I do])
<Amthrax> BTW, I just added a doc/issues.txt file with general issues that need to be addressed
<Amthrax> Oh, Albert, could you get the FDD to Dan or I at some point?  You can slip it under my door if that's convenient
<Amthrax> Alright, enough rambling to myself...  I'm going to bed
<aleung> i'll drop you the fdd in about 30 mins
<aleung> looking at the timestamps, i'm hoping you're not still up
<aleung> if you wanna see an implementation of an abstract action system, check out 54 from the fall
<aleung> they also seem to have network play
<aleung> fdd delivered, collisions with welcome mat tested
*** You have new email.
*** You have new email.
<Amthrax> Thanks
<Amthrax> Holy..  It just dawned on my how much she doesn't understand our collision approach.  "So you assume that only a ball moves?  What if the amendment was to make any gizmo mobile?"
*** You have new email.
> Wait, she thought we made that assumption?
> (She thought we made assumptions?)
* dan pounds his head against the desk.
<Amthrax> Yeah, isn't it great?  I'm wondering if we should email her and directly ask how we can express the fact that our collision system is totally general since we apparently failed to get this across.
<Amthrax> On an almost unrelated note, would it be much trouble to add line segments to the Blobs?
<Amthrax> "Let me know .. if it actually works for you"  That fills me with so much confidence
> I suppose there's no reason not to have segments in blobs. We already have points, after all (as zero-radius circles)
> (Could I implement line segments as zero-width rectangular polygons or something similar?)
> And I agree, we do need to do something to drive home the point that our collision system is absolutely general.
<Amthrax> Um, I suppose there's nothing wrong with zero-width rectangular polygons from an algorithmis standpoint (thought it might be unnecessarily slow).  Mostly I want them so dynamic blobs are more directly implementable.
* dan checks the '6.033 dp2' checkbox with great fanfare.
> I turned the design project into something I'm almost not ashamed to turn in with my name on!
> (Though that may be because my standards fell as I grew more sleep-deprived)
<Amthrax> Heh heh
> I'm not sure how serious I was about the zero-width polygons. It was mostly a joke, though I guess it would make implementation easier.
> (In any case, I'll put in an addSegment method)
<Amthrax> Okay
> But first I need to take a nap, and flush my mind of Mars rovers. Then I'll implement blobs. Hopefully they'll be implemented and tested tonight.
<Amthrax> Cool.  G'nap
<aleung> yeah, i think looking at the comments, she must've missed a thing or two about the collision system
<aleung> and she seems to bring it up everywhere
<aleung> she also seemed to be against our individual drawers, but i suppose it was badly expressed (sounded as though each gizmo class needed a drawer)
<aleung> btw, we could probably optimize the drawing using blobs (check blob intersections with dirty rects and only redraw gizmos that have some overlap)
*** You have new email.
<aleung> damn, this wireless mouse sucked up a pair of 2250mAh AA's in a day
*** You have new email.
<Amthrax> Actually, I was thinking that a lot of the drawers could be collapsed using blobs (kind of like the polygonal gizmo drawer now, but draw any blob -- which would cover most of the standard gizmos).
<Amthrax> The problem with using dirty rectangles for that is that you need to know which rectangles are dirty, and there's currently no way of reporting that.
<aleung> if we tracked last positions, we could do a bounding rectangle of anything that changed positions and mark that as dirty
<aleung> (positions and rotations, i guess)
<aleung> and the only problem with collapsing the drawers is if we want to customize gizmo looks, we'd probably have to do it on a per gizmo basis
<aleung> i guess we can dispatch within the standard gizmo drawer, kinda like the hack now for the absorber
<aleung> but anyway, we basically only have 3 drawers for the standard gizmos now
<aleung> poly, circle, and flipper
<aleung> plus the ball, cause of the origin specification
<aleung> ah, i just turned antialiasing on
<aleung> maybe mac has it on by default
<aleung> everything looks much more pleasant
<Amthrax> Oooh, I didn't know you could tell it to do that
<Amthrax> Have you tried selected non-default L&F?
<Amthrax> Dan's laptop wasn't antialiasing (we determined this), but its circles were much rounder.
<aleung> are you sure his vm wasn't doing it by default?
<aleung> apparently, you can set it, and the default is different per platform
<Amthrax> I'm pretty certain.  We zoomed in on it to be sure
<Amthrax> Who's around?
*** You have new email.
<aleung> eh, i'm here
<aleung> your email looks ok
<aleung> although i really doubt it'll clear things up with her
<Amthrax> I still don't understand how she can so thoroughly misunderstand our system
<Amthrax> Maybe she's just too stuck on her idea of a generalized physics thing to understand that it's equivalent
<Amthrax> Admittedly, that would package things a bit better, I think, but it would also highlight the weakness of the physics system they gave us
<aleung> i've never really looked in detail at it
<aleung> what do they provide?
<Amthrax> Exactly what you need.. and nothing else.
<Amthrax> The physics library is in no way general.
<Amthrax> ie, it has specified methods for ball-ball collisions, and others for ball-wall collsions, and even others for ball-rotating wall collisions.
<aleung> oh, can you quickly do the polygizmo?
<aleung> i'll try to set up the building framework for that soon
<Amthrax> I can spec it quickly
<Amthrax> It'll be the same as AGWPG, but with an added GizmoVertex collection property
<Amthrax> Do you have the frobber menu done?
*** You have new email.
*** You have new email.
<Amthrax> Because I'd recommend getting the frobber menu done before implementing poly editing (since that's not required)
<Amthrax> Dan, can you add getters to the Blob?
<Amthrax> I go ahead and code to Set<Vect[]> getPolygons(), Set<Circle> getCircles(), and Set<LineSegment> getLineSegments()
<Amthrax> (Speaking of which, why don't you use addCircle(Circle)?)
<Amthrax> Also, I assume we assume blobs are relative to the gizmo origin?
> *pong*
<Amthrax> He lives!
> Yeah. I told myself I was going to take a nice short nap.
> That worked pretty well, except for the short part.
> Sure, we can have blob getters. I conveniently left them out before since we didn't need them, but it's no trouble to put them in.
> I was originally thinking of blobs as having absolute position. But that's not so useful for us, is it?
<Amthrax> It's hard to say
<Amthrax> And it'll greatly affect the semantics of intersect
> Right.
<Amthrax> I personally think blobs should be as static as possible
> And we'd probably also want the origin-position to be mutable.
<Amthrax> Yeah
> (Which screws with the semi-mutability of blobs)
<Amthrax> *nods*  I think the absolute position of the blob should be blob+getPosition
> Where getPosition is AGizmo.getPosition?
<Amthrax> Plus, I've been thinking of blobs more as the "geometry" of a gizmo
<Amthrax> Yes
> I've been thinking of them as abstract geometric objects that just happen to be useful to us.
<Amthrax> Heh, yes
<Amthrax> Oh, speaking of which, do you want to see the FDD?
> Sure, I guess I ought to take a look at it.
<Amthrax> Gah.  I hate flippers...
<Amthrax> Why did we say things could not snap to grid and have arbitrary orientations?
> Ugh. Reading the FDD comments has managed to totally un-enlighten me.
> I disagree (almost) entirely with everything she's said.
> I'm amazed that she managed to misinterpret our collision system so thoroughly.
<Amthrax> Yeah
<Amthrax> I'm hoping the email I sent will help, at least a little bit
> Yeah, I just reread that too (it makes a lot more sense having seen the FDD comments)
> Inasmuch as 'sense' is a term that can be applied in this case.
> I'm also proud of myself for managing to include a reference to Section 2.5.3 in the middle of Section 2.5.3. That's the kind of thing I would do just to be obtuse, but I didn't plan it in this case.
<Amthrax> Oh wow...  I'd missed that too
> I assume it was a last-minute resectioning issue or something like that.
> Your tact is impressive.
<Amthrax> Heh, thanks.  It took a lot of work to distill my wish to rant into that
> Yeah. There's a lot to rant about.
> Ooh! My battery will ship today!
> (I was actually in the process of composing a rant about that.)
<Amthrax> Congratulations
<Amthrax> Before we get too deep into this, are we shooting ourselves in our collective foot by allowing non-grid-snapped gizmos and arbitrary orientations?
> Do non-grid-snapped gizmos really make things harder? I could see arbitrary orientations being a problem.
<Amthrax> Well, afterall, without those two properties, the blob system becomes completely unneccessary
> Oh. Then we could just define editor collisions in terms of grid squares. Hmm.
<Amthrax> And we can just return bounding boxes and be happy like the rest of the groups
<Amthrax> (Speaking of which, have you looked at projects from previous terms?)
> Nope
> Did they actually post a working link somewhere?
<Amthrax> Yep (finally)
<Amthrax> Last terms' are up
<Amthrax> It looks like Fall '02 is up, too
> hmm. Looks like there's some interesting stuff there.
<Amthrax> Yeah.  I wish that'd been there before so we could have sto.. gotten ideas
<Amthrax> I'm trying to figure out what the hell was up last term with all of the bizarre custom LaF
> hmm. So do we want to disable disabling snapping to the grid?
> It seems that arbitrary positions are a good thing to have. But I guess it does make things a lot harder...
> What about just leaving out arbitrary orientations? Would that make things any easier?
<Amthrax> It would certainly make things easier, though I'll have to ponder for a moment to figure out how much easier
<Amthrax> If we disabled arbitrary orientations, would it make it possible to use regular bounding boxes?
<Amthrax> Oh, and there are still poly gizmos to consider (Was that what prompted up to do this whole blob thing in the first place?)
> Well, we still have round things like balls and circle bumpers too... we could bounding-box them, but obviously that gives us some limited flexibility.
<Amthrax> That's true, but at least with those we'd only lose (1-\frac{\pi}{4}) of the area to the bounding box ]:--8)
> Yeah, and we're not trying to close-pack gizmos here. ;)
<Amthrax> The other advantage of non-arbitrary orientation is that it lets us expand into pixmaps for gizmo prettification
<Amthrax> That's also true
> How do we handle non-arbitrary orientation in the editor? (Do we?)
<Amthrax> Uh, come to think of it, probably the way we are anyways, since I don't think we've discussed arbitrary orientation with Albert.  Click the rotate frobber to rotate by 90 degrees?
> (I actually meant to type 'arbitrary orientation', but that answer still works)
<Amthrax> Oh, yes
<Amthrax> So...  What is the fate of blobs?
<Amthrax> I'd like to use at least a bit of the blob code to write AbstractFixedGizmo
<Amthrax> What about the polygizmos?
> What about them?
<Amthrax> Should we just ignore the bounding problem with them and let them float etherially on the board?
> Hell, why can't we just let everything float on the board? Do we even need to consider editor collisions?
<Amthrax> That thought has crossed my mind, but they technically do specify that there should be editor collisions
> Oh. But it's empowering the user? If they want to have two bumpers overlapping, who are we to stop them?
<Amthrax> Yeah, I know...
> Well, if they say we have to, even if it doesn't make sense, I guess we do
<Amthrax> And, really, it's not a problem now except for poly gizmos, which I think we can ignore (EtherealPolyGizmo?)
> Our simulator can, after all, deal with balls inside PolyGizmos.
<Amthrax> That's true
> Why don't we just specify that a PolyGizmo is just the outline of a polygon and stuff can be placed inside it? That might even be useful.
* Amthrax nods
<Amthrax> Of course, weird things happen if you place things on the.. edges
<Amthrax> But we'll ignore that, too.  In the name of user empowerment!
> Sounds good to me.
<Amthrax> So, does that leave you working on the property table now?
<Amthrax> (If so, mind if I sketch out some things I was thinking for that?)
> I guess, unless there's something we want me to do with bounding boxes.
> (SquareBlobs!)
<Amthrax> Uh, I guess just add the Right Method to AbstractGizmo
<Amthrax> Be sure it can return null or something for gizmos that we don't want to have to deal with  ]:--8)
> getBoundingBox()? How should it be specified? Make it abstract for the gizmos to override? In the constructor to AGizmo? a setBoundingBox?
<Amthrax> Hmm.  I think abstract getBoundingBox is probably best
<Amthrax> 'Cause otherwise you'll need both a get and a set method
> Yeah, that's what I was thinking. Since it depends on position, in non-obvious ways thanks to their weird positioning specs.
<Amthrax> Yeah
<Amthrax> Speaking of which, what should it be relative to?
> Should it be relative?
<Amthrax> Hmm.  I suppose none of our other getters are...
<Amthrax> Which is actually probably bad, but eh
<Amthrax> Then again..
> It might make things weird in Albert's code. I dunno how he deals with placing the gizmo. Is the new gizmo actually a gizmo?
<Amthrax> IIRC
<aleung> have we ditched blobs?
<aleung> or ditched non-arbitrary transformations?
<aleung> regardless, we need to handle gizmo selection mouse clicks
<aleung> which, i guess bounding box is sufficient
> Yeah. Except with polygons, since they wouldn't have bounding boxes.
<aleung> so no editor collisions?
> No, we still have editor collisions represented by bounding boxes, just not for PolyGizmos.
<aleung> ah, ok
*** Mode change "-A" for user dan by dan
*** Your user mode is "+oiwsgnh"
<aleung> how are polygizmos handled?
*** Mode change "+aA" for user dan by dan
> For editor collisions? They're not.
<aleung> ok
<aleung> any other significant changes?
> For clicking? By a special case?
<aleung> i guess at the very least, i can restrict point definition during polygizmo building to remain outside of other gizmos
<aleung> since we have to handle clicking anyway
> An abstract testIntersectionWithPoint?
> Austin really hates flippers.
<aleung> i would imagine
> Or we could just completely ignore PolyGizmos in the editor, since they're not required, and deal with them when we have time?
<aleung> sure, that works
<aleung> will you be doing the property table?
> Yeah, Austin and I were just talking about it.
<aleung> i was thinking more of an editable tree
> That's good, so were we.
<aleung> eh, reading the stuff for it, it's somewhat ugly?
<aleung> anyway, i guess i'll do frobbers for now
> Yes. Do frobbers. Frobbers are good.
> Austin and I are in agreement on that.
*** You have new email.
<aleung> as usual, i will be gone tomorrow
<aleung> i will be leaving tonight, returning tomorrow night
<aleung> if i don't have frobbers by then, i should be close
> Sounds good. I'm looking into how to do the property table.
*** You have new email.
<aleung> from what i read of it, you could make treecelleditors
<aleung> for each of the various value types
<aleung> there was the issue of distinguishing between a position property, which you would want to edit as x,y and velocity which you would want to edit as mag angle
<aleung> (well, prefer to edit as mag angle)
<Amthrax> Yeah, we were looking at the tutorial on how to create editable tree tables last night
<aleung> cool
<aleung> it didn't seem to cover much actually
<Amthrax> Hmm, good point.  I guess the only way to distinguish those is by the name of the property (kind of ugly, but..)
<aleung> there was that thing about making treetables
<aleung> ah, another issue
<aleung> so the collection of gizmos is a property of the gameboard
<aleung> making that do add or remove might be tricky
<aleung> and if you want propertyifieds in those collections to expand to show their properties
<aleung> that'd be tricky too
<aleung> actually, maybe not so much with gizmos
<aleung> you could just make it select the gizmo and then use the tree from the gizmo
<Amthrax> I'm not sure if we should display the gizmos of the board that way
<Amthrax> Just because it might prove confusing to the user
<aleung> hmm
<aleung> it'd give you a nice heirarchy
<aleung> but i suppose it would be confusing
* Amthrax nods
<aleung> still, doing add/remove of nodes
<aleung> that might be tricky
<Amthrax> BRB
<aleung> btw, do you know if loading in pngs maintains the alpha data?
<Amthrax> Um, if it can load png's, I suspect it will
<aleung> ok
<aleung> maybe we can still do prettification like that
<aleung> eh, i'd still like to optimize the drawer
<Amthrax> I don't think it really needs optimization.  Is it running slowly?
<aleung> not at current scales of things
<Amthrax> Oh
<Amthrax> Have you disabled the gameboard checkrep?
<aleung> ah, maybe that's it
<aleung> but it is obviously inefficient
<aleung> if you placed hundreds of perfectly overlapping gizmos
<aleung> it'd redraw that same spot hundreds of times
<aleung> we can definitely store the drawn unmoving gameboard and then only draw the moving parts
<aleung> anyway, i guess for now it's alright
<aleung> i'm leaving soon
<aleung> if anything comes up, you can call my cell
<aleung> btw, reading her replies to your questions
<aleung> i think she's still missing it
<Amthrax> *nods*  I considered the static store a while ago, but I'm not sure how you'd implement it (ie, currently there's no general way to find out if a gizmo has moved or not)
<Amthrax> I agree, though I don't think she's completely missing it
<aleung> yeah, i don't think so either
<aleung> i guess we can optimize in the end
<aleung> if it's even necessary
<aleung> performance with lots of balls seemed a bit sluggish
<aleung> more than expected
<Amthrax> That doesn't really surprise me, since then the collision system has to do O(n^2) tests.
<aleung> ok
<aleung> i figured it was collision side
<aleung> did you see the snow one from the fall?
<aleung> that ran surprisingly smooth
<aleung> how are flippers, btw?
<Amthrax> Yeah, that was cool
<Amthrax> It might also be that drawing circles takes a long time (since they would have had hardware acceleration for that)
<Amthrax> I'm still reworking the collision system
<Amthrax> Though I'm getting tired of doing that, so I think I might rerework it to be simpler
<aleung> hmm
<aleung> for kicks, i'll make balls rects
<Amthrax> Eh?
<aleung> you said circle drawing is slow?
<Amthrax> Oh
<aleung> eh, it's the collisions
<aleung> i don't think people would be able to tell that these squares were colliding as circles do
<Amthrax> That's true
<aleung> hah, moving squares are an exciting change after watching balls so long
<aleung> how sad
<aleung> i tried the placing many overlapping circle bumpers, there seems to be no to little deterioration in performance
<aleung> i also tried placing non overlapping ones with the same result
<aleung> i think this is only amusing cause squares are more often symbols of something in the computer world
<Amthrax> Hmm, yeah.  The overlappingness of those shouldn't matter at all, though
<aleung> yeah, it shouldn't, but just checking if there's some implicit optimization
<aleung> though i can't imagine how there would be
<aleung> ah, we could do a simulated world, birds eye view
<aleung> with flippers as doors and balls as people
<aleung> we could make the sims
<aleung> how scary...
* Amthrax twitches
<aleung> it might be award worthy or at least amusing
<Amthrax> If we have time/stamina/willpower, I think we should make tetris
<aleung> eh, definitely
<aleung> we don't even need amazing collisions stuff
<aleung> each falling piece just triggers the random piece generator
<aleung> to release the next one
<aleung> and triggers the piece heap thing
<aleung> to merge it
<Amthrax> *nods*
<aleung> the only thing we're missing is probably the trigger system
<aleung> alright
<aleung> quick overview of what we have to do:
<aleung> saving, frobbers, gizmo selection, property tree
<Amthrax> And some tweaks of the gizmos
<Amthrax> Gizmo draggin/moving?
<aleung> things we can do: prettify gizmos, polygizmo editor support, enhanced editor support, prettify stuff, generalize collisions even more(?)
<aleung> abstract actions
<Amthrax> Collisions are already totally general
<aleung> yeah, i know
<Amthrax> Though I think the way we do it should be changed to be more explicit (see the issues.txt)
<aleung> but people (person) are lobbying for more general
<aleung> if i have time, i will do an mdd/object model builder in the editor
<Amthrax> We can't make something that's already totally general more general!  Person must be smacked into understanding this...
<aleung> and maybe antichess
<aleung> in the editor
<Amthrax> Heh heh
<aleung> supporting mouse clicks in play mode would suck
<aleung> how about gizmo properties for visibility and tangibility?
<Amthrax> Hmm.  That might be interesting, though I don't see how it would be useful
<aleung> eh, you could make gizmos disappear, in the physical and visual senses
<aleung> and if we abstract the triggering to support arbitrary property setting
<aleung> people might want that
<aleung> those properties
<aleung> also, color...
<aleung> ugh, the green is bugging me
<aleung> all the std colors are supersaturated
<Amthrax> Heh, yes.  I think the default colors should be changed.  ]:--8)
<aleung> well, it'd be nice to be able to set them
<aleung> through the editor and what not
<Amthrax> That's true
<aleung> and we can definitely prettify gizmos without using pixmaps
<aleung> that would be a start
<Amthrax> Yes
<aleung> just gradienting them or whatever
<Amthrax> (BRB.  I'm getting hungry and my student is nowhere to be found)
<aleung> hah
<aleung> it's a nice day
<aleung> if i were your student, i wouldn't be there either
<aleung> ah, i guess we could have a style property too
<aleung> that supports setting the look on a per gizmo basis
<aleung> and out of undecidedness/the desire to steal and outdo past terms, support all the looks they had: metal, shaded, etc.
<aleung> anyway, i gotta catch a bus
<aleung> i'll see you guys tomorrow night/sunday morning
<aleung> btw, out of curiosity, have you heard of sam gentile?
<Amthrax> Yeah, if I were my student and I was going to be here, I wouldn't have said "See you at 4:30" earlier today
<Amthrax> Hmm, and have a propertyified style class that captures all of the style settings for a gizmo?  That could be cool
<Amthrax> Nope
<Amthrax> Happy bussing
> I'm not your student, but today I said 'it's a nice day, I don't feel like going to class'.
> Of course, instead I spent three hours at the pistol range.
<Amthrax> Of course
> hey, I figured I'd better make the most of my $10 ammo fee.
<Amthrax> Ah
<Amthrax> I _should_ have said "It's a nice day, I don't feel like going to the 004 lab today"
> So I went through two 100-round boxes, and started on a third. It was a very productive day.
> Or destructive.
<Amthrax> Were you picturing Gizmoball on the target the whole time?
> I was thinking we should take our FDD to the range sometime.
<Amthrax> And my student finally appears!
<Amthrax> Be back later
> (c-entry.)Albert and I were talking about taking the 6.111 lab report to the range and shooting it. But we think it would survive.
> Happy student-tormenting.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
> I ci'd the extensions to AGizmo to support bounding boxes.
> I put in a default implementation that just returns null (no bounding box) instead of making it abstract so it wouldn't break things until the gizmos support it. We may want to change that later.
<Amthrax> Okay
> I'm propertyifing GameBoard now.
> One snag I hit was that for the collection property representing the gizmo list, the getter is getGizmos() and the mutators are addGizmo() and removeGizmo()
> I'm pondering the implications of making the properties system automatically add the 's' to the getter name. I'm not thrilled with that idea.
*** Amthrax_ (amthrax@AWAKENING.MIT.EDU) has joined channel #6.170
*** Signoff: Amthrax (Read error: Connection reset by peer)
*** Amthrax_ is now known as Amthrax
*** dan is dan@clamshell.ambulatoryclam.net (Dan Ports)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** dan is an IRC Operator - Server Administrator
*** dan has been idle 17 minutes, signed on at Thu Apr 15 03:43:10 2004
*** dan : End of /WHOIS list.
> I'm propertyifing GameBoard now.
> One snag I hit was that for the collection property representing the gizmo list, the getter is getGizmos() and the mutators are addGizmo() and removeGizmo()
> I'm pondering the implications of making the properties system automatically add the 's' to the getter name. I'm not thrilled with that idea.
<Amthrax> I've put some thought into that, too
<Amthrax> I'm going to add a second argument to addCollectionProperty that takes the plural
<Amthrax> (I was originally going to add an "s", then I realized that English pluralization rules are quite that simple
<Amthrax> )
> I had essentially the same realization.
> Want me to take care of it?
> (I did, in fact, implement the 's' rule before realizing that things weren't always so simple)
<Amthrax> Heh.  Sure, if you want.
> Oh, I decided to just make Vect a property-table primitive instead of propertyifying it.
> Otherwise its immutability would have broken things
<Amthrax> Ah, true
> ci'd the pluralified collection properties and (partially) propertyified GameBoard
<Amthrax> Cool.  Does it have friction/gravity?
> Not yet, just gizmos right now.
<Amthrax> Okay
<Amthrax> Did we ever come to a conclusion on coordinate systems for gizmo get methods?
> Which get methods?
<Amthrax> For getting geometry-related stuff
<Amthrax> ie, gizmo-relative or board-relative
> I don't think we did.
<Amthrax> Alright.  I'll just go with board-relative because that seems to be more useful
> I think so too.
> oh, I defined the bounding box by its upper-left corner and width/height. I figured that would be the easiest way to do it, but feel free to change it if you disagree.
<Amthrax> Okay
> bah. I wish c-electric-brace would behave.
<Amthrax> That would be nice
<Amthrax> Oh, if I write the CollisionManager, would you mind shifting GameBoard to using it?
> Sure, I guess. Uh, what does the CollisionManager do?
<Amthrax> Basically maintains the list of CollisionHandlers
<Amthrax> It's the generic programming with statically registered interaction handlers thing we were talking about a while ago
> Right, I figured that much.
<Amthrax> Uh, so, I suppose you'd be able to give it two gizmos and it would give you back the appropriate CollisionHandler
<Amthrax> (or null if they don't collide)
> Sounds good to me.
<Amthrax> I intend to finish shifting over to the abstracted physics thing tonight, and I'll hopefully have time to write that too (I'll at least spec it)
> OK. Are there any other required features that you need to work on before the release?
<Amthrax> The saver
<Amthrax> Oh, and the multi-ball absorber
<Amthrax> But I'd rather write the multi-ball absorber on top of the new collision system instead of moving it over later
> If you're sure you'll have time...
<Amthrax> Er, and polygizmos.  But that's almost automatic with the new abstract physics gizmo
<Amthrax> Well, I'll see how I'm doing after tonight
> ok
> My hanging braces behave!
<Amthrax> Ooooh
> That was *far* harder than it should have been.
<Amthrax> How'd you fix it?
> (setq c-hanging-braces-alist '((defun-open after) (inline-open after)))
<Amthrax> Oooh
> I think the inline-open is the only one I needed. But I also think I tried that before too. *shrug*
<Amthrax> Gimzo!
> GimzoAll!
> Need to get something to eat, AFK for a bit.
<Amthrax>         return Geometry.rotateAround
<Amthrax>             (Geometry.rotateAround(vect, center, orientation),
<Amthrax>              rotationPivot, rotationAngle).plus(getPosition());
<Amthrax> Gah.  I knew there was something amiss with c-hanging-braces-alist.  It leaves out all of the rest of the hanging braces.
<Amthrax> Do we actually use the last position anywhere?
<Amthrax> AFG tested and ci'd.  AGWPG is still there for now for backwards compatibility.
<aleung> ah, i've returned, btw
<aleung> seems like you guys have had a fairly productive session
<Amthrax> Ah, cool.  Welcome back
<Amthrax> Would you mind merging R2PolygonDrawer and R2CircleDrawer?
<Amthrax> I was about to do so, but you actually know what's going on in them
<aleung> how would i distinguish between polys and circles/
<Amthrax> Take a look at AbstractFixedGizmo
<aleung> cool
<aleung> i guess i'll look through all the changes as well
<Amthrax> Basically, I'm phasing out AGWPG for AFG because AFG is a generalized AGWPG (AGWPACG?)
<aleung> AGWPOCG?
<Amthrax> and circular.  The geoemtry is a union of polys, circles, and line segments
<Amthrax> It's also half-way between the broken generalized physics thing Magdalena wanted us to do and our system
<aleung> ah, ok
<aleung> yeah, it seems so
<Amthrax> (ie, it provides the physics magics for them)
<aleung> how's the tree going?
<Amthrax> I haven't heard from Dan for a while
<aleung> alright
<Amthrax> I should probably go check if he's dead...
<Amthrax> Anyways, I'm working on moving the AGWPG gizmos, the CircleBumperGizmo, and the FlipperGizmo over to AFG (though you'll probably still want a special drawer for the flippers)
<Amthrax> This should also fix the flipper brokenness
<aleung> alright, great
<aleung> we might not actually need a special drawer for flippers, but i guess we'll see
<aleung> alright, i might not work till the morning
<aleung> i'm gonna have some food
<aleung> brb
* dan is not dead.
<Amthrax> If possible, it would be nice to have the R2FixedDrawer soon, since I'm going to be breaking R2 pretty badly.  Unless I'm mistaken, it should be a fairly easy merge of the poly drawer and the circle drawer.
<aleung> sure thing, i'll go through the spec and do it now
<Amthrax> Cool, thanks
<Amthrax> For the time being, it's probably best to leave in AGWPG so we can smoothly transition
<aleung> i did some r2 refactoring that i don't think i ci'd
<aleung> what's the link to the spec again?
<Amthrax> http://awakening.mit.edu/~amthrax/gizmoball/
<Amthrax> I'll update that now...
<aleung> alright
<aleung> it was giving me a 403 for a sec
<Amthrax> Should be up now
> Speaking of refactoring, I feel the urge to refactor GameBoard since it's getting so unwieldy. But I can't think of any really good way to do it.
<Amthrax> The CollisionManager should help at least a bit, right?
> A bit, but probably not much.
<Amthrax> Maybe some way to pull out the triggers stuff?
> It's tempting to try to pull the simulator out, but the two classes would wind up being pretty tightly coupled anyway.
<aleung> ah, you pulled all the concrete gizmos?
<Amthrax> WDYM?
> They got refactored into gizmoball.gizmos.standard
<aleung> oh
<Amthrax> Oh, yes.
<aleung> that makes sense
<aleung> ah, didn't notice that one
<aleung> for a sec, i thought you were reworking so much stuff you just killed it all
<Amthrax> (After a two hour battle-to-the-death with Eclipse's refactoring tool)
> (Not to be confused with the non-standard standard gizmos, of course)
<aleung> are we doing the general triggered action system?
<Amthrax> Not yet?
<aleung> ok
> I may work on that after the property table.
<aleung> eh, it seems the refactoring/moving isn't so smart after all
<aleung> so square, triangle, circle, outerwall, absorber are all AFGs?
<Amthrax> Yes
<Amthrax> And flipper
<Amthrax> And poly
<aleung> ok
<aleung> you haven't extended them yet, though?
<Amthrax> Square, triangle, and circle are done.  Flippers are almost done.
<Amthrax> (Though none are ci'd)
<aleung> alright
<Amthrax> Wow.  Flippers were altogether too easy to write with AFG's
<aleung> nice
<aleung> i just merged circle and poly drawers
<Amthrax> Cool.  Tell me when it's ci'd and I'll test it
<aleung> alright
<aleung> damn, i'm getting cvs conflicts cause i moved stuff
<aleung> ci'd
<aleung> looks like everything's in order
<aleung> i don't know if the factory is handling outerwalls or absorbers right
<aleung> and the drawer definitely doesn't dispatch on them to make them non-solid
<aleung> if you just uncomment that part in the drawer, it should work fine
<aleung> if you get through all the gizmo stuff before i go, i'll make sure the drawers work so you can watch it simulate if you need
<Amthrax> Woah.  Oodles o' ci's
<aleung> nothing exciting
<Amthrax> 'Kay.  New gizmos ci'd
<Amthrax> BTW, in a sec the outer walls gizmo will just be line segments, so you shouldn't have to worry about filling it
<Amthrax> Er, not filling it, that is
<aleung> ah, but then i have to worry about line segments
<Amthrax> You'll have to worry about those anyways, since they're part of the AFG geometry
<aleung> true
<aleung> alright, it's a good fix
<Amthrax> OWG with line segments ci'd
<aleung> tested
<aleung> everything looks good
<aleung> the absorbers aren't line segd yet, i guess
<aleung> but flipper collisions seem to work
<aleung> i'm getting a weird checkrep fail on the gameboard though
<Amthrax> The absorbers are still polygons.  I'm pondering exactly what to do with those (more generally, I'm doing the multi-ball absorber now)
<Amthrax> Cool
<Amthrax> Dan?
<aleung> it's probably the paint function calling the accessor in between ticks?
* Amthrax pokes Dan
<aleung> that doesn't seem likely, since the repaint and ticking are synched
<Amthrax> Yeah...
<aleung> but it is the event.type != end of tick assertion
<Amthrax> Looks like he passed out again.  I'll let him rest for a while
<Amthrax> I think he was having weird issues with that before, too.
<Amthrax> I'm not convinced that's a oorrect assertion
<aleung> yeah
<aleung> ci'd the updated drawer stuff
<Amthrax> Cool
<aleung> AFG is nice ^_^
<Amthrax> Heh, yeah.  I hate to admit it, but Magdalena was on to something with that.  Of course, she was on to the wrong something, but that's another matter...
<Amthrax> Ooh, antialiasing!  (Sorry, this is the first time I've seen it aa'd)
<aleung> lol
<aleung> non-pixmapped things have one slight advantage
<Amthrax> Hmm, that checkRep failure is rather annoying...  Maybe I should go wake him up
<aleung> i can do non-bounding box gizmo selection things pretty easily
<aleung> and it looks decent
<Amthrax> Ah, true.  I noticed you were doing some magic with that in your drawers
<aleung> it's just stroking twice more in varying thicknesses
<Amthrax> Hmm.  How does one select in the editor?
<aleung> oh, one doesn't yet
<aleung> if we have the (new) blob stuff ready, i'll implement that first thing tomorrow
<Amthrax> Okay.  Want me to go ahead and add the bounding boxes now?
<aleung> sure
<aleung> hah, editing is nice
<aleung> it allows me to transform the some bumpers testfile into something interesting
<Amthrax> Heh heh
<aleung> rather than just watching the ball go up and down
<aleung> i haven't gotten the assertion fail for this board yet
<aleung> hmm, it seemed to die when i tried to smack the ball with the flippers
* Amthrax nods
<Amthrax> I have no idea what that has to do with Dan's assertion.  Hopefully he'll have a better idea
<aleung> is there gameboard side support for flipper collisions?
<Amthrax> Nope
<aleung> hah, i forgot to remove the test tree i added from the property part of the ui
<Amthrax> BTW, I updated the issues file today
<aleung> is that in the docs?
<Amthrax> Yep
<aleung> which file?
<Amthrax> doc/issues.txt
<aleung> ah, yes, so clearly named
<Amthrax> Heh
<aleung> about the load save thing
<aleung> since the interaction mode calls the xml parts
<aleung> it catches the exception there
<aleung> i guess i can have it rethrow and have the ui catch it
<aleung> and then report the text
<Amthrax> Yeah, that's probably best
<aleung> alright
<Amthrax> Alternatively, you could have the interaction mode report it, but that's probably suboptimal
<aleung> i haven't really used the status bar since the ui's been working
<aleung> i guess i'll rethrow and recatch it
<Amthrax> Oh, you mean display the error in the status bar?  Wouldn't it be better to display an error dialog?
<aleung> hmm, i guess that works too
<aleung> as a user, i tend not to like error dialogs, regardless of what they report
<Amthrax> I suppose, though people would probably be expecting an error dialog
<aleung> there's this forced choice of accepting the failure
<aleung> yeah, i suppose
<Amthrax> Heh, or we could use.. an error UI continuation!  (Sorry, obscure reference to CSAIL's Haystack project)
<aleung> i'll do it both ways, then
<Amthrax> Heh, so add a cancel button  ]:--8)
<aleung> ah, the orientation setting accounting for blobs isn't too hard
<Amthrax> I suppose, but that doesn't make blobs any less of a pain
<aleung> and i've already planned for orientation snapping
<Amthrax> Oh, speaking of which, how're the frobbers coming?
<aleung> i have the design in my head
<aleung> so implementation shouldn't be too bad
<aleung> the only annoying thing is accounting for display edges
<Amthrax> Heh, so make the window bigger  ]:--8)
<aleung> eh, i'll just make the frobber menu smart
<aleung> it'll have to be two tiered near corners though, which i guess isn't bad
<aleung> it's still more usable than the alternative
<Amthrax> Yeah
<aleung> looking at past years, i wonder why there were so many designs where you had to click a button in the top toolbar to do a rotate
<Amthrax> Out of curiousity, where are you drawing the gizmo palette?  I just noticed that they look like pixmaps, but you don't have any pixmaps...
<aleung> at the very least, why not a right click popup menu?
<aleung> oh, it's in the icon drawer
<Amthrax> Yeah, I wondered about that, too
<Amthrax> Too many people stuck in their old ways.  ]:--8)
<aleung> i suppose to be fair to mac people who have no right clicks
<aleung> but i always wondered about that
<aleung> and why mac people don't have multiple mouse buttons
<aleung> of all things to be non-conformist about...
<Amthrax> I still think that's one of the worst aspects of the Mac interface
<aleung> let's remove the right shift key while we're at it
<Amthrax> I wouldn't call it non-conformist...  just traditionalist
<Amthrax> Heh
<aleung> but about the icon drawer
<aleung> i was debating whether to pixmap the icons
<Amthrax> Hmm.  Would it be possible to use the gizmo drawers themselves to draw those?
<aleung> yeah, i was debating that too
<aleung> the debate is in the spec for the icon drawer, i think
<aleung> or at least in the comments
<aleung> i think i'll just pixmap all the icons for the ui ultimately
<Amthrax> Is that easier than using the gizmo drawers?
<Amthrax> I also kind of like how past terms put text on the buttons to say what the gizmos were (instead of just circle, smaller circle, smaller circle with a box around it  ]:--8)
<aleung> the reasons against using the gizmo drawers themselves were 1- scaling, and 2- some gizmos don't look like what they are
<Amthrax> Ah
<aleung> yeah, it was a temporary solution
<aleung> i guess part of the reason for having gizmo palette dependent on the drawer was so the gizmos in the palette look like they do in the drawer
<aleung> but at the same time, i don't know how much you really want the buttons changing between drawers
<aleung> well, i guess having an icon drawer still lets you match the icon look to the drawer
<aleung> anyway, ultimately it seems more a subjective choice than a matter of correctness
<aleung> so whatever you prefer
<Amthrax> Alright, one more random question: Would it be not-too-ugly to make the ball snap to the middle of a box, despite its origin?
<Amthrax> That's true.  I can certainly see what you mean about the size being an issue (though maybe all of the buttons should just be made two spaces high to fully correspond)
<Amthrax> I still think it would be best to use the gizmo drawers, since they'll look exactly the same
<aleung> yup
<aleung> well
<aleung> i had this notion that r2 drawers would still have flexibility, like color setting and things like that
<aleung> and that shading option for a prettier version
<aleung> so you still wouldn't get it looking exactly the same
<aleung> but sure, it's not a hard fix
<Amthrax> Hmm.  Well, since you still need to show something meaningful in the palette, it seems that it would make sense to choose reasonable values (ie, the defaults)
<aleung> yup
<Amthrax> Okay.  Well, only if you have time.  The frobbers are more important
<aleung> ah, we should probably have settable defaults
<aleung> snapping the ball, that's pretty ugly
<Amthrax> Mm, I disagree.  Defaults are defaults for a reason  ]:--8)
<Amthrax> Yeah, I know.  (I'm still trying to convince myself of what origin they're thinking of in the specs)
<aleung> yeah
<aleung> the options look like this:
<aleung> i can make the buildmode just not use snapped position when the ball is being placed
<Amthrax> Oh, that would be good, too
<aleung> i can write a separate snapmode that gets used when balls are being placed, but this means ball snapping can't be easily disabled
<aleung> i can have it automatically deactivate snapping when balls are being placed and set it back to the original value after?
<aleung> that way the default is free ball placement
<aleung> but if you wanted it to snap to the upper left corner, you still could
<Amthrax> Hmm
<Amthrax> They all sound good.  Whichever is easiest
<aleung> i think i'll go for the last
<aleung> maybe if there's time, i'll do customizable snapping
<aleung> wouldn't be too hard
<aleung> alright, here's my tasklist, ordered:
<aleung> gizmo selection, frobbers, the frobber actions, poly build support, prettifying things
<aleung> btw, i was wondering what the default poly icon would look like
<aleung> which was why i ended up having the icon drawer work the way it did
<Amthrax> Sounds good
<Amthrax> Ah, hmm.
<Amthrax> An amorphus blob!
<aleung> there didn't seem to be a reasonable default
<Amthrax> Speaking of which, I should probably go wake up Dan...
<aleung> eh, it's early
<aleung> i'm about to go
<Amthrax> Okay
<aleung> here's stuff i'm hoping gets done soon:
<Amthrax> Oh, editor collisions should slip in there too
<aleung> well, i guess the big thing is saving
<Amthrax> I'll have the bounding box stuff in soon
<aleung> ah, editor collisions, right
<aleung> that'll go with gizmo selection
<aleung> since the mechanism is pretty similar
<Amthrax> Yep, saving's on my list, too.  That shouldn't be too hard, though it'll take some time
<aleung> other things: moving polys!
<aleung> the advanced action sstem
<aleung> system
<aleung> (maybe not so soon)
<aleung> if you had controllable gizmos, i figured you could have the controlled velocity and add on to it velocity from forces, collisions, etc.
<Amthrax> Heh, that would be interesting
<Amthrax> (Though the physics library doesn't give us stuff for that.  Stupid physics library)
<aleung> you could make stupid walking gizmos
<aleung> or 
<aleung> a magic ball gizmo
<aleung> eh...
<aleung> ah, i had a list of potentially offensive demos we could build
<Amthrax> Heh, then GizmoAll could be Traffick, AntiChess, Flash, PowerPoint, Illustrator...
<aleung> most involve pixmapped gizmos
<Amthrax> Heh.  Bad Albert!
<aleung> like one where you try to hit a ball at a bolin gizmo with a flipper
<Amthrax> Heh heh, actually he'd probably appreciate that
<aleung> or one titled "but our collisions do work..." with a magda gizmo getting struck by balls
<Amthrax> LOL
<aleung> and various staff gizmos with descriptions "doesn't do much"
<Amthrax> Heh heh heh
<aleung> and we can easily implement the bouncing baby game, if you're familiar with it
<Amthrax> gizmoball.gizmos.staff?
<aleung> what could be better than having the 6.170 staff as gizmoball bumpers...
<aleung> i guess when i'm done with my tasklist, i can start with the gizmochess mode in the editor
<aleung> it seems trivial enough
<aleung> btw, when we prettify the ui, i should probably take a look at how things look on linux and mac
<Amthrax> That's true.
<aleung> but that'll all happen tomorrow
<Amthrax> They look pretty similar on Linux
<Amthrax> They look all round and watery on Mac
<aleung> i noticed the default fonts seem differently sized
<Amthrax> That's probably true
<aleung> oh, right, i have to make my mdd/om drawer
<Amthrax> X fonts suck, by tradition
<Amthrax> Heh
<aleung> i was trying to figure out how to do the multiplicity/static modifiers on the om arrows
<aleung> like what he best way of setting that stuff was interface wise
<aleung> i guess a frobber can toggle it
<aleung> anyway, i'll be back around 11
<Amthrax> Okay
<aleung> will you all still be around?
<Amthrax> Someone's waking me up around 1, so I'll be back then
<aleung> cool
<Amthrax> I hope to go to bed reasonably soon
<aleung> alright
<Amthrax> Just a few more things I want to take care of tonight
<aleung> by the time you come to, i might have a significant part of frobbers done
<Amthrax> Cool
<aleung> might do that first, if i can't figure out the selection side stuff
<Amthrax> I definitely have bounding boxed in by then
<aleung> alright
<aleung> looks good
<Amthrax> Does Swing have a togglable button?
<aleung> togglable?
<aleung> you can enable/disable buttons
<Amthrax> Yeah, so the currently-being-placed gizmo button can remain depressed (and then be undepressed to go into selection mode)
<aleung> ah, that works
<aleung> i considered having a mode indicator icon in the status bar
<Amthrax> I think it does...  though it might be a kinky form of a checkbox
<aleung> but i guess that wouldn't capture the current gizmo being built
<aleung> hmm, i'll look into that
<Amthrax> I think teams in previous terms have done that
<aleung> you do like the stamp format, where you can click repeated to place multiple gizmos of a type
<Amthrax> (the depressed button, that is)
<aleung> as opposed to the build and select format?
<Amthrax> Yeah, that's good, especially since some gizmos will probably be placed a lot (ie bumpers)
<aleung> yup, alright
<Amthrax> Though I still think a depressed button to indicate that would good, too (and consistent)
<aleung> ah, one past project had a draggable tiling build feature
<Amthrax> Plus it gives a fairly obvious way to switch back into selection mode
<aleung> oh, so unclicking the current build mode switches back to select?
<Amthrax> Yeah
<aleung> that works
<aleung> i'll have to look into whether it reports actions when the button is disabled
<Amthrax> I've seen a lot of programs use that approach.. therefore it must be good!
<aleung> yup
<aleung> we may still want modifier tools
<Amthrax> I don't know about disabled, but if you use whatever the toggle button is, it should
<aleung> only so you don't have to select individual gizmos to modify their properties
<Amthrax> Hmm
<Amthrax> Would they duplicate the functionality of the frobbers?  Because that would probably be suboptimal
<aleung> not exactly
<aleung> well, rather than having to click a gizmo, then click the rotate frobber
<aleung> you can go into a rotate mode that sets orientation of whatever you click
<aleung> and persists like build modes do
<Amthrax> Hmm, that would be interesting, though I think it should be low priority
<aleung> alright
<aleung> the one in particular i was thinking about was color setting
<aleung> since that probably won't make it as a frobber
<aleung> and going through the prop tree for that per gizmo would suck
<Amthrax> That's true
<aleung> so a paintbucket style tool
<aleung> that sets color of whatever you click
<aleung> and if you're gonna have that one, might as well get some others
<aleung> but this is low priority
<aleung> probably higher priority than antichess
<aleung> but what isn't
<Amthrax> Ooh, ooh, there's a JToggleButton
<Amthrax> How nice and unexpected of them to call it something reasonable...
<aleung> nice
<aleung> can it be added to toolbars?
<aleung> eh, i'll look at it
<Amthrax> Probably
<aleung> it's pretty sad that i can probably do the antichess final project in a couple hours tomorrow
<Amthrax> It's a subclass of AbstractButton
<Amthrax> Heh
<aleung> ah, but JToolBars don't take buttons
<Amthrax> Oh?
<aleung> they take actions, it seemed?
<Amthrax> " As of 1.3, this is no longer the preferred method for adding Actions to a container. Instead it is recommended to configure a control with an action using using setAction, and then add that control directly to the Container."
<aleung> ah, ok
<Amthrax> Probably for exactly that reason  ]:--8)
<aleung> hmm
<aleung> i figured they'd list the important methods
<aleung> in that case, a toolbar doesn't seem much different than a panel?
<Amthrax> Layout, maybe?
<aleung> eh, that doesn't strike me as particularly significant
<aleung> but i guess they've done some things
<aleung> like the dockability
<Amthrax> That's true
<aleung> do you like the idea of multiple internal gizmoball windows?
<Amthrax> For?
<aleung> so you could open several boards in the same interface
<aleung> it makes control ugly though
<aleung> but it's been done in the past
<Amthrax> Yeah.  That scared me
<aleung> i also considered having views
<aleung> like a xml view
<aleung> in some editable text component
<aleung> we could synchronize gizmoselection with selection of the xml code for that gizmo!
<aleung> probably overly complicated to do
<Amthrax> Gah
<aleung> alright, we'll stick to a simple interface...
<aleung> we're not building visual studio
<Amthrax> Sounds good to me  ]:--8)
<aleung> last i checked, the interface for that was terrible
<aleung> but i haven't checked in a while
<Amthrax> I kind of liked MSVS's interface, though it was quite cluttered
<Amthrax> Granted, that was before I discovered the magic of Emacs
<Amthrax> Now I consider practically any interface beyond a fullscreen text box excessive  ]:--8)
<aleung> yup, i know what you mean
<aleung> i guess the extras in eclipse aren't too intruding
<aleung> vs just felt particularly cluttered
<Amthrax> I disagree, but, then again, Eclipse leaves a bad taste in my mouth every time I use it
<aleung> hah, alright
<Amthrax> Anyways, I'm going to go poke Dan now
<aleung> cool
<aleung> i'll tag out for him
<aleung> and take his place being the dead member
<Amthrax> Alright.  G'night
<Amthrax> AFG's are kinda nice.  All AFG's just magically inhereted bounding boxes
<Amthrax> Hmm.  And I was about to make getBoundingBox abstract, but.. a lot of the test code includes gizmo subclasses
<Amthrax> Hmm.  The physics loop appears to go off the deep end if timeUntilCollisionWith returns 0, collide is called, and timeUntilCollisionWith still returns 0
<Amthrax> Granted, that may be correct, but it's probably not a good thing
> I guess I can put in a special case for that. Not that I'm entirely sure how to handle that case.
<Amthrax> One possibility is to ignore it
<Amthrax> (Because it'll probably go away after another tick)
<Amthrax> However, I don't think it's right to hard lock the game loop when it happens
> I don't think that's really the right thing to be doing either in most cases.
* dan is reading the log.
> (I'm going to stop passing out now, I think)
<Amthrax> Heh, okay
> (Why am I so tired today? Or do I even need to ask that question?)
<Amthrax> Yeah..  So the repeated 0 collision time doesn't make much sense from a physical standpoint, but it can otherwise (ie, I'm doing some things in the absorber that don't make physical sense, and they keep sending it off the deep end)
<Amthrax> It must have something to do with the warm weather.
> Yeah, I figured it was the absorber that was causing the weirdness.
> And about the Mac having only one mouse button... yeah, I hate that too.
> They even added control-click contextual menus a while ago... but nobody uses them, control-click is inconvenient to type.
> I'm going to pretend I didn't just say 'control-click is inconvenient to type'.
<Amthrax> Heh heh heh
<Amthrax> Oof, my head is starting to hurt.  I think I'm going to bed soon
* dan throws back his head with insane glee and cackles at the thought of 6.170 staff gizmos.
<Amthrax> Ah, it feels so much better to be able to type "from physics import *"
<Amthrax> (I'm testing something in the physics library with Jython)
> You had me thinking 'oh no, you didn't implement the standard gizmos in Python, did you?'
<Amthrax> Heh.  Surprise!
> Not that I'm opposed to it per se, I'd just rather not have to learn a new language in the three days before the deadline. Even if it is Python. ;)
* Amthrax grins
> I like the idea of renaming collisions as interactions.
<Amthrax> Oh, and it looks like the physics library always return 0 if two balls are going to collide with eachother and are overlapping, which is probably where most of these zeros are coming from
<Amthrax> Yeah, I think it would make it a lot clearer
<Amthrax> The ball thing actually turns out to be a problem for the absorber, since I was planning on letting the balls space themselves out for me
> How would that work?
<Amthrax> I tell the balls to roll towards the lower right corner of the absorber.
> Oh. That would be cool if it worked.
<Amthrax> It's mostly working
<Amthrax> If the physics loop didn't go haywire, I think it would even almost work
> Yeah, I'm working on how to fix that.
<Amthrax> F = m_1m_2G/r^2, right?
> Right
<Amthrax> Hmm.  Gravity's broken
> Wait, do we have universal gravitation now?
<Amthrax> Uh, not quite
<Amthrax> Though that _would_ be pretty easy to do
<Amthrax> I was using a gravitation model for the absorber (ie, put an invisible mass at the absorbent point)
<Amthrax> I wanted to avoid thinking about how to make it move towards it, but it looks like that's not going to work
> "GizmoAll is not just a pinball game but a physics simulator, useful in predicting the motion of celestial bodies..."
<Amthrax> Heh.  Should we make the ball mass a property, and if it's large enough, the gravitational effects become noticable?
<Amthrax> Make it even larger and it collapses into a singularity?
> What if the ball were sufficiently massive that it sucked the outer walls into the board and broke them?
<Amthrax> Oops
<Amthrax> DEBUG BallGizmo: Tick: new p=<19,19> new v=<2147483647,2147483647>
> While that's one of my favorite numbers, I hope that wasn't what you were going for.
<Amthrax> Not quite...
<Amthrax> And I think I found another way to send the simulator off the deep end
> Damnit, stop abusing my beloved simulator!
> JDE is so helpful! It just imported gizmoball.game.GameBoard.SimulatorEvent for me.
> This seems like a vaguely strange thing to do in gizmoball.game.GameBoard, however.
<Amthrax> Heh heh
<Amthrax> Alright, I'm really not lucid enough to deal with infinite right now (I thought I fixed it, but.. new v=<-2147483648,-2147483648>).
> I think that's a sign you should get some sleep.
> And it occurs to me that I've become a morning person. But for entirely unusual reasons.
> So if a collision pair gives time-to-collide=0 right after colliding, it'll get treated as though it actually returned MAX_TICK_TIME.
<Amthrax> *nods*  I was wondering a while ago whether I not I could be considered a morning person.
<Amthrax> Sounds good
<Amthrax> Of course, by BST, everybody's a morning person!
> (I was going to make it recalculate on the next tick, but that turns out to be just a little harder to do)
> That thought occurred to me too.
<Amthrax> Want me to check in the last semi-working absorber I had, just for kicks?
> Is that the one that grinds the simulator into the ground?
<Amthrax> Yeah
<Amthrax> But not with the INF's
> Yeah, that'd be great, I was about to ask if that was checked in
<Amthrax> It's in
> Cool.
> Have I mentioned how great it is to have a project team that is actually competent, and even goes far beyond that minimal standard?
> (Entirely unlike 6.033)
<Amthrax> Heh, speaking of which, how's that going (went?)
> One nice long all-nighter later, I wound up with something that I was not entirely ashamed to turn in with my name on.
> (Though I admit I wasn't totally pleased with it.)
<Amthrax> Ah, okay
> I did some revisions to my teammates' sections. Fairly major ones, at that. I didn't tell them.
> This is why I not only assignmed myself more than half the project, I also made sure I was the one integrating the parts.
<Amthrax> That's the way to do it.  The nice thing is, with how long it takes them to grade the DP's, they'll never find out
<Amthrax> The only problem is that it might give them false confidence
> err, did Albert start implementing the PropertyTable?
> I hadn't thought about it giving them confidence.
<Amthrax> You mean the little thing in the UI?
<Amthrax> He just stuck that in there because he wanted something to stick in there
> Oh, OK. Makes sense.
> I was a bit confused since I have something else stuck in there. ;)
<Amthrax> Ah, yes.
> It'd be kinda nice to have a 'revert' or 'reload' button that puts the board back to its saved state.
<Amthrax> Yeah..
<Amthrax> Hmm.  I guess by "go to bed", I meant get in bed and continue working
*** dan is dan@clamshell.ambulatoryclam.net (Dan Ports)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** dan is an IRC Operator - Server Administrator
*** dan has been idle 7 minutes, signed on at Thu Apr 15 03:43:10 2004
*** dan : End of /WHOIS list.
> GameBoard just broke 1000 lines.
<Amthrax> Eep
<Amthrax> That class alone is a tenth of the overall codce
> I guess that's not wholly unexpected, but it's still scary.
> I really want to refactor it. Somehow.
<Amthrax> Somehow
<Amthrax> Hmm.  Vertexes or vertices?
> I've always used vertices.
> I think at the very least I'll reorganize the code in GameBoard so it's chunked into reasonable sections. (manipulating the gizmo list, simulating, triggering, propertifying, ...)
<Amthrax> Oh boy.  I just managed to give a variable two names in the same declaration.  It took me a few moments to figure out why it was complaining about this.
> I think it's time to get some sleep.
<Amthrax> Yeah.
<Amthrax> I want to ci poly first
<Amthrax> Besides, I'm laying in bed.  That counts, right?
> hmm. The simulator is doing Weird Stuff.
<Amthrax> Uh oh
<Amthrax> Maybe it's sleepy, too?
<Amthrax> PolyBumperGizmo ci'd
<Amthrax> And speaking of which, g'night
* Amthrax curls up, covers himself with his wing, and promptly passes out
> Night.
> Bah. The bug that was causing the checkRep errors is actually a fairly subtle but important bug in our collision system design.
> Fortunately, a fixable one.
<aleung> ci'd revert button and status bar support for load errors
> Cool.
<aleung> (i'll do an error dialog in a sec)
> I'm knee-deep in the collision system right now.
<aleung> cool
<aleung> has austin been revived yet?
<aleung> and how's the subtle bug going?
> I have the fix written, and I'm testing it now.
> It turns out that the checkRep failure bug was actually being caused by an exception from the gizmo that got thrown and screwed up the simulator state.
> The exception that was being thrown was when a ball and flipper were expected to collide, but actually didn't.
> And the cause for that was that we didn't have a way to invalidate the timeUntilCollisions when flippers start and stop flippering.
> And now we do. At least, hopefully.
> hmm. Flipper collisions still aren't working right.
> This is surprisingly elusive, but I'm pretty sure it's a bug in the gizmos not the collision system. Maybe Austin will have some insight when he revives.
<aleung> alright
<aleung> ah, btw
<aleung> bounding box isn't in yet?
<aleung> nevermind
<aleung> maybe i forgot to update
> No, it's in.
> (Isn't it?)
<aleung> lemme check again
<aleung> if it is, selection might be done
> I'm going to ci this whole mess of code. It works more than what's currently in cvs, after all.
<aleung> hah, it seems selection always selects the outerwall gizmos
> ci done, lots of things changed.
<aleung> that should be fixed
> I'm mucking around in the standard gizmos right now, I may as well fix that.
<aleung> ah, so you'll have the bounding box different?
> I was going to make it have no bounding box.
<aleung> no bounding box as in a degenerate one?
> Or does that cause other problems for you?
> A null bounding box
<aleung> degenerate is probably preferred
> ci'd
<aleung> oh man, this drifting ball thing is interesting
<aleung> in the absorber
<aleung> ah, selection ci'd
<aleung> feel free to go to edit mode and watch things be selected
<aleung> frobber time
> I'm getting too much enjoyment out of selecting gizmos.
<aleung> yeah, likewise
<aleung> wait till we have frobbers!
<aleung> i'll start on them once i get this place back to being livable
> I'm going to go back to the PropertyTable, after my unexpectedly long interlude fighting that bug.
<aleung> has it been resolved?
> Sort of. It doesn't throw exceptions anymore, and it has some useful new code that makes it deal with this situation better. But flipper collisions still don't seem right.
> I'm punting that issue to Austin. It seems like it's the physics library misbehaving.
<aleung> is he still not revived?
> He's alive, I talked to him earlier and showed him what was going on
<aleung> great
<aleung> i'm just about ready to do frobbers
<aleung> so in an hour or two, there'll be even more stuff to play with
<Amthrax> I left the bounding box in for the outer walls so that gizmos couldn't be placed overlapping with it, but maybe that should be a separate mechanism
> That's what I figured.
<Amthrax> Reading diffs now
> That should keep you busy for a while.
<Amthrax> Oof, alright
<Amthrax> I need to figure out how to colorize less.  Reading that much green text is more boring than it needs to be
<Amthrax> Alright, the geometry of the flippers is right, which suggests to me there's either something else that's very subtle, the physics library is broken, or the physics library is expecting something other than what I'm giving it
<aleung> what's the issue with flippers now?
<Amthrax> They still don't work
<aleung> how do they break?
<Amthrax> The ball doesn't do the right thing
<aleung> ah, it goes off in weird directions with weird speeds?
<Amthrax> Yeah
<Amthrax> And passes through parts of the flipper in weird ways
<aleung> mmm, it seems to collide ok if the flipper doesn't move into the ball
<Amthrax> Yeah, non-moving flippers are fine
<aleung> eh, i get this weird lockup
<aleung> where the interface dies
<aleung> but the game seems to keep ticking
<Amthrax> That's interesting
<aleung> it seems to be from balls in the absorber?
> I get that if you get two balls into the absorber at once.
> It's a known bug.
<aleung> ok
<Amthrax> I think I'm just going to make the absorber stupider, at least for now.
<Amthrax> But right now I'm working on the flippers
> I want to call it a feature, but I don't think I can justify tha... wait. They said we could specify the behavior of the absorber when it has multiple balls in it, right?
<Amthrax> Heh heh
> Why do Sun's source files say:
>  * You acknowledge that this software is not designed, licensed or
>  * intended for use in the design, construction, operation or
>  * maintenance of any nuclear facility.
<aleung> lol
<Amthrax> Well, it probably isn't
> And should we be saying that in our documentation too?
<Amthrax> Maybe they've had problems with this
<aleung> why not make it more general
<aleung> why specifically nuclear facilities
<aleung> but yes, let's say that in our documentation
> And let's say that Gizmoball is not designed for implantation into the body or life support systems, like IC spec sheets.
* dan is resisting the urge to ask the zephyr instance whether Gizmoball needs to be designed foruse in the design, consturction, operation, or maintenance of nuclear facilities.
<Amthrax> Hmm.  So I made the flippers rotate really slowly and the reflection is definitely wrong.  I think it's the physics library
> hmm.
<Amthrax> The GameBoard log is reporting the current time in seconds, right?
> Yeah
<Amthrax> Is it just me, or is the time increasing by one about every two seconds?
> It didn't seem like realtime to me either.
> (Is it not being ticked at the right rate?)
<Amthrax> Wow.  Selection looks cool
<Amthrax> Is it possible to get back into selection mode after placement mode yet?
<aleung> nope
<aleung> i should do that
<Amthrax> Okay.  Just checking
<aleung> but i'm trying to do a good general frobber system
<Amthrax> Okay
> In keeping with the apparent tradition of the ui package, I'm creating a gizmoball.ui.propertytable package.
<Amthrax> How many classes does it take?
> A fair number... PropertyTable, TreeTable, TreeTableModel, PropertyTreeTableModel...
<Amthrax> Gah
<Amthrax> Oh, oh, saner flipper collisions
> Since, after all, there's no JTreeTable.
<Amthrax> Though I still don't believe their rotation rate
> What did you change?
<Amthrax> The sign of the rotation rate
> Oh. Was it rotating backwards?
<Amthrax> Apparently it was rotating forwards but moving backwards
> Now that could make things interesting.
<Amthrax> Oh, great.  It was expecting a clock-wise positive rate
<Amthrax> Of course
> Naturally.
<Amthrax> It still seriously sends the ball flying
> Yeah, that seems wrong.
<Amthrax> Oh
> Ooh, I could buy a JTreeTable for $100! http://www.e-beans.com/products/tools/jtreetable/
* Amthrax sheilds his eyes from the light that just turned on above his head
<Amthrax> Wow.  That you can
<Amthrax> Ooh, ooh, is it a Bean, too?
<Amthrax> Stupid coordinate systems
> heh. The ui package has a multitude of subpackages, whereas the game package basically just has one really huge monolithic class. This amuses me.
<Amthrax> Ooh, an error dialog  ]:--8)
<Amthrax> Wow, that's reasonable enough that it might even be correct!
<Amthrax> Fixed flippers ci'd
<aleung> mmm, i gotta see this
> They flipper correctly!
> This is even more fun to play with than selection!
<aleung> hmm, is that the correct speed?
<aleung> there also seems to be an occasional lag
<aleung> damn, i got it to crash without absorbers
<Amthrax> I'm pretty sure that's the correct speed, comparing with past term's flippers
<aleung> ok
<Amthrax> It's still pretty fast, but at least the ball doesn't instantly wind up in the absorber
> TreeTableModelToTableModelAdapter is a perfectly good name for a class, right?
> (Look! I'm using a design pattern!)
<Amthrax> Gah
> It does exactly what the name suggests...
<Amthrax> I would expect nothing less
> And that's the class javadoc.
<aleung> i'll be back in 30 mins
<aleung> this frobber thing is rather annoying
<Amthrax> Dan, out of curiosity, do your log messages check whether or not the stream is enabled before logging?
> Nope. Should they? How would they? I haven't delved any deeper into log4j than calling logger.debug().
<Amthrax> I'm just wondering how much time is bring put into formatting those strings even if they never go out
> Good point.
<Amthrax> You might want to add the check to the more copious messages.  See BallGizmo for how to do it
> OK. I'll do that once I finish this.
<Amthrax> Are collision triggers fired before collisions are?
> Apparently so, though I can't imagine why.
<Amthrax> Oh
> I don't think they should be, so unless you do or it relies on something I'll change that.
<Amthrax> It would be nice if they fired after
<Amthrax> (This is arising in the context of the self-triggered absorber)
> *nod*. That was what I intended too.
> (And that worked before. Wow.)
<Amthrax> Alright.  I'm pretty sure the absorber works otherwise, so I'll go ahead and ci
> I just ci'd that.
<Amthrax> Yeah, except that the absorber used to be such a quivering mass of bizarreness that it probably sprouted intelligence and took care of that autonomously
<Amthrax> New absorber ci'd
> btw, it seems to me that JDE screws with c-hanging-braces-alist when it loads, so I added a hook to set that.
> (God help me, I'm turning into an emacs power user, aren't I?)
<Amthrax> Have you written your own major mode yet?
> Not yet. That means there's hope, right?
*** You have new email.
<Amthrax> A hook does not a power user make
> Also, I use vi to edit my .emacs.
<Amthrax> That's.. just plain bizarre
<Amthrax> My criterion are as follows:
<Amthrax> 1) No .emacs customization - Beginner
<Amthrax> 2) .emacs customization - Novice
<Amthrax> 3) Minor modes - Expert
<Amthrax> 4) Major modes - Power user
> That makes me feel better.
> (But I do concede that becoming an emacs guru was on my TODO list for the summer)
> hey, that was cool. I just saw:
> Broadcast Message from root@clamshell.ambulatoryclam.net
>         (no tty) at 16:32 PDT...
> UPS smartups@localhost on battery
> But it was sent to all of my ttys. Five of those are in this screen session.
<Amthrax> That's interesting
<Amthrax> Haha
> 'Bell in window 0' 'Bell in window 1' 'Bell in window 2' ...
<Amthrax> Bwahaha
<Amthrax> 'You hear a nearby bell in window 0'
> Yeah, why isn't that one customized in nethack-mode?
<Amthrax> Darnit, I want closures...
<Amthrax> Wait.  What the hell?  Why do polyGizmos include a dimension?
> What?
<Amthrax> In the XML format
<Amthrax> The gizmo includes width and height
<Amthrax> I think.. I'm just going to ignore that
<Amthrax> Because it is stupid.  And therefore ignorable
> Uh, so it does.
> Revised specifications!
<Amthrax> Yep
> I'm sure this is how everyone else is handling editor collisions... no, wait, they don't even have to do that.
<Amthrax> Eew, you think they're just using bounding boxes?
<Amthrax> I mean, technically we automatically support that.  It's just currently inhibited.  It's inhibited for a reason.
> Well, they don't even have to have an editor for polyGizmos.
*** You have new email.
<aleung> but you do need to be able to edit a board containing existing polyGizmos
<aleung> so they do still need editor collisions
<Amthrax> Speaking of which, why aren't we using java.awt.geom.Area for this?
<aleung> you know, i think it's cause java natively supports so much crap you don't even know what to expect they have
<Amthrax> I was thinking the same thing
<Amthrax> Dan?  Would this be easy to move over to?
<Amthrax> I could easily port the gizmos over to it
<Amthrax> Actually, getBoundingBox -> java.awt.geom.Area getBoundingArea()
> I imagine so. Let me take a look at the javadocs.
> Whoa, where'd that come from? It's practically a blob.
<Amthrax> I.. think it's actually more than a blob
> Yes.
<Amthrax> Alright.  I think poly gizmo loading is almost done.  I can port the gizmos over to that then
> Sure, why not. Let's do that.
> I'll change AGizmo and GameBoard.
<aleung> wow, impressive
> So Java has everything I could possibly need... except a TreeTable?
<aleung> the change on my side is minimal
<Amthrax> Haha, yes Dan
<aleung> there was probably some lobbying done by the treetable software engineers union
> Sun probably owns stock in that company that's selling TreeTables.
> And before I keep going, there isn't a java.awt.gizmoball.GameBoard class, is there? :P
<Amthrax> Albert, could you make a quick change to the save/load/revert exception handling?
<aleung> maybe not, but i'm sure someone's out there you can buy it from
<aleung> sure
<Amthrax> That's true
<Amthrax> Two things:
<Amthrax> 1) Catch IOException instead of Exception
<aleung> i can guess one of them
<aleung> yup, i had that at first
<aleung> and when i was testing it, it threw a runtime, so i decided to catch that as well
<Amthrax> 2) Add a logger for the stack trace.  One sec and I'll give you the magic snippit for that
<aleung> cool
<Amthrax> Ah
<Amthrax> logger.debug("IOException caught", e); should do it
<aleung> cool
<aleung> what of runtimes?
<Amthrax> Yeah, without a stack trace I'm kinda stuck on why the loader isn't loading polys  ]:--8P
<Amthrax> Oh, and, in theory, I only throw RuntimeExceptions from there when stuff happens that really shouldn't with validated XML
<Amthrax> Of course, at the moment it's ignoring the results of validation anyways, so those might arise.  I should fix that...
<aleung> ah, i was trying to load random files
<aleung> xml and otherwise
<Amthrax> Heh.  Yes, that should have dumped a bunch of complaints to the console and then blown up randomly
> Good! Testing!
<aleung> technically, it's not catastrophic
<aleung> even if loading of random things fails
<aleung> ci'd
<Amthrax> Thanks
<Amthrax> Heh, and the RuntimeException messages are notable less friendly than the IOException ones  ]:--8)
<aleung> btw, i intend to add a developer's comments line to the status bar
<aleung> so our colorful remarks will infect even that aspect of the project
<Amthrax> Oh.  Dan, on the plural property names, do you think I should add both the plural and the non-plural?
<Amthrax> Because from the loader it makes more sense to go after the singular
<Amthrax> Er, but then it'll show up twice in the names list...
<Amthrax> Hmm, ugliness
<Amthrax> isPluralCollection!
> That's weird, I'm getting 76% packet loss to robinhood.
<Amthrax> The network's going haywire with UDP broadcasts
<Amthrax> Like 100K/s work it them
<Amthrax> Did you shutdown unwonkifyd?
> It shut itself down.
* dan fires up ethereal.
<Amthrax> Er, right.  (Missed the email)
<Amthrax> What are the specs for the bounding poly method?
> public Area getBoundingArea()
> Gah, what is all this crap on the network?
<Amthrax> Uh.  I just noticed that java.awt.Polygon only works on ints
<Amthrax> Ideas?
> hmm.
<Amthrax> Hot new Windows patch?  Er, virus?
<aleung> err, were you planning on using java.awt.Polygon?
<Amthrax> Oh...  GeneralPath?
<Amthrax> Yeah, I think GeneralPath does it
<Amthrax> Yeah
<Amthrax> Since I figured that would do, y'know, polygons
> That was fun, I lost connectivity.
<aleung> it seems to be part of the old shape framework that only did ints
<Amthrax> *nods*
> GeneralPath does polygons and Polygon does, uh, not-polygons. This makes perfect sense.
<aleung> hah, what makes java even worse is all the deprecated stuff is still there
<aleung> i mean, i guess that's necessary for backwards compatability
> So, uh, what's a Browser Election Request and a Local Master Announcement?
<aleung> but it adds even more clutter to go through when trying to find features
<Amthrax> Yeah, but it makes Java crufty
<Amthrax> I don't know about BER, but LMA has to do with chosing a master for Windoze Networking.  It's only P2P in a sense; it choses a master within the broadcast range to make the server until it goes away
<aleung> what's a good algorithm to do this:
> And apparently BER is what gets sent out to start the process of choosing the master browser.
<Amthrax> Ah
<Amthrax> That would make sense
<aleung> ah, nevermind, i got it
<Amthrax> Good grief.  Of course GeneralPath only exists in float form
> hey, here's a LMA from AWAKENING
<Amthrax> Gah.  I thought unwonkifyd suicided?
<Amthrax> Uh
<Amthrax> Yeah, that's possible
<Amthrax> I am running Samba *lowers his snout in shame*
> I thought it did too, is it kept alive somehow?
<Amthrax> I.. didn't think so
<Amthrax> Maybe?
<Amthrax> Anyways, gizmo bounding areas are done.
<Amthrax> Once I can get a word in edge-wise to the AFS servers, they'll be ci'd
> ok, I'll ci the interface for it.
> (That's not the correct order of things, is it?)
<Amthrax> ci'd
<Amthrax> No.. but this way we don't break the build.  As much.
<Amthrax> Is the UI bounding area stuff ready?
<Amthrax> (Hmm.  Router software upgrades today?  I wonder)
> Checking in a new AGizmo, if AFS cooperates.
<aleung> ah, is the bounding area stuff in?
<aleung> if so, i'll switch the ui over
<aleung> ah, alright, i'll switch in a sec
<aleung> btw, what's the difference between Angle.RAD_PI_OVER_TWO and Angle.DEG_90?
<aleung> damn network
<Amthrax> There isn't any difference, I think
<Amthrax> They just included things in both radians and degrees
<Amthrax> Looks like the network's starting to calm down
<aleung> i think i've gotten the functional side of frobber menus done
<aleung> now just to do the drawing side, and then editor support for setting properties
<aleung> i notice with some satisfaction that selecting now works even better than before
> I was wondering about the difference between RAD_PI_OVER_TWO and DEG_90 myself. I figured there was some kind of subtle difference that would screw everything up.
<aleung> do we have a list of standard property names yet or shall i just go to GizmoballReader?
> I have TreeTable stuff, now I'm just hacking together the PropertyTableModel
<aleung> hah, i'm glad you took it off my hands, it looked rather ugly
<Amthrax> Uh, just look at the reader
<Amthrax> [phone]
<aleung> not that frobbers aren't ugly themselves
> Yeah, I imagine that's pretty ugly to implement
<aleung> are triggers properties at present?
> No, but they will be.
<aleung> alright
<Amthrax> [/phone]
<aleung> frobber drawing time
<aleung> are you ready to handle saving?
<Amthrax> No
<Amthrax> Hopefully I will be in a few hours, though
<aleung> i think i'll complete frobbers and then switch over to another pset i gotta do
<Amthrax> Okay
<aleung> mind if i pixmap the frobber icons?
<Amthrax> That's fine.  There will have to be some magic added to the build file, though
<aleung> ah, really?
<aleung> where should i throw them?
<Amthrax> Yeah, to copy them into the classpath.
<Amthrax> Go ahead and put them in the right source directory
<aleung> hah, i don't know whether i should do a ui.frobbermenu
<aleung> it'd probably make locating the pixmaps neater
<Amthrax> Take a look at the three lines in build.xml where it says "copy XML schema" and duplicate those
<Amthrax> Depends on where you want them
<Amthrax> I just put the XML schema in the root of the classpath
<Amthrax> The location in the source tree is irrelevant, though
<aleung> alright
<Amthrax> Cool.  Selection of poly gizmos.  ]:--8)
<aleung> does it work?
<Amthrax> Yep
<aleung> as far as i know, the drawing should be fine too ^_^
<Amthrax> Looks like it is
<Amthrax> I'm just about done with poly gizmo loader support
<aleung> great
> And I'm having fun with PropertyTables.
<Amthrax> Did the keyup/keydown ever get in?
> Oh. Right. No, but it's trivial.
<aleung> ah, i'm still lobbying for general actions
*** You have new email.
> GameBoard.fireKeypressTrigger and the KeypressTrigger constructor will now take another argument that's true if the trigger in question is a keydown trigger.
> (As soon as I ci that)
<Amthrax> Heh.  Before I fix flipper orientation, take a look at all-gizmos.xml and play with the flippers (asdf jkl;)
> Do we have any xml files with keyUp triggers?
<Amthrax> Don't most of them?
<Amthrax> all-gizmos does, at least
<aleung> ah, if you wanna really test it
<aleung> you can hold down the trigger, click the pause, and release the trigger (assuming the trigger is space)
> Don't know, but I went ahead and implemented keyDirectionness in the loader and ui too, testing them now.
<Amthrax> That works
<aleung> alright
<Amthrax> (I assume you found where I disabled it?)
<aleung> do we have new testfiles?
<Amthrax> all-gizmos is new
<aleung> exciting...
<aleung> hmm, is something being messed with?
<aleung> it doesn't load for me
<Amthrax> Eh?
<Amthrax> Oh.
<Amthrax> One sec
<Amthrax> update and rebuild
<Amthrax> (Sorry, forgot to checkin poly gizmo stuff)
<aleung> hah, my select mode has a bug
<aleung> where it leaves the selection artifact hanging around
<Amthrax> Oh, so that was what that was...  I was wondering why I had a temporary floating square  ]:--8)
<aleung> amazing, those oddly oriented flippers actually hit
<Amthrax> Yeah.  Everything correct, I just have the wrong center point
<Amthrax> And, of course, the drawing is using the same data that the physics is
<aleung> do we still have issues with the collision system?
<aleung> there seem to be states when it locks up a bit
<Amthrax> Not that I know of
<aleung> wow, where i have to click to select some of these flippers is interesting
> It runs annoyingly slow for me... but that's because I'm abusing my system horribly at the moment.
<Amthrax> It runs pretty fast for me, especially if I disable logging
<aleung> ah, it seems the bounding area prevents absorber selection
<Amthrax> Ah, yes
<Amthrax> I'll fix that
> Well, I've got all the log messages going into an emacs buffer, and I'm compiling other stuff in the background.
> Anyway, I think I have keydirections working. Let me check that in...
<aleung> i like the new absorber
* dan assigns himself a pointy-hat.
> (Stray commit broke the tree, let me back it out)
<Amthrax> Uh oh
> Backed out, the tree should be well again.
<aleung> ah, we have a tree?
> No, the source tree.
<aleung> oh...  got my hopes up
<Amthrax> Playing with the flippers is much too fun
> That's why I'm not letting myself do it until I have some semblance of a property table.
<Amthrax> I'm going to make pasta and then write the saver
<Amthrax> Oh wait, nevermind.  I already had dinner...
<Amthrax> I'm going to write the saver
> Heh.
<Amthrax> ...  DOM doesn't have an unparser?
<Amthrax> DOM.. doesn't have an unparser.  What the hell is wrong with these people?
> It doesn't? That sounds... kinda important.
<Amthrax> What's wrong with this picture?
<Amthrax> "No one ever believes me when I tell them how easy it is to develop programs that write XML documents. In fact, writing a program to output an XML document is unbelievably trivial. It\x{2019}s something an eight-year old typing BASIC in their first class at computer camp can do. In Java, it\x{2019}s even easier than that due to Java\x{2019}s strong Unicode support. You don\x{2019}t need to know any special APIs like DOM or SAX or JDOM. All you have to kno
<Amthrax> Yay!  All I have to know is a single function call that has entirely nothing to do with the intricacies of XML or with XML itself
> What is this magic function call?
<aleung> lol, i was just wondering the same thing...
<aleung> it sounds akin to coding via ed
<Amthrax> No kidding.  And they're trying to convince me that this is a good thing
> It's trivial!
<Amthrax> It's idiotic!
<Amthrax> Er, I mean, trivial
> Just like JTreeTable isn't included because it's trivial... oh, wait, it's not.
<Amthrax> But just think, you wrote at least $100 worth of marketable code today
<Amthrax> Just imagine what we could sell Gizmoball for!
> Remind me to run sloccount on it.
<Amthrax> Oh, which reminds me..
<Amthrax> Yes!  We've passed 10 KLOCs
> 1 KLOC in GameBoard alone!
<aleung> we should definitely patent frobber technology
<Amthrax> 5.3 KLOCs of physical code
<Amthrax> Total Estimated Cost to Develop                           = $ 156,785
> OK. We're sending Rob Miller the bill.
> I caught myself writing an 'if' in my code and thought 'this represents a lost opportunity for dynamic polymorphism!'
> So I redesigned.
<aleung> hah, i actually use the ? : syntax
<aleung> ugh, who came up with these graphics calls
<Amthrax> Sun!
<Amthrax> We all love Sun
<aleung> i also hate this user-space/real-space thing
<Amthrax> I glanced over some stuff on that a while ago and decided it needed to be ignored
> I am writing an AbstractPropertyTreeNode.
<aleung> we love sun's trees
> Next I will write the PropertyTreeNodeFactory.
<aleung> was it a defaultmutabletreenode that they provide?
> no, it uses a custom TreeModel
<aleung> cool
<aleung> (and no, i didn't think you were using what they provided)
<aleung> (i don't know if that's possible at all)
> I don't think it is for this. At least not without even more creativity.
<Amthrax> So apparently the magic method for writing XML got cut off in my quote earlier.  It is *drumroll*
<Amthrax> System.out.println
<aleung> uh...
<Amthrax> Do not question the wisdom of Sun!
<aleung> btw, do you find that angles are disfunctional?
<Amthrax> WDYM?
<aleung> do they go clockwise or counter?
<Amthrax> I have no idea
<Amthrax> I think clockwise
<aleung> i am getting weird negative angles, which isn't possible according to the spec
<Amthrax> From?
<aleung> from angles i'm creating
<Amthrax> Oh
<Amthrax> Ooh, Java strings have a method for replacing one character with another, and a method for regular expression substitution...  but no method to replace occurences of one substring with another
<aleung> ah, this is ridiculous
<aleung> angles represent angles in the range of 0 to 2*pi
<aleung> but angle.radians() returns in a range from -pi to pi
<Amthrax> Wow
<Amthrax> Though, I suppose it's true that it represents angles in the range of 0 to 2*pi.. since EVERY angle is in that range.
<aleung> yeah, i suppose
<aleung> but every angle would also be in the other range
<aleung> ugh
<aleung> well, it also specifically says non-negative angle in the overview
<Amthrax> Yeah.  That's pretty bad
<aleung> meanwhile, Graphics likes degrees
<aleung> and 360 is a useful angle value
<Amthrax> Uh, is there a reason I'm not getting a backtrace on my save exception?
<aleung> probably
<Amthrax> Wow.  You're right about the uselessness of Angle.  I just ran into the same problem in the saver
<aleung> i didn't really implement the save stuff as it wasn't supported yet
<aleung> but i'll add that now
<Amthrax> Okay
<aleung> ci'd
<Amthrax> The save dialog is entitled "Open", which, while consistent, may prove confusing to our users ]:--8)
> But... consistency!
* dan is writing abstractions to swaddle other abstractions inside yet more layers of abstraction.
* dan shudders.
<Amthrax> You should use SOP more!
> I guess I could use SOP to draw the tree...
<aleung> yup, i'll switch up the dialog name
<Amthrax> Hmm.  Now to modify the XML schema so the files written by the saver are valid...  This is probably not the right way to do this
> It's kinda like no-box testing.
<Amthrax> Wait...  What the hell?  The position for squareBumper and circleBumper must be int's by the schema, but the triangleBumper and flipper positions are floats by the schema
> I just named a class PropertyPropertyTreeNode.
<Amthrax> Ooooh, and the orientation for flippers is a float, but the orientation for other things must be 0|90|180|270
<Amthrax> Yeah, this schema is stupid.  I'm going to rewrite it
<aleung> lol
> hmm. Are there any collection properties that don't contain Propertyified objects?
<Amthrax> GizmoVertices of PolyBumperGizmo are Vert's
> hrm. That's annoying.
> It would have been convenient if the only type of tree nodes I had to deal with were Propertys and Propertyifieds
<Amthrax> Don't you have to deal with Verts anyway?
<Amthrax> Since it was decided they should be special cased...
> Yeah, but a Vect property is different than just a random Vect floating alone.
<Amthrax> Oh
> The property has a name associated with it, etc.
<aleung> so they do go clockwise
<aleung> ugh
<aleung> whoever wrote that class deserves to die
> Maybe I should make an AbstractPropertyPropertyTreeNode!
> It could have PrimitivePropertyPropertyTreeNode and CollectionPropertyPropertyTreeNode subclasses.
<aleung> ah, i've managed to make frobbers draw correctly!
<aleung> i practically wrapped their angle class
<aleung> but frobbers now redistribute correctly to account for component edges
<Amthrax> Cool
<aleung> they also correctly account for the number of frobbers
> I noticed you had some impressively-complex looking stuff in FrobberMenu.
<aleung> i just have to do the icons and stuff
<aleung> and the editing side support
<Amthrax> @throws UnsupportedOperationException always
> I needed a way to test whether something was a collection property. So I made it try getCollectionValue on it and catch the UOE.
<Amthrax> isCollectionProperty didn't suffice?
> I just have the property.
<Amthrax> Oh
<Amthrax> Pfft.  Collection.class.isAssignableFrom(property.getType())
> That works too.
> Mostly I couldn't remember isAssignableFrom, and I'm really feeling kinda apathetic right now.
<Amthrax> My, what pointy brackets you have
<aleung> ugh, who would've guessed ellipse2d is a rectangularshape
<Amthrax> Well, obviously.  Ellipses are just lazy rectangles
<Amthrax> Dude.  It's an XML schema for XML Schema.
<aleung> btw, did you ever fix the absorber bounding area?
<Amthrax> Uh...  No.
<aleung> alright, just checking
<aleung> it was frobbing weird, so i was wondering
<Amthrax> I would check in the change, but I have some others in there that would break the tree
<aleung> alright, no problem
<aleung> i think i'm gonna stop for a bit
<Amthrax> But the change is there now, at least
<Amthrax> Yay, their schema is now actually correct
<Amthrax> Odd how many changes I had to make...
<Amthrax> It was also doing fun things before like not actually validating the gizmo tags that were in the gizmos list
<Amthrax> It had a list of valid gizmo tags, and at the end was the wildcard
<aleung> does this mean we'll have saving soon?
<Amthrax> It's getting there
<aleung> btw, i'll be gone for a couple hours soon
<Amthrax> I just need to add collection properties and triggers
<aleung> alright
<Amthrax> Collection properties work
<Amthrax> And trigger saving works
<Amthrax> I'll clean up a bit and ci
<Amthrax> Saver ci'd
> Entry-people are learning Baxil Time!
<Amthrax> Who'd you get this time? ]:--8)
> Pong came by and wished me a good evening.
<Amthrax> Ah, excellent
> The current count is 1240 lines of code that don't do anything.
<Amthrax> So wrong...
> (Of course, by this point they are supposed to be doing something. We will ignore the fact that they don't for now.)
> I wound up defining an AbstractPropertyTreeNode.
> Then I defined an AbstractPropertyPropertyTreeNode that derives from it.
<Amthrax> Wow
> I have a non-trivial inheritance hierarchy here.
> Now I'm going to go take out my unhappiness with these layers of abstraction by shooting things.
*** You have new email.
<Amthrax> I'm adding settable friction/gravity now
<Amthrax> Hmm.  Shouldn't testBoundingBoxIntersection be testBoundingAreaIntersection?  ]:--8)
> Err, yeah, it should.
> I thought I replaced all the BoundingBoxes with BoundingAreas, but apparently I missed one fairly important one.
<Amthrax> AbstactFixedGizmo should have been called AbstractNotABallGizmo
> It's not to late to refactor it!
<Amthrax> That's true
<Amthrax> So, in theory, we support configurable gravity and friction now
> Cool. Is that ci'd?
> I have a lot of buffers open right now. And the sad thing is that I'm actually using them.
> Right. My PropertyTreeModel works better if I actually set the root.
<Amthrax> Hmm.  For some reason it's not pushing over ssh.  I guess I'll just assume it works and ci
<Amthrax> (Why is it taking 50 K/s to give me a blank Gizmoball window?)
> I have something that's starting to look vaguely promising (but clearly not anywhere near complete)
<Amthrax> Ooh
> I see a property tree that lists the properties of the GameBoard.
> (Though I can't expand the gizmo list yet, or edit them, or do anything at all meaningful)
> But I can see that the value of Gravity is 25.0.
<Amthrax> Cool
> I also need to make the property table not take up more space on the screen than the gameboard pane.
<Amthrax> That would probably be a good idea (but look at how cool our property table is!)
> It's actually so big right now that Swing has helpfully decided to shrink the gameboard so there'll be space for the ptable.
<Amthrax> Oh
<Amthrax> How kind of it
> But it looks vaguely cool.
<Amthrax> execjar target is in
*** You have new email.
*** You have new email.
> Glad to hear that works.
> I am now the proud(?) owner of a piece of paper from the admissions department that says 'Dan has a very good head on his shoulders'. I think that's a good thing. (Where else would my head be?)
> And now it's back to the world of property tables.
<Amthrax> Ah, you got your records?
<Amthrax> (BTW, take a look at newton.xml ]:--8)
> Yeah. I need to figure out how to interpret the card of numbers.
> But my interviewer (she of the compulsive note-taking habit) wrote out a two-page essay about me. This scares me a little.
<Amthrax> Heh heh.  I wonder if she knew that admissions ignores those...
<Amthrax> Alright, _now_ take a look at newton.xml
> Ooh, now that's cool. So many collision pairs to check.
<Amthrax> (I just ci'd an even better one)
> Running it now.
> My poor system seems a little unhappy at having to run it... but that's cool.
<Amthrax> Really?  It runs great on mine...
<Amthrax> Well, almost great, at least
> I'm abusing my system again.
<Amthrax> Ah
<Amthrax> (Granted, it takes 90% of my poor laptop's CPU, but...)
<Amthrax> I showed a simulation of a bunch of balls to a previous term 6.170er and she was impressed by its smoothness.
> hmm. And lots of balls is the least efficient simulation we can run.
<Amthrax> Right
<Amthrax> Er, wait, is the game board's checkrep still on?
> I never turned it off in cvs.
<Amthrax> Woah.  Now I wonder...
> Yes. I was wondering that too.
<Amthrax> Hmm.  I changes things surprisingly little, but that's definitely smooth for 25 balls
> I'm surprised, that's an expensive checkRep. I wonder where the bottleneck is. (A profiler sure would be nice)
<Amthrax> The bottleneck's probably in the fact that it's computing 625 collisions...
> Yeah. I suppose it's in the physics code.
<Amthrax> I was thinking about quick tests I could do to trivially throw out non-collisions between balls, but I'm afraid of breaking things
> Yeah. I don't think it's worth it.
> Well, I have the PropertyTable displaying things. Now I just have to make it display the correct things.
<Amthrax> Excellent
<Amthrax> Anyways, back to MacGregor
<aleung> i'll probably throw the propertytable in a scrollpane or something
<aleung> is it just me or did the loader break?
<Amthrax> Uh, what are you trying to load"
<aleung> any of it
<aleung> newton
<aleung> example
<aleung> it gives me a numberformatexception, i think
<Amthrax> o.O
<aleung> Error: URI=file:C:/eclipse-SDK-2.1.2-win32/eclipse/workspace/gizmoball/doc/testfiles/example.xml Line=1: Document root element "board", must match DOCTYPE root "null".
<aleung> java.lang.NumberFormatException: empty String
<aleung> 	at java.lang.FloatingDecimal.readJavaFormatString(Unknown Source)
<Amthrax> That's interesting
<Amthrax> That looks like it's the XML validator going haywire
<Amthrax> Where's the first place in the traceback that's in our code?
<aleung> gizmoballframe.loadlistener.actionperformed -> aimode.load -> reader.load(78) -> loadboard(89)
<aleung> -> getdoubleattrib(403)
<Amthrax> Hmm
<Amthrax> Oh, I think I found the problem
<Amthrax> Were there any other parser errors that appeared before that one?
<aleung> nope, but there are no grammar found errors
<Amthrax> Ah, that would be what I was wondering about
<Amthrax> How are you building it?
<aleung> just in eclipse
<aleung> that's probably not a good thing
<Amthrax> Ah, then it's probably not copying the XML schema into place
<Amthrax> The ant target does that
<aleung> alright
<Amthrax> I'll make it so it doesn't fail catastrophically if there's no schema
<aleung> eh, i should just switch over to a better builder
<Amthrax> It still shouldn't fail like that, though
<Amthrax> (Since I wrote the rest of it so it can work without a schema)
<aleung> that's true
<aleung> btw, i'm doing the frobber icons now
<aleung> once those are in, i can do editor side frobber stuff, and that'll be that
<aleung> eta 2 hours or so
<Amthrax> Cool.
<Amthrax> Including the trigger stuff?
<Amthrax> Speaking of which, how do we delete triggers?
<aleung> are triggers propertyified?
<aleung> ooh, i mean
<aleung> collection propertied
<aleung> that'd be a good way
<Amthrax> Good question...
<aleung> i definitely don't want to implement connection selection
<aleung> (is there line segment intersection with points?)
<Amthrax> Nope.
<Amthrax> Though nothing's stopping us from making a skinny box
<aleung> i suppose
<Amthrax> (LineSegment2D is actually spec'd to always return false for collision tests since it has no area)
<aleung> wow, that sucks
<aleung> we can wrap it, i suppose
<aleung> how are we looking in terms of required stuff?
<aleung> we're practically there?
<aleung> oh, and boundingareas for flippers, is it the whole box they take up?
<Amthrax> Well, but it makes sense in the general sense.
<Amthrax> We're getting there
<Amthrax> The main remaining stuff is in the editor
<Amthrax> I'm working on cleaning up the rest of the system now
<Amthrax> :o)
<Amthrax> (Petra apparently says hi)
<Amthrax> sorry i'm bored
<aleung> hah, bored?
<aleung> there's plenty to do
<Amthrax> Heh, are you saying we should assign her a part of the UI?  ]:--8)
<Amthrax> She's already done some user testing
<aleung> oh, lol
<aleung> eh, so far, it's been boring
<Amthrax> And, yes, the flipper box is the whole thing, since that's what's needed for the editor collisions
<aleung> we need something in the running for the artistic award
<Amthrax> I think the vector graphics we have are fairly pretty
<Amthrax> Though the rest the UI could still use some visual cleaning-up
<aleung> hah, yeah
<aleung> i've rather neglected it
<aleung> selection still impresses me
<Amthrax> Yeah, that's cool
<aleung> the best thing about not doing tdd is you get presently surprised
<aleung> care to suggest a "handedness" icon?
<Amthrax> A hand?  ]:--8)
<aleung> alright, that works
<Amthrax> Trigger lists are now properties
> oh, cool, I was going to do that. Thanks.
<Amthrax> I was rather automatic
<Amthrax> *It
> I was still too lazy to do it. ;)
> The problem with having so many layers upon layers of useless abstractions:   (Well, one of them)
> apple.awt.EventQueueExceptionHandler Caught Throwable : 
> java.lang.ClassCastException
>         at java.util.Arrays.mergeSort(Arrays.java:1152)
>         at java.util.Arrays.mergeSort(Arrays.java:1163)
>         at java.util.Arrays.mergeSort(Arrays.java:1163)
>         at java.util.Arrays.mergeSort(Arrays.java:1163)
>         at java.util.Arrays.sort(Arrays.java:1079)
>         at java.util.Collections.sort(Collections.java:113)
>         at gizmoball.ui.propertytable.CollectionPropertyPropertyTreeNode.<init>(CollectionPropertyPropertyTreeNode.java:26)
>         at gizmoball.ui.propertytable.PropertyTreeNodeFactory.constructNode(PropertyTreeNodeFactory.java:35)
>         at gizmoball.ui.propertytable.PropertyifiedPropertyTreeNode.rebuild(PropertyifiedPropertyTreeNode.java:41)
>         at gizmoball.ui.propertytable.PropertyifiedPropertyTreeNode.<init>(PropertyifiedPropertyTreeNode.java:29)
>         at gizmoball.ui.propertytable.PropertyTreeNodeFactory.constructNode(PropertyTreeNodeFactory.java:26)
>         at gizmoball.ui.propertytable.PropertyTableModel.<init>(PropertyTableModel.java:26)
>         at gizmoball.ui.propertytable.PropertyTable.<init>(PropertyTable.java:28)
>         at gizmoball.ui.GizmoballFrame$LoadListener.actionPerformed(GizmoballFrame.java:254)
>         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1819)
>         at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1872)
>         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
>         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
>         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:247)
>         at java.awt.Component.processMouseEvent(Component.java:5100)
>         at java.awt.Component.processEvent(Component.java:4897)
>         at java.awt.Container.processEvent(Container.java:1569)
>         at java.awt.Component.dispatchEventImpl(Component.java:3615)
>         at java.awt.Container.dispatchEventImpl(Container.java:1627)
>         at java.awt.Component.dispatchEvent(Component.java:3477)
>         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
>         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198)
>         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
>         at java.awt.Container.dispatchEventImpl(Container.java:1613)
>         at java.awt.Window.dispatchEventImpl(Window.java:1606)
>         at java.awt.Component.dispatchEvent(Component.java:3477)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
>         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
>         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
>         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
>         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
* dan shudders.
<Amthrax> Heh, at least you didn't get a "... 35 entries left ..." message at the bottom like I did yesterday
*** dan is dan@clamshell.ambulatoryclam.net (Dan Ports)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** dan is an IRC Operator - Server Administrator
*** dan has been idle 17 minutes, signed on at Thu Apr 15 03:43:10 2004
*** dan : End of /WHOIS list.
<aleung> ah, the power of bitmap graphics
*** dan is dan@clamshell.ambulatoryclam.net (Dan Ports)
*** on channels: #6.170 
*** on irc via server clamshell.ambulatoryclam.net (Ambs's test IRC server)
*** dan is an IRC Operator - Server Administrator
*** dan has been idle 17 minutes, signed on at Thu Apr 15 03:43:10 2004
*** dan : End of /WHOIS list.
*** Reconnecting to server 0
*** Connecting to port 6667 of server localhost [refnum 0]
*** Looking up your hostname...
*** Checking Ident
*** Found your hostname
*** Got Ident response
*** Welcome to the NetMUGnet IRC Network dan!dan@clamshell.ambulatoryclam.net 
*** Your host is clamshell.ambulatoryclam.net[@0.0.0.0], running version bahamut-1.4(34) 
*** This server was created Sun Jul 28 2002 at 22:32:43 PDT 
*** clamshell.ambulatoryclam.net bahamut-1.4(34) oiwscrknfydaAbghe biklLmMnoprRstvc 
*** NOQUIT WATCH=128 SAFELIST MODES=13 MAXCHANNELS=10 MAXBANS=100 NICKLEN=30 TOPICLEN=307 KICKLEN=307 CHANTYPES=&# PREFIX=(ov)@+ NETWORK=NetMUGnet SILENCE=10 CASEMAPPING=ascii : are available on this server
*** There are 5 users and 6 invisible on 3 servers 
*** 5 : IRC Operators online
*** 1 : channels formed
*** I have 3 clients and 1 servers 
*** Current local users: 3 Max: 5 
*** Current global users: 11 Max: 509 
*** Notice -- motd was last changed at 27/12/2001 22:41
*** - clamshell.ambulatoryclam.net Message of the Day -  
*** - 15/4/2004 3:43 
*** - This is ircd-hybrid MOTD replace it with something better 
*** End of /MOTD command. 
*** Mode change "+i" for user dan by dan
*** dan (dan@clamshell.ambulatoryclam.net) has joined channel #6.170
*** Users on #6.170: dan Amthrax aleung 
*** Mode change "+wsg" for user dan by dan
-NickServ- This nickname is registered and protected.  If it is your nickname, type /msg NickServ IDENTIFY password.  Otherwise, please choose a different nickname.
Defaulting +r to CHANMODE type D
*** Mode for channel #6.170 is "+tnr"
*** Channel #6.170 was created at Wed Apr 14 19:33:07 2004
> Damnit, why is it so hard to make a PropertyTable.
<aleung> you know, my frobber menu can probably support a frobber for every property a gizmo has
> I've written almost 1300 lines of code, I'm determined to make this work. I'm just now sure how.
<aleung> alright, cool
<aleung> we definitely need to bill professor miller for this stuff
<Amthrax>         at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151)
<Amthrax>         at gizmoball.xml.GizmoballReader.openDocument(GizmoballReader.java:464)
<Amthrax>         ... 32 more
<Amthrax> That's Java saying "32 more" for my convenience
> I never thought I'd consider myself lucky to be able to see interminably long stack traces, but I do.
<aleung> so, convert me to an alternate builder
<Amthrax> Um.  Use ant.  Because ant is better than building with Eclipse
> ant is better than something? This surprises me.
<Amthrax> At least it's scriptable.. uh, ish
> In XML!
<aleung> btw, are file names case sensitive?
<Amthrax> Yes
> I assume that depends on the filesystem.
<Amthrax> Assume yes
> Bah. My nodes are updating, but the tree isn't redisplaying them.
<Amthrax> Is there some magical call you need to make to tell it to update
> Probably, but I haven't found it yet.
<Amthrax> re-somethiing
> This seems like it should be a fairly basic thing to do.
<Amthrax> Speaking of which, does the editor guarantee the uniqueness of gizmo names?
> It should.
<aleung> yeah, everytime you do a place, it increments a counter
> (in the correctness sense, that is. I don't think it actually does)
<aleung> i don't know about in the tree, but at least on the placement side
> Well, you can't even see a gizmo name in the tree, so we don't have to worry about that just yet. ;)
<aleung> alright
<aleung> any good resources for ant scripting?
<Amthrax>  Ant scripting?
<Amthrax> Just use the existing script (copy paste as needed0
<aleung> i can't copy multiple files?
<aleung> (and i'd rather figure it out)
<Amthrax> It's a pain to figure out what actually needs to go in there
<Amthrax> Of course you can.  Take a look at the code that copies the XML schema and just duplicate that
<aleung> i mean, i can't copy multiple with a single line?
<Amthrax> Oh, like wildcarded?
<Amthrax> You can probably comma-separate them in file
<Amthrax> Or give the copy target a fileset
<Amthrax> Alternatively, look up the copy target on the ant site
<aleung> ah, ok
<Amthrax> Newho, I'll be back soon
<aleung> ugh, this image translucency is being annoying
<aleung> nice, my system is being flooded by copies of the javavm
> What the hell? The property table *is* updating. But it updates to the *previous* change, not the current one.
<Amthrax> ...  o.O
> I'm wondering if the table is responding to the TreeModelEvent before the tree
> But that shouldn't happen, since I invokeLater the fireTableDataChanged call.
<Amthrax> Validation support ci'd
<Amthrax> Dan, do you have pending changes on GameBoard?  If not I'll predicate the logging
> I don't think so, let me check.
<Amthrax> That's interesting.  Your hanging indents are different
> nope, go ahead.
<Amthrax> Okay
> They are?
<Amthrax> Yes.  Mine hang inline with the previous line of the expression, but yours go in a constant four spaces (which looks better and makes more sense)
> Probably a style issue. I'm never entirely sure what style I'm using.
<Amthrax> c-default-style, I think
> I'm TRYING to use the java style, but I'm not sure.
<Amthrax> I'm pretty sure I do
<Amthrax> Though I'm also not entirely convinced
> I need to fight with my .emacs. But this isn't the time.
> Hmm. Upon further reflection (no, not that kind, though that might also be useful), it's probably not a table/tree race condition on the TreeModelEvent.
<aleung> eh, i've given up on real transparency
<Amthrax> It's that painful?
<aleung> so it's odd
<aleung> it'll find the "transparent" pixels from the image
<aleung> and then it feels the need to color them with some opaque color
<Amthrax> Oh
<Amthrax> Chroma-key style?
> It's opaque transparency!
<aleung> yes, i really don't understand why it can't just not fill the transparent pixels
<Amthrax> Out of curiosity, which drawImage method(s) did you use?
<aleung> i'm using the graphics one
<Amthrax> But which one?
<aleung> image, int, int, color?
<Amthrax> What are you passing for color?
<aleung> and imageobservor
<aleung> i think that one
<aleung> i tried (0, 0, 0, 0)
<aleung> (0,0,0,255)
<aleung> etc.
<Amthrax> Why not image,int,int,imageobserver
<aleung> there's an image int int imageobserver?
<Amthrax> Becuse image,int,int,color,imageobserver doesn't draw transparently
* Amthrax nods
<aleung> ah..
<aleung> well i'll be damned
<aleung> ugh
<Amthrax> Heh, you should have given up earlier.  ]:--8)
<aleung> yeah
<aleung> next time i will
<aleung> ah, nice
<aleung> back on track
> It's very hard to fight with property tables when people are trying to learn to play the trumpet next to you.
<Amthrax> I can imagine
<aleung> hah, i spent more than enough time wrestling with saving png-24s
<aleung> the mechanism is terrible in photoshop
> They're clubbing seals!
<Amthrax> Yeah, I think I can even hear it down here
<Amthrax> It's ugly ugliness!
* dan plays http://drkp.net/seals.mp3
> Ooh! It finally actually updates to the correct value.
* Amthrax applauds
> This is somehow progress. And yet it's still totally unusable.
> The solution was -- and I have absolutely no idea why this works -- to wrap fireTreeStructureChanged in an invokeLater.
<Amthrax> Oh.  Of course
> That only took me all day to debug.
> Now I think I'll work on making it possible to actually expand nodes in the tree.
<aleung> if you wanna see how frobbers look, try the drawertestapp
<aleung> ci'd
<aleung> arg
<aleung> one sec
<aleung> yeah, should be ci'd
<aleung> the menu normally doesn't have so much crap, i just packed it to test it
<aleung> i'll do editor side in a little bit
> Wow. That's cool. I have no idea what it is. But it's cool.
<Amthrax> Wow
<aleung> are the icons intelligible?
<aleung> had to make them kinda small so the frobber menu wasn't huge
<Amthrax> What are the two immediately to the left?
<aleung> velocity and size
> Size and velocity?
<Amthrax> Ah, okay
> (It took me a while to figure out)
<aleung> the size one is a bit iffy
<aleung> but i guess it won't be appearing much
<Amthrax> I think the velocity one would make sense if a ball were selected, though maybe add a standard double-headed arrow to the corner of the box in the size one?
<aleung> alright
<aleung> if you can think of any i missed, lemme know
<Amthrax> Would it be feasible to pack all eight into a single teir?
<Amthrax> *tier
<aleung> i can try it
<aleung> it's a very small change
<aleung> it'd be feasible except when it redistributes for corners
<Amthrax> Right
<Amthrax> It just seems like the second tier isn't necessary unless it's necessary
<aleung> yeah, eh, it's just for show at the moment
<aleung> i have the frobber menu initialize with only up to 5
<aleung> but you can add more manually
<Amthrax> Ah, okay
<aleung> if you wanna see 8 in one tier
<aleung> just set the max tier size in frobber menu
> Does it go into the next tier when it runs into a corner?
> (I looked through the code last night, but then I got scared by it.)
<aleung> yeah, it halves the capacity of the tiers at the corners
<aleung> i haven't retested it since i got all this stuff in, but it should still work fine
> cool.
<aleung> 8 in a tier looks pretty nice
<aleung> i guess the logical thing to do would be to shrink the capacity of tiers in proportion to how many quadrants are available
<aleung> but eh...
<Amthrax> It seems like that would be necessary in the corners of the gameboard
<Amthrax> (But, then again, I don't really understand what's going on)
<aleung> well, it does it for the corners
> Yeah, actually, that's not bad. Maybe a little crowded, but 8 frobbers is a lot for one gizmo.
<aleung> but the edges should be half capacity, the corners a quarter
<aleung> it's designed to fit one per 45 degrees
<aleung> anyway, there are never gonna be 8
<aleung> but the support is there
<Amthrax> Yeah.  It just seems like there will often be more than four
<Amthrax> But, anyways, very cool
<aleung> hmm
<aleung> alright, i'll add the better capacity model
<aleung> and while i'm at it, i'll test edges and corners
> Bobby agrees that they're really cool.
> (Even more so than The Incredible Machine!)
<aleung> mmm
<aleung> let's get this thing together...
<Amthrax> Darn, I sure could use amb for solving the interaction manager lattice problem
> You mean java doesn't have an amb class hidden away somewhere?
<aleung> we've officially transitioned to interactions?
<Amthrax> Eh, it probably does.  Along with its Continuation, Lambda, and Lazy classes
<Amthrax> We're working on it
<aleung> ooh, revised design
<Amthrax> Eyup
<aleung> i've tested every corner and edge
<Amthrax> It's surprisingly difficult for how simple it seems, but I'm working out the type algebra now
<aleung> and 3 tier support
<Amthrax> Ooh
<aleung> there's this odd staggering that happens on the second tier sometimes
<aleung> where the last frobber is too wide
<aleung> i'll ignore it for now
<aleung> it could also be the area being misdrawn
> It's amazing how dificult such simple things can be.
> We should have a help frobber!
<aleung> ah, i considered
<aleung> what would it do?
> Display help for each gizmo!
<Amthrax> Put up a dialog explaining the current gizmo and what its frobbers do?
> Gizmodoc!
<aleung> i also considered having a hide frobber frobber
> (I know nobody is actually going to write documentation for gizmos. But it's a cool design idea.)
<Amthrax> Heh.  That reminds me of Emacs' mode-line management mode.
<aleung> maybe as an extension
<Amthrax> Though, isn't "hide frobbers" basically equivalent to deselect?
<aleung> yeah... more or less
> But you could have a show-frobbers frobber.
<Amthrax> We could have a scholarly reference on the interaction manager.  After all, this exact inheretence problem is one of the reasons Hindley and Milner ditched subtyping (that and the fact that it's an unsolvable problem, but I'm not letting that get in my way)
> Let's build a bounded-time arbiter next.
> Damnit, that's why it wasn't expanding: I needed to make isCellEditable return true for the tree column.
> I figured that I probably ought to return false in isCellEditable, because, oh, it's not supposed to be editable.
> But it turns out that the way it finds out that the user clicked on the tree is by overriding isCellEditable in an editor which then returns false to indicate that it can't be edited, but not before passing the MouseEvent over to the JTree.
<Amthrax> Ah, yes, of course
> (I'm ignoring the fact that the JTree isn't actually a JTree, it happens to be some subclass of a JTree)
<aleung> ah, frobber menus now pop up on gizmo selection
<Amthrax> Oooh
<aleung> you can also click frobbers to highlight them
<aleung> have fun
<aleung> no real functionality yet though
<aleung> if it weren't for the angle class and drawImage...
<aleung> anyway, lemme know if you find any bugs
<Amthrax> Dang.  That looks impressive
> Now I can run a simulation, and watch the ball position and velocity get updated in realtime on the property table.
<aleung> indeed
<aleung> we have frobbers!
<aleung> at one point i thought it was a maniacal dream
> Except of course that 'realtime' is used loosely here.
<Amthrax> But now that dream has been realized.  ]:--8)
<aleung> yeah
<aleung> i gotta stop clicking stupid gizmos and go do something else
> We have found the reality that we call dreams?
<aleung> hmm, so square aren't orientable?
<Amthrax> Something like that
<Amthrax> Right
<Amthrax> Are we doing continuous orientation with snap?
<aleung> sure
<Amthrax> Alright, then I can make them orientable
<aleung> don't worry about it for now
<aleung> if i'm to test orienting, i'll just use tris
<aleung> or flippers
<Amthrax> Well, tell me when you're ready and I'll make the change
<Amthrax> Found a bug:
<aleung> yeah, there's a weird point where the clicking acts up, it seems
<Amthrax> Click on a gizmo to display frobber menu.  Click off gizmo to deselect.  Then try to click on a gizmo that was under the previously open frobber menu
<aleung> yup
<aleung> it seems not to defrob right yet
<aleung> the frobber is still there collecting the clicks
<aleung> i'll fix that shortly
<aleung> i'm still in disbelief
> I'm just about to try the frobbers myself.
<Amthrax> There appear to be a number of other instances where the frobber doesn't go away automatically when it should
> Like switching from edit mode to play mode.
<Amthrax> Actually that works for me...
> err, yeah, me too. What was I thinking of?
<Amthrax> Loading a new board while in edit mode
<aleung> ah, i ci'd a new one
> Oh, yeah, loading a board.
<aleung> yeah, those issues i haven't fixed yet
> Can we refer to frobbers as 'patent pending'?
> (The writing of a patent application is, after all, pending)
<aleung> so i've fixed frobber menu removal for loading and when switching to a build mode
<aleung> lemme know if there are others i'm missing
<aleung> time to make frobbers work
<Amthrax> Wheee
<aleung> i'll start with delete ^_~
<aleung> ah, a checkrep failed
<aleung>                  Assert.assertTrue(gizmos.contains(t.getTarget()));
<Amthrax> BTW, I'm leaving "collision" triggers for the moment
<aleung> do i have to manually pull triggers when i remove a gizmo?
> Uh, you shouldn't have to.
> (Did I really never test that?)
<aleung> seems there's a residue
<aleung> i'll ci and you can play with it
<aleung> ci'd
<aleung> removing flippers crashes
<aleung> same with absorber
> Yeah, I see the bug. Hold on.
<aleung> alright
> I think Chloe just decided on Robert Morris for her advisor, because I told her about the Morris Worm
> ci'd a fix (but haven't tested it)
> It just occurred to me that ther's more code in the property table than the GameBoard.
<aleung> ooh
<aleung> it's a concurrent mod exception
<aleung> java.util.ConcurrentModificationException
<aleung> 	at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
<aleung> 	at java.util.HashMap$KeyIterator.next(Unknown Source)
<aleung> 	at gizmoball.game.GameBoard.removeGizmo(GameBoard.java:602)
<aleung> happens for removing flippers
<aleung> ooh
<aleung> i filled an absorber with balls
<aleung> it seems to be the right number to get an out of memory
<aleung> eh, it was just a fluke
> Well, we're getting better exceptions now, right?
> (I know how to fix that one, hold on)
<aleung> is austin still alive?
> Yeah, he's eating dinner.
> (So am I, but I'm sufficiently ashamed of that last bug that I'm going to fix it first.)
<aleung> ah, cool
<aleung> i should probably eat sometime soon as well
> ci'd a new fix, maybe this one is correct.
> (I can't actually test it because of some of the property table stuff I'm running)
> It's black-hole testing!
<aleung> ah, validated
<aleung> ugh, jtogglebutton and buttongroup are some more great implementations
> heh. I opened up AbstractTrigger to Propertyify it, and right at the point is the comment '// TODO: make AbstractTrigger extend Propertyified?'
*** Value of INSERT_MODE set to OFF
*** Value of INSERT_MODE set to ON
> I wish ant didn't suck at detecting dependencies.
<aleung> ah, you can now unclick build modes
<aleung> which brings you back to selection mode
<Amthrax> Ah, good
<aleung> so you can delete what you made
<aleung> ugh, that togglebutton thing was ugly
<aleung> i'm tempted to pixmap the standard icons
<Amthrax> That's probably fine
<aleung> putting text to the buttons doesn't work well, unless the buttons are like half a screen wide
<aleung> but i did put a tooltip
<Amthrax> Oh
<Amthrax> What does it do?
<aleung> the tooltip just says what the gizmo is
<aleung> which is almost as good as giving the buttons labels
<Amthrax> No, I mean if you give it a label
<aleung> oh...
<aleung> either you set the button size and the text flows over
<aleung> or you make the buttons really wide
<Amthrax> Ah
> Now I have propertyified triggers, so I can actually load boards with triggers!
<Amthrax> Ooh
<aleung> ah, lemme make the SetPropertySubMode so we can mess around with the frobbers more
<Amthrax> The button tutorial makes it look like labels should Just Work.  Did you do something similar to what they did?
<aleung> lemme check what they did
<aleung> well, labels do work
<aleung> but the toolbar just becomes really wide
<Amthrax> Hmm.  Much wider than the labels?
<aleung> no, but the labels themselves are wide
<Amthrax> Oh
<aleung> they are named "SquareBumperGizmo"
<aleung> etc.
<aleung> even if i cut off the gizmo part
<Amthrax> Hmm.  It seemed to work in past terms...  Let me see if the one I'm thinking of did something weir
<aleung> yeah, there was one that had a wide toolbar
<aleung> actually, they all did
<Amthrax> Oh, right.  They tended to breviate all the way to ie "Square"
<aleung> or the labels are abbreviated
<aleung> which doesn't bode well with my general loading
<aleung> i mean, i can have it truncate off Gizmo and Bumper
<Amthrax> Though don't you have special drawers for each one anyways?  (soon to be pixmaps)
<aleung> eh, well, i can name the pixmaps relative to the class names and it's still kinda general?
<Amthrax> That's true
<aleung> anyway, i guess that'll be fixed later
<aleung> frobbers are more important
<Amthrax> Yes
<aleung> but i just wanted to get the unbuild thing in
<Amthrax> Yeah, that's pretty necessary
<aleung> we can practically build boards now
<aleung> minus some property setting and connection stuff
<aleung> btw, what's the name for the Keypress trigger property?
<aleung> and the other trigger property?
> What do you mean?
<aleung> do we have properties for the keypress triggers of a gizmo?
> You have IncomingTriggers, which contains both keypress and collision triggers
> (interaction triggers?)
<aleung> ah, alright
<Amthrax> Yeah, I've been pondering the name change
*** drkp (~dan@AMBULATORY-CLAM.MIT.EDU) has joined channel #6.170
<drkp> I really needed an IRC window in one of my emacs frames.
<Amthrax> ERC?
<drkp> zenirc
<Amthrax> Ah, that works too
<drkp> I'm actually (slowly) making progress on the PropertyTable. woohoo!
<Amthrax> And the new interaction system is almost done
<aleung> nice
<aleung> i've started the submode
<aleung> it'll be general enough to mean that the frobbers will all work when it's done
<drkp> I will pretend I know what a submode is and claim that that's excellent.
<drkp> Now the PropertyTable can deal with anything it finds. It won't throw exceptions on PolyGizmos anymore.
<drkp> (Not that it necessarily deals *well* with anything)
<aleung> how about a cloning frobber?
<Amthrax> Maybe, though the necessary ones need to be completed first
<drkp> lambda!
<aleung> yup
<Amthrax> All of the gizmos support the new system now.  Now to clean up all of the other places it's used...
<aleung> how are orientations set?
<aleung> do you just use their standards for angle?
> Oops. I just made the property table visible only in Play mode. Probably not the best of ideas.
<Amthrax> Did you figure out the orientation?
<aleung> i've not been trying
<aleung> so if you'd like to tell me, that'd be nice
> I think I'm ready to start unleashing the PropertyTable onto the cvs tree...
<Amthrax> If I understand what you're asking, yes, it uses their angle standards
> initial PropertyTable ci'd.
> !j
> We've each ci'd over 4000 lines of code. *shudder*
<Amthrax> Just in the current incarnation
> Right.
> And we've thrown some iterations away. (hey, does that mean we're using the spiral model?)
<aleung> is the build broken?
> I don't think so, is it supposed to be?
<aleung> ah, nevermind
<aleung> it's complaining about keyups in the saver or something
<Amthrax> I.. haven't touched the saver for a while
<aleung> ok
<aleung> hmm, is my building misnaming things?
> Oh...
<Amthrax> Dan and I poked around that a bit a while ago and it looked like it was
<aleung> yeah
<Amthrax> I haven't reexamined it since the saver was implemented
<aleung> i found it
<aleung> my bad
> I broke the saver, oops.
> I changed isKeyDownTrigger to getIsKeyDownTrigger to make the property system happy.
> Of course, ant didn't know about this dependency.
> Fix ci'd.
<Amthrax> AbstractTransitionalGizmo!
<aleung> ci'd the naming fix
<aleung> when are we scheduled to demo, btw?
<Amthrax> 6:30, IIRC
<aleung> alright
<aleung> eh, i'll be back in an hour
> 13 hours...
<aleung> if i'm not, give me a call or something
<aleung> or a knock
*** You have new email.
<Amthrax> Uh, has BoundingBox not been removed from AbstractGizmo yet?
> Apparently not.
> Now it has.
<Amthrax> Thanks
<Amthrax> Do the collidabilities of your scripted gizmo affect anything other than which of the two in a pair is collided?
> I don't think so. (What else would they affect?)
<Amthrax> Well, if you actually tested the collidability values at some point, but it looks like you don't
<Amthrax> And.. a carefully placed "abstract" modifier on a class with no abstract methods, and a {} after the new ScriptedGizmo(..) and voila!  We have subclasses.
> Oh. I don't explicitly test that, I figured that testing the simulator would be enough.
<Amthrax> I dare the staff to track down where those anonymous classes are.
> Heh. That's creative.
<Amthrax> They're anonymous!  Very, very anonymous
<Amthrax> There.  That wasn't so bad.  I haven't actually made sure it still works yet, but the recoding was easy
> I apologize for making you endure the horrors of GameBoardTest.
<Amthrax> Pfft, it's not that ba
<Amthrax> d
<Amthrax> And the interaction system can handle it, therefore the new system must be good!
> I suppose that reading it isn't so bad. Writing it certainly was.
<Amthrax> That I can imagine
<Amthrax> Dude.  Green bar
<Amthrax> Now to make the rest of the tests conform...
<Amthrax> I won't even need the @deprecated AbstractTransitionalGizmo
> What does that do?
<Amthrax> It was supposed to provide the old collision interfaces and translate them to the new system
<Amthrax> As automatically as possible
> That's what I thought. Not that I wanted to think about that.
<Amthrax> +487 -309
<Amthrax> New system ci'd
<Amthrax> Check that I didn't break the build
> Hold on, I'm breaking it in various creative ways myself.
<Amthrax> Okay
<Amthrax> Wow.  GameBoard's at v1.27
> It's an InteractionManager!
<Amthrax> Eyup
<Amthrax> Ugh.  I think I'm going to leave collision triggers for now
<Amthrax> And, uh, forever.
> Builds for me.
<Amthrax> Cool
<Amthrax> Heh.  130 lines in the GameBoard changed in the terminology switch
> Heh
> hey, you broke your own property system contract in GameBoard with the mus! Bad!
<Amthrax> Uh, I did?
> Yeah, they don't have firePropertyObservers calls in the setters
<Amthrax> Oops
* Amthrax lowers his snout in shame
> Not to worry, I've already fixed it.
> And if this works, I should be able to change the gravity and friction constants...
<Amthrax> Ooh, are you removing your listeners now?
> I wouldn't be so rude as to check it into the tree otherwise.
*** You have new email.
<Amthrax> Alright.  I declare the interaction system officially complete.
<Amthrax> I'm going to shower, then I'll either pass out or get to work on the design document
> Ooh, I can change gravity and friction now!
<Amthrax> Oooh
<Amthrax> Hmm.  So, according to what they said at the beginning of the term, how many bugs are we expected to have?
> I just ran just-some-balls with no gravity and high friction coefficients. The balls came to a complete stop.
<Amthrax> Excellent
> Now I'm running it with massive gravity and no friction.
> They plummeted. It was more fun than I would have thought.
> hmm. What's the appopriate thing to do if the user enters an invalid value? Beep and go back to the original value? Display a dialog? 
<Amthrax> Gah.  It's a bizarre feeling when you roll away from the terminal on your desktop, flip open your laptop which hasn't been touched for hours, and find the exact same terminal waiting there for you.
<Amthrax> Call them stupid
<Amthrax> Um.  Don't most forms just go back to the original value?
<Amthrax> An error dialog seems to heavyweight.  Perhaps something in the status bar?
> Yeah, I agree. I'm thinking beeping would be the appopriate thing to do.
> (How do I do that?)
<Amthrax> I.. have no idea
<Amthrax> But \exists a method to do it
> I'm sure.
<Amthrax> BTW, I just posted my notes from the last TA meeting to the blog
> cool.
> java.awt.Toolkit.getDefaultToolkit().beep(), apparently.
<Amthrax> Oh
<Amthrax> Isn't Bobby supposed to be waking up soon?
>         } catch (IllegalArgumentException e) {
>             // Gently remind the user that they did something
>             // wrong. In a non-accusatory way, of course.
>             Toolkit.getDefaultToolkit().beep();
>         } // end of try-catch
<Amthrax> Heh heh
<aleung> ah, a few moments to reorient
<aleung> hah ha!  success
<Amthrax> Success?!
<aleung> eh, not entirely
<Amthrax> Oh
<aleung> but frobbers will be done shortly
<aleung> hah
<aleung> i somehow managed to get it to be in frobber mode, set size mode and set position mode simultaneously
<Amthrax> That's interesting
<aleung> it's cool to watch the frobber menu drift
<aleung> anyway, i've tested handedness, orientation, position
<aleung> size is acting a little funny
<Amthrax> Cool
<aleung> and uh, the others need special things, so i'll get to those soon
<aleung> alright
<aleung> feel free to play with any of the previously mentioned frobbers
> So, uh, do we actually support GizmoballSelectionObservers?
<aleung> nope, not yet
<aleung> i'll throw that in in a sec
<aleung> ugh, there seems to be some weird behavior with set orientation with flippers for a certain handedness
<aleung> hmm, how shall we support gizmoballselectionobservers?
<aleung> would the table add itself as one for the editinginteractionmode?
> Uh. Actually, that was the question I was trying to answer myself.
> I guess we could do this without observers, in theory.
<aleung> maybe the gameboard component should have selectionobservers
> What I really need is something to call a method in PropertyTable to set the root to the selected object.
> which might be easier to do some other way.
<aleung> sure
<aleung> what's the method?
> PropertyTable.setRoot
> When nothing is selected it should be set to the GameBoard.
<aleung> ok
<aleung> ugh
<aleung> now i have to find your property table somehow
<aleung> this is complicated since interactions are usually only from interface components
<aleung> eh, just do it the observer way
> Yeah. It's breaking abstraction barriers left and right.
> uh, ok.
<Amthrax> Could the handedness frobber just toggle the handedness?
<aleung> yeah
<aleung> good idea
<aleung> what the hell was i thinking o.O
<aleung> addGizmoballSelectionObserver
> Could one, say, make the GameBoardComponent or interaction mode Propertyified and just use a PropertyObserver?
<aleung> probably
<aleung> let's not...
<Amthrax> Good answer
> Sorry. I had to suggest it.
> It's the abstract unity of the thing!
<aleung> alright, interaction modes support adding selection observers
<aleung> eh, it should definitely be in the gameboard component
<aleung> ugh
<aleung> alright, you add it to the gameboard component
> cool.
<aleung> lemme fix that handedness thing
<Amthrax> Flipper bounding areas now rotate with the flipper
<aleung> alright, handedness fixed
<aleung> btw, i've been getting these errors in eclipse for a while
<aleung> about Collidability
<aleung> ah, nevermind
<aleung> i forgot to change an outdated stub
<aleung> there's something in gameboardtest too
<Amthrax> I completely removed Collidability a while ago
<aleung> ok
<aleung> ci'd velocity frobber
<aleung> hmm, check on orientation for poly gizmos
<Amthrax> Yeah, it's weird, but there's no way around it that I can think of that doesn't break about 20 abstraction barries
<aleung> alright
<Amthrax> Of course, we could side-step the issue
<Amthrax> In fact, I'll do that right now.
* Amthrax side-steps the issue
<aleung> at one point i thought setting properties would be pretty
<aleung> cause type mapped to mode of setting
<aleung> which turns out not to be true at all
<aleung> what's the entry point for adding triggers?
<aleung> if i add to the gameboard will it add to the gizmos?
<aleung> (eh, this is somewhere in the specs, but i'm too lazy to check at the moment)
> Yeah, they're both the same.
> The gizmo actually passes it off to the gameboard
<aleung> oh, alright
<aleung> nice
<aleung> i have collision triggers
<Amthrax> Cool
<aleung> hmm, i should implement the keyboard stuff
<aleung> modes were suppose to have exits by pressing the escape key
<aleung> so you don't have to keep going back and clicking the stupid palette
<Amthrax> Polys should rotate sanely now
> Albert, are you commiting something?
<aleung> yeah, i just put in trigger frobbers
<aleung> is that a problem?
> For some reason you seem to have a lock in gizmoball/lib
<aleung> oh
<aleung> ugh
<aleung> i seem to have the jars floating around for some reason
<aleung> will they die if i ant clean?
<Amthrax> ant clean stays out of lib because those are provided libs
<aleung> should i delete them then?
> I don't think so. Is Eclipse trying to ci something right now?
<aleung> no
<aleung> but when i do ci, it tells me tablelayout and gizmoball aren't under cvs control
<aleung> which i assumed is a good thing
<Amthrax> That's because they're not
<Amthrax> I removed tablelayout and gizmoball is generated
<aleung> then there's no reason i should have a lock at all
> ok, I'm going to break it.
> angle properties ci'd.
<aleung> what's an angle property?
<aleung> oh...
<aleung> nevermind ^_^
<Amthrax> Finaler Design Document checked in
<Amthrax> I've already started making changed to it, including adding some of the new sections to the top-level
<Amthrax> I'll be back in a while
<aleung> ok
<aleung> i just about have keypress trigger frobbers
<aleung> i'm just wondering whether to do a confirm
<aleung> eh, no confirm
<aleung> damn, what to do about the keyup keydown thing
<aleung> eh, i'll have it add both by default
> Debugging regexes sucks.
<aleung> woo, keypresses supported
<aleung> alright, all the standard frobbers are working as expected
> cool.
<Amthrax> Ooh
<Amthrax> I think it would be good if the keypress frobber prompted the user for a key in some manner
> And code readability goes right out the window:
>             else if (property.getType() == Vect.class) {
>                 Pattern pattern = Pattern.compile
>                     ("^[\\s]*<[\\s]*([\\d.]*)[\\s]*,[\\s]*([\\d.]*)[\\s]*>[\\s]*$");
>                 Matcher matcher = pattern.matcher((String) value);
>                 if (!matcher.matches()) {
>                     throw new IllegalArgumentException
>                         ("Cannot parse vector string");
>                 } // end of if (!matcher.matches())
>                 double g1 = Double.parseDouble(matcher.group(1));
>                 double g2 = Double.parseDouble(matcher.group(2));
>                 setProperty(new Vect(g1,g2));
>             } // end of else if (property.getType() == Vect.class)
<aleung> eh
<aleung> i gave up code readability a long time ago
> We noticed. :)
<aleung> long as it works
<aleung> as far as even i'm concerned, it's a miracle
> ci'd vector editing support to the ptable
<Amthrax> Wow.  You need Python raw strings!
<aleung> ah, btw
<aleung> i might add stuff to the property table so that selected properties are editable in the component as well
<aleung> (makes velocity a bit easier for the user)
> ...good luck.
<aleung> ha, how about custom pixmapped treenoderenderers?
<aleung> i think our interactions system is currently even more efficient than our logging
<Amthrax> Ah, just found another bug: Load a file, let play for a moment so balls move, edit mode, select a ball, play mode, revert, edit mode
<Amthrax> (It might be possible in fewer steps)
<Amthrax> The jist being that the gizmo from the pre-reverted board is still selected and frobber menued
<aleung> ah
<aleung> yup
<Amthrax> Is is possible to just totally flush the editor state on load/revert?
<aleung> yeah, i was working on that
<aleung> ooh
<aleung> i had the flushing in a mode specific load method
> The property table has some similar issues.
<aleung> hah, the hack fix is to just always use the editing mode loader
> My solution is to toggle between edit and play modes and back.
> The editor is really quite amazingly cool.
<aleung> time for snap and building poly gizmos
> Don't forget displaying connection arrows.
<aleung> eh, i decided to ignore that for now
<aleung> it's not particularly impressive or useful
<aleung> ah, i might as well do it since it's not too hard
> Impressive? Maybe not. But it seems pretty important and useful...
<Amthrax> I have results from a user test!
<Amthrax> The rotate and move frobbers should work if you just drag them (instead of having to click and then move the mouse without the button pressed)
<Amthrax> And rotate and move should also be relative instead of absolute
<aleung> yup
<Amthrax> Uh, there are some more required things that should get done before poly building..
<aleung> eh, handling mouse presses in the frobber and then dispatching was annoying
<aleung> so i decided to hold off on that and just use a click click scheme
<aleung> which required things?
<aleung> btw, it's about time i hid the palette in play mode
<Amthrax> Like displaying the triggers
<aleung> that's required?
<Amthrax> Uh, more required than poly building?
<aleung> ok
<aleung> i'm on it right now
<Amthrax> Ruh roh
<aleung> ?
<Amthrax> DEBUG R2EditingInteractionMode: Starting probing
<Amthrax> java.lang.NullPointerException
<Amthrax>         at gizmoball.ui.r2.R2EditingInteractionMode$SetPropertySubMode.extractValue(R2EditingInteractionMode.java:492)
<Amthrax>         at gizmoball.ui.r2.R2EditingInteractionMode$SetPropertySubMode.updateModeArtifact(R2EditingInteractionMode.java:386)
<Amthrax>         at gizmoball.ui.r2.R2EditingInteractionMode$SubModeProbe.mouseClicked(R2EditingInteractionMode.java:941)
<aleung> what are you doing?
<Amthrax> I don't know.  Petra was playing with it
<aleung> hmm
<Amthrax> I'll try to reproduce it
<Amthrax> Double clicking something?
<aleung> hmm
<aleung> oh, when setting a property?
<aleung> lemme try it
*** Signoff: drkp (Write Error: Broken pipe)
<aleung> hmm, i'm not getting it
<Amthrax> Oh.  Select something, then click the move frobber, then click again without moving the mouse
<aleung> alright
<aleung> got it
<Amthrax> Oh, and editor collisions.  That was the other required thing...
<aleung> ok
<aleung> there's too much editing artifact madness
<aleung> trigger drawing almost done
<aleung> how's everyone doing?
<aleung> triggers are now displayed
<Amthrax> Other than the fact that everything appears far more colorful than it should in my current state of sleep deprivation.. decently
<aleung> mmm
<Amthrax> How're editor collisions coming?
<Amthrax> Hmm.  Are they supposed to interact correctly with the trigger direction checkboxes at the top?
<aleung> yeah, they are
<Amthrax> I had to toggle the "in" box to get the out connection to display..  then if I kept triggering it the arrow was getting thicker
<aleung> oh
<aleung> you have an old version
<Amthrax> Oh
<Amthrax> I have the one that's in cvs now...
<aleung> lemme put one in and see if it's better
<Amthrax> Oh, wait
<aleung> i spent a bit fixing all those issues
<aleung> so i'm pretty sure it's sound now
<Amthrax> NM
<Amthrax> I did have an old version, but in a weird way
<Amthrax> Though the arrows don't seem to point to the right place (they point near the target gizmo, but are off)
<aleung> yeah, that's intentional
<aleung> the arrows were getting too much into the frobber space
<aleung> which made it hard to see anything
<aleung> if you want them to go all the way,i can reset that
<aleung> there's this one issue with the interactions system
<aleung> if a ball gets stuck between a bumper and a wall, it seems to lock
<aleung> a flipper and a wall rather
<aleung> presumably cause it collides forever in the closed space
<aleung> of all the things not to have, an Area.intersects(Area)?
<aleung> there is area.intersect(area)
> And area.intersect is a mutator, naturally.
<aleung> anyway, unless one of you can dig up the magic method
<aleung> it'll have to be area vs. bounding box
<aleung> i don't much like editor collisions to begin with
> What do we need a magic method for?
<aleung> for determining whether two Areas intersect
> Are these bounding areas?
<aleung> yeah
<aleung> did we implement a magic method?
> Why yes, we did.
<aleung> ooh
<aleung> how nice
<aleung> ah, i won't actually use your method
<aleung> but i'll steal the idea
> I can't remember what it was, but it exists.
<aleung> i prefer to cache all the filled space in the gameboard as a single shape
<aleung> so it doesn't have to keep recalculating collision (or would it do it internally anyway?)
> Oh. That works.
<aleung> what's a primitive type void?
<aleung> ah, nevermind
<aleung> i never knew it was a primitive type, although that would make sense
<aleung> i've got editor collisions done, except for some indicator that what's being done is invalid
*** You have new email.
<aleung> does someone have a lock on the repository?
<aleung> the server's rejecting me
<Amthrax> *ping*
<Amthrax> Ack, my client was scrolled back
<aleung> ci'd editor collisions
<aleung> and the hiding toolbar
<aleung> i'll start on some doc stuff, i guess
<aleung> unless there are any requests
<aleung> eh, mind if i request a pdf of finaler?
<aleung> i'll be back in ten mins or so
<Amthrax> Hmm.  There are still a bunch of small things left (issues.txt), but it might be a good idea to do some doc stuff now
<aleung> shall i edit the issues file to reflect what's been handled?
<Amthrax> Sure
<aleung> what's "dealing with mouse off the board"?
<Amthrax> Oof, you know it can't be good when you look over the printout of the lecture slides from the lecture you were just in and you don't recognize half of them
<aleung> you were in a lecture?
<aleung> 004?
<aleung> right
<Amthrax> When you're editing something (say moving it) and you move the mouse off the board, it stops the edit
<aleung> should i turn that off?
<Amthrax> Oh, was that intentional?
<aleung> yeah
<aleung> there might be side effects of disabling it
<aleung> like stuff lingering when you switched modes
<Amthrax> Hmm
<Amthrax> Is the collision stuff ci'd?
<aleung> yeah
<aleung> should be
<aleung> lemme ci property setting snapping
<aleung> btw, you can clear the board, kinda
<aleung> revert will revert to a new board if you haven't loaded or saved
<Amthrax> Oh
<aleung> (yes, this is not the best mechanism, clearly)
<aleung> how's the treetable?
<Amthrax> It appears to be working
<aleung> are editor collisions working?
<Amthrax> Uh, sort of...
<Amthrax> If I try to place an overlapping gizmo, it jumps back to its original position, but that appears to be it
<aleung> yeah, that's basically it for now
<Amthrax> Ah, okay
<Amthrax> Dan says the property table is essentially done
<aleung> cool
<aleung> i'm jazzing up some of the interface stuff
<aleung> like overloading the save button to support save vs. save as, with overwrite confirmation
<aleung> there seems to be an issue with either saving or loading flipper orientation
<aleung> see gizmoman.xml
<Amthrax> gizmoman.xml?
<aleung> err, is it not there?
<Amthrax> in testfiles?  Nope
<aleung> alright
<aleung> lemme ci
<aleung> there'll be a flipper that's obviously misoriented
<aleung> try correcting it, and saving somewhere, then reloading
<aleung> and i think it goes back to being broken
* dan is here again.
<aleung> ah, nevermind
<aleung> it's not even possible anymore, with editor collisions
> Time to finish up PropertyTable.
<aleung> i guess move it out of the way, rotate it 180 degrees, save
<aleung> then reload it
<aleung> btw, i tested the afg bounding box stuff while doing editor collisions
<aleung> by having it actually draw them, they look alright
<Amthrax> Oops.  Sorry, looks like I'm geometrically challenged
<Amthrax> Fix ci'd
<aleung> how would relative angle work?
<aleung> relative to what?
<Amthrax> Relative to whatever angle the mouse started at
<Amthrax> ie, it wouldn't jump when you clicked the angle frobber
<aleung> oh, so it's differential
<Amthrax> But if you move the mouse 5 degrees from the starting point, the gizmo turns 5 degrees
<Amthrax> Yes
<aleung> sure
> DEBUG PrimitivePropertyPropertyTreeNode: The user screwed up and entered Ball3 which threw a java.lang.IllegalArgumentException
> http://www.cs.brandeis.edu/~dkw/C-humor/pasta.txt
> http://www.gnu.org/fun/jokes/pasta.code.html
<Amthrax> We should take out the undo button
<Amthrax> (Or undo putting in the undo button?)
<aleung> sure
<Amthrax> Speaking of which, how is what going?
<aleung> what sections do i need to write
<aleung> i'll redo the user manual
<aleung> and do something on editor design
<aleung> i got frobber dragging to work
<aleung> and i'm working on keypress stuff
<Amthrax> Yeah, update the UI stuff
<Amthrax> Ah, cool
<Amthrax> Oh, and the MDD needs to be tweaked a bit...
<aleung> alright, lemme know where?
<aleung> and i'll do the sub MDDs
<Amthrax> Yeah, I'll have to think about it for a moment
<Amthrax> Uh, so, PropertyTable should probably be an ethereal cloud
<aleung> hah
> Labeled 'here there be dragons', ideally.
<aleung> all the ui should be as well
<Amthrax> Yes.
<Amthrax> In fact, I think the MDD needs a general HBD label
<Amthrax> That would certainly make me happy  ]:--8)
> In a nice black-letter font.
<Amthrax> Everything below AbstractGizmo should be in the gizmoball.gizmos.standard package
> ci'd PropertyTable with selection observation
<Amthrax> Oh, and there should just be BallGizmo and AbstractFixedGizmo directly deriving from it.  Everything else comes from AFG
<Amthrax> I think that's it
<aleung> cool
<aleung> damn, these files are huge
> I'm calling the PropertyTable done for now, and moving to docs.
<Amthrax> Are the latest frobber menu features ci'd?
<aleung> yeah, just about
<aleung> gimme a sec
<aleung> what's a keyup trigger and what's a keydown?
<aleung> up = release?
<Amthrax> Yes
<Amthrax> I think
<aleung> eh, alright
<Amthrax> Unless your keyboard is upside-down
<aleung> alright, doc time
<aleung> i ci'd a keypress thing with a dialog in the component
<aleung> can you send me a pdf of the current state of the finaler?
<Amthrax> Sure
<Amthrax> Er..  Can you implement the big X and not jumping back to its original position on a placement collision?
<aleung> sure
<aleung> but it'll jump back if you try to place it
<aleung> lemme take care of some doc stuff first
<Amthrax> Okay
<Amthrax> Woah.  The key trigger thing is crazy
<Amthrax> Uh, shouldn't it default to true, true instead of false, false?
<aleung> good point
<aleung> i couldn't think of a particularly usable way to do it
> Something like, oh, a dialog?
<aleung> it's basically a dialog
<aleung> but we have to do all our stuff in-house
> I suppose you could say that...
<aleung> ci'd
<aleung> test it?
<Amthrax> It appears to work
<aleung> cool
<aleung> can we do something about the property table sizing if there's time?
> Sure. What do you want to do to it?
<aleung> just have it not resize so much, i guess
<aleung> fix the height at something reasonable
<Amthrax> It resizes?
<aleung> oh, maybe i was getting confused
<aleung> eh, we should fix the component size
<aleung> oh, btw, you can enable orientation for squares
<Amthrax> Er, yeah
<Amthrax> Done
<aleung> cool
<Amthrax> Would you like some aquified screenshots?  ]:--8)
<aleung> ooh
<aleung> i was thinking of just using my own, but that'd be nice
> Tell me what you want a screenshot of. Send me saved gameboards if you like.
<aleung> eh, just load example or something
<aleung> show a frobber menu, some connections
<aleung> that should be sufficient
<Amthrax> DEBUG R2EditingInteractionMode: Starting probing
<Amthrax> mouse pressed
<Amthrax> java.lang.IllegalArgumentException
<Amthrax>         at gizmoball.game.GameBoard.addGizmo(GameBoard.java:514)
<Amthrax>         at gizmoball.ui.r2.R2EditingInteractionMode$BuildSubMode.endingProbeSession(R2EditingInteractionMode.java:776)
<Amthrax> I just tried adding a ball to gizmoman
<aleung> hmm
> That means it tried to create a ball with a name that was not unique
<aleung> lemme look at it
> It enforces that now.
<aleung> oh, right
<aleung> ugh
<aleung> it's kinda hard to adjust the numbers to reflect what's on the board
<Amthrax> Just keep incrementing it and asking the board if one already exists?
<aleung> sure
<aleung> i'll catch the exception and loop it till it works?
<Amthrax> That
<Amthrax> 's.. one way to do it
<aleung> or is there a better way of finding what the gameboard has
<Amthrax> Not what I was thinking, but it works
<Amthrax> I was thinking just make a set of the names and work from that
<aleung> sure
<aleung> what's the accessor?
> getGizmos gives you the gizmos
<aleung> can i get the names?
> Not easily
<aleung> hmm
<aleung> ugh, i wish i had map
> Yes. So do I.
<aleung> so i can iterate through, add all the names to a set and then increment the name i'm using till it's not in the set
<aleung> fixed
<Amthrax> How's the MDD?
<aleung> eh, i'm writing my parts first
<aleung> i'll get to it shourtly
*** You have new email.
*** You have new email.
<Amthrax> Uh, how long'll it take you to get over here?
<aleung> h...
<aleung> i'll be there by 6:30
<aleung> ugh
<aleung> i'm still writing though
<aleung> when are we to submit the report?
<Amthrax> By the end of our demo
<aleung> ugh
<aleung> hmm
<aleung> well
<aleung> i'll complete this paragraph, ci and come over
<aleung> where are you guys?
<Amthrax> w20 1st floor
<Amthrax> By Alpine
<aleung> alright, i'll see you soon
<aleung> alright, i'm back
<Amthrax> WB
<Amthrax> How are the MDDs coming?
<aleung> eh, i'm still writing
<aleung> i can probably do graphics faster than i can write
<aleung> alright, i ci'd the editor design stuff
<Amthrax> Cool
> I guess I should probably take out the part about how we're going to implement a R3 renderer with Java3D if time permits.
*** You have new email.
<aleung> so what needs change in the mdd?
<aleung> the refactoring of gizmos and such
<aleung> how do these interaction handlers fit in?
> Austin has collapsed from exhaustion, let me revive him.
<aleung> ok
*** You have new email.
> He's not responding to poking.
<aleung> eh, don't worry about it
> I think I'm going to let him sleep, he needs it.
> I assume that the GameBoard and the gizmos depend on the InteractionManager
> oh, and I propertyified GameBoard and AbstractTrigger
<aleung> yeah, probably
<aleung> alright, i need like 10 more mins
> ok.
* Amthrax uncollapses
<Amthrax> How's the MDD?
<aleung> ah, so i have 3 small ones
<aleung> for ui, ui.r2, and game/standard gizmos
<aleung> and i'm making a big gutted one with a few interconnects
<aleung> with that, it should be good
<aleung> alright, propertytable cloud, and then i'll ci
<aleung> where you wanna stick all this stuff, i'm not sure
<aleung> i assume you can handle sizing?
<Amthrax> Yes
<aleung> about to ci
<aleung> you should probably have the full one in there too
<aleung> these are rather bare
<aleung> ci'd
<aleung> i think i'll redo gizmoman
<aleung> editor collisions suck
<aleung> ah, how do i get the schema fix?
<Amthrax> I ci'd that already
<Amthrax> It should Just Work
<Amthrax> (though you'll have to build again)
*** You have new email.
*** You have new email.
*** You have new email.
<aleung> the disturbing obsession with gizmoball that slowly set in now won't go away!
<aleung> i am very tempted to do poly building just for the heck of it
* Amthrax backs away slowly
<aleung> anyway, i figure it's about time i acquaint myself with the other parts of the system
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** You have new email.
*** X_ranger (~Harperjg@cpe-024-165-115-083.cinci.rr.com) has joined channel #6.170
*** X_ranger has left channel #6.170
*** X_ranger (~Harperjg@cpe-024-165-115-083.cinci.rr.com) has joined channel #6.170
*** X_ranger has left channel #6.170
*** X_ranger (~Harperjg@cpe-024-165-115-083.cinci.rr.com) has joined channel #6.170
<X_ranger> Anybody listening?
*** X_ranger has left channel #6.170
*** You have new email.
*** You have new email.
*** You have new email.
<Amthrax> Over and out
*** Signoff: Amthrax (Quit: leaving)
*** You have new email.
#6.170	dan       H   dan@clamshell.ambulatoryclam.net (0 Dan Ports)
#6.170	aleung    H   ~aleung@MACGREGOR-THREE-SIXTY-ONE.MIT.EDU (0 Albert Leung)
*** clamshell.ambulatoryclam.net #6.170 :End of /WHO list.
*** You have new email.
*** You have new email.
IRC log ended Mon May 17 15:45:03 2004