Default pre-5.0.22 adventures to HighestPriorityPassingTask - #15
Open
angstsmurf wants to merge 1 commit into
Open
Default pre-5.0.22 adventures to HighestPriorityPassingTask#15angstsmurf wants to merge 1 commit into
angstsmurf wants to merge 1 commit into
Conversation
clsAdventure.TaskExecution defaults to HighestPriorityTask, and Load500 only
ever overrides it when the file carries an explicit <TaskExecution> element.
But both that element and the HighestPriorityTask mode arrived in 5.0.22.
Adventures written before then never carry the element, and ran the v4
"highest priority passing task" logic -- the same logic the v4 .taf loader
still sets explicitly. Leaving them on the modern default can make them
unwinnable: a puzzle whose task is a lower priority passing task never fires
because a higher priority failing-with-output library task claims the turn.
Repro: Return to Camelot (Finn Rosenlov, IF Comp 2011), file version
5.000020. "unlock chain" hits the stock library "unlock %object%" task
("The heavy chain cannot be locked or unlocked"), so the armour-freeing task
never runs and the game cannot be completed.
When the element is absent and dFileVersion < 5.000022, fall back to
HighestPriorityPassingTask. Guarded with Not bLibrary so that loading an old
library file cannot clobber the setting of the adventure already loaded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Return to Camelot cannot be completed with the current ADRIFT runner (regardless of the reply to the Adventure Upgrade dialog at the start.)
UNLOCK CHAIN will produce the response "The heavy chain cannot be locked or unlocked" instead of the intended "The key fits perfectly in the lock, and within seconds the chain is unlocked."
(There is a similar problem in Death Shack, where OPEN DOOR outputs "You can't do that here!", making the game unwinnable.)
clsAdventure.TaskExecutiondefaults toHighestPriorityTask, andLoad500only ever overrides it when the adventure file carries an explicit<TaskExecution>element:However, the
<TaskExecution>element and theHighestPriorityTaskmode were both introduced in 5.0.22, so adventures authored before 5.0.22 never carry the element, and run the v4 "highest priority passing task" logic — the same logic the v4.tafloader still sets explicitly (FileIO.vb,.TaskExecution = clsAdventure.TaskExecutionEnum.HighestPriorityPassingTask). This makes these games unwinnable: puzzles whose task is a lower-priority passing task never fire, because a higher-priority failing-with-output library task claims the turn.Repro: Return to Camelot. The central
unlock chainpuzzle hits the stock libraryunlock %object%task → "The heavy chain cannot be locked or unlocked", so the armour-freeing task never runs and the game can't be completed.This was reproduced in ADRIFT Runner 5.0.36.6 on Windows 10, running Return to Camelot and Death Shack with the attached save files.
Fix
When
<TaskExecution>is absent and the file version is< 5.000022, fall back toHighestPriorityPassingTask.The
ElseIfis additionally guarded withNot bLibrary, following theTitle/Authoridiom a few lines above, so that loading an old library file in the Generator can't clobber the setting of the adventure that is already loaded.Validation
I can't build the WinForms solution here (macOS), so this was validated by applying the identical change to the FrankenDrift port of this source (awlck/frankendrift#69): Return to Camelot and Death Shack both then reach
*** You have won ***, with the full transcripts cross-checked byte-for-byte against a second, independent ADRIFT 5 interpreter (Scarier, which version-gates the same default). No other game in a ~110-game regression corpus changed behaviour.🤖 Generated with Claude Code (but edited by a human)
RtC.tas.zip
deathshack.tas.zip