Orders to NPC to take and drop multiple objects not working #30
Comments
|
Problem first appears at 5675c83 (Fix Issue L61115 (Mantis 977)) Issue L61115 was "'multiheld' can match unholdable objects" |
…r_act(). Still code duplication in actor_act() to get rid of.
The first time we call self.actor_act(), some things must be done slightly differently in order to avoid problems when doing something to several items at once. For instance: TAKE ROCKS. See this function in 1d95759 to see how there used to be essentially two functions. The need for this distiction came about with Issue #30. So, if this is the first time calling actor_act(), pass true on the fifth parameter (ft).
Evidently my attempt to consolidate Roger's code back into actor_act() for #30 wasn't entirely successful.
|
broken again |
DavidGriffith
changed the title
|
This latest attempt fixes #34, but results in this: |
|
Here's a new test program, this time including Dyslexic Dan from DM4 Example 32 so I can check that part of the bug. For some reason, I decided to check the Glulx version. Curiously, Z-machine and Glulx perform differently. Doing GIRL, JUMP will at all times work correctly under Glulx. Doing GIRL, TAKE ROCKS will not. With Glulxe: |
|
Commentary from Vince at http://www.intfiction.org/forum/viewtopic.php?f=7&t=19868&start=40#p108515
|
|
After going over the DM4, Vince has a solution to the DROP ROCKS problem: I've finished looking into the DROP ROCKS issue. TL;DR: It's not a bug, it's a feature. Read on for the gory details, some actual bugs, and some thoughts on inform6lib development. What's the issue? When we run the test program for issue #30 (mantis http://inform7.com/mantis/view.php?id=1885) , we see: When all of the rocks are on the ground and we try to drop a single rock, parsing succeeds and we receive a response from the Drop action telling us that the rock is already here. When we try to drop multiple rocks, parsing fails and no action is generated. Instead, we receive an error message from the parser. When we order the girl to drop the rocks, this error is transformed into a NotUnderstood action, sent to the girl's orders, and redirected to her life, where it ultimately produces the suboptimal default response that we see. In this post, we'll focus on the simpler DROP ROCKS command with the player as the actor. What's causing it? At parser trace level 1, we can see the big picture: There are 3 grammar lines for DROP, and "drop rocks" fails to match any of them. Line 0 (* multiheld -> Drop) is one that we'd expect to match our input and the one that we'll focus on here. The grammar requires the word 'drop' followed by text matching a multiheld token. The DM4 describes multiheld as "one or more held objects", but, as we can see from our success parsing DROP ROCK, this isn't a hard and fast rule; the reality is a little more nuanced. If we crank up the trace level to 5, we can see more detail as the parser tries to parse "rocks" as a multiheld token: This trace is mostly produced by NounDomain and Adjudicate in parserm.h. The call chain that got us there is: The parser calls ParseToken__ to match a multiheld token (with input "rocks"), which calls NounDomain to find the best matching object or objects in the actor's scope. Notice that, when NounDomain is first called, we're "seeking definite object", but, by the beginning of Adjudicate, we're looking for all of an indefinite group of objects ("indefinite_type: plural, number wanted: all"). This happens because, when NounDomain calls SearchScope to find matching objects in the actor's scope, TryGivenObject finds that a rock matches the plural dictionary word 'rocks//p'. This causes the parser to switch into indefinite plural mode. We look for "all" (represented by 100) because no specific number has been requested (we didn't type DROP TWO ROCKS): In contrast, DROP ROCK does not trigger this code and remains in definite mode, accounting for the difference in results that we'll see. After NounDomain finds multiple objects that match "rocks" ("NounDomain made 4 matches"), it calls Adjudicate to score them and disambiguate among them. This process depends on the actor, action_to_be, the token that we're trying to match, whether we're in definite or indefinite mode, and the state of the world model at the time. It's described in some detail in §33 of the DM4 on pages 240-242, about which more below. During disambiguation, we reach a block of code specific to indefinite plural mode, and (spoiler) it rejects all four of our rocks! (For I7 people: this code is analogous to the deciding whether all includes activity.): The for loop iterates over all candidate objects and accepts or rejects each one in turn based on a series of tests. For DROP ROCKS, all of the rocks are rejected, resulting in a multiple object of size 0 which percolates up the parser and triggers a parse error. The specific test that rejects the rocks is " if (context == MULTIHELD_TOKEN or MULTIEXCEPT_TOKEN && parent(j) ~= actor)". So, that's what's happening. In indefinite plural mode, for a multiheld token, an object is rejected unless the actor is holding it, even when there are no other candidates. In definite mode, an object might be disfavored for multiheld because it's not held, but it's not rejected outright when there are no other candidates. This code raises a couple issues that I'll discuss later in this post.
Notice also that an author can provide a ChooseObjects function that can override the parser's decision (stored in flag). See DM4 §33 page 239. Is this behavior intended? Yes. It's mentioned in the DM4's explanation of disambiguation: (From DM4 Section 33 page 241 rule 7ip (indef plural)
Section (iii) makes it clear that this is intended behavior. For additional evidence, in issue 0001488, filed against I7 about a multiexcept issue, but stemming from the exact same line of code, GN says: (quote from Graham Nelson:)
(The I7 does the player mean rules are roughly analogous to ChooseObjects.) Ok. It's intended behavior. Why? So that this happens: instead of this: (Similarly for DROP ALL.) The idea behind the indef plural disambiguation is that we want to decide what should reasonably be included in "all" or a group of objects based on the context of the actor, the action, and the world. The particular rule that caused our issue says that, when an actor is performing an action that prefers held objects, those are the objects that the parser should choose preferentially. It only breaks down when there are no candidate objects that meet the criteria, as in DROP ROCKS when all rocks are on the ground. So what can we do? If we want the best of both worlds, we can write a ChooseObjects routine for our test program that will allow the parser to reject rocks on the ground when there are better candidates, while forcing it to accept rocks on the ground when there are none. (This also handles Take which suffers from a similar issue.) With this ChooseObjects in place, we get these results: Can we do more? We could change the parser to relax this rejection filter when there is an undifferentiated set of candidates while still using it to disambiguate among candidates with differing characteristics. However, it would take a bit of restructuring since the indef plural loop rejects candidates one at a time in decreasing BestGuess order. It's only later in Adjudicate that objects are grouped into equivalence classes. Also, it's not clear that everyone would agree that the behavior in the transcript above is desirable. To quote the DM4's introduction to ChooseObjects: (from DM4 Section 33 page 239)
My conclusion: use ChooseObjects. Here ends the discussion of DROP ROCKS. Next up are a couple of side issues, and then some thoughts about I6 library development moving forward. Back to David now: The side issues will be written up separately and the I6 library development concerns will be discussed at intfiction.org until someone decides to file an issue report about it if such a thing is necessary. |
Somehow the noun global variable gets set to "nothing" when an NPC is ordered to do something with multiple items.
Expected response:
Actual response:
The text was updated successfully, but these errors were encountered: