Community Awareness Survey of TADS 3

[pinkunz]

@Dannii

Sure, it is a big ask. Just be aware that it’s an even bigger ask for non-TADS devs to do, which is how it feels whenever I see people bemoaning the lack of TADS features in Parchment.

As an outsider looking in, I don’t understand why this has to be the case. Identifying the gaps and creating an incentive beyond altruism for someone to address it doesn’t necessarily mean you or another non-TADS dev would or should be the ones ultimately doing this work. Ideally, it wouldn’t be, for the several reasons you pointed out above.

But if we don’t take the time to clearly delineate the problem and the specific steps needed to address it, we’re left with a fairly open-ended and ambiguous prospect, which makes it an even bigger ask for any potential individual.

Appropriately or not, your past experience and work on Glk interpreters in general, and wider community awareness of your skills specifically, make you a logical focal point to address concerns with Glk implementation. I’m also sure, superficially, many folks would love if you could somehow wave a magic wand and just fix this; you aren’t wrong there. Yet, we both know reality doesn’t work that way. This will take real work and time, and gains will be incremental, as you stated yourself.

I, for one, do not expect that you should martyr yourself on this hill. You already do an immense amount of work, entirely pro bono, for the IF community; more than most folks realize, to be honest.

With that said, getting anything done, especially difficult things, requires awareness, and organization, and a general mandate that something should be done. All of this needs to occur before we can even start to identify who might be both well suited and also willing to do this. You can’t get any of that done without some amount of “bemoaning.” I’m hoping by nailing down the specifics of the ask and providing a little bit of incentive, even if mostly token, might coax one of the more skilled semi-retired TADS folks to consider the project.

I gently suggest we perhaps focus on figuring out the scope of the problem and the best avenue for attack first, and leave who will do the attacking for later deliberation. Which is why I’m working on a grant proposal right now that might provide some funding to task a willing individual to do just that.

[Dannii]

Very unlikely. It might be possible to have some Z6 support, but there’s unlikely to be enough demand to warrant the effort, considering that pretty much everything Z6 can do, Glulx can do better. (In isolation, not necessarily in conjunction. That would be the difficulty in trying to implement Z6 in Glk - if a Z6 game requires some kind of pixel perfect window quirk then it’s unlikely to be possible in Glk.)

Maximising Glk Z6 support would really have to be done by an Infocom ultrafan. Otherwise, non-Glk Z-Machine interpreters are the way to go for the few Z6 games that exist.

[pinkunz]

@Dannii

I would’ve thought that full HTML TADS compatibility would matter less for screen reader users (though partially sighted users do deserve the best of both the visual presentation that HTML TADS offers, and solid screen reader support.)

Perhaps, but I, for one, don’t rely on screen readers to interact with IF, and I also don’t have the vast majority of videogames (and countless other visual mediums) walled off to me due to the universe dealing me a bum hand. I can imagine feeling a bit sensitive about access to what remains being considered unnecessary. Perhaps it’s better to offer more than is necessary than the other way around.

@Dannii

Screen readers should support the console mode terps including Parchment and Lectrote.

I believe they do support Parchment and Lectrote, and ideally they would support QTADS as well, but the latter doesn’t seem to be the case. Bridging the gap between HTML-TADS and Glk interpreters might potentially address both issues.

@Dannii

Does TADS have alt-texts for images, things like that? While not impossible to implement in Glk TADS, that would be more involved.

I wish I could answer this offhand, but I cannot. I do think, fwiw, that having image alt-text is important for the visually-impaired and many of us, myself included, could do a better job consistently remembering to use it. Hopefully someone more familiar with TADS will chime in and answer this.

[Dannii]

If TADS does have alt-texts then actually it probably wouldn’t be too hard to support them, as I think we’ll want to be building a temporary blorb file anyway.

[inventor200 (Joey (Jess) Tanden)]

@Dannii

I would’ve thought that full HTML TADS compatibility would matter less for screen reader users

HTML TADS has a pretty solid sound effects and music system.

@Dannii

@inventor200

The second cliff face of a hurdle is that there are very few centralized sources of info on Glk, what it is, how it works, what its limits are,

This seems backwards to me - info on Glk is very centralised - there’s one very well written specification, and then for questions most of the Glk library authors are here on this forum.

Corrected…!

@pinkunz

@Dannii

Does TADS have alt-texts for images, things like that? While not impossible to implement in Glk TADS, that would be more involved.

I wish I could answer this offhand, but I cannot. I do think, fwiw, that having image alt-text is important for the visually-impaired and many of us, myself included, could do a better job consistently remembering to use it. Hopefully someone more familiar with TADS will chime in and answer this.

I should test this… I’d need to get the workbench installed on my Windows laptop because the HTML TADS interpreter has screen reader support. There’s a chance that alt-text doesn’t break the compiler but it doesn’t get sent to the screen reader. The docs for images don’t explicitly confirm or deny this. The images use the same format as web browser HTML, though, so I’m optimistic…

This is gonna be a few days, though; the laptop needs fixing.

