Can't say I'm knocking it out of the park, but I was uploading this note https://lispy-gopher-show.itch.io/lispmoo2/devlog/1480416/simple-handlerrestart-basis-for-lispmoo2-take-2 to ask @me for thoughts, but I guess you could venture thoughts too #commonLisp #programming #lambdaMOO #showerThoughts @dougmerritt
tl;dr

A macro that introduces player / feature objects as the sources of 'spatially local' handlers and restarts the same way lambdaMOO does.

A rock, that when it is in my inventory prints debugging information about actions and short-circuits evaluation.

Simple handler/restart basis for lispmoo2 take 2 - lispmoo2 by screwtape

L-USER> (let ((*this* nil) (*caller* 'screwlisp) (*player* nil)) (moo 'pet 'rock)) (:THIS NIL :CALLER SCREWLISP :PLAYER SCREWLISP :VERB PET :DOBJSTR "ROCK" :DOBJ ROCK :PREPSTR "NIL" :IOBJSTR "NIL" :IO...

itch.io

@screwlisp
I've never been a MOO expert, but it kind of sounds like you want to monitor all actions, which sounds like it might be hard.

I'm not sure about spatially local handlers.
@me

@dougmerritt
Off the top of my head, I do not know for what I might want to monitor all actions.

What I showed here is using a macro that dynamically generates the handler-bind from the moo's notion of visible objects (player, stuff in the player's inventory, the room the player is in, first object in the action, second object in the action)

but in the lisp repl. So the metaphor for adding debugging in my repl is picking up a debugging ROCK and placing it in my inventory before retrying
@me

@dougmerritt
This is what mooing is directly like. When you call a verb, your inventory gets searched for items that define that verb.
@me

@screwlisp
The rock idea is good, but it's not about how you turn on debugging:

On the Mud I frequented, the current room was also searched, which presumably is true of Moo, too, but there were hidden verbs, which the room's author did not want to get unhidden.

If the latter is also true of the Moo, then there *shouldn't* be a handler that screens all verbs before passing them on elsewhere.

That objection is moot if you only want to debug things in your inventory -- but rooms legit need debugging, too.
@me

@dougmerritt @screwlisp @me In moo there's a specific list of places it searches including the inventory and the current room (I forget the order, and I recall at one point wishing the process were more extensible)

@jeremy_list
I think according to ygm http://www.yibco.com/ygm/ it's player - inventory - room - dobj - iobj.

Something I didn't implement in the linked one is inheritance.

@dougmerritt @me

@screwlisp @dougmerritt @me Yeah, on second thoughts the thing I actually wished were more extensible was the list of places it searched for dobj and iobj (it's possible to redo that search once the verb has already been picked but for example in the case of open containers you still have to name the container)