Up to Main Index                           Up to Journal for October, 2019

                   JOURNAL FOR THURSDAY 10TH OCTOBER, 2019
______________________________________________________________________________

SUBJECT: TAKE command update and OPEN/CLOSE progress
   DATE: Thu 10 Oct 22:36:06 BST 2019

I’ve been working on WolfMUD again over the last week. Just a few hours here
and there, but it’s progress and things are moving forward again…

I’ve just pushed out some changes to the public dev branch. Main change is the
reimplementation of the TAKE command to use the new matcher code. I’ve also
updated the PUT, GET and DROP messages sent to actors and observers a little.

While working on the TAKE command I realised that using TheName() when
referring to items for the actor and just Name() when referring to items for
the observers improved the messages. For example:


      Actor: You get the ball.
             You drop the ball.
             You put the ball into the box.
             You take the ball out of the box.

  Observers: You see the actor get a ball.
             The actor drops a ball.
             You see the actor put something into a box.
             You see the actor take something out of a box.


Notice the actor’s messages use ‘the ball’ and ‘the box’ while the observer’s
messages use ‘a ball’ and ‘a box’. It’s only a minor thing, but I think it’s
an improvement.

The code for both TAKE and PUT commands is still very verbose. It works, I can
move on and revisit it later.

Next I’m working on the OPEN and CLOSE commands so that they use the matcher
and you can have commands like:


  >OPEN DOOR
  >OPEN RED DOOR
  >OPEN WEST DOOR
  >OPEN EAST DOOR
  >OPEN 1ST DOOR
  >OPEN 2ND DOOR


At the moment you cannot have multiple doors in the same location — there is
no way to specify a specific door. Doh! So this change would be a big
improvement.

For OPEN/CLOSE I wasn’t going to allow multiple doors to be specified, which
kind of trips up the matcher code a bit — or more precisely the interaction
with it. I did write something here about why it was tripping up the matcher
interaction. However, the explanation was a bit of a incomprehensible mess,
was then rewritten into another incomprehensible mess, and then deleted after
I had a different idea on how to solve the issue anyway. Maybe I’ll write
about my solution, if it pans out, next time.

One thing I do need to solve is the adding of automatic direction qualifiers
for doors. So if you have a door leading west from a location you can use
‘OPEN WEST DOOR’ and ‘OPEN EAST DOOR’ from the other side, with the ‘EAST’ and
‘WEST’ qualifiers being added based on the door’s exit. Not sure yet if the
door attribute should manipulate the aliases, override the alias attribute,
implement the alias interface itself or do something totally different to
accomplish that.

Actually the door attribute needs some work at it can also be used to create
other things that can be open and closed like boxes, jars and chests. Or maybe
I just need another attribute to cover containers that can be open and closed.

--
Diddymus


  Up to Main Index                           Up to Journal for October, 2019