Idea for message grouping:

Actions are executed implicitly (no "default messages"), and then
registered in a stack of actions.

Each message_generator object (defined by the system or
customized/defined by the user) is passed this stack (by the
message_handler), and returns the number of actions it can report. The
one which returns the highest number wins. (This way, the more
sophisticated message_generators override the less sophisticated ones
where possible.) That message_generator is then instructed to generate a
message for that group of actions. The group of actions reported are
removed from the stack, and the process repeats. 

to do:

 * add LockIn verb, for handling: >bob, lock ball in box

 * add verbose option for rFind (returns *path* as well as action).

 * add a "exclude plan" option, to disallow certain plans to be
   considered by rFind in any given case.

 * either or both of the former two would solve our current trouble
   with "goto". (which currently moves the player towards a key,
   rather than towards a locked door.)

 * some generic intelligence for light sources (ie, don't enter a dark
   room until it's lighted)

 * fix rPress i.e., press a button. How to check rTrue? Set a flag to
   nil, until the action phase is called, which sets it to true?

 * A demo game with one NPC with one top-level goal and the
   player's job is to try to stop them.

 * beliefs. ("knowledge" = of existence; "belief" = of current states.)

 * link knowledge and belief to planbase; i.e., provide an additional
   knowledge-oriented planbase.

 * test all connectors, not just rooms, doors, and stairways

 * exploration plan: when no plan is found because knowledge is limited,
   build on current knowledge by exploring. this could include ask about.

 * a RAP/actor interface, for tracking frustration, obstacles, plan-path,
   registering other plans for later processing, etc.

 * multiple plan consideration: set lower-priority plans, or cache
   plans. Simultaneous plan pursuit is probably impossible, though.

 * consider abstract handler objects as RAPPERS, not only NPC actors.

-------------
http://lists.v-space.org/archive/tads3/200309/threads.html

for belief/knowledge discussion.

=============================================

New idea: instead of rAction executing a nested action, return
a verb and the (a,p) to the interface, so pre and post-execution
routines can go through the same interface easily.

=====

To speed up processing where the parameter is a class/list/vector:

write a specifyParam() method in the Rapper object, and a
resetParam() also. when a Rapper finds a target, it specifies the
parameter to that object in particular. if the processor in the future
fails to find that parameter, the processor calls resetParam(), and
reititializes its process.

e.g., if a combatant is attacked, specifyParam(target). if the RAP
processor fails to find the target, resetParam(old_param) or so. and
then the same RAP process goes again.