Nikos has released FrobTADS 1.2, which incorporates the latest TADS 3.1.1 release. This means the new release is now available for Linux/Unix and OS X.
The new 3.1.1 release is now available for Windows (and in source code format) on tads.org. This release has a few significant bug fixes, and a number of minor new features that I've been meaning to add for a while. The biggest new features are a full-featured Date class for manipulating date/time values, integer overflow handling (with automatic promotion of results to BigNumbers when they overflow the integer type), new syntax for creating static regular expression objects, and an upgrade of the Unicode implementation to include complex case conversions involving one-to-N foldings (the canonical example is the German "sharp S" or ess-zed, but there are a number of other ligatures and accented characters that require similar handling). There's also a handy new string embedding << >> feature that lets you use a sprintf format code inline with an embedding, such as <<%x n>> to show 'n' as a hex number.
At present the new version is just for Windows, but Nikos has already gotten the preliminary release candidate going on Unix, so it shouldn't require a lot of new work to integrate the final version. I'll post the updated FrobTADS when it's available.
I'm pleased to announce that the long-delayed TADS 3.1 is finally available. This is a fairly major upgrade; it has two major new feature areas, a raft of little language enhancements, and many bug fixes. The Windows and source code packages can be downloaded from tads.org immediately. (The code has already been ported to Unix and Mac OS, but those still need to be finalized and packaged.)
For full details on the changes, see (as usual) the change history - that's available on tads.org on the Manuals page, along with the current documentation.
The first major new feature area is Web play. It's now possible to design a game for deployment on the Web, so that players can run it in a Web browser without installing any TADS software on their machines. The game and the TADS interpreter run on an Internet server, and the game presents its user interface as essentially an HTML page. The game itself acts as a Web server, serving the HTML/JavaScript/CSS resources that make up its UI.
It's not quite TADS's answer to Parchment: for one thing it doesn't give existing games instant net deployment, since the game has to be built specially for this mode; for another, the .t3 program actually runs on the server and communicates with the browser via AJAX, rather than running entirely inside the browser as javascript the way Parchment does. This second point has some pluses and minuses; the main drawback is that it requires a continuous connection with the server, so you can't play disconnected with a browser. (You actually can play such games disconnected if you install the TADS interpreter on your client machine, since that lets the whole client/server setup run locally without the need for any network connection.)
But there are also some serious pluses. The big one is that TADS now has a true network infrastructure. The obvious possibility this opens up is multi-user play, for building MUDs or multi-PC games. Now, this is just a possibility at this point, since there's no library support for any of that, but the network plumbing is in place to support it. I see a few other possibilities that are also pretty interesting. One is collaborative play - which is more than a possibility, actually, in that the updated Adv3 supports it out of the box. Collaborative play means that multiple people can simultaneously connect to a session - still playing a single-player game, but with each player able to see what the other players see and able to enter commands. The same idea as a couple people huddling around a computer playing together, but remotely via the Internet. Another idea I'd like to explore at some point is using the networking to let the author be involved while people are playing - either directly involved in the sense of actively manipulating the game in response to what the player is trying, or more simply, just gathering ongoing information on where players got stuck, verbs that didn't work, etc., that could go into improving the game in a rapid update cycle. Same idea as beta testing, but continuously after release, and without people having to manually gather logs and send them to the author. I also have this back-of-the-mind idea of using the network as a real-time human supplement to the parser, where commands that aren't recognized by the mechanical parser could be instantly flashed to a network of people who could step in and interpret the commands into something recognizable to the parser, and send it back, so that from the player's perspective the parser seems to understand whatever a human could.
The second big new feature area is dynamic compilation, and a bunch of related improvements in the reflection system. This pushes TADS pretty fully into dynamic language territory. So far it's not something that Adv3 uses at all, but I added it because I have a bunch of library facilities in mind that could take advantage of it. Adv3 or, more likely, the "Mercury" library I've mentioned will probably start taking advantage of it in the next round, and in the meantime, I think it opens up a lot of new possibilities for add-on libraries.