|
|
Plural sounding objects cannot be seen.
Issue Type: |
Status: |
Priority: |
Date Submitted: |
Votes: |
Bug |
Open |
Critical |
Thu 2nd Feb 2012 |
3 votes
 |
|
Found in version: |
Last Updated: |
Completed in version: |
Date Completed: |
Track Changes: |
5.0.22 |
Tue 15th Dec 2015 |
|
|
Log In |
|
adriftste | | Thu 2nd Feb 2012 13:46 |
Plural sounding objects cannot be seen in commands using %objects% (take) if there exists another object that has a name that is the singular of the plural: Some keys, a key
2 locations,
Location 1 (Starting Location) has dynamic object 'a set of skeleton keys' - name is 'keys'
Location 2 has dynamic object 'a rusty iron key' - name is 'key'
Take keys in Loc1 at start of game results in must have seen rusty iron key failure
Goto 2 then back to 1
Take keys results in 'You can't see the rusty iron key!'
Goto 2, take iron key, goto 1
Take keys gives 'You already have the rusty iron key!'
Take skeleton keys always works.
Commands with %object% work okay ... however:
Adding key as a synonym of keys allows take keys to work, but then, for example, push key will disambiguate if keys and key are in the same location. |
|
ElliotM | | Tue 15th Dec 2015 19:34 |
I attempted to replicate this bug in version 5.0.34.1 and was unable to get behavior I would call a bug.
If the 'keys' and the 'key' are not in the same location, there weren't restriction messages popping up that shouldn't have in the demo file I made to test this. If the 'keys' and the 'key' are in the same location, 'take keys' would grab both and 'drop keys' would drop both, and that seems correct to me. If I wanted to take or drop just the 'keys' object, I tried 'take skeleton keys' or 'drop skeleton keys' and both of those worked as expected, leaving the other 'key' where it was, either on the ground or in my inventory.
You mention that commands with %object% work okay, so that would seem to suggest standard library actions work just fine with either object. Were you writing general tasks with direct object references?
The pattern of the standard library, which Adrift 5 encourages, is to write generic general tasks for default cases and override them with specific tasks for special cases. In Adrift 5, most of the tasks we will be writing will be specific tasks. If you write a general task with an %object% reference and make a specific task overriding it, you can narrow the focus of the specific task to one object by clicking on the %object% reference in the specific task to choose a single object. |
|
ElliotM | | Tue 15th Dec 2015 20:14 |
This bug appears to be related: http://www.adrift.co/bug/2275 |
|
|