You can indeed! That’s why all the debugging commands start with @—so that they (hopefully) won’t conflict with in-game commands. You can also put in arbitrary queries and now-statements at any (get input $) moment.
I’ll have to test and make sure those work properly with the new tag options.
EDIT: They do, and it also prints ) when it’s waiting for a keypress for a [more] prompt. Woo!
dgt is a tiny, specialized, highly opinionated command line tool used to build, debug, and test interactive fiction created using Dialog.
To install for the first time:
brew install hlship/brew/dialog-tool
To upgrade from an earlier version:
brew upgrade dialog-tool
Download the latest distribution from GitHub dialog-tool releases.
You must have a recent version of Java installed. You must have the Dialog commands installed (see the full instructions for details).
Unpack the archive, and copy the dgt and dialog-tool-<version>.jar file onto your executable search path. You can also symlink dgt to a directory already on the search path.
Are we having fun? I’m having fun.
dgt is a tiny, specialized, highly opinionated command line tool used to build, debug, and test interactive fiction created using Dialog.
This new functionality complements the existing dynamic state: you can request a trace of the queries executed for a particular command and see it in a modal dialog as a searchable, expandable tree.
I’m incredibly jazzed about this feature (though I’m sure it could use a few tweaks); as you can see, hovering over a source link shows you a preview of the source (syntax highlighted, no less!) and clicking the link opens the full source in a new browser tab.
I think this would have saved me epic amounts of time with some of my projects … the Skein is now acting very much like an interactive, visual debugger for Dialog.
This is better than setting a breakpoint as you can decide to get the trace after you’ve seen the result (the Skein replays the game to just before the command, then enables tracing). Does that count as more time travel? It does.
At this point, I think development on dialog-tool will slow, with a 2.0 release soon, and a 2.1 coming after the next Dialog release.
To install for the first time:
brew install hlship/brew/dialog-tool
To upgrade from an earlier version:
brew upgrade dialog-tool
Download the latest distribution from GitHub dialog-tool releases.
You must have a recent version of Java installed. You must have the Dialog commands installed (see the full instructions for details).
Unpack the archive, and copy the dgt and dialog-tool-<version>.jar file onto your executable search path. You can also symlink dgt to a directory already on the search path.
dgt is a tiny, specialized, highly opinionated command line tool used to build, debug, and test interactive fiction created using Dialog.
This is the first (and hopefully only) release candidate prior to the final 2.0 release. I’ve been working on this update since Jun 2024 and I’m really proud of what I’ve accomplished; I’ve learned several new technologies and built a tool that, in my opinion, enhances the experience of developing Dialog projects in some really significant ways, tapping all the potential that Linus and Daniel have provided for us but also making it more accessible.
Yes, you could see the dynamic state before but you couldn’t see how it changed. Yes, you could see the trace from running a command, but you couldn’t search it, or see the hierarchy of queries, or see the sources. Enjoy! I’m looking forward to
switching gears back to working on my extensions, and then my actual game.
To install for the first time:
brew install hlship/brew/dialog-tool
To upgrade from an earlier version:
brew upgrade dialog-tool
Download the latest distribution from GitHub dialog-tool releases.
You must have a recent version of Java installed. You must have the Dialog commands installed (see the full instructions for details).
Unpack the archive, and copy the dgt and dialog-tool-<version>.jar file onto your executable search path. You can also symlink dgt to a directory already on the search path.
On Mac Tahoe 26.3.1:
sue@solfar stellar-core % dgt --version
Unrecognized option: --enable-native-access=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
sue@solfar stellar-core %
What version of Java?
Er, the most recent one that the Oracle installer prompted me to install? handwave
The fact that it’s falling over now is keeping me from checking java -v, but it fails with the same error message, so it’s clearly my Java installation and not dgt.
Okay, I have Java 8 build 481, from Oracle, plus OpenJDK 25.0.2, through Homebrew. Let’s kill that old Oracle build and see if that fixes it.
Okay, now I’m able to play with it. How do you get it to output multiple formats? And how do you specify the order in which your source files need to be fed to the compiler?
It’s as described here:
Basically, order is all :main, then all :debug, then all :library.
In each section, a directory is all .dg files immediately in that directory (in arbitrary order, but probably alphabetical). A file is just that one file.
dgt build will build the project in the format defined by the :format key, or :zblorb if not specified.
You can also dgt build ---format aa (for example), to build in a different format.
There is not (yet?) a facility to build multiple things, but when it builds, the extension will be different for each format.
Bugs? Other ideas? Discuss here or add to the Issues on the GitHub page. I’ll see it faster via GitHub, but discussions here are nice too.
I’m still dying to try this out but haven’t got it working on Windows yet. The Java app runs fine but the Skein doesn’t work because dgdebug on Windows doesn’t work the way it expects. I haven’t delved yet into whether it’s possible to build the Mac/Linux version on Windows; presumably there’s a reason it doesn’t work this way in the first place?
Basically that command-line I/O is so limited on Windows. Dgdebug tries to provide a reasonably good experience (not breaking words across lines, for example, and letting you use the left arrow key to move through your input and edit earlier letters without deleting the whole thing) and the tools to do that aren’t easily available on Windows the same way they are on Mac and Linux.
For the Skein, of course, that doesn’t matter, so it wouldn’t be hard to provide an extremely limited (“dumb”?) version of dgdebug that can be hooked up to the Skein without doing any fancy styling.
At least some of them should be… for example, readline is available for cygwin and mingw64.
Dgt does not seem to be fond of dgdebug now explicitly resetting the foreground and background colors around newlines:
It’s not necessary to support colors completely (or at all!), but it would be nice if unknown ANSI escape codes were ignored rather than printing [?] and [/?].
I’ve built something of the sort. Any Windows-users willing to run a strange EXE file I send you to make sure it doesn’t crash immediately on startup?
The main things it can’t do:
But, none of these should be a problem for dgt specifically, and that’s the intended use case here. If this works, a dgdebug_tty.exe file will be included in the next release.
Really, I should just disable all the line editing stuff. Without the ability to control key echoing it’ll just be awful. I’ll do that quick.
I’d be glad to try it, but I can’t until some time tomorrow.
You can grab it here for the moment, though most software will not be happy about random EXE files off the internet nowadays. If this works, it’ll be part of the distribution for the next version.
![lots of [?] blocks](https://intfiction.org/uploads/default/original/3X/9/2/92c1d7fd24da87bfd239e75266552f8191e9ed58.png)