Resets and repops

[Adam Wiggins]

> [Chris G:]
> :> 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
> [Adam W:]
> :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

No, because the only things that appear there are 'actual' things, ie real
actions in the game.  Things that don't appear are things that don't
'happen', due to typos or whatever.  Thus you get a situation like this:

> get sword
You get a steel longsword.
> exa
It is a double-sided long blade, about four feet long, with a leather-bound
hilt.
> put sword chest
No such object is visible.
> put sword bga
No such object is visible.
> put sword bag
You put a steel longsword into a bag.

The text pane would look like this:

You get a steel longsword.
It's a double-sided long blade, about four feet long, with a leather-bound
hilt.
You put a steel longsword into a bag.

The history list would look like you expect it to - the 'no such object'
messages basically disappear into the ether unless you have an system
line larger than one line.

> 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.

Ah...well since we don't have a client it's a bit simpler :)

> 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.

*nod*...okay I see.  Looks good.  Our system is fundamentally different
for two reasons - one, no client/mouse/graphics of any sort to deal with,
and two, our adherance to 'realism'.  There are never any commands like
"shop" that give you a list of what's for sale.  Instead you just walk into
a shop, there are things on the shelves which you can pick up and check out.
Usually the shopkeeper will approach you and try to sell you items which
you are examining, and you can then barter with him (multiple coinage types
which have fluctuating values according to the local economy and limited
item-barter make this pretty interesting).  'Stealing' from a shop consists
simply of either smuggling something into your bag without the shopkeeper
noticing, or sneaking out the door without attracting attention.
Although there's no reason he wouldn't realize what happened, later,
making it unwise for you to return to that shop, and in fact, that town...

> :>     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.]

Ah, okay, gotcha.  We're lazier than that, just hardcode it.  Ie you've
got a string for the room desc you want to output that needs to be indented
two spaces...we just output two spaces and then the desc.  Of course
we use this in so few places that it's not really necessary for us to
bother with anything else.

> :>     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.

Ah, I see.  Nice idea, actually...

> [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!

*thinks hard* As I recall from when I was fooling around with writing a
'normal' text mud client, telnet is just a byte stream with ocassional
telnet codes which do something, although I'm not sure what.  It's a 0xff
character followed by two bytes of code data; all I did was ignore it.
As I recall very few of these are defined for stock telnet anyhow, I think
it was designed to be some sort of expansion thing which never got used,
or at least by anything interesting.