i guess there's a reason the back macro was deprecated

jaderade

It behaves reaaaaaally weirdly, especially with the hasVisited() function in sugarcube. I was trying to find ways to cut down on typing & simplify stuff, so I figured I'd make a <<back>> widget when lo-and-behold, I wasn't allowed to overwrite one that already existed. So I just used what they gave me.

But then I started to run into a ton of trouble with another widget I have that needs to check whether a given passage (one the user is coming back from, usually) has been visited. But I guess the <<back>> macro was not only returning me to the previous passage, but also uhm, erasing whether I had visited the room, I was backing out of, or not?

I know that <<back>> was deprecated in favor of previous(), so I take it that explains why I've been able to find so little documentation about it; but I'm really curious about what was happening under the hood there. Is that an intentional design of the macro, or does it just conflict weirdly with hasVisited() ?

If anyone has some insight on this, I'm really curious and would love to hear explanations.

(in my case, basically I have a widget that lets the player check a description passage via a link, and when that passage sends them back, the link is rendered inert, so they can't revisit the description passage. obviously that's pretty dependent on hasVisited() working properly, which, when I was trying out <<back>>, it definitely wasn't working properly)

TheMadExile

The <<back>> macro has not been deprecated, in favor of anything. I'm unsure how you got the idea that it was. Story formats have become far more stateful than they used to be, so it is probably used far less now than it was in the past—that much is certainly true.

You're running into trouble with hasVisited() function because of the way <<back>> functions—both are actually working properly. The <<back>> macro, essentially, does the same thing as the Backward button within the history controls (top of the UI bar) and the Engine.backward() static method. It undoes the current moment—i.e. it rewinds the history by one moment. So, obviously, if you're undoing large sections of the history by using <<back>>, then hasVisited() cannot find what does not exist.

Here's where previous() comes in. If you want these moments to remain within the history, you should be using either the <<return>> macro or the previous() function within a link—e.g. previous()—as they will both forward the player to the previous passage—i.e. they create new history, rather than undoing existing history.

Makes sense?

jaderade

Oh, gosh, i definitely misread it, but I got the deprecation impression from here, at the bottom of the page. The fact that <<back>> didn't have it's own wiki page and the way it was described got me, but I should have checked the sugarcube documentation because it says a lot more here!

Thanks for talking at more length about how each works, and sort of what they're related to. It made a lot of what was happening much clearer.

TheMadExile

jaderade wrote: »

Oh, gosh, i definitely misread it, but I got the deprecation impression from here, at the bottom of the page.

Ah. I see what you mean. That wording is quite unfortunate isn't it—for <<back>>, <<return>>, and <<silently>>.

It's also incorrect, if taken literally—particularly for <<back>> and <<silently>>. If you actually do want to undo the history, and there are certainly times you might*, then using previous() in a link is absolutely no replacement for <<back>>. Similarly, if you need suppress the output of a chunk of markup, then <<nobr>> is absolutely no replacement for <<silently>>. Using supplant alone was a poor choice there, IMO.

* For example. Let's say you have a dead end passage which exists solely as an optional bit of fluff for the player to add to the depth of your world. It doesn't modify any variables, it's never going to be checked with any of the vistied family of functions, it is essentially stateless. In that case, it's better to back the player out of the passage, so that it's not kept within the history. The player gets to see the fluff and the history is kept clean.

jaderade

Ah! Yeah, that's much more useful than I was initially led to believe. But then, getting it wrong is how I learn. Thank you very much.