I’m fiddling around with Planner and Basic Plans by Nate Cull. I am able to successfully get NPCs to execute their plans in the correct sequence, even in multi-step actions, but there’s a problem: all NPC actions are invisible. I can’t see what they’re doing. When Planner is set to show the plans explicitly, I can see their planning; but the actual behavior is not displayed, even when I’m in the room. For instance, the butler enters and puts a tray of sandwiches on the table, but you don’t see him doing it. The valet goes upstairs, lights the fire, heats a bed-warmer, and warms the bed; but the only thing I see is a command disambiguation: “(Hill first taking the silver warming tray)” but the action following it does not appear. Even basic actions such as going do not report.
I have tried adding report blocks for "report someone ", "report an actor ", "report someone trying ", "report an actor trying ", “report Hill trying ,” but none of them appear on screen. What could be causing this?
Okay, I have solved the above problem; apparently I hadn’t upgraded to the version of Planner and Basic Plans that was on GitHub. However, there is something else happening: NPCs won’t drop things.
An excerpt of the code from Basic Plans, with a few lines inserted to show what is being executed:
[code]Planning-testing when the desired relation is being-in and the desired param1 is a portable thing and the desired param1 is not a person and the desired param2 is a room (this is the basic dropping objects in rooms rule):
plan 1;
say “Planning basic dropping: now suggesting being carried by:”;
suggest being-carried-by with the desired param1 and the planning actor;
say “Now suggesting being in the room:”;
suggest being-in with the planning actor and the desired param2;
say “Now suggesting dropping:”;
suggest doing-dropping with the desired param1;
say “Drop was suggested:”;
rule succeeds;
Doing-dropping is a planning-action.
Planning-acting when the planned action is doing-dropping (this is the basic executing dropping rule):
say “[the planning actor] is going to try dropping [the planned param1].”;
try the planning actor trying dropping the planned param1;
[/code]
When I run this, the output is as follows, with plans turned visible:
Planner: starting planning for Hill.
Planner: testing goal 1: Being-in silver warming pan Your Bedroom: Planning basic dropping: now suggesting being carried by:Now suggesting being in the room:Now suggesting dropping:Drop was suggested:true, no work to do
In other words, it successfully gets all the way through the basic dropping objects in rooms rule, printing every one of the debug lines; but it never prints the part where the actor even tries to drop the object. What could be preventing it?
I downloaded the extensions from github and tried the Alchemy example program included with Basic Plans. It required a tweak or two, because it was missing *: before its title (to allow easy cut and paste) and one of its assertions ended with a colon instead of a period.
After getting it working, I saw the following output (with debugging planning enabled):
I traced this down to the following code in Planner:
To have (A - a person) plan an action for (C - a planning-relation) with (P1 - an object) and (P2 - an object):
...
if goal C with P1 and P2 is true begin;
now the planned action is success-action;
if debugging planner, say "true, no work to do[line break]";
[say "after debug in if.";]
otherwise;
if debugging planner, say "false, generating plans [run paragraph on]";
clear the goal table;
choose row 1 in the Table of Goals;
now the Token entry is the requested relation;
now the Param1 entry is the requested param1;
now the Param2 entry is the requested param2;
now the Parent entry is 0;
now the Plan entry is 0;
now the Step entry is 0;
expand goal 1;
advance all goals;
end if;
...
Apparently, despite the indentation, the “otherwise” is being associated with “if debugging planner” rather than “if goal C” (a classic dangling else issue). If I uncomment the say statement before the otherwise, things begin to work. So, I rewrote this entire rule using the indentation-based syntax for conditionals:
To have (A - a person) plan an action for (C - a planning-relation) with (P1 - an object) and (P2 - an object):
if debugging planner, say "Planner: starting planning for [A].";
if debugging planner, say "Planner: testing goal 1: [C] [P1] [P2]: [run paragraph on]";
now the planning actor is A;
now the requested relation is C;
now the requested param1 is P1;
now the requested param2 is P2;
now the planned action is no-action;
now the planned param1 is no-object;
now the planned param2 is no-object;
if goal C with P1 and P2 is true:
now the planned action is success-action;
if debugging planner, say "true, no work to do[line break]";
otherwise:
if debugging planner, say "false, generating plans [run paragraph on]";
clear the goal table;
choose row 1 in the Table of Goals;
now the Token entry is the requested relation;
now the Param1 entry is the requested param1;
now the Param2 entry is the requested param2;
now the Parent entry is 0;
now the Plan entry is 0;
now the Step entry is 0;
expand goal 1;
advance all goals;
if debugging planner:
if the planned action is no-action, say "Planner: no action chosen";
otherwise say "Planner: choosing [the planned action] [the planned param1] [the planned param2]";
say "[paragraph break]";
execute the planned action;
Thanks for looking into this code. I’m not sure if this particular fix is the root of the problem, because it hasn’t cured the “NPCs won’t drop” problem. There must be something about the being-in property that is improperly firing, but I’m jiggered if I can figure out what it is.
When I take Alchemy and add a few lines to it, I would expect Bob the wizard to execute a “drop” as part of his plan, but he doesn’t:
A blob of farts is in the library.
Planning when the desired relation is being-in and the desired param1 is broth and the desired param2 is the crucible:
plan 1;
suggest being-in with the blob of farts and the laboratory;
suggest being-in with the onion and the crucible;
suggest being-in with the celery and the crucible;
suggest being-in with the banana and the crucible;
suggest being-in with the ginger and the crucible;
When Bob is going about his actions, he entirely ignores the first directive (moving the blob of farts to the laboratory) and carries on with the other items as if the first were already true. Somehow, the doing-dropping action never makes it to the to-do list.
The code in Basic Plans is incorrect. It should be:
Planning when the desired relation is being-in and the desired param1 is a portable thing and the desired param1 is not a person and the desired param2 is a room (this is the basic dropping objects in rooms rule):
plan 1;
suggest being-carried-by with the desired param1 and the planning actor;
suggest being-in with the planning actor and the desired param2;
suggest doing-dropping with the desired param1;
rule succeeds;
It was incorrectly defined as planning-testing — which meant that after suggesting all of the items on the list, it would automatically identify as “true” before anything had been done.