I know this may be a long shot, but hey... gaming community and Interactive Fiction is like MUing's second cousin.
I'm developing a game in Twine and I'm having a bitch of a time getting one of my scripting macros to work. I reached out to my instructor, but the formula he gave me doesn't work either.
So if anyone's familiar with Harlowe in Twine 2, I'd really appreciate the help.
I get all my twine from amazon they usually have great prices!
Yeah actual Twine the engine? PiTA really is. Tried and failed so many times to build something in Twine.
It is such a PITA.
I'm losing more time to fixing bugs than I'm spending actually building this damn game for class. 
Saying the quiet parts out loud since 1996.
@auspice Sadly, until you have the basic design pattern down, that is always the case. Bugs and basic functionality.
I have a waggish sense of humor.
@misadventure said in Anyone familiar with Twine?:
@auspice Sadly, until you have the basic design pattern down, that is always the case. Bugs and basic functionality.
For most of it I have a pattern down (I do wish it was smart enough that it could pick up auto-complete for shit, but noooooo). My main issue is this one bug that I just cannot resolve and I was hoping mebbe someone around here knew it well enough.
Good news:
Achieved victory over one macro that arose today in Twine.
Bad news:
Still stymied by my other problem.
Basically, I can't get (if: $variable >= #) to behave.
(if variable is greater than or equal to number). The game will either ignore it altogether or act like it's true every single time. In one instance, it acts like it's always true. In another, it just ignores it. So right now, I'm leaving it out entirely and just focusing on getting everything else done. ![😕](http://musoapbox.net/assets/plugins/nodebb-plugin-emoji/emoji/android/1f615.png?v=4vfms5ns7sl ":\")
Saying the quiet parts out loud since 1996.
That's odd. I haven't usually had any problems with that one. Can you post a verbatim bit of code with the hook you're attaching it to?
@auspice My guess would be that in the logic where you define the variable, something else is causing it to consistently assigned a bad value, so I'd copy the code of where you are first assigning the variable and every case where it is modified.
Okay so.
At the beginning of the game, we have:
(set: $operations to 5)
Later there is a section in the game where certain actions (at links) will cause:
(set: $operations to operations - 1)
Then, I have a single node where at the beginning of the node I have:
{
(if: $operations <= 0)(goto: "peregrine@end:~$ ^z")
(cleaned up of course for the full node, but..)
The intent is: if they've got 0 or fewer operations remaining when they hit that node, they'll go to the node named "peregrine@end:~$ ^z" (it's a cyberpunk game, all the nodes are named jokey *NIX prompts). The issue is, I've even bumped up the starting operations to 8, played through in debug to where I KNOW I'd have plenty left over... Every time I hit that node, it sends me to the end condition.
In my other instance, I have links that will cause:
(set: $interrogatorDisposition to interrogatorDisposition + 1) or set: $interrogatorDisposition to interrogatorDisposition - 1)
depending on what they choose, it's one or the other.
Then there's a node where it has a fairly basic:
{
(if: $interrogatorDisposition is >= 5)[Some text here]
(else)
I've used similar for basic switches (for link decisions) with absolutely no issue. 'Okay they made X decision, so they see Y text in the next node.' But for some reason, having it based on what the variable has built up to at that point... it just doesn't display at all. It doesn't show. Again, I tested it, picking all the choices that would ensure the $interrogatorDisposition variable had built up to be over 5 and... no dice. Didn't work.
Would the SugarCube option of gte work the same as >=? Should I go back in and alter it to try that?
Just programming advice in general: if (x < 6) only requires testing the first 4 bits at runtime, while if (x <= 5) may start with the first 4 bits and any time you're actually equal to 5 it requires testing all 32 or 64 bits in the underlying value, depending on the platform's CPU mode. Both statements are functionally identical except for the performance issue.
Your particular issue is probably that (set: $operations to it - 1) is equivalent to (set: $operations to $operations - 1) while (set: $operations to operations - 1) is bad syntax.
@nemesis said in Anyone familiar with Twine?:
Just programming advice in general: if (x < 6) only requires testing the first 4 bits at runtime, while if (x <= 5) may start with the first 4 bits and any time you're actually equal to 5 it requires testing all 32 or 64 bits in the underlying value, depending on the platform's CPU mode.
That hasn't been true since the early 90s. Every processor on the market these days will do either version in a single clock cycle.
A valuable tip if Auspice decides to switch from Twine to Atari 2600 homebrew, though.
@nemesis said in Anyone familiar with Twine?:
Your particular issue is probably that (set: $operations to it - 1) is equivalent to (set: $operations to $operations - 1) while (set: $operations to operations - 1) is bad syntax.
If that is the case, I'll need to yell at my instructor. Because I used to have it as:
(set: $operations to $operations - 1) and I was told not to do that early on because it's incorrect syntax to double up on the variable indicator.
So meh meh meh. Maybe I'll go through and fuss with just changing them all to 'it' for the latter half of the macro and see if that fixes it.
@cheesegrater said in Anyone familiar with Twine?:
@nemesis said in Anyone familiar with Twine?:
Just programming advice in general: if (x < 6) only requires testing the first 4 bits at runtime, while if (x <= 5) may start with the first 4 bits and any time you're actually equal to 5 it requires testing all 32 or 64 bits in the underlying value, depending on the platform's CPU mode.
That hasn't been true since the early 90s. Every processor on the market these days will do either version in a single clock cycle.
A valuable tip if Auspice decides to switch from Twine to Atari 2600 homebrew, though.
When $x < 5 fails to be true the additional = test introduces a 2nd clock cycle regardless. 1 + 1 = 2.
When $x < 6 is true, you accomplished the exact same thing in that single clock cycle. 1 + 0 = 1.
So don't wait for the class on 8088 Assembly programming.
Edit: Looked it up and cheesegrater is correct. JGE. Derp on me.
So (set: $operations to $operations + 1) does not work.
But (set: $operations to it + 1) does.
I got the latter instance of it (with the (if: $this >= 5)[Stuff...] ) working.
However, the initial one of: (if: $operations <= 0)(goto: location) is still just triggering every single time, regardless. It'll dump me there and the debugger still happily says like: 'value $operations = 4'
Thanks debugger. You're super useful.
I've had only had 3 days to write this entire game so far and it's technically due by 11p CST tonight. I don't see it being done. Gonna take the 5pt deduction on my grade, I suppose. At least it doesn't have to be totally bug free this week, just... story complete. Going to use tonight / tomorrow to focus on that.
(This thing has had me so stressed out, y'all: I woke up three times yesterday from nightmares. 
)
@auspice said in Anyone familiar with Twine?:
(if: $operations <= 0)(goto: location)
(if: $operations <= 0)[goto: location]
Or maybe: (if: $operations <= 0)[(goto: $location)]
The documentation is unclear but I'm fairly confident the IF's result should go in [] and maybe the goto should go in () inside that.
Square brackets on command or what Harlowe likes to call "changer" Just To Be Different. Forevermore referred to as JTBD and highly derogatory.
Nope.
Doesn't matter if it's:
(if: $operations <= 0)[(goto: "peregrine@end:~$ ^z")]
or
(if: $operations <= 0)(goto: "peregrine@end:~$ ^z")
As soon as the user lands on that node, they're redirected to the node named "peregrine@end:~$ ^z" regardless of what the variable $operations is set to.
Eh. If I can get everything else working happily and that's my major bug for the final pass next week, I'll take it. So far everything else I'm looking at for next week is story polish (like uh, forgetting I buried a variable set to true in act one and did nothing to utilize/resolve it... ahem).
I'll take one major bug.
I can live with one bug for shitty scripting language in a tool I just learned in the past week and a half.
I call that a win.
(if: $operations <= 0)[(goto: "peregrine@end:~$ ^z")]
Try go-to instead of goto
I'm guessing or betting that "peregrin@end" is the next chapter or section in-line anyway so it's going there as a default in flow control. So the bool isn't always true it's just the command is always ignored as an application exception and the thing is behaving normally in all other respects.
Tried this and nope. goto works just exactly like go-to and if there's nothing there at all then it does nothing.
(set: $operations to 0)
(if: $operations <= 0)[(goto: "peregrine@end:~$ ^z")]
If I set $operations to anything but 0 (including by adding 1) then it doesn't goto.
So I think you should present more of your code. That entire file, maybe. Something's going way wrong if Twine didn't alert you to the syntax error and it's giving you this other behavior too.
@nemesis said in Anyone familiar with Twine?:
@auspice said in Anyone familiar with Twine?:
(set: $operations to $operations + 1)
Where's the debugger you're using?
The one built into Twine. I'm unaware of any other that exists.
I think there's something wrong with your browser then, if you're using Twine's built-in debug feature. When I tried: (set: $operations to operations + 1) it actually gave me a very useful error output stating that "operations is not defined"
So I've actually started a Twine story up in Harlowe 2 and been playing with different code structures and permutations. Everything works fine and normally.
Instead if (if: $operations <= 0) you could also try:
(set: $isOperationsDone to ($operations <= 0))
(print: $isOperationsDone)
Instead of the if: statement (if you leave the if statement in, it'll trash your existing output when it jumps to the next storyboard). If the print value is correct and if you actually don't jump to the end without the apparently offending if statement, then try adding:
$isOperationsDone[(goto: "peregrine@end:~$ ^z")]
@misadventure said in Anyone familiar with Twine?:
@auspice Sadly, until you have the basic design pattern down, that is always the case. Bugs and basic functionality.
For most of it I have a pattern down (I do wish it was smart enough that it could pick up auto-complete for shit, but noooooo). My main issue is this one bug that I just cannot resolve and I was hoping mebbe someone around here knew it well enough.