[Angstsmurf (Petter Sjölund)]

@SomeOne2

If this all gets done, is understanding .z6 files ever to be accomplished (since Gargoyle can only understand text and refuses to use pictures or windows from v6 z-machine games), or am I being unrealistic?

Full Z6 support would require huge changes to Glk. Z6 breaks pretty much every assumption Glk makes about text and windows layout. You might as well ditch Glk entirely and create a new interface from scratch.

Also, even if you ignore Glk, it is still tricky to create a universal interpreter for Z6 games. The original Infocom interpreters are themselves pretty glitchy, with lots of system-specific and game-specific hacks.

[Dannii]

Well it would always be possible to implement it via drawing everything (including text) one pixel at a time in a graphics window

[pinkunz]

And the award for the most resources-intensive ZIL game ever written goes to...

[SomeOne2 (Max Fog)]

@pinkunz

And the award for the most resources-intensive ZIL game ever written goes to…

NGL though, Zork Zero is really, really mechanics intensive. It included 8x8 life-size chess that actually functioned while incorporating that into another part of the game (AND carriable passages that can actually function!), not to mention a point-and-click part. That is pretty damn intense with its usage of stuff, including storage space.

[Oh, and I can’t forget to mention… Although Shogun is not considered a very good game, it implemented the ability to say proper statements (to a fair extent) and converse with people using this. Using properly intense and deep mechanics, not simple stuff like the “if the command matches X…”]

[Dannii]

@inventor200

HTML TADS has a pretty solid sound effects and music system.

This is part of the confusion: TADS 3 always uses HTML TADS in terms of the HTML parser. So when I’ve been talking about implementing HTML TADS I meant using the results of the parser, rather than the reduced minimal text mode. But we can partially use the HTML parser now, which is how @ArdiMaster added monospace support.

It is possible that the sound system can be implemented entirely distinctly from any display/formatting questions, so that sounds could be added to Gargoyle right now. (Though Parchment/Lectrote don’t have any sound support right now.)

[inventor200 (Joey (Jess) Tanden)]

@Dannii

Well it would always be possible to implement it via drawing everything (including text) one pixel at a time in a graphics window

Ah, the renowned Google Docs approach!

@Dannii

It is possible that the sound system can be implemented entirely distinctly from any display/formatting questions, so that sounds could be added to Gargoyle right now. (Though Parchment/Lectrote don’t have any sound support right now.)

…Oh! Fair point! The sound tags don’t actually render, even though they’re technically loaded into the output buffer. However, this still should not ask anything of the graphics end of things, assuming the output data buffer is not on the Glk side of things.

[ArdiMaster (Adrian)]

@rpatten

For instance, if you go to the tads.org site, you’ll see the last entry on the changelog is 2013, so it’s easy to assume TADS is dead. But in this thread, people are saying TADS is indeed being updated, the source code is available, etc.

Yes and no. The core parts chiefly maintained by Mike Roberts (so the compiler, t3vm core, adv3 library, and the Windows Workbench and reference interpreter) are no longer being updated, but they’re also fairly stable (much more so than the Inform 7 compiler, in my experience). Third-party contributions like the QTads interpreter and adv3lite alternate library are still being maintained.

---

@pinkunz

I would hate to see a concerted effort to move further away from a universal interpreter, and I could also point out that move would certainly sacrifice some fraction of audience for TADS. Before we press the nuclear option button, could we discuss, specifically, what is needed to bring these options to Parchment, etc.?

The problem, as I see it, is that multimedia TADS and Glk have fundamentally opposing design philosophies. TADS gives the game author fine-grained control over the formatting and layout of the output, whereas the explicit goal of Glk is to limit the author’s/interpreter’s control over these things and instead leave them up to the Glk implementation and player configuration as much as possible.

Edit: there’s also the aspect that Glk only accepts blorb as a resource file format. Since Tads uses its own resource format, Glk interpreters can’t load images or sounds.

---

@Dannii

TADS 3 always uses HTML TADS in terms of the HTML parser. So when I’ve been talking about implementing HTML TADS I meant using the results of the parser, rather than the reduced minimal text mode. But we can partially use the HTML parser now, which is how @ArdiMaster added monospace support.

It’s even more complicated than that, I think. “Full” HTML TADS interpreters (e.g. QTads) are expected to bring their own HTML parser and receive the marked-up game text from the VM core.

For interpreters that don’t claim HTML support, the VM also contains a minimal HTML parser that only deals with simple formatting like paragraph breaks, bold text, etc. (What you called the “reduced minimal text mode”.) The Glk interface plugs into this part, and this is what I extended to handle monospace support.

[pinkunz]

@ArdiMaster

The problem, as I see it, is that multimedia TADS and Glk have fundamentally opposing design philosophies. TADS gives the game author fine-grained control over the formatting and layout of the output, whereas the explicit goal of Glk is to limit the author’s/interpreter’s control over these things and instead leave them up to the Glk implementation and player configuration as much as possible.

Which I suspect is part of the reason for Dannii’s comment earlier:

@Dannii

There will probably be a point where Glk TADS can switch on most of HTML TADS, but some things may never be possible in Glk TADS.

Afaict, the ideal goal would be to maximize HTML TADS support and to then clearly and emphatically document which remaining features, if any, are beyond standard Glk support. Alternatively, for those remaining features, you could grant that choice to the player:

This game contains features, if implemented, that will limit full user configuration and customization. Conversely, running this game without these features implemented may impact this game's performance. Would you like to run this game with these features implemented? Y/N

Then the player can choose whether they’d like to retain full control over configuration or if they’d prefer to experience the game as originally intended. Preferences will vary and both positions are valid.

ETA: I’d like to point out that’s an idealized hypothetical, and I do not have the expertise to know if that last bit is even possible, let alone the difficulty in making it work.

[Dannii]

@ArdiMaster

“Full” HTML TADS interpreters (e.g. QTads) are expected to bring their own HTML parser and receive the marked-up game text from the VM core.

From my reading of the porting doc, it doesn’t look like the HTML parser needs to be implemented in new terps.

@ArdiMaster

there’s also the aspect that Glk only accepts blorb as a resource file format. Since Tads uses its own resource format, Glk interpreters can’t load images or sounds.

We can construct a temporary blorb, either in memory or in a temp folder. That’s probably the simplest way to support multimedia.

[rpatten (Robert Patten)]

@inventor200

Also—and I’m sorry for making this more convoluted—there are two VS Code extensions for TADS, I believe. Which one were you trying, which didn’t work on Windows?

I was using the Tomas Öberg extension. It defaulted to the location of TADS files on Unix-like systems in its settings. I tried to change it, but I either pointed to a wrong file, or it wouldn’t work with TADS projects it hadn’t created itself. (I was trying to get it to work with something created in Workbench.)

[inventor200 (Joey (Jess) Tanden)]

@inventor200

@pinkunz

@Dannii

Does TADS have alt-texts for images, things like that? While not impossible to implement in Glk TADS, that would be more involved.

I wish I could answer this offhand, but I cannot. I do think, fwiw, that having image alt-text is important for the visually-impaired and many of us, myself included, could do a better job consistently remembering to use it. Hopefully someone more familiar with TADS will chime in and answer this.

I should test this… I’d need to get the workbench installed on my Windows laptop because the HTML TADS interpreter has screen reader support. There’s a chance that alt-text doesn’t break the compiler but it doesn’t get sent to the screen reader.

Results are in. The screen reader can find the content window when alt-tabbing to it, but it’s not reading the text, and I tried several hotkeys to read it all. For context, I’m using Microsoft Narrator on HTML TADS.

However, images in HTML TADS do support alt text. If I hovered over the image, the alt text appeared. At one point, the screen reader caught it and read it out to me, but I’m not sure how I got it to do that.

Honestly, watching me attempt this is probably comical to watch. I have been told that HTML TADS works with a screen reader by a screen reader user before.

---

Okay, I did some poking around, and think I may or may not have found some information that is going to take me a moment to process:

The easiest and most reliable way to use TADS games with screen reader software on Windows is to the use the “DOS box” version of the TADS interpreter. This interpreter is compatible with virtually all TADS games - even games that use HTML TADS features to display graphics. The DOS-box interpreter simply ignores any graphics that the game attempts to display, and removes any special formatting effects, leaving only the plain text. Screen readers have a much easier time with this plain format than with the mixture of formatting and graphics that HTML TADS can display.

From here.

The issue I’m finding is specifically with this:

The DOS-box interpreter simply ignores any graphics that the game attempts to display, and removes any special formatting effects, leaving only the plain text.

Confusion and problems are the following:

1. I have been told that clickable hyperlinks do show up in the screen reader when playing HTML TADS games. Is this not a “special formatting effect”?
2. Sound only plays because an invisible, zero-size, text-based tag gets output to the screen. If you clear the screen, the sounds also stop.
3. Depending on what counts as “special formatting effects”, this might also include sound.

I’ve been doing screen reader tests through Lectrote because I’m on Linux, and have only heard from one tester who uses HTML TADS on Windows with a screen reader, so I’m not working with first-hand personal experience here, but I am very confused. Add onto this that I’m not in a very good headspace as it is; I have a lot to think about right now.

Gawd, what is it like being a person who has been aware of text games for most of the medium’s lifecycle, and not some hermit who only learned what they were around 2010, and only found a community in the last few years? What must it be like to be driven to do things, and have the context and wisdom to follow through clearly?

[BadParser]

@inventor200

Gawd, what is it like being a person who has been aware of text games for most of the medium’s lifecycle…?

I kind of know what that’s like

@inventor200

What must it be like to be driven to do things, and have the context and wisdom to follow through clearly?

That one, not so much

[Doug_Egan]

OK. You people sucked me in with your effective advertising. I’ve downloaded the TADS3 development system.

[johnnywz00 (John Ziegler)]

Welcome, Doug!

[johnnywz00 (John Ziegler)]

Learning TADS 3 is the thing to read first…