Using variable in links

Hi all, newbie-ish author using Sugarcube 2 here.

I’m trying to use a variable to determine where a link goes, but it doesn’t seem to work.
For example:

A previous passage sets $endtag to one of three values, all of which are the names of passages: End1, End2, End3.

I’d like [[YOU DIED|$endtag]] to link to one of those passages depending on the variable. Instead, it creates a new passage called “$endtag”

Any suggestions?

This is simply a difference between the Twine editor and SugarCube. Story formats are welcome to add functionality, and SugarCube added the ability to include its variables within links.

This is non-standard, but SugarCube allows it, so assuming your code is correct, the action will still happen during run-time. You can safely delete that extra passage and any others the editor might create with SugarCube variable names.

That will work, however you’ll have to delete the “$endtag” passage first. That said, it will display in the Twine editor as a broken link, even if the code actually works just fine.

If you want to avoid the false “broken link” indicator, then just use the <<link>> macro instead. For example:

<<link "YOU DIED" $endtag>><</link>>

That will do the same thing as your code, but it won’t create an “$endtag” passage or cause a broken link indicator.

Have fun! :slight_smile:

That functionality is perfectly standard for SugarCube and predates Twine 2 by a large margin, so if you want to split hairs, it’s Twine 2 that’s being non-standard here. Beyond that, Twine 2 has long been supposed to receive an API to fix that particular regression—by allowing story formats to identify links—but to date has not, so the ball is doubly on Twine 2’s side of the court in this case.

1 Like

Since this seems important to you, @TheMadExile, I’d be happy to work with you to better document the different variations of the Twine link syntax as part of the Twine Specs project. That may be a way to bring greater pressure on the Twine 2 editor to conform to a more standardized approach to links.

I also know others in the community would appreciate having better documentation of functionality like this.

1 Like

@videlais I was addressing the implication that SugarCube was doing something odd in the specified case, rather than the issue being firmly in Twine 2’s court.

As far as documenting links goes. I’m not opposed to it, but I’m unsure that it’s going to accomplish much. Twine 2 is unlikely to add more core support for square bracketed link markup than it already has and that’s not really the issue here anyway.

Even in the event that Twine 2 offered the API I mentioned previously, the case that started the thread would still be a failure point because there’s likely no way to know the value of the variable, thus the passage name, within the editor. We’re talking run time versus compile time information. The best case scenario here would be for the (nonexistent) API to tell Twine 2 something like: this link’s passage name is only determined at run time, so either do not automatically create a passage or ask the author for its name.

1 Like