Create your own Interactive Fiction

ADRIFT - Interactive Fiction  
Home   |   News ADRIFT News RSS   |   Screenshots   |   Download   |   Games ADRIFT Reviews RSS   |   Forum   |   Help   |   Links
Welcome Guest Register | Login
Popular Games
Skybreak v. 1.4
The Fortress of Fear
The Lost Children
Skybreak v 1.2
The PK Girl
the virtual human
The Euripides Enigma
Magnetic Moon
Lost Coastlines
Starship Quest
 
Latest Forum Posts
The Book of Jax - The Adventures of Alaric Blackmoon # 10
HAPPY BIRTHDAY DazaKiwi
HAPPY BIRTHDAY ralphmerridew
An' anuvver fing....
Why don't my folders stay where I put them?
Results of The 2023 IFDB Awards are in!
Setting nickname / displaying unique text based on character name
Some excellent loot
ADRIFT 5's rendering API?
Getting Adrift 4 to ignore "and"
 
Latest Reviews
Classic Adventure
Private Eye
Roozden's Color Code Module
Wumpus Hunt
Lost Coastlines
The Lost Labyrinth of Lazaitch
October 31st (Post comp.)
The Euripides Enigma
AI
Hint System Library - Release 1

Make a donation

Cursor  Fails to prompt for ambiguity if lower priority task exists

Issue Type: Status: Priority: Date Submitted: Votes:
Bug Open Critical Sun 6th Apr 2014 5 votes Vote Up Vote Down
 
Found in version: Last Updated: Completed in version: Date Completed: Track Changes:
5.0.31.4 Tue 31st Jan 2023 Log In
 
saabieSun 6th Apr 2014 09:02
In the following ADRIFT debugger output, it can be seen that the first task passes all restrictions for two objects and decides to prompt for ambiguity.
But instead of doing so it tries to run a lower priority matching task which then fails with restriction output.
ADRIFT prints the failure message from the low priority task instead of giving the prompt for ambiguity for the high priority task that passed twice!

Task 'Examine objects (saa)' matches input.
Checking scope: Applicable
Referenced Object must exist: Passed
Referenced Object must have been seen by the Player character: Passed
Referenced Object must be visible to the Player character: Passed
Referenced Object must exist: Passed
Referenced Object must have been seen by the Player character: Passed
Referenced Object must be visible to the Player character: Passed
Checking scope: Visible
Checking scope: Seen
Multiple matches. Prompt for ambiguity.
Task 'Examine objects' matches input.
Checking scope: Applicable
Referenced Object must exist: Passed
Referenced Object must have been seen by the Player character: Passed
Referenced Object must be visible to the Player character: Passed
Referenced Object must exist: Passed
Referenced Object must have been seen by the Player character: Passed
Referenced Object must be visible to the Player character: Passed
Checking scope: Visible
Checking scope: Seen
Multiple matches. Prompt for ambiguity.
Task 'examine un-implimented object' matches input.
Checking scope: Applicable
instr(%s_NoDesc%,%text%&" ")>0: Failed
Checking scope: Visible
Command matches without ambiguity.
instr(%s_NoDesc%,%text%&" ")>0: Failed
Task doesn't pass restrictions, but is current highest priority failing task with restriction output.
Task priority: 600184
Attempting to execute task examine un-implimented object...
Checking single reference task [x/examine/look at] pockets
instr(%s_NoDesc%,%text%&" ")>0: Failed
Failed Restrictions
%CharacterName% can't see anything called "%text%" here.

First Reference: (no output)
 
ElliotMTue 15th Dec 2015 22:47
I tried to recreate this using the debugger output but I either don't have enough information to do so or it has been fixed along the way to version 5.0.34.1. At any rate, I found that the highest priority task always displays its output in 5.0.34.1., even if there was ambiguity to resolve. Steps I took to implement the test and the commands I used are below the line.

------------------------------------------------------------------------
Setup
------------------------------------------------------------------------
Task 'examine object' from the standard library takes the following syntax
Syntax: [examine/exam/ex/x/look {at/in{side}/under}] %object%

Task 'Examine objects (saa)'
Syntax: [examine/exam/ex/x/look {at/in{side}/under}] %objects%
Referenced Objects must exist.
Referenced Objects must have been seen by the Player character.
Referenced Objects must be visible to the Player character.
Message: Examine objects (saa): %objects%

