Thanks, Kerm.
And while, yes, the key-input is a bit advanced, the display thing is actually much simpler than (and actually functional versus) most of the other examples of such given in this thread. One of the main points is that you have to take into account that the row & column count starting at 1 means that going {column+16*row} automatically puts position (1,1) at 17 in the string (rather than 1), so you'd have to subtract enough (16) so that position(1,1) gives you 1.
Perhaps I should explain the key-input code more rather than just dumping it here. First off, a statement such as {theKeyPress = someKey} is going to resolve to 1 (true) or 0 (false). Anding it with "is it in bounds?" causes it to be ignored if it is not in bounds. Roughly, the "(K=26 and X<16)" part is saying "did you press [right] AND can you move that way without going off the screen (i.e. the column is less than the max)?" If and only if both of those are true, you get 1; else you get 0. I did a similar thing with "(K=24 and X>1)" to get 1 if you pressed [left] and it's not already too far over to move left; only I SUBTRACTED it. Basically, the whole expression "X+1(K=26 and X<16)-1(K=24 and X>1)" says add to the column (1 if we are moving right, -1 if we are moving left); except you don't need the 1's in there.
Anyway, the change in column is stored in A, and the change in row is stored in B (rather than storing them back into X and Y) so that the statement below those can check to see if that spot on the map is even something you can move onto (hence, "IF" (that position in the string) is a " "; unless there are other things you can move onto), and "IF" it is allowed to move there, THEN it stores the new position to X and Y. You can do both at the same time because you can only have one key value given from GetKey anyway; so if anything is different, it will be either the row or column, but not both. If NO movement is made, then you are adding 0 and 0 anyway, so it's safe.
)*
