Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variables set as a result of a custom handled command in ink can be skipped over #858

Open
tomkail opened this issue Aug 3, 2023 · 0 comments

Comments

@tomkail
Copy link
Collaborator

tomkail commented Aug 3, 2023

Hi! We're Continuing() over ink line by line, and using a custom instruction format (>>> MyInstruction). We've hit a fun little bug that we'd like some guidance on.

Here's a minimal repro of the bug. The "SetVariable" command is something else in reality but ultimately that's what it does.

VAR coachingAdvice = ""

>>> SetVariable (variableName=coachingAdvice) (valueToSet="Blah")
{coachingAdvice}

+ [Choice]
    -> Home

Here's what should happen:

  1. When we first Continue(), the line starting >>> SetVariable is printed.
  2. We then parse the SetVariable instruction in our app code, which sets coachingAdvice to Blah.
  3. When we Continue() again, Blah should be printed.
  4. A further Continue() should then show the choice.

However, when we run this in engine, Blah is not printed. The line {coachingAdvice} is entirely skipped.

The reason for this is that the canContinue flag is set false at the end of the Continue() function in step 1, because ink looks at the next line and determines that it's empty and can be skipped - even though it's set immediately afterwards.

You can "fix" this issue by adding some content anywhere between the >>> SetVariable line and the choice; but it's not something we want and it's tripping up our writers when they encounter it.
It's something of an edge case, but the use of instructions that might affect the ink is pretty typical and I thought it might be a good one to raise.

I can't see any great solutions though! One to consider is just not skipping empty lines - many ink devs are already in the habit of trimming any strings that come from ink and discarding empty ones - but making that problem worse doesn't appeal to me much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant