[rfk-dev] bugs

[Peter A. H. Peterson]

Quoting Tim Allen:
> I'm happy for there to be just one quit key mentioned in the
> documentation, but I don't see why we couldn't acknowledge other obvious
> attempts to quit (supporting multi-character sequences like ":q" or C-x
> C-c is probably too much effort for too little payoff).

We could. I don't have a strong opinion about this.

> > 2. I don't like how "In Glorious Color" stays in the status line
> > until you touch the first NKI. It kind of breaks the spell for me,
> > because it's not status -- but there it is, masquerading as one! 
> 
> It feels like this is the sort of message that should go on the
> title-screen, or on the top line beside the version and NKI count,
> rather than as a status message.

Yeah, although while it somewhat amusing, I don't know that it is
necessary -- especially if we put NKI messages back into Medicore
Black & White. The playfield has always (?) been in color.

This could make for a few funny NKI, perhaps:

robotfindskitten -- in Glorious Colour!
robotfindskitten -- in stereo where available!
A poster for robotfindskitten: the film! starring robot, introducing kitten.

> > 3. I'm actually not sure how I feel about having the NKI messages in
> > color -- I'm not sure it's a UI enhancement. Some colors are great for
> > NKI color variety but I find a little harder to read. And I find the
> > color changes to be a little distracting a la #2 above.
> 
> I like that it obviously relates the message to the NKI you just
> touched, but it's inconsistent: while the NKIs have a random colour, and
> are randomly bold-or-not, the messages seem to always be displayed
> not-bold. On some terminals, this makes the messages display in
> a markedly different colour to the associated NKI (hello, classic VGA
> palette).

Agreed. My vote is (tentatively) to go back to B&W as a default,
although I am not opposed to adding command-line switches for
behaviors like this.

> > 4. I'm not sure that I like the bounded playfield. It uses up
> > real-estate and is a UI change that I'm not sure anyone was asking
> > for. On the other hand, it does imply a certain boundedness to the zen
> > plane, which I can appreciate in that it lends clarity to the
> > representation...
> 
> The RFK implementation I created, the J2ME one, has a border because my
> phone's screen was too small to depict a complete playfield; I needed to
> scroll the playfield, therefore I needed to draw where the boundary was
> to make it obvious how far robot could actually move. 

Sure. Those kind of choices are necessary for some ports (I think
OpenGL has a walled in "game grid").

> Which is to say, I have no problem at all with the idea of a frame being
> drawn around the playfield.

I'm warming to it but still would like to hear opinions from others.

It also occurs to me that the field border could also be a run-time
option (Although since it is currently a macro that would imply some
code changes to make it dynamic). So I guess the question in my mind
is more about default behavior.

> > and implies that field won't resize given a larger window.
> 
> Turns out, this isn't actually the case: if you resize the terminal
> larger than the original size, the border gets drawn around the new,
> larger size, even though the NKIs are all clustered within the original
> boundaries, and even though robot can't venture into the new space (he
> gets stuck at the old edge).

Ah ha. Also, it seems like the field only resizes downward, and does
not expand horizontally. (BUGS)

> One other minor thing I noticed while figuring out how the
> bold-attribute worked in the new codebase: one of Eric's changes was to
> change the way EMACS keybindings were represented in the source, from
> "char literal minus 64" to defining an actual CTRL() macro. This is
> great, but the old comment ("Subtracting 64 makes it a control command")
> is still present.

Ok. We'll need to fix that.

-- 
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles