Hi! For quite a while I’ve been working on a vscode extension for Tads3. It’s named vscode-tads3tools and is available now at the marketplace for vscode (easy installation via the extension panel in vscode). At its core it is a language server written in node.js that can be implemented in other editors beside vscode that supports the language server protocol.
The extension features an outliner, go-to-definitions, word completions, snippets, diagnostics, and a bunch of useful commands such as project creator, prop-generator etc…
It also feature an interactive map editor. That allows visualizing the game world and adding rooms and creating connections between them.
I’ve assembled some movies of its features in the readme, so for a quick overview, check them out:
I hope to receive feedback on this. It is an alpha release as I dare not call it anything else at this point in time (since I’m the only tester so far). I do hope that collaborators will join in, even if it’s just as feature wishes, AND bug reports are most welcome too! (Add them in that case as issues in the repository or just write here via this forum, or message me directly).
It’s been tested to work all major OS:es, but the main development environment was on linux/macos, and it will always have focus on those platforms, since windows already have the tads3 workbench.
Nice! This is actually what I was going to going for a bit with my own extension in this regard, but I lacked the immediate skills. What you have there is so much better than what I’ve put in place.
Thank you very much! I’ve believe your extension has a bit better syntax highlighting since it also covers both .t3m and .tl files in addition to .t and .h (and maybe some other feature?) but I couldn’t think of a neat way to make both of our extensions coexist nicely without removing the existing syntax highlighting modeI (that VoidPhantom created some year ago). So I just kept the syntax highlighting as it is for now.
Thank you very much for TADS3 Language Server, I have been waiting for a similar extension for a long time. I tested the current version in Arch Linux, where I currently have FrobTads 2.0, QTADS 3.0 and VSCode 1.59.1 installed, and I am sending my experience:
there must not be more than 1 file with the t3m extension in the directory with the game to be opened, otherwise I get an error:
"undefined symbol " gameMain \ "—> stack depth is -1 after block codegen (line 1252)! —> stack depth is -2 after block codegen (line 1501)! —> stack depth is - 1 after block codegen (line 1640)! ",
“source”: “/usr/local/share/frobtads/tads3/lib/adv3/action.t(1241):”,
sometimes it is necessary to reopen the project in VSCode in order to run the ParsingSymbols routine to load all *.t files. Other times it will help to close all open project files and restart VSCode, it is always necessary to run the ParsingSymbols routine. Sometimes it is even necessary to move the project directory to another location and then it will open (usually moving directly to the user’s home directory will help).
I’m looking forward to further updates (debugger, the function for compiling and subsequent launch of the TADS project would help, now I use a terminal in VSCode). TADS3 Language Server is a great project that gives TADS completely new possibilities, especially for Linux users, and is another reason to still use it to develop text games.
Hi Krouziciorel! You are welcome! Thank you for your kind words and your valuable bug report.
You are right it is not working optimally when you have several makefiles. I’m looking at it right now.
It should be possible to have several makefiles (.t3m) files. The extension searches the project directory initially for all *.t3m files. If several such files can be found it chooses the first one it finds. If it can’t find any makefile a dialog should appear, letting you choose one manually. I will improve this to let it favor any “Makefile.t3m” file it finds first. That will be the default unless another one is chosen via the command “setMakefile”. I’m also considering a full reparse if changing makefiles.
I’m guessing that the makefile that got chosen in your project might have some different configuration in regards to the adv3 or action.t library file? Or are both makefiles valid and uses the same library?
May I suggest that you send me the two makefiles (stripped clean of your source code files) so I have a little more to work with. (Or what else you feel okay sharing)
Also, you can get a lot more detail from the language server itself by opening up View/Output and select “Tads3 Language Server” in the selector (I’m not sure if is there you saw the error you got?). There you can see which makefile was chosen at least. That log there might give some additional information where things goes wrong.
Regarding the second issue, have you tried to save a file in the project after opening it? That will hopefully trigger a parsing too, and if an initial parsing of all files haven’t been run already it will do it at the first file save. (It’s not a real fix of the problem, just a potential workaround for now.)
By the way, the subsequent launch already exist. You can toggle it with ”Tads3 command: Toggles on/off if the game should restarted as soon as the t3 image game file changes” via ctrl-shift-p. It will default to “frob” (interpreter) but this can be change in the configuration.
And if you also run the command:
”Tads3 command: Install a tracker game file in the project so the game will remember player position between sessions"
A tads extension will be installed in the project that persists the player location between sessions, so you always start in the latest room visited.
Thank you for quick response. Yes, the problem with opening was actually caused by multiple Makefile .t3m files. I have a text game developed from the environment of prairie Indians named Krouzici orel (in the Czech language) and I use the standard TADS3 game Heidi as a pattern. Directory with Heidi I have located as an subdirectory of Krouzici orel and when TADS3 Language Server was indexing he found more Makefiles. Now I have deleted the Heidi subdirectory and everything works as it should. I use a standard configuration with the adv3 library.
I tested the TADS3 Lanuage Server output on the console, everything seems to be OK. Thank you very much for the tip with saving the file, yes, then the parser always runs again, fortunately, thanks to the use of only one Makefile, the error no longer occurs.
Great, thanks to the TADS3 command: Toggles on / off and subsequent saving, the game starts to the VSCode console, now I don’t have to leave the editor even when debugging. The command TADS3 command: Install a tracker game also works, since it is a Czech game, it was enough to edit the line #include <en_us.h> to #include <cs_cz.h> in the file _gameTrackerAdv3.t, now everything works without any problems.
My game is open source, in the attachment I send its source codes, including Makefile (now without the Heidi directory) and also the output of the TADS3 Language server.
The extension is excellent and I will use it in my next work, I’m already looking forward to the updated version. VSCode is a great editor, I’m starting to use it for Python and Java as well, so I’m very happy that your extension is available for it.
Great! I’ll control check with your source later today, and see if there are anything else that needs fixing. I already have a few fixes coming up and I think the overall experience will be better now, but it needs a little bit more testing before next release.
Alright, I didn’t think about language extensions… good catch! I need to adapt the script there. If all language extensions follows the same pattern I guess the header filename can be easily changed using the makefile’s LANGUAGE variable.
By the way let me know if you (or anyone else is) interested in testing out the latest before a new release. In that case I’ll compile a VSIX-package that can be installed locally.
OK, I’m very happy to have helped with error reporting, TADS3 definitely deserves a proper Language server. I will also help with further testing, as soon as another VSIX package is available, I will try it in VSCode in my project. Maybe it will be better to send me new versions directly to e-mail, mine is ludek (dot) stastny (at-sign) gmail (dot) com.
Thanks Tomas for this great project, I finally got around to getting set up. I’ve never used VS Code but I’m going to for this game, perhaps in the future this work can be ported to other editors but I think for now it might be fruitful to focus on a common platform so work is easily shared.
One minor detail in setup that might be good to add to the beginning of the readme is modifying Makefile.t3m paths as needed, for example frobtads installs to /usr/share/ on my Manjaro rather than /usr/local/share, and adv3lite might not be in the root project folder.
Everything seemed to parse smoothly and go to definition already is such a quality of life boost. Thanks again!
Thank you George! Glad to hear it. I’ll add note about that!
It also got me thinking. It would be a nice feature to have that would validate and automatically add and/or edit libraries and include paths in the Makefile in case they are missing or invalid.
At least it would be nice with an option to automatically scan (and present choices to the user in case there are duplicates) and modify with those results.
Would be nice fit with CodeLens to achieve this.
(This might for instance be the case for the macintosh platform that has problem with slow compilation with library paths that doesn’t reside in the home folder.)
thank you very much for version 0.2.0, the autocompletion including documentation works great. The extension is now very stable, just to be sure I cleared the cache of my project and everything works as it should.
As soon as you have time for further improvements I would focus on the debugger, it is very important for larger projects and then you really won’t need to use the good old TADS Workbench anymore.
Yes, the debugger will make it eventually. It is the ultimate goal with this extension. But don’t expect it very soon due to its integration complexity. Perhaps a basic step functionality is within reach in a couple of months to a year. In the meantime there’s both patching and possible features to be expected.
This is an interesting project. I am currently using Workbench. The only thing I hate about Workbench is how unstable it is when working with the WebUI. If the project works with WebUI and has a debugger of at least the same functionality, I would happily switch. I’ll keep an eye on this for now.
Yes, I fully understand, adding a debugger will definitely be challenging. I’m also busy with school Python projects at the moment, but I’m still looking at TADS extensions, and I’m happy to test them as soon as a new version comes out.
Can anyone chime in and confirm for me the way to build and run T3 games in VS Code – I don’t think this extension provides that, and I’ve set up build and test tasks, binding some key combos for them. Just want to double check since I’m a VS Code newb, thanks!
I saw no current need to create a regular launcher for compiling/running, since on every save you do in the editor the extensIon uses the tads3 compiler to produce diagnostics and in that process a new image is built if no errors were found. So the only thing you need to do is to run the produced t3 image built according to how your makefile is configured.
Running it in an interpreter can be toggled to happen automatically using the (CTRL-SHIFT-P) command: ”Tads3 command: Toggles on/off if the game should restarted as soon as the t3 image game file changes” or configuring it in the settings. The extension monitors any t3 file within the project folder for changes and with this setting enabled launches the game with the frob interpreter in a terminal within vscode.
Also, the subsequent launching can be spiced up by installing a game tracker with the command “Tads3 command: Install a tracker…”. This will persist the player’s position and restore it on each new game run. (It is simply a tads3 extension being added to the directory and the makefile that can be removed anytime).
I need to update the readme about all of this since it isn’t obvious.
All this, by the way isn’t set in stone of course. I’m for instance considering skipping the image creation part of the diagnostic and just do a compilation without linking to be more economic on the drive. In that case creating launchers would seem like the right thing to do. Otherwise adding a launcher will be necessary if/when the debugger functionality arrives later on.