If it's $mood1, then I assume that there's a $mood2. My suggestion is that this naming convention is bad. If you believe you need numbered variables because the related vars encapsulate related functionality, then you are probably better served by a datamap or array. If instead these variables are meant to be different, for example, if $mood1 represents the mood of character 1, or the angry mood or something, more specific names will help you prevent issues where you can accidentally write $mood2 or something when you mean $mood1.
> If you think it's terrible because I might get it mixed up down the line, then that isn't an issue because of my structure and planning...
You can do what you want, it's not my game and I don't have to work on it, so it doesn't matter to me. But I would point out that this is a mistake you've already made, even if you don't believe it counts because it was made in a question and not in "real" code. Structure and planning are not an effective counter, in my personal experience, to the human capacity for making mistakes. It's like not wearing a seatbelt because you're confident in your driving ability. Again, this is just my opinion. You may be an excellent and experienced programmer who never creates hard to find bugs, but this is still advice I'd give to anyone who has variables named like this.
If there's just a $mood1 variable, and no $mood or $mood2, etc, then I still don't get the naming convention but at least there's some uniqueness here, so maybe it won't be an issue for you.
> Edit: upon relaunching Twine (and I guess restarting my computer), the problem seemed to fix itself. I've had this issue with other programs (such as Quest), but not with Twine yet.
There are a few potential culprits, one is that you potentially forgot to refresh or close and reopen the test or play view in Twine 2, and the other is a bit more nefarious, sometimes your browser will cache an older version of the story even through reloads. You can fix this by hard reloading with CTRL + F5. I believe the application version is also susceptible to this behavior, but I'm not sure. Regardless, as long as the issue is solved, that's good.
I'd also like to support @Greyelf's suggestions about limiting the instances of running timers. It wasn't something that was directly related to the apparent variable name issue I erroneously thought was the problem, but it is also good advice, if unsolicited, much like my advice about changing the variable names.