Resets and repops

[Chris Gray]

[Adam W:]

[me]
:> Sounds similar to mine. I don't have a status line in the text window,
:> but the scenario could do that in the graphics window if desired. So,
:> there is no separation between the input line and the output area. This
:> makes is look quite natural when you hit RETURN, since your input line
:> is just inserted, prompt-included, into the output area. Do you use the
:
:Ugh.  I really dislike this, to be honest.  This is exactly how the
:split-screen mode in tintin works, and I've always avoided it.
:My feeling is that text that scrolls in the game-pane should read more
:less like a book.  We are very careful to re-route all 'system' messages
:(such as "Invalid command" or "You do not see that here") to the system
:message window (one line currently).  Also we have a thing called "newbie
:notes" - until the player manually toggles off the newbie flag on
:his account, he will get all sorts of little messages to help them along,
:ie wield -> "The 'wield' command is useless here - type 'help hands'."
:Then we make all game messages verbose in that you never type open door
:and just get the message 'Okay.' or 'It seems to be locked.'
:Instead your character actually walk up to the door and tries to open
:it.  Everyone in the room gets the message that you tried to open it,
:and if there are traps etc on the door they will be triggered.  (Assuming
:they are set for touch.)
:The result is that you get an unbroken flow of text that a third party
:could read and follow easily, and it's never broken up by messages like
:"You don't see that here", since they don't appear in that pane.

Hmm. I deliberately added the user's commands to my output window so that
I *could* see what caused the various things that appear. Don't you lose
the flow of control by having only selected things appear? Commands that
fail to do anything (not even showing other players that you tried) could
be deleted, but I can't easily do that since the failure is known only
in the server, and it is the client that copies the input command to the
output history.

My client lets you use the numeric keypad for command entry. The current
scenario uses it for simple movement. Also, the client supports on-screen
"buttons" that you can click on with the mouse, and you can also click
in the graphics to move relative to your cursor's current position. In
all of these cases, I deem it important to put the command into the output
history, so you can tell what the heck you were doing. I find that it
makes a fairly readable log of what you were doing. E.g. here is one:

	input> i
	You have 75 blutos.
	You are not carrying anything.
	>>> south
	You are in a small store.
	You can SHOP for supplies here.
	Obvious exits: north out
	input> shop
	For sale here:
	ballpoint pen - 1 bluto
	writing pad - 1 bluto
	universal carryall - 1000 blutos
	everlight lamp - 5000 blutos
	instant camera - 50 blutos
	>>> north
	You are in the mini mall.
	This is a small shopping area which
	collects together a number of useful
	services. The seven individual areas are
	distributed around the sides of the
	mall, and a passageway to the street is 
	to the east.
	Obvious exits: east out northeast north 
	  northwest west southwest south
	  southeast

I deliberately set the output width small to show things. The commands
that were entered via keypad/mouse are the ones prefixed by ">>> ". Before
I added that feature to the scenario, logs were often *very* confusing.

[readline]

I don't actually use 'readline' myself - I wrote stuff of my own that
exactly mimics the behaviour of the Amiga console windows. Then I added
the extra key combinations so that Gnu fans would be happy. :-)

:>     the current indent amount
:
:Not sure what you mean by this?

See the above log. The "Obvious exits:" code sets the indent amount before
running through and identifying the exits. This allows them to be
indented, thus easier to identify. Now that I look at it, I don't know
why I didn't do that for the 'For sale' stuff! [Scribbles note.]

:>     the current output prefix if any (I use this to distinguish output
:>	produced in some special way, e.g. from a remote viewer)
:
:Snooping, remote charmie control, etc I assume

Yep. Any nesting would have to be done programatically by the scenario.

:>     the current output width (defaults to the width of the client's
:>	text area, but can be changed by the scenario)
:
:Hmmm.	Changed by the scenario?  We have auto word-wrap based on the
:width the user specifies for their screen in the account configuration,
:but I'm not sure why this would ever change?

Well, I had to have a variable associated with each client in order to
format properly for them, and since I don't know the width for a text-only
client, I wanted a way for there to be a scenario command to change the
width. Having the resulting builtin return the old value was free, so
I did it. I had some vague idea of having some kind of special output
that was indented on both sides, like is done for quotations.

[telnet]

Nothing much there by default, huh? I guess I should forget about it
then. I just sort of assumed that your run-of-the mill 'telnet' program
would support the full set of telnet options!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA