Honestly, I’m not trying to be obtuse. I know several programming languages. I have a game in this year’s comp written in TADS 3. But what you’re saying does not link up for me. I don’t understand what you’re saying.
I messed up with the getVar/setVar parts though. It’s been a while since I’ve used Twine, so I forgot that you need to pass it the leading tokens (or whatever it’s called) along with the name. This is how you can access temporary variables with it. So State.getVar("$story_var") and State.setVar("_temp_var").
As for where you would put this code:
If you choose to use the getter, you would put that bit of code in your StoryInit passage. It’s a “set it and forget it” function that only needs to be run once.
Is there such a tutorial? I’ve been looking, and I haven’t found one.
Your suggestion that I put that code in my StoryInit (even if I had one) wouldn’t solve this particular problem, because I don’t want something set up at init time. I want it evaluated only when the user clicks on a word in a particular passage.
You might want to take a look at this, if you haven’t already. I don’t think I can link directly the “examples” tab, but that’s where I’m trying to direct you. https://twinery.org/cookbook/
Sadly, that probably is the best site for examples of simple things. It’s supposed to be a comparison of the languages, but it’s also the closest you’ll get to basic examples, as far as I know.
As for your code issue, <<script>> will probably be your best best, placed inside a <<link>> tag, maybe.
An alternative is to use a widget, which is basically like a mini passage called like a function and you can pass arguments to. What’s convenient about widgets is that they’re written like normal story script (IOW, it’s all HTML and sugarcube tags and accepts story variable names).
I’ve been trying to use <<script>> inside a <<link>>. I managed to figure that out. But the business of passing variables back and forth (and whether that will even solve the very silly problem I set for myself) is unknown. I thought of using a widget too. I don’t remember what happened.
BTW, your hashtagged links (such as the one above) are defective in Firefox. I don’t know why.
Thanks – that works perfectly (and without the JS). I have no idea why there’s a hashtag in the <<replace lines, nor do I understand why there’s a div statement in it. It appears that the replace line is replacing a div with the for loop, or alternatively with nothing (on “close”), but why that works, or why the div statement is floating off at the end of the code, I have no idea.
And of course that doesn’t work at all. Logically it ought to work, as far as I can see, so obviously I don’t understand the syntax.
Where would I go to read a tutorial that explains this kind of stuff? This is not quite an idle question. I wrote the I7 Handbook ten years ago, and people are still using it. One of my mottos is, “If you want to learn something, write a book about it.” I could actually be moved to write a book about this type of programming, but first I would need to understand it…
The hashtag is targeting the div ID. I probably should have named them different to be more clear. The names aren’t linked or anything. The “t8n” part makes it fade in.
You’re correct that it’s replacing the div. But probably more accurately is that it’s replacing the contents of the div. (It’d be documents.getElementById("#items").innerHTML, or $("#items").html() in jquery, if we’re being super specific.)
The way that <<replace>> works is that it renders its content to a buffer when run and then pastes that into the target HTML element. In this case, we’re collecting all of the items that you have in the inventory, adding a close button to it, and then putting that into the div element below the “show items” link. The close button sets the div’s content to nothing again, as you surmised.
Since the “show items” link calls the replace macro each time, and the replace macro runs the for loop fresh each time, it doesn’t just recycle the old text. If you click an item while the list is still displayed and then click the “show items” link again, it’ll refresh the list with updated inventory.
I hope that makes sense. I’m horrible about explaining things like this.
Those two code snippets do the exact same thing, though the second one is quite a bit shorter.
It’s a SugarCube object. See the State API documentation.
Looks like the security certificate still hasn’t quite been fixed there. Just change “https://” to “http://” and they will work fine.
It’s not a “hashtag”. It’s a CSS selector, where a hash “#” in front of a name means that it refers to an element’s ID (IDs should be unique on a page), and a period “.” refers to all elements with that class (classes do not need to be unique on a page). So the “#items” refers to the <div> because that <div> has “items” in its id attribute.
That selector tells the <<replace>> macro what its target is for replacing the content within that target. See the <<replace>> macro for details.
It’s not really a security risk. It’s just Chrome and Firefox being over protective. It’s because it’s an HTTPS address but the certificate expired. It’s like denying someone alcohol because their license expired, as if they’ve de-aged somehow now that the license is no longer valid.
Ironically, if this were a normal HTTP address instead of HTTPS, it wouldn’t require a security certificate and it wouldn’t throw an error. The site would be less secure but you wouldn’t be alerted.
That being said, it sure would be great if the sugarcube docs would update their certificate so it didn’t look like a sketchy phishing site every time I visited.
If you haven’t figured out your issue, it’s that you’re not using <<run $items.pop()>> or <<set $items.pop()>>. You can’t just dump JS into a sugarcube tag. You have to use set or run to tell sugarcube to execute it.
As HiEv mentioned, set and run are just aliases of the same thing to keep the code more readable. However I’m lazy and I just use set for everything regardless of whether assigning a value or running a function.
That makes perfect sense. I tend to think about code in procedural terms – that when a line is encountered by the software, the line is executed. The idea that you have to tell the software to execute a line in order for the line not to be ignored is a bit foreign to me.
It’d probably make more sense once you realize that everything inside a << >> tag is basically a function in sugarcube’s list of macros (widgets and user defined macros get added to this list) and stuff not listed in sugarcube’s list of macros throws an error. The first word in the << >> tag is the function name and what follows it are the arguments.
The reason <<run $items.pop()>> works is because run() is a function that takes a string argument that it then evaluates (executes). So <<run $items.pop()>> is really saying run("$items.pop()");
Or at least that’s my assumption of the process. I never actually peeked at that part of sugarcube’s source code.