Task 'examine un-implemented object'
Syntax: [examine/exam/ex/x/look {at/in{side}/under}] %objects%
Referenced Objects must exist.
Referenced Objects must have been seen by the Player character.
Referenced Objects must be visible to the Player character.
instr(%objects%.Description,"abc") > 0
Message: Examine unimplemented objects: %objects%

Wasn't sure what you were using instr() for, but because it failed to pass in your example, I just mocked up a similar restriction based on it for examine un-implemented that was designed to fail: 'instr(%objects%.Description,"abc") > 0'. Neither object I used in testing had anything in their descriptions, so searching for string 'abc' is guaranteed to not pass.

Object named 'a dynamic test'
Object named 'a static test'

------------------------------------------------------------------------
Test Case 1
------------------------------------------------------------------------
Enter the command: 'examine test and test' and the debugger shows that two tasks match the input. Ambiguity was recognized when the Runner evaluated each task that matched, but ambiguity was only prompted once, essentially discarding one of the objects when ambiguity for the first object was resolved. The task message that printed came from task 'Examine objects (saa)', the task with the highest priority.

Task 'Examine objects (saa)' matches input.
Checking scope: Applicable
Checking scope: Visible
Checking scope: Seen
Multiple matches. Prompt for ambiguity.

Task 'examine un-implemented object' matches input.
Checking scope: Applicable
Checking scope: Visible
Checking scope: Seen
Multiple matches, but we already have an ambiguity.

------------------------------------------------------------------------
Test Case 2
------------------------------------------------------------------------
Enter the command: 'examine test' and the debugger shows that three tasks match the input (the library task has the lowest priority and shows up last. It's syntax accepts only one object, which is why it didn't show when multiple objects were in the player command input. Ambiguity is again recognized when each task was evaluated. Once resolved, the task with the highest priority printed its output, which was again task 'Examine objects (saa)'.

Task 'Examine objects (saa)' matches input.
Checking scope: Applicable
Checking scope: Visible
Checking scope: Seen
Multiple matches. Prompt for ambiguity.

Task 'examine un-implemented object' matches input.
Checking scope: Applicable
Checking scope: Visible
Checking scope: Seen
Multiple matches, but we already have an ambiguity.

Task 'Examine objects' matches input.
Checking scope: Applicable
Checking scope: Visible
Checking scope: Seen
Multiple matches, but we already have an ambiguity.
 
saabieMon 14th Mar 2016 05:12
The important point here is that the first 2 tasks pass but have an ambiguity, but the third task does NOT have an ambiguity because it uses a %text% reference instead of an %object% reference.

ADRIFT seems to have an (undocumented) rule that if it finds an ambiguity it will continue checking tasks to look for one that does NOT have an ambiguity and it will run that instead.

The problem is that it runs that task even when it FAILS RESTRICTIONS.
It should have been rejected at the "Checking scope: Applicable" phase (because it had already found tasks that passed this phase) and ADRIFT should continue checking lower priority tasks.
When it does not find another task it should run the first task that passed the highest scope level.
The first task passed the Applicable/Visible/Seen scopes and had the "Multiple matches. Prompt for ambiguity." state, so it should be the one which is run.

ALSO: If you have ambigous objects and every object fails restrictions on the first task, but some pass the second task, then ADRIFT only lists the objects that passed the second task in the ambiguity message.
But after choosing one ADRIFT runs the first task which failed scope.
Even if you select the "execute highest priority task passing restriction" option, the debugger says it is going to check lower priority tasks but it doesn't.

ADRIFT has avoiding ambiguity as it's highest priority, but that means that it ignores the two objects in the room with you and assumes you are talking about a completely inappropriate object that is nowhere near you.
Objects that are applicable should always have precedence over objects that are not, and a lower priority non-ambiguous task should only be chosen over an ambiguous task if it has the same or better scope.
 
DenkTue 31st Jan 2023 09:49
Not sure in this specific case but: IT MAY BE DANGEROUS TO FIX THIS AS IT MAY CAUSE EXISTING GAMES TO MISBEHAVE(?). I think we should at some point "lock" how Adrift works to avoid backwards compatibility with earlier Adrift 5 games.
© 2013 Campbell Wild. All rights reserved. | Contact the Webmaster