The message “v init” is appearing in the console. The passage itself renders as well. Everything looks good – except for no events.
Tested in Chrome and Edge, same behavior in both.
I’m writing code in TypeScript and transpiling it into JavaScript, then throwing the “.tw” and “.js” files into a build directory (along with other js files from macros, specifically “speech box”) and running Tweego against that directory. Tweego doesn’t complain.
Never mind. Fixed it – somehow. I reworked my gulp to use Babel instead of Webpack, and was more careful about targeting ES5, and now it seems to be working fine.
FYI - Instead of doing the above you can simply do:
<<run console.log("v init")>>
The <<silently>> wasn’t necessary there, since the code inside of it wasn’t displaying any text anyways, and for single lines of JavaScript it’s simpler to use it in a <<run>> macro, instead of wrapping it inside of a <<script>> macro.
Thanks HiEv. That will simplify a couple of bits for me. For what it’s worth, in this case, there was more code there for which the silently made sense (or used to), but I stripped it all out and replaced it with the log call just to trace what the execution was doing.
Now I have another problem. A mysterious “Cannot find module ‘undefined’” being thrown at the start. Never happens after that, and things seem to run just fine. Trying to debug it now. Only clue I have at the moment is the string “tw-user-script-0”.
Honestly, based on your comments in this thread an others, it sounds like you have a fairly abnormal setup, so it will likely be difficult for anyone to help you with that. At least, not without being able to compile and test it themselves.
I’d simply recommend “bracket testing”*, where you attempt to isolate exactly where/when the problem is occurring by putting in code to indicate when certain steps have occurred, and then narrow down the locations of the error using those “brackets” (based on the last and first “brackets” to trigger before and after the error, respectively) through repeated tests, until you know exactly where the problem code lies. Once you’ve found that line of code, you can then examine that code for what problems would trigger that error.
Good luck!
*: Not sure if that’s the correct terminology for that kind of debugging, since that lingo was from one of my college computer science professors back in the '90s.
Definitely a home-brew setup. I have a “dev” directory in which goes my TypeScript work and Sass files. Gulp/babel compiles those into Javascript and CSS and plops that into a build directory. I also write the the .tw files in dev and gulp just copies them into build. Now that build has js files, css files, and tw files, I run tweego against it, directing the output into the dist directory.
I don’t expect someone to say “Hey, step 3 is wrong”, obviously. But maybe someone knows that “tw-user-script-0” always means “init” or something like that. In the mean time I’m cutting back chunks to narrow it down – haven’t come across it yet. I’m almost at the point where I think it’s not in my code at all but rather something still wrong in my setup.
If I recall correctly, as the name suggests, “tw-user-script-0” refers to either the JavaScript section in a game compiled using the Twine editor -or- the first “script” tagged passage of user-created JavaScript in a game compiled from Twee code via something like Tweego. Thus I’d say that it looks like there’s a bug in your game’s JavaScript code somewhere there. Knowing the full error message might help.
Note that, if your code fails part way through the JavaScript section, then no other code after that point will execute. Thus this explains how your events might not appear to be triggering, since they were never actually initiated due to being in the JavaScript section after that error.
I’d recommend starting by taking a look at your game’s JavaScript code using the debugging method I suggested above to see if that appears to be correct.
Might have zoomed in on it. Not my code after all, but it is the way I’m doing things. I dropped ChapelR’s “speech box” macro directly into the js directory to feed it to tweego. Get the error. When I remove it and re-tweego the code, the error goes away. I already modified my code so that it didn’t actually call the speech box service. Just the presence was causing the error.
Pass speech.js through the babel process. Something is not resolving correctly when I skip this.
Just roll my own speech box. I actually did at first, before I came across his macros. Since I don’t use the picture box feature anyway, maybe I don’t really need it.
Honestly, I’m not a fan of Babel. I’ve had very few experiences with it and almost all have been bad. For example, someone using some of my code that had a rather simple typeof call in it, caused Babel to recompile it in a way that it used its own _typeof instead, which then it then proceeded to fail with a “Maximum call stack size exceeded” error. I added my notes to the report that existed regarding that problem, and it still took them over a year to fix that bug.
Personally, I’d avoid using Babel whenever you can.
I usually use Webpack with the appropriate loaders, but switching to Babel seemed to fix my issues in this case. But that got me to thinking, along with some of your insightful comments.
What if I’m trying too hard? I have re-organized the page structure, added numerous features, altered styles dramatically – basically bashing apart Sugarcube, likely in bad ways, and then wondering why I’m having trouble with macros, events, and so on. I don’t even like macros. I’m an HTML/CSS/ES developer, which is why I glommed onto Twine in the first place, instead of, say, Ren’Py.
Sounds like what I need to do is hoist my work onto Snowman as a story format. No macros to get me into trouble. Just an infrastructure for organizing passages and links, along with related events. Everything else is up to me. Thoughts?
Do you particularly like having the visual editor? I feel like if you’re a web dev, Twine doesn’t offer much at all other than the graphical view. I guess my question is, what does Twine do for you that you couldn’t do with just a web page and a bit of custom JS?
SugarCube’s built-in tools can save you a lot of time that would be spent reinventing the wheel. However, if you think you don’t need any of that, then Snowman is a good minimal alternative.
But really, the problem doesn’t appear to be “macros”, it appears to be something that you’re doing to the code, because (other than the problems related to bugs in Babel mentioned earlier) I haven’t heard anyone else making complaints like this. It could be because people don’t do things this way very often, but it sounds like the real problem is that, for no particular reason, you’re recompiling code that doesn’t need to be/shouldn’t be recompiled. Resolve that issue, and the other issues should go away.
That said, it’s your project. You’d know better than me which path will likely be better for you in the long run.
Good luck!
That’s just not true at all. It includes a system for quickly connecting passages of text using simple markup, a history system, passage events, a saving/loading system, and sets up a lot of HTML stuff behind the scenes, including generating an IFID to make it trackable in the IFDB (Interactive Fiction DataBase). And that’s at a bare minimum. Story formats like SugarCube add a plethora of other features and tools.
You could say that of just about any web code. The answer is: Save you time that would otherwise be spent reinventing the wheel.
Everyone could always rewrite things from scratch instead of using existing code. That doesn’t mean that it’s a good idea to do it, especially if you don’t really know/understand everything that’s going on under the hood of the existing code which people have spent years, or even decades in some cases, working on to get all of the kinks worked out.
Basically, I’m not sure if telling people to redo a bunch of stuff from scratch is really a helpful suggestion.
OK, so yes, a web-dev by circumstance, and pretty decent at it, though always learning.
New plan!
Returned to Sugarcube. Snowman is nice in theory, but no save game module and other key elements means a lot of work to bring it up to speed. HiEv’s comment about “reinventing the wheel” is right on point. I might not be using all of Sugarcube’s capabilitities, but there are critical ones that I would need to recreate.
Finally got my speech.js stuff working the way I like it. Basically, I moved the code directly into my codebase, cleaned it up for TypeScript, stripped out the bits I don’t use, and have it initializing in a way that works. No more tangled mess of undefined modules and other weirdness.
I’ve built a VN Development environment inside of WebStorm, since I already have a license for work (run my own company). I’m used to it. The only thing I don’t have is a formatter for .tw files. Might see if I can cook one up for myself.
Macros are fine and I shouldn’t pooh-pooh them so quickly, but my default approach is somewhat different. For instance, as the dialog progresses, the image of the character changes to fit the mood (Ren’Py has a feature like that). To do that, I pepper the tw stream with hidden div’s that contain data blocks for the character and the image to use. As the page progressively reveals, those divs are scanned with jquery code, and that in turn extracts the data for the image swaps to perform. I didn’t even think of figuring out a macro for that – seemed easier to just leverage JS/jQuery skills.
Rewriting things by accident – that’s my way of working. OK, not a smart way, of course. I actually had a “speech box” thing written when I stumbled across ChapelR’s version, which of course was better (I like the macro factory idea – weird since I’m not a fan of macros to start with). Now that I’ve figured out how to integrate it properly, I can leverage that and other code I find and avoid re-work. Still, customizing it is a lot of fun!
Yeah. Sorry. I put that very badly. Some Twine games don’t care about any of the tricky features, and there are a lot of JS libraries out there that handle various parts of what it does. It seemed worth asking if the OP was using part of Twine’s feature set that would be hard to replace.